[Ganciodocker] Gancio deploy automatico | Pull request

[Siroco]

Quoting matus (2021-06-11 12:29:50)
> 
> 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?

Si,
pero por eso, de este Gancio más universal y adaptado para cualquier
otro servicio de docker, hago una versión específica del docker-compose para estibadores y
así no generamos confusión con este asunto en este repositorio, que me
parece que está muy bien pensado como lo has realizado tu.

En la máquina donde lanzamos los ervicios para SD, tenemos acceso a Root
y daremos los permisos manualmente, como hacemos con otros servicios. 

> 
> 
> 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.
> 

Nosotr_s solemos mantenerlo en "always" para gestionarlo como servicios
del systemctl. Por mi, lo definiría con "always".

> 
> > 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?
> 

No tenemos maquinas para levantar instancias en pruebas por usuarias
fuera de la asamblea de Sindominio, tenemos algun testbed pero solo
usamos las admins para checkear nuevas herramientas... Podemos si eso
hacer alguna petición a algun colectivo cercano a ver si os pueden
ofrecer una maquina para debugear vuestras propios códigos.

> 
> > 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
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: </pipermail/ganciodocker/attachments/20210611/9e585e5c/attachment.sig>