Dockerizando apps +no-tutorial

KazuluDev

Planteo mi idea.

Tengo un bot de Telegram que se ejecuta con Docker Compose en dos contenedores. Quiero automatizar un poco todo, así que tenía pensado:

  • Github Actions para validar push y pull request.
  • Buildea la imagen del Compose y la sube a Github Hub.
  • En la Raspberry, Portainer detecta el update y actualiza la imagen que está funcionando.

Mis dudas son, ahora mismo estoy pasando el token como "environment" en el docker-compose.yml. ¿Cuál es la mejor forma que se os ocurre para manejar el token del bot de telegram en este caso?

https://github.com/kazulu/el-paraguas-bot

El bot ahora mismo está usando un fichero de configuración donde hay que poner el token.

HeXaN

Parámetro en el yaml del compose y a otra cosa.

1 respuesta
sharker

Environment variable que pueda leer el docker container y que puedes especificar mediante docker run -e directamente, o ya que usas docker compose, mediante https://docs.docker.com/compose/environment-variables/

Luego puedes definir esa environment variable como secret de Github y a correr (o en el cloud provider que tengas de turno de manera segura si lo despliegas a producción desde otro sitio)

1 respuesta
KazuluDev

#2 #3 Estoy teniendo un problema con eso, es decir, tengo una versión funcionando con parámetro en el yaml, pero eso no sé traducirlo a Docker Hub.

Pregunta tonta pero no estoy encontrando respuesta, ¿es posible generar una imagen con docker compose y subirla a Docker Hub empaquetando los dos contenedores de Python y MongoDB?

O quizás sea mejor pasar de Docker Hub y desplegar el Compose directamente en la Raspberry...

2 respuestas
andoni013

Siendo que es un bot "para tus cosas", pasa de DockerHub y despliega con el compose directamente en la Raspberry.

Porque si vas a usarlo solo tu, para que quieres subir la imagen a DockerHub?

PD: Igualmente nunca he usado portainer, pero seguro que tiene alguna forma de dejarle configurado las variables de entorno y asi mantienes el despliegue automatico cada vez que mandes la imagen a DockerHub, si eso es lo que quieres

1 1 respuesta
DiSKuN

#4 Tenerlo en Docker Hub es como tenerlo en un repo de git. Al final es eso, un repo para acceder a la imagen de docker. Si es para ti únicamente, no es necesario.

2 respuestas
KazuluDev

#6 en principio si es para mí, puede usarlo quien quiera pero dudo que alguien quiera la verdad xDDD

sharker

#4 despliégalo en tu Raspberry y pon la variable de entorno directamente allí (.env file, .bashrc o .zshrc, como quieras pero que solo sea visible desde la cuenta que ejecuta tu aplicación, y que esa cuenta esté protegida).

Pregunta tonta pero no estoy encontrando respuesta, ¿es posible generar una imagen con docker compose y subirla a Docker Hub empaquetando los dos contenedores de Python y MongoDB?

Esto no es para lo que docker hub está hecho, ya estás hablando un poco a nivel de orquestación y tendrías que irte a nivel de docker swarm o Kubernetes, que no es una complejidad que necesitas. Tu docker compose es algo que mantienes en tu repo, y las imágenes de docker son abstractas que cualquiera debería de usar. Tienes muchas maneras de desplegar realmente, pero en tu caso lo que yo haría

  • Tendría en mi repo el docker-compose de manera abstracta (puede ser público), los docker images que usa si están en docker hub ya, mejor. Si tengo que tener algún image específico, lo tendría en el repo pero no es tu caso. Ese docker-compose va a automáticamente cargar las variables de entorno definidas en los containers
  • Instalar docker (y compose) en tu raspberry pi, checkout del repo (que es público) y meter los secrets en un archivo llamado .env que tenga permisos restringidos y de owner el usuario que ejecuta docker (root no): https://docs.docker.com/compose/environment-variables/#the-env_file-configuration-option

Esa seria una opción sencilla y que te vendría bien

JuAn4k4

Tenerlo den docker hub te evita tener el código y tener que compilar en la rasp. Ni caso a #5 y #6

¿Qué problema tienes exactamente? Puedes usar el mismo compose que en local quitando la parte de build.

El env es lo correcto, dado que evitas tener volumenes montados (salvo para el mongo).

3 respuestas
andoni013

#9 y cual es el problema de tener el código o "compilar" la imagen en las raspberry?

Que estamos hablando de un proyecto pequeño, casero y en python... Casi que hasta mejor tener el código en la raspberry por si se quiere probar algún cambio rápido en caliente. Y viendo el proyecto, va a tardar nada en buildearse la imagen.

DiSKuN

#9 en ningun momento digo que no lo suba. Solo que para este caso, no es algo necesario.

Pero vaya, no deja de ser 2 comandos mas

eXtreM3

Las ideas de Kazulu tienen menos futuro que el blog de desu.

1 1 respuesta
JuAn4k4

Yo creo que es una buena forma de empezar con ci/cd sinceramente

3 1 respuesta
KazuluDev

#13 para eso es el proyecto, al final el bot como veis no hace más que soltar memes del grupo que nadie más entiende, el reto era aprender eso y Python, que no tenía ni idea.

He dejado cosas a medias, ahora llego a casa intento lo que tenía en mente y actualizo.

DiSKuN

Luego todo esto se complica infinito cuando entramos en la orquestración de microservicios xD

KazuluDev

#9 Pues había leido en Reddit que sí se podía subir la imagen generada de hacer docker-compose build pero al parecer ojeando la imagen que crea, solo coge uno de los dos contenedores, el de Python al ser la única que construyo yo con Dockerfile, cagada, no era lo que esperaba.

Estaba ojeando ahora Portainer, y puedo crear un "stack" que basicamente es un Compose que puedo escribir ahí mismo, subir o seleccionar un repositorio. Así que voy a probar de momento a hacerlo así y para aprender Github Actions voy a intentar automatizar la creación del container de Python por ejemplo.

#12 Cabrón, que el otro proyecto si lo terminé xDD

EDIT: Mi gozo en un pozo, no acepta Compose v3.

2 respuestas
wdaoajw

#16 usa variables a la hora de taggear la imagen que generas y añades esa variable al compose, de forma que cada vez que hagas el docker-compose Up actualice a la última imagen que hayas generado.

1 respuesta
KazuluDev

#17 no he entendido esto

2 respuestas
aren-pulid0

#18 no estoy seguro, pero creo que cuando subes una imagen a docker hub, lleva unos tags del palo posgres:12.0.0.
Si haces lo mismo y pones posgres:latest creo que va pillando la ultima versión de posgres cada vez que haces un build

2 respuestas
KazuluDev

#19 ah vale, sisi, pero eso se pone por defecto si no escribes nada

wdaoajw

#18 entiendo que por un lado generas la nueva imagen de docker de alguna forma, pues a esa imagen la llamas "imagen:$var", de esta forma en el compose puedes añadir esa misma variable $var en la imagen del servicio y pasar la variable como argumento al lanzar la orden docker-compose Up.

Y como tienes (o eso he entendido) un flujo de CI/CD tienes la variable $var controlada en todo momento

1 respuesta
wdaoajw

#19 ojo con usar el tag latest. Si no haces un docker pull previo nunca actualizará esa imágen en el host y además siempre sobreescribiras la anterior en el registry. Y en entornos más complejos (aka kubernetes) solo es un dolor de cabeza.

KazuluDev

#21 ahora no tengo CI/CD ni creo imagenes, esto último fue una idea que no está saliendo bien y posiblemente descarte

1 respuesta
wdaoajw

#23 entonces no te líes y pásalo como variable de entorno como te dicen por arriba

1 respuesta
KazuluDev

#24 si, eso es fácil, el problema es que no sé hacia donde tirar de cara a automatizar un poco todo

JuAn4k4

#16 Con docker-compose build te hace la build de todas las imagenes que tienen "build" context, las demás, esta usando una imagen ya subida a un docker-hub, probablemente público. Creo que piensas que docker-compose te junta todo en un docker-image y no es así, simplemente te levanta varios containers en una red compartida configurando cada container según el yml con la sintaxis de docker-compose.

RasperriPi no acepta docker-compose v3 ? O te refieres a github actions ?

1 respuesta
KazuluDev

#26 Exacto, eso pensaba al principio pero ya veo que no.

Portainer no acepta v3, pero bueno, no es mucho problema.

Actualmente he conseguido crear una Action para que en push o pr a master, haga build y lo suba a Docker Hub.

El problema con el que me he encontrado, fallo mío no mirarlo, la imagen de Docker no acepta armv7, así que no va a funcionar en la Raspberry.

Tengo cuenta con free tier en la nube de Oracle y creo que me da acceso a dos servers básicos. Así que voy a probar con un server real.

KazuluDev

Me he pasado a usar el server de Oracle que ofrece dos instancias gratis para siempre jamás. No es gran cosa pero para estos bots de sobra.

Ahora mismo lo que hace es en push o pull request a master, buildea la imagen de Python y la sube a Docker Hub.

Problemas actuales y posibles soluciones:

  • La imagen que subo a Docker Hub actualmente requiere tener el repositorio descargado ya que copia el código con COPY, creo que es mejor solución descargar el código del repositorio al momento de generar el contenedor, investigaré si puedo meter el código dentro de la imagen al momento de buildear para que no haga falta ni copiar ni descargar al crear el contenedor.

  • El despliegue en el servidor no es automático, tengo que entrar, parar el contenedor y borrarlo, actualizar la imagen y volver a levantar el Compose, para actualizar la imagen existe una imagen que actualiza tus imagenes cuando se actualizan, para todo lo demás, quizás sea posible hacerlo mediante una Action.

  • La base de datos no tiene backups, había pensado generar un contenedor auxiliar en el Compose que se encargase de esto, simplemente una imagen de Linux Alpine por ejemplo con un Cron que haga el backup y lo envíe a otro sitio, no sé a donde pero algo así será.

Usuarios habituales

  • KazuluDev
  • JuAn4k4
  • wdaoajw
  • aren-pulid0
  • DiSKuN
  • andoni013
  • sharker