Что включать в Docker-образ

#администрирование #веб_сервер #docker #сборка

Имеется веб-сайт на Django, на боевом сервере для запуска использую связку uWSGI/Nginx,
локальная разработка - virtualenv/dev-сервер Django

Из некоторых вопросов, которые задал на SO:


Распространение Docker-образов 
Запуск Docker-образов на боевом сервере
Запуск сайта из Docker-образа VS запуск c традиционными средствами (uWSGI, Nginx, Apache)


появилось еще пара.

Что включать в образ Docker?

Мы имеем production-версию и developer-версию. Как понимаю, в репозиториях распространяют
production. 

Имеет ли смысл создавать docker-образ для developer-версии (применительно ко мне,
код проекта и виртуальное окружение virtualenv)? Или разработчику достаточно только
кода из репозитория, чтобы начать разработку?

Где создают docker-образ production-версии?

На боевом сервере имеется проект, который работает на указанной связке - uwsgi/nginx/упаковщик
с production-настройками. Собирать образ я должен на боевом сервере?
    

Ответы

Ответ 1

Не должно быть понятия production и non-production версия образа. Разработчики, тестировщики,
эксплуатационники и все остальные должны использовать одну и туже версию образа.

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

Как, где и чем создают docker-образы?

Процесс изготовления образа должен быть полностью автоматизирован, что бы избежать
ошибок и сделать процесс повторяемым.

Приблизительно процесс изготовления образа выглядит так (я опускаю некоторые шаги):


Разработчик дописал код и протестировал его локально, в том числе и сборку образа.
Разработчик заливает код в систему контроля версий.
Робот собирает проект и создает артефакты для развертывания (мнифицирует все, объединяет
в общий пакет и т.п.). 


Необязательный шаг - артефакты помещаются в хранилище. 

Робот собирает docker-образ.


Необязательный шаг - робот подписывает образ.

Робот заливает образ в реестр. 


Если нет специфических требовани, то для управления процессом создания можно использовать
любой Continuous Integration сервер - Jenkins, TeamCity, Bamboo и т.д. У них у всех
есть соответсвующие плагины или можно написать простые шел-скрипты и создавать образы
стандартной командой docker build.

Что включать в docker-образ?

Сложно дать однозначный ответ на этот вопрос, так как многое зависит от типа образа
и личных предпочтений. Я напишу как бы я поступил с сервером на Django.

Я мало работал с Django, так что поправьте меня, если я говорю что-то несоответствующее
действительности.

Если проект только начинается и нагрузка на сервис будет маленькая, то я бы поместил
все (кроме БД) в один образ. Т.е. образ будет содержать:


Python фиксированной версии установленный как системный (без virtualenv и пр)
nginx/Apache фиксированных версий с нужными настройками
собственно ваше приложение, взятое как артефакт для развертывания и развернутое внутри
образа


БД либо в отдельный образ, либо на отдельный сервер без использования контейнерезации.
Если БД идёт отдельным образом, то важно позаботится о сохранении данных на внешний
(по отношению к контейнеру) раздел диска. В противном случае данные будут утеряны при
перезапуске контейнера. 

Если нагрузка будет значительная и есть много статических страниц, то я бы сделал
несколько образов:


Образ со статическими страницами


nginx/Apache
статическая часть вашего приложения

Образ с динамической частью


Python
часть вашего приложения (Django) 

Образ балансировщиком (необязательный)


nginx/HAProxy/Varnish/etc



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