[Ganciodocker] Gancio deploy automatico | Pull request

[matus]

On 11/6/21 11:35, Siroco wrote:
> Quoting matus (2021-06-10 20:55:25)
>> hola gente,
>>
>> tengo un [nuevo pull request][1] para nuestro gancio
>> este es el ultimo de los que tenia en mente
>>
>> [1]: https://git.sindominio.net/gancio/docker-gancio/pulls/4
>>
>> con este, agregamos un nuevo comando a gancio, llamado `deploy`, que nos
>> permite deplegar e iniciar una instancia de gancio configurandola con dos
>> archivos: `config.json` y `.env`.
>>
>> este metodo de instalacion no necesita interaccion con la usuaria (algo que si
>> requere el proceso estandar).
>>
>> con este ultimo cambio, ya estamos listos para automatizar el despliegue de
>> instancias gancio por dentro de sindominio (o otro proveedor de servicios).
>>
>> aun no he participado de estas actividades de despliegues automaticos en
>> sindominio, pero si me invitan, encantado seguimos empunando esto.
>>
>>
>> salute,
> Que bien,
>
> he autorizado el pull y cuando tenga un ratito me lo miro para volcarlo
> a estibadores y probar la instancia en Sindominio. Lo único, en la versión de Estibadorees, voy a añadirle la option de usuario de ejecución
> del container para estantarizarlo con el resto de docker-compose de los
> otros servicios.


este cambio romperia lo que tenemos andando actualmente. os cuento 
porque pienso esto:

tal y como esta, el docker de gancio se inicia y ejecuta el entrypoint 
como `root`, hace unas acciones sobre archivos y permisos, y luego deja 
todo listo para ejecutar el Docker Command como usuaria `gancio`. Con 
esto logramos que el servicio de gancio se ejecute con usuaria no-root 
dentro del docker.

la usuaria gancio se crea durante la construccion del docker (build), y 
la UID se puede gestionar con un parametro que se pasa al proceso de 
build (por defecto 110, definido en el Dockerfile, que creo que es lo 
que usa SD).

ahora, si definimos un `user` dentro del `docker-compose.yml`, esta 
usuaria se utiliza desde el inicio del docker, y por ende ejecuta el 
entrypoint con esta usuaria. como nuestro entrypoint gestiona 
propiedad/permisos de archivos, solo funciona si es ejecutado por `root` 
y por esto no podemos usar esta opcion

si necesitamos el parametro `user` de forma forzosa en nuestro 
`docker-compose.yml`, entonces tenemos que delegar en la persona que 
instale el servicio la gestion de la propiedad y permisos de archivos 
(para lo que, en la mayoria de los casos, necesitara sudo/root en el host).


@siroco, ya nos comentas si el definir el user en el 
`docker-compose.yml` es algo mandatorio o no?


por otro lado, hay un tema tambien con la politica de reinicio de 
dockers que me gustaria entender mejor. me pregunto si hay algun valor 
que se deba usar siempre, para `restart`? por ejemplo, si usamos 
`always`, los servicios se reinician cuando se reinicia el host. si 
usamos `no`, valor por defecto, si un host se reinicia los servicios que 
se ejecutan en docker no lo hacen. esto podria tener un pequeño impacto 
en la forma en la que se haga el script de despliegue, para evitar que 
un docker que no levanta bien entre en loop.


> Pero por el resto, creo que cuando queráis, podemos
> probar de lanzar convoca.la con esta versión.


@fadelkon, estas tambien en la lista de organizacion de convoca.la? ... 
si fuese el caso, nos contas como viene la mano por ese lado?


en el hacklab logout nos interesa tener una instancia propia para seguir 
trasteando. quiza podemos aprovechar y levantar una instancia dentro de 
SD (donde ya tenemos web y codigo) y aprovechar para debuguear esta 
nueva integracion y que quede listo para despliegues desde Lawry?


> Me comentáis y si os animáis, apuntaís el dominio de convoca.la a SD y
> me encargo de configurar los proxies para apuntarlo a Gancio.
>
> src