Muchas instrucciones de Internet describen un cierto mínimo de acciones y, como resultado, un mínimo de comandos y capacidades.
Decidí hacer una selección de características poco iluminadas, características. El artículo no pretende ser único, me ayudará como recordatorio, y tal vez ayude a algunos Padawans a comenzar su viaje con docker-compose.
Uso de múltiples archivos docker-compose.yml
Hay configuraciones complejas, donde hay una cierta capa básica de contenedores, que, por ejemplo, siempre es necesaria. Y generalmente sucede que tomamos del equipo vecino \ otro proyecto \ Internet y lo terminamos según sus necesidades. Pero si hay varios comandos, la parte básica se puede mover a un repositorio interno común. Y obtenemos una parte base idéntica para la mayoría de los proyectos, que también está versionada.
Describamos un ejemplo de un docker-compose-base.yml básico.
Supongamos que se trata de una imagen nginx personalizada con certificados, ajustes y métricas. Y exportador de prometeo:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
Ahora describimos un ejemplo de nuestra aplicación docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2
Para comenzar, necesitamos el equipo habitual con una diferencia. Indicaremos 2 archivos docker-compose:
docker-compose up -d -f docker-compose-base.yml -f docker-compose-app.yml
¡Y listo, obtenemos un conjunto de servicios, como si estuvieran descritos en un solo archivo de compilación acoplable!
También hay una segunda opción para usar múltiples archivos, mediante el uso de la directiva extend.
docker-compose-base.yml:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2 ### web: extends: # ( ) file: docker-compose-base.yml # service: nginx web-exporter: extends: file: docker-compose-base.yml service: nginx-exporter
Complemento de iSlava :
Puede describir todos los archivos de composición en variables de entorno y utilizar docker-compose up -d sin especificar archivos manualmente:
COMPOSE_PATH_SEPARATOR=: COMPOSE_FILE=docker-compose-base.yml:docker-compose-app.yml
Qué opción elegir: usted elige. Todo individualmente, solo quería mostrar opciones =)
Herencia en docker-compose
El siguiente ejemplo requiere la versión docker-compose > = 2.4
También es una característica bastante interesante, y de hecho se mencionan pocos.
Esta funcionalidad nos permite describir varios servicios del mismo tipo en el archivo docker-compose, sin duplicar su descripción, es decir, heredar.
Por ejemplo, tenemos un archivo como este:
version: '2.4' services: backend: image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Y era necesario levantar varios contenedores, pero con algunas diferencias, por supuesto, podemos "ahorrar" y cambiar, pero podemos hacer esto:
version: '2.4' services: backend: &base-app # image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend-2: <<: *base-app # ports: # - 8081:8080
Por lo tanto, tenemos la oportunidad de cambiar en un lugar, que editar en la descripción de cada contenedor.
Hay otra opción para moverse al área raíz, por ejemplo:
version: '2.4' services: x-backend: # "x-" , . &base-app image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend: <<: *base-app # backend-2: <<: *base-app # ports: # - 8081:8080
Límites de recursos
A partir de la versión 2.2, puede usar límites de recursos para contenedores, de hecho, desde la versión 2.1, pero todavía no se entregan todos =)
Hay un matiz! ¡En la versión 3, estas características se eliminan! Ya hay un énfasis en el enjambre de docker.
El ejemplo más simple de limitación de recursos de CPU, MEM:
version: '2.2' services: backend: cpus: 1.5 # . cpuset: '0,3' # . mem_limit: 1gb # 1 memswap_limit: 2gb # SWAP . oom_kill_disable: true # , OOM Killer , . image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Empaquetar imágenes en un archivo
Desafortunadamente, no siempre es posible insertar imágenes en su propio registro de acoplador en la nube. A veces es necesario recopilar imágenes de un archivo de composición acoplable y enviar, por ejemplo, un archivo de almacenamiento. Las manos lo hacen a veces mucho tiempo, así que dibujé un guión simple, de repente alguien es útil:
#!/bin/bash dc=${1} if [ ! -z ${dc} ] && [ -f ${dc} ]; then echo "Saving docker images from file ${dc}..." images=`grep image: ${dc} | awk '{print $2}'` docker save ${images} | gzip > docker-images.gz echo "Success!" else echo "ERROR! You must set path to docker-compose.yml as argument!" fi
Guardar en el archivo decir docker-compose-images-save.sh
Le damos el derecho de ejecutar:
chmod +x docker-compose-images-save.sh
Lo iniciamos y pasamos la ruta al archivo docker-compose como argumento:
./docker-compose-images-save.sh /home/some_user/docker-compose-app.yml
En la salida, llegamos a la carpeta desde donde se llamó el archivo de script con imágenes - docker-images.gz
Cualquier forma que podamos enviar a un servidor remoto.
Ahora en el servidor remoto es suficiente para ejecutar:
gzip -cd docker-images.gz | docker load
Todas las imágenes se cargarán en el registro local, después de lo cual puede ejecutarlas aquí de forma segura.
docker-compose up -d , ya que todas las imágenes están en el registro local en Internet, docker no entrará en él.
Reenviar IPv6
En ciertas tareas, ipv6 puede ser extremadamente útil, tome al menos el matiz de que Roskomnadzor pasa todo el tráfico a través de ipv6 sin problemas, y el mismo bot de telegramas funciona sin problemas.
Consideraré una situación en la que ipv6 no está en su máquina, ya sea una máquina virtual o un servidor en Internet.
Asegúrese de que el nivel de sistema ipv6 esté habilitado:
sysctl net.ipv6.conf.all.disable_ipv6
El valor debe ser 0, si no, cambie:
sysctl -w net.ipv6.conf.all.disable_ipv6=0
Instale miredo (este es un servicio con una VPN incorporada al servidor que nos dará IPv6 pública)
apt-get install miredo -y
Verifique que el servicio se esté ejecutando:
systemctl status miredo
Verificamos que recibimos la dirección ipv6:
ifconfig teredo
Escribimos en /etc/docker/daemon.json
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
Reinicia la ventana acoplable:
systemctl restart docker
Bueno, queda por habilitar NAT para ipv6 para que las direcciones internas de nuestro contenedor puedan llegar al mundo exterior a través de nuestra interfaz teredo:
ip6tables -t nat -A POSTROUTING -o teredo -j MASQUERADE
Levantamos el contenedor docker que necesitamos, y se puede publicar a través de la dirección ipv6.
El ejemplo anterior con sysctl e iptables funcionará hasta que se reinicie, si necesita hacerlo de forma continua, debe consultar las instrucciones para su distribución, hay diferencias.
Espero que alguien haya proporcionado la información aquí será útil.