☰

как мне установить громкость docker-swarm

tag-icon • tag-icon docker docker-swarm docker-compose
как мне установить громкость docker-swarm

Я планирую перенести docker-compose в docker-swarm для работы с несколькими узлами.

Я использовал docker-composeвот так, как показано ниже

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

хорошо работает для хоста django.

то теперь я пытаюсь использовать docker-swarm.

docker-composeи docker-swarmвыглядят похоже, но есть один вопрос.

Я смонтировал локальные диски вот так

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

  or here

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

Однако в docker-swarm, volumesкак это не работает и служба никогда не запускается.

(Понятно... это понятно, ведь узлов может быть много..)

Думаю, мне следует внести некоторые изменения.

Я погуглил и обнаружил, что есть такие настройки.

services:
  python:
    volumes:
      - src:/code

volumes:
  src:
    driver: local

Однако я не понимаю, как этим пользоваться...

Куда мне поместить исходный код или какой-нибудь файл конфигурации?

Какова наилучшая практика для часто используемых файлов docker-swarm?

решение1

Если вы развертываете образ на нескольких узлах в режиме swarm, исходный код должен находиться внутри вашего образа, и этот образ должен быть отправлен в реестр. Монтирование исходного кода как тома — это метод ускорения процесса разработки, но тестируемый образ должен быть создан с этим исходным кодом, включенным в команду COPYв вашем Dockerfile, чтобы его можно было использовать без монтирования томов.

Поэтому изменение в вашем файле compose заключается в добавлении имен образов, указывающих на ваш собственный репозиторий, желательно с версионными тегами. И тогда каждый образ будет иметь Dockerfile и будет собран и отправлен в реестр перед развертыванием стека.

Обратите внимание, что container_name, depends_on и build недействительны в режиме swarm. Вам нужно будет удалить все зависимости от жестко закодированного имени контейнера (используйте имя службы для обнаружения на основе DNS). В идеале зависимости должны обрабатываться приложением с проверкой подключения с некоторой экспоненциальной отсрочкой до максимального предела или добавлением чего-то вроде скрипта wait-for-it.shв точку входа для проверки доступности зависимостей перед запуском приложения. Сборки обычно перемещаются из файла compose в систему CI/CD. Затем файл compose получает текущее имя тега как переменную из этого инструментария CI/CD.

Для постоянных данных вы бы использовали том, но этот том должен быть в сетевой файловой системе, например NFS, а не в локальной файловой системе по умолчанию, если вы хотите, чтобы данные были постоянными при миграции контейнеров между узлами. Пример этого вмой ответ здесь.

Для обмена данными между контейнерами в кластере Swarm в идеале это делается с помощью сетевых API (например, все микросервисы на основе REST). Вы также можете вынести это на внешний уровень в базу данных, которая либо работает вне Swarm, либо разработана для контейнерной среды (CNCF имеет некоторые из них в своем ландшафте). Вы можете сделать это с тем же решением NFS и монтированием тома, но имейте в виду, что вы можете иметь дело с блокировкой файлов и более высокой задержкой.

Связанный контент