Как лучше реализовать контейнеры для теста и прода?
Добрый день, у меня такая проблема:
У меня при помощи gitlab ci-cd собирается бэкенд проекта, после чего деплоится в контейнере в локальной сети. Сейчас у меня есть два контейнера, один для продакшн, который собирается на main ветке, второй - тетовый, собирается на development (контейнеры имеют разное название, тестовый имеет _test в конце). Шаги сборки - такие, build - сборка контейнера (сейчас тестовый и продакшн собираются отдельно с разными названиями), затем push_to_local_registry, соответственно тоже разные контейнеры, затем run_container. Есть ощущение, что это неправильно и контейнер должен быть один, но разных версий, но как я понял, в докере нельзя запустить контейнер с одним названием, даже с разными версиями, а мне нужно, чтобы продакшн и тест оба работали одновременно. Вопрос в том, как должны быть правильно организованы в контейнере тестовая и продакшн версия, я немного потерялся с тем, как это должно быть устроено "по уму" в идеале, чтобы при переходе с теста на прод, контейнер не создавался заново, а просто запускался на продакшн портах и с продакшн переменными окружения
Лучше для чего именно? Сейчас у вас всё работает нормально и проблем нет? Значит и нечего тут менять. Есть какая-то проблема? Тогда озвучивайте свою конкретную проблему и тогда уже можно будет думать как её решить с минимальными усилиями.
я немного потерялся с тем, как это должно быть устроено "по уму" в идеале, чтобы при переходе с теста на прод, контейнер не создавался заново, а просто запускался на продакшн портах и с продакшн переменными окружения
При переходе где, откуда и куда? Остановить тестовый контейнер и запустить продакшен? Ну так у вас же уже есть два отдельных контейнера - просто заранее делаете сборку, а уже потом запускаете что надо и когда надо. В целом логика обычно такая: делается базовый контейнер с нужными зависимостями, далее на базе этого контейнера собираются остальные - тестовый, стэйж, прод со своими отдельными зависимостями. Далее уже зависит от логики вашего приложения и его особенностей - к контейнеру монтируется внешний каталог с ресурсами или приложением, либо собирается финальный контейнер вместе с вашим приложением полностью внутри него.
Тут я плохо описал чего именно я хочу. Сценарий примерно такой: Я делаю коммит на любую ветку кроме development или main - ничего не происходит, после этого - делаю merge на development, должен создаться контейнер и задеплоиться на тестовых портах и с тестовым окружением. После этого, когда я сделаю merge на main ветку тестовый контейнер должен запуститься с продакшн окружением и на продакшн портах. Сейчас это у меня реализовано при помощи двух контейнеров с разными названиями, мне сказали, что контейнер должен быть один, я попробовал сделать контейнер с одним названием, но с разными версиями (через тег), это не работает. Теперь я не понимаю, как это должно быть правильно. Потому что мне нужно, чтобы тестовая версия работала параллельно продакшн версии, не хотелось бы удалять тестовый контейнер после merge на main
Кому именно он должен и почему? Вот кто это вам сказал - вот у него и уточняйте этот момент. Если вам поставлена задача упаковать в один контейнер две разные версии приложения - ну это так себе идея. Какую проблему это решает? Это лишь делает контейнер толще и усложняет управление версиями приложения.
Потому что мне нужно, чтобы тестовая версия работала параллельно продакшн версии, не хотелось бы удалять тестовый контейнер
Ну вот и пускай всё дальше и работает так, как у вас сейчас сделано.
А деплой у вас идет на одну машину что ли в случае дева и прода? Или на разные?
Просто немного (капельку) выглядит так, что достаточно брать все настройки (порты и прочее) из переменных окружения (условно - это может быть и конфиг-файл монтирующийся, и что угодно другое). Т.е. чтобы это был один контейнер, который подхватывает настройки окружения, независимо от ветки.
Простой
Простой
