.
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)
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
#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.
#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
.envque 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
#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.
#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
#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.
#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
#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
#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.
#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 ?