☰

¿Cómo debo configurar el volumen de Docker-Swarm?

tag-icon • tag-icon docker docker-swarm docker-compose
¿Cómo debo configurar el volumen de Docker-Swarm?

Estoy planeando mover docker-compose a docker-swarm para múltiples nodos.

Lo he usado docker-composeasí a continuación.

version: '3'
services:
  python:
    container_name: python
    build: ./python
    command: uwsgi --socket :8001 --module myapp.wsgi --py-autoreload 1 --logto /tmp/mylog.log
    volumes: 
      - ./src:/code
      - ./src/static:/static
    ports:
      - "8082:8082"
    expose:
      - "8001"
  nginx:
    image: nginx:1.13
    container_name: nginx
    ports:
      - "8000:8000"
    volumes:
      - ./nginx/conf:/etc/nginx/conf.d
      - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params
      - ./static:/static
    depends_on:
      - python

Funciona bien para el host Django.

entonces ahora estoy intentando usar docker-swarm.

docker-composey docker-swarmse parecen, pero hay una pregunta.

Monté las unidades locales así.

  - ./src:/code
  - ./src/static:/static 

  or here

  - ./nginx/conf:/etc/nginx/conf.d
  - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params
  - ./static:/static

Sin embargo, en docker-swarm, volumesesto no funciona y el servicio nunca se inicia.

(Ya veo... es comprensible, porque puede haber muchos nodos...)

Creo que debería hacer algunos cambios.

Busqué en Google y descubrí que hay algunas configuraciones como esta.

services:
  python:
    volumes:
      - src:/code

volumes:
  src:
    driver: local

Sin embargo, no entiendo cómo usar esto...

¿Dónde debería poner mi código fuente o algún archivo de configuración?

¿Cuál es la mejor práctica para archivos usados ​​comunes de Docker-swarm?

Respuesta1

Si está implementando una imagen en varios nodos en modo enjambre, el código fuente debe estar dentro de su imagen y esa imagen debe enviarse a un registro. Montar el código fuente como un volumen es un método para acelerar el proceso de desarrollo, pero la imagen que se está probando debe crearse con ese código fuente incluido con un COPYcomando en su Dockerfile para que pueda usarse sin los montajes del volumen.

Por lo tanto, el cambio en su archivo de redacción es agregar nombres de imágenes que apunten a su propio repositorio, preferiblemente con etiquetas versionadas. Y luego, cada imagen tendrá un Dockerfile y se creará y enviará al registro antes de implementar la pila.

Tenga en cuenta que nombre_contenedor, depende_de y compilación no son válidos en modo enjambre. Deberá eliminar cualquier dependencia de un nombre de contenedor codificado (use el nombre del servicio para el descubrimiento basado en DNS). Idealmente, las dependencias deberían ser manejadas por la aplicación con una prueba de conectividad con algún tipo de retroceso exponencial hasta un límite máximo, o agregando algo como el wait-for-it.shscript al punto de entrada para verificar que las dependencias estén disponibles antes de iniciar la aplicación. Las compilaciones normalmente se sacan del archivo de redacción y se colocan en un sistema CI/CD. Luego, el archivo de redacción recibe el nombre de la etiqueta actual como una variable de esa herramienta CI/CD.

Para datos persistentes, usaría un volumen, pero ese volumen debe estar en un sistema de archivos de red como NFS, en lugar del sistema de archivos local predeterminado, si desea que los datos sean persistentes cuando los contenedores migren entre nodos. Un ejemplo de esto está enmi respuesta aquí.

Para compartir datos entre contenedores en un clúster de enjambre, lo ideal es hacerlo con API de red (por ejemplo, todos los microservicios basados ​​en REST). También puede externalizar eso a una base de datos que se ejecuta fuera del enjambre o está diseñada para un entorno de contenedor (CNCF tiene algunos en su entorno). Podría hacer esto con la misma solución NFS y un montaje de volumen, pero tenga en cuenta que puede estar lidiando con bloqueo de archivos y una mayor latencia.

información relacionada