Dockerizando apps +no-tutorial

B

.

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
B

.

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
D

#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
B

.

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.

D

#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
B

.

D

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

B

.

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
B

.

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
B

.

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.

B

.

1 respuesta
wdaoajw

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

1 respuesta
B

.

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
B

.

B

.

Usuarios habituales