Hacemos una verificación exhaustiva cada artículos en nuestra web con la meta de mostrarte en todo momento información con la mayor veracidad y certera.
Solución:
Creo que mirar ejemplos que son fáciles de entender podría darle la mejor imagen.
Lo que quiere hacer es perfectamente válido, una imagen debe ser cualquier cosa que necesite ejecutar, sin la configuración.
Para generar la configuración, puede:
a) montajes de volumen
use volúmenes y monte el archivo durante el inicio del contenedor docker run -v my.ini:/etc/mysql/my.ini percona (y similar con docker-compose). Tenga en cuenta que puede repetir esto tantas veces como quiera, así que monte varias configuraciones en su envase (así que la versión de tiempo de ejecución de la imagen). Creará esas configuraciones en el host antes de ejecutar el contenedor y deberá enviar esos archivos con el contenedor, que es la desventaja de este enfoque (portabilidad)
b) configuración basada en el punto de entrada (generación)
La mayoría de las imágenes acoplables avanzadas proporcionan un llamado punto de entrada complejo que consume las variables ENV que pasa al iniciar la imagen, para crear las configuraciones para usted, como https://github.com/docker-library/percona /blob/master/5.7/docker-entrypoint.sh
así que cuando ejecutas esta imagen, puedes hacer docker run -e MYSQL_DATABASE=myapp percona y esto iniciará percona y creará la base de datos percona para usted. Todo esto es hecho por
- agregando el script de punto de entrada aquí https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L65
- no olvide copiar el script durante la creación de la imagen https://github.com/docker-library/percona/blob/master/5.7/Dockerfile#L63
- Luego, durante el inicio de la imagen, su variable ENV hará que esto se active: https://github.com/docker-library/percona/blob/master/5.7/docker-entrypoint.sh#L91
Por supuesto, puedes hacer lo que quieras con esto. Por ejemplo, esto configura una imagen de portus general: https://github.com/EugenMayer/docker-rancher-extra-catalogs/blob/master/templates/registry-slim/11/docker-compose.yml que tiene este punto de entrada https:/ /github.com/EugenMayer/docker-image-portus/blob/master/build/startup.sh
Como puede ver, la estrategia del punto de entrada es muy común y muy poderosa, y supongo que debe seguir esta ruta siempre que pueda.
c) Imágenes derivadas
Tal vez para “completar”, la estrategia de derivación de imágenes, por lo que tiene su imagen base llamada “myapp” y para la instalación X crea una nueva imagen
from myapp
COPY my.ini /etc/mysql/my.ini
COPY application.yml /var/app/config/application.yml
Y llame a esta imagen myapp:x: el problema obvio con esto es que termina teniendo muchas imágenes, por otro lado, en comparación con a) es mucho más portátil.
Espero que ayude
Simplemente ejecute desde la misma imagen tantas veces como sea necesario. Se crearán nuevos contenedores y luego se podrán iniciar y detener cada uno guardando su propia configuración. Para su comodidad, sería mejor dar a cada uno de sus contenedores un nombre con “–name”.
fi:
docker run --name MyContainer1
docker run --name MyContainer2
docker run --name MyContainer3
Eso es todo.
$ docker ps
CONTAINER ID IMAGE CREATED STATUS NAMES
a7e789711e62 67759a80360c 12 hours ago Up 2 minutes MyContainer1
87ae9c5c3f84 67759a80360c 12 hours ago Up About a minute MyContainer2
c1524520d864 67759a80360c 12 hours ago Up About a minute MyContainer3
Después de eso, tiene sus contenedores creados para siempre y puede iniciarlos y detenerlos como máquinas virtuales.
docker start MyContainer1
Cada contenedor se ejecuta con la misma imagen RO pero con una capa de sistema de archivos específica del contenedor RW. El resultado es que cada contenedor puede tener sus propios archivos que son distintos de cualquier otro contenedor.
Puede pasar la configuración en la CLI, como una variable de entorno o como un montaje de volumen único. Es un caso de uso muy estándar para Docker.
Si te gusta el asunto, tienes la opción de dejar una sección acerca de qué te ha gustado de este ensayo.