Я создаю образы докеров для наших серверов, и я ищу передовые методы, связанные с поддержкой нескольких сред, при создании ДОКЕРФАЙЛА (ов).
Основное назначение серверов - запуск LAMP поверх Centos 6, и я хочу сделать DOCKERFILE (ы) как можно более общими для поддержки как среды разработки, так и производственной среды. Образы будут иметь много общих конфигураций / утилит и некоторые отличия.
Например, различия:
Я подумал об использовании примерно такой структуры:
но, как вы можете видеть, это невозможно сделать с текущим механизмом наследования, и даже если бы это было так, он не обслуживается.
Я не могу найти способ использовать условия ENV в DOCKERFILE (например, только с условиями на основе Linux в команде RUN).
На данный момент я использую следующую структуру:
Есть ли какие-нибудь передовые практики для вышеуказанного? Дублирование изображений (двойное обслуживание) - единственная возможность?
Одна из концепций Docker состоит в том, чтобы иметь одну и ту же среду - если у вас другая рабочая среда, чем dev, то вы не знаете, что она действительно будет работать с полной уверенностью, когда приложение будет перемещено в производство.
С сайта docker.com:
Устранение несоответствий в среде
Упаковывая приложение с его конфигурациями и зависимостями вместе и отправляя его как контейнер, приложение всегда будет работать в соответствии с разработкой локально, на другой машине, в тестировании или производстве. Больше не нужно беспокоиться о необходимости устанавливать одни и те же конфигурации в другую среду.
При этом, конечно, производственная среда и разработчик будут иметь различия, но это должно быть в основном с точки зрения конфигурации приложения - например, экземпляр разработчика не будет отправлять электронные письма клиентам, а скорее в фиктивный почтовый ящик и т. Д.
Я не думаю, что было бы правильным иметь такую разницу между производством и разработкой, как то, что вы упоминаете в своем посте.
Что касается разницы между конфигурацией разработки и производственной конфигурации (как в примере, который я привел выше), я лично вижу два действенных способа сделать это.
В Dev - файл Docker, который перезаписывает определенную конфигурацию общей базы как для production, так и для dev.
Ваш контейнер что-то запускает - запускает httpd и т. Д. Сценарий, запускающий процесс, сначала извлекает конфигурацию из Git или любого другого репозитория на основе переменной среды (например, docker run ... -e RUNAS=PROD ...) - вот что я делаю. В моем случае при запуске контейнера для Tomcat сценарии запуска Tomcat просто загружают версию файла войны на основе переменной среды (например, -e VERSION=current) и извлекает из Git файлы конфигурации на основе переменной, которая определяет, является ли она производственной или разработанной (-e RUNAS=DEV).