docker-compose та же конфигурация для dev и production, но разрешить совместное использование кода между хостом и контейнером только в разработке - PullRequest
Новая
       18

docker-compose та же конфигурация для dev и production, но разрешить совместное использование кода между хостом и контейнером только в разработке

0 голосов
/ 14 января 2019

Поскольку наиболее важным преимуществом использования docker является сохранение одинаковых dev и prod env, давайте исключим возможность использования двух разных docker-compose.yml

Допустим, у нас есть приложение Django, и мы используем gunicorn для обслуживания, и у нас есть выделенный apache2 в качестве обратного прокси-сервера (этот apache2 не предназначен для работы с докером). Таким образом, это приложение (docker-compose) состоит только из двух частей: web (Django) и db (mysql). Там нет ничего плохого в части БД.

Для части Django подпрограмма dev без докера будет использовать venv и python3 manage.py runserver или любой другой ярлык, который предоставляет IDE. Мы можем с радостью изменить наш код, а сервер разработки умен, чтобы его можно было быстро собрать и изменить, и он быстро задумался.

Ситуация усложняется, когда приходит docker, так как весь исходный код должен быть упакован в образ, это дает нашему разработчику большие затраты на воссоздание изображения и контейнера снова и снова. Можно было бы найти следующие решения (которые я нашел не элегантным):

  • В docker-compose.yml используйте том для монтирования папки с исходным кодом в контейнер, чтобы все изменения в папке с исходным кодом хоста автоматически отражались в контейнере, тогда gunicorn получит изменение и отразит. --- Это устраняет большую часть затрат на воссоздание контейнера, но мы не можем использовать тот же docker-compose.yml в производственном процессе, поскольку это вводит зависимость от исходного кода на хост-сервере.

  • Я знаю, что есть опция командной строки для монтирования папки хоста в контейнер, но, насколько мне известно, эта опция существует только в docker run, а не docker-compose. Таким образом, использование другой команды для перевода службы в другую среду является еще одним тупиком. ( Я не уверен на 100% в этом, так как я все еще новичок в докере, пожалуйста, поправьте меня, если я не прав )

TLDR; Как я могу настроить свой env так, чтобы

  • Я использую только один docker-compose.yml как для разработчика, так и для продукта
  • Я могу легко разрабатывать живые изменения, не воссоздавая Docker-контейнер

Большое спасибо!

Ответы [ 2 ]

0 голосов
/ 14 января 2019

Определите свой сервис django в docker-compose.yml как 

services:
  backend:
    image: backend

Затем добавьте файл для dev: docker-compose.dev.yml

services:
  backend:
    extends:
      file: docker-compose.yml
      service: backend
    volume: local_path:path

Чтобы запустить для прод, просто docker-compose up

Запустить для разработчика docker-compose -f docker-compose.yml -f docker-compose.dev.yml up

Чтобы перезагрузить приложение dev django, просто перезагрузите gunicorn ps aux | grep gunicorn | grep greencar_proj | awk '{ print $2 }' | xargs kill -HUP

0 голосов
/ 14 января 2019

Мне также понравилось использовать как можно больше функций в одном файле docker-compose.yml. Несколько стратегий, которые я бы рассмотрел:

  1. определить различные сервисы для prod и dev. Таким образом, вы запустите docker-compose up dev или docker-compose up prod или docker-compose run dev. Здесь есть некоторое копирование, но обычно не много.

  2. Используйте несколько файлов docker-compose.yml и объедините их. например: docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d. Подробнее здесь: https://docs.docker.com/compose/extends/

Обычно я просто комментирую раздел томов, но это, вероятно, не лучшее решение.

...