Как поднимаешь?
у меня там 2 вида compose: override и prod, которые расширяют docker-compoe.yml, docker-compose up --build -d чтоб поднять override
Мда, 3 антипаттерна из 3
а как правильно?
Собирать образы docker, а не docker-compose. Не собирать образы на проде, вместо этого собирать их в CI, пушить в registry, а при деплое скачивать. Не использовать override, делать полностью отдельные конфигурации для прода и dev
Покажите все композы, мне почему то кажется что можно обойтись одним
А в чем минусы собирать через docker-compose up --build и почему оверрайдинг файлов это плохо?
1. с ним есть странные приколы, из-за которых процесс сборки отличается от docker build. например в какой-то момент кэши сборки, созданные docker build, docker-compose не использовались 2. override сложно читать (не понятно, какая итоговая конфигурация ушла в docker-compose) и он умеет далеко не во все (например, изменить переменную окружения может, а сбросить установленную в базовом файле - нет)
1) как быть если нужно будет собрать, допустим 5+ образов? Для каждого писать docker build? 2) Т.е получается, что нужно иметь на каждую стадию свой файл? Типа docker-compose.Development.yml, docker-compose.Staging.yml и так же production? И как быть тогда с переменным окружения которые могут быть одинаковыми для вот этих трёх стадий? Описывать в общий .env файл и пробрасывать его в env_file?
1. да. и вообще образы должны собираться в CI 2. да, описывать в .env файле.
Даже в development на локальной машине разраба?
как часть разрабу нужно пересобирать сразу 5 контейнеров?
Про 5 контейнеров пример просто из головы, просто вот допустим вот мы каждый билд что-то меняем в пяти самописных сервисах
1. Неясно почему так 2. Насчёт этого написано, что override мерджит, поэтому скинуть переменную нельзя
Обсуждают сегодня