Docker, обновить изображение или просто использовать bind-mounts для кода сайта?

Question

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

В нашем случае есть два типа кодов, первый из которых представляет собой код Python (выполняется в Django), идругие - статические файлы (html / js / css)

Я мог бы опубликовать новое изображение, когда в любом коде произошли изменения.
Или я мог бы использовать bind mounts для кода.(Для django мы могли бы связать и смонтировать корневой каталог проекта и статический каталог)

Если я использую bind mounts для кода, я мог бы просто обновить рабочую машину (возможно, с git pull), когда произойдет изменение кода.

Затем образ Docker будет обрабатывать обновления, которые не являются строго нашими собственными изменениями кода.(например, обновление библиотеки или новые настройки, такие как настройкаasticsearch).

Означает ли этот подход какой-либо очевидный недостаток?

Answer 1

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

Я бы предложил три веских причины сделать это следующим образом:

1. Если у вас есть воспроизводимый путь к docker buildСодержимое изображения, каждый может построить и воспроизвести его.Это включает в себя ваших разработчиков, которые могут протестировать почти точную копию производственной системы, прежде чем она действительно пойдет в производство.Если это образ Docker, плюс этот код из этого места, а также эти статические файлы из этого другого места, то сложнее быть уверенным, что у вас есть идеальная настройка, соответствующая тому, что идет в производство.

2. Некоторые из более продвинутых Docker-ориентированных инструментов (Kubernetes, Amazon ECS, Docker Swarm, Hashicorp Nomad, ...) упрощают работу с контейнерами и изображениями как первоклассными объектами, но сложнее сказать «это изображение».плюс этот набор дополнительных файлов ".

3. Если вы используете инструмент автоматизации сервера (Ansible, Salt Stack, Chef, ...), чтобы вытолкнуть ваш код, то это простотакже использовать их, чтобы вытолкнуть правильную среду выполнения.Использование Docker для простой компоновки среды выполнения не дает вам ничего, кроме уровня сложности и некоторых рисков для безопасности.(Вы можете использовать Packer или Vagrant с этим набором инструментов для имитации последовательности развертывания в виртуальной машине для предпроизводственного тестирования.)

Вы также увидите последовательность во многих вопросах SO, гдеDockerfile копирует код приложения в какой-либо каталог, а затем docker-compose.yml bind-монтирует текущий каталог хоста над тем же каталогом.В этой настройке контейнерная среда отражает среду рабочего стола разработчика и в действительности не проверяет, что встроено в образ Docker.

(«Статические файлы» оказываются в серой зоне между «это приложение илиэто данные? "В контексте этого вопроса я склонялся бы к упаковке их в образ, особенно если они выходят из вашего обычного процесса сборки. Особенно это касается основного пользовательского интерфейса приложения, которое вы запускаете. Если это такие вещи, какбольшие ресурсы изображений или видео, которые вы могли бы разумно разместить на совершенно отдельном сервере, возможно, имеет смысл использовать их отдельно.)

Answer 2

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

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

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