usar tutorial hub dockers crear contenedor container compose como deployment web-deployment docker

deployment - tutorial - dockers container download



¿Cómo editar código en un contenedor Docker en desarrollo? (5)

Descubrí que la mejor manera de editar código en desarrollo es instalar todo como siempre (incluida la clonación del repositorio de su aplicación), pero mueva todo el código en el contenedor para decir /srv/myapp.deploy.dev . A continuación, inicie el contenedor con un volumen rw para /srv/myapp y un script init.d que limpie ese volumen y copie los nuevos contenidos en el interior de esta manera:

rm -r /srv/myapp/* rm -r /srv/myapp/.[!.]* cp -r /srv/myapp.deploy.dev/. /srv/myapp rm -r /srv/myapp.deploy.dev

Tengo el código de todos mis sitios web en /srv en mis contenedores.

My Dockerfile descarga el código usando git y lo hace parte de la imagen para una implementación más fácil a la producción.

Pero entonces, ¿cómo edito el código en desarrollo? Pensé que usar volúmenes era la solución, por ejemplo: -v /docker/mycontainer/srv:/srv . Pero sobrescribe el directorio en el contenedor. Si es la primera vez que lo ejecuto, lo vacía porque no hay nada en el host. Entonces todo lo que hice en el archivo Dockerf se perdió.

También hay directorios y archivos dentro de /srv/myapp que quiero compartir entre las diferentes versiones de mi aplicación, por ejemplo: /srv/myapp/user-uploads . Esta es una práctica común en el desarrollo web profesional.

Entonces, ¿qué puedo hacer para poder hacer todas estas cosas ?:

  • editar código en / srv en desarrollo
  • share / srv / myapp / user-uploads en diferentes versiones
  • deja que Dockerfile descargue el código. Hacer "git clone" o "git pull" fuera de Docker vencería el propósito de Docker en mi opinión. Además, hay cosas que no puedo ejecutar en el host, como las migraciones de la base de datos u otras secuencias de comandos específicas de la aplicación.

¿Hay alguna manera de hacer un montaje de volumen inverso? Me refiero a hacer que el contenedor sobrescriba al host, en lugar de hacer lo contrario.

Estoy pensando que una solución podría ser copiar / srv en /srv.deployment-copy antes de ejecutar el daemon del contenedor. Y luego, cuando ejecuto el daemon, compruebo si /srv.deployment-copy existe y copio todo a / srv. De esta forma puedo usar / srv como un volumen y aún ser capaz de implementar código en él con Dockerfile. Ya estoy usando alias para todos los comandos de Docker, así que automatizar esto no será un problema. ¿Qué piensas?


Encontré una buena manera de hacerlo usando solo git:

CONTAINER=my_container SYNC_REPO=/tmp/my.git CODE=/var/www #create bare repo in container docker exec $CONTAINER git init --bare $SYNC_REPO #add executable syncing hook that checks out into code dir in container printf "#!/bin/sh/nGIT_WORK_TREE=$CODE git checkout -f/n" | / docker exec -i $CONTAINER bash -c "tee $SYNC_REPO/hooks/post-receive;chmod +x /$_" #use git-remote-helper to use docker exec instead of ssh for git git remote add docker "ext::docker exec -i $CONTAINER sh -c %S% $SYNC_REPO" #push updated local code into docker git push docker master

Supone que tienes un git local con el código. Git necesita ser instalado en contenedor. Alternativamente, probablemente podría usar la docker run y un contenedor de datos con un volumen compartido con git instalado.


Hay otra forma de iniciar el contenedor con el volumen de otro contenedor:

Mira https://docs.docker.com/userguide/dockervolumes/
Crear y montar un contenedor de volúmenes de datos

Si tiene algunos datos persistentes que desea compartir entre contenedores, o desea utilizarlos desde contenedores no persistentes, es mejor crear un contenedor de volúmenes de datos con nombre y luego montar los datos desde él.

Vamos a crear un nuevo contenedor con nombre con un volumen para compartir.

$ sudo docker run -d -v /dbdata --name dbdata training/postgres echo Data-only container for postgres

Luego puede usar el indicador --volumes-from para montar el volumen / dbdata en otro contenedor.

$ sudo docker run -d --volumes-from dbdata --name db1 training/postgres

Y otro:

$ sudo docker run -d --volumes-from dbdata --name db2 training/postgres

Otra función útil que podemos realizar con volúmenes es usarlos para copias de seguridad, restauraciones o migraciones. Hacemos esto usando el indicador --volumes-from para crear un contenedor nuevo que monte ese volumen, de esta forma:

$ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

=============

Creo que no deberías usar el montaje de tu directorio de host en un contenedor. Pero puedes usar volúmenes con todos sus poderes. Puede editar archivos en volúmenes utilizando otros contenedores con un conjunto perfecto de sus editores y herramientas. Y contenedor esta su aplicación estará limpia sin gastos generales.

La estructura es:
-) Contenedor para datos de la aplicación
docker run -d -v /data --name data
-) Contenedor para binarios de aplicaciones
docker run -d --volumes-from data --name app1
-) Contenedor para editores y utilidades para desarrollo
docker run -d --volumes-from data --name editor


Nota: no puede montar el directorio del contenedor en el directorio del host con -v .

No creo que deba manipular / srv y /srv.deployment-copy. Si tu

Creo que:

  • Debe usar el volumen para datos persistentes / compartidos: -v /hostdir/user-uploads:/srv/myapp/user-uploads , o puede usar el concepto de contenedor de volumen de datos . Puede considerar esto como una base de datos respaldada por el sistema de archivos que está almacenada en el host (solo contenedor de datos) y el contenedor puede usarla por -v .

  • Estás en lo cierto: para la implementación de producción : puedes construir la imagen con el código fuente ( git clone ), creas una imagen para cada lanzamiento. No debería haber necesidad de editar el código fuente en producción.

  • para el entorno de desarrollo : debe compilar la imagen sin código fuente o puede sombrear el directorio del código fuente con el volumen en caso de utilizar la misma imagen para la implementación / desarrollo. Luego git clone el código fuente localmente y use el volumen -v /hostdir/project/src:/srv/project para compartir el código fuente con el contenedor. Preferiblemente, debe compartir el código fuente de solo lectura ( :ro al final) y cualquier archivo temporal o intermedio debe almacenarse en otro lugar en el contenedor. Tengo scripts de configuración (migración de datos, reconstrucción de algunos archivos de datos de caché / índice, etc.) ejecutados en el inicio del contenedor, antes del inicio del servicio. Entonces, cada vez que siento que necesito un nuevo re-init , simplemente elimino el contenedor dev y lo ejecuto de nuevo. O bien, no detengo el contenedor anterior, solo ejecuto otro.


Suponiendo que git no es el punto de entrada del contenedor, si git está instalado en su contenedor, puede ingresar al contenedor y ejecutar git clone / git pull . Debido a la forma en que se comparte el volumen con el host, los cambios realizados desde el contenedor a los archivos se realizarán también en el host (realmente son los mismos archivos).

Here hay una explicación de cómo rápidamente ssh en un contenedor.