Что включать в 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-настройками. Собирать образ я должен на боевом сервере?

Ответ

Не должно быть понятия 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 к своей части проекта.