Как правильно настроить сервер(а) для dev/test/prod?

Question

[Strixi]

Подскажите, как лучше настроить сервера для dev/test/prod. Есть боевой сервер с prod (для юзеров), на нем не очень хочется что-то ковырять, чтобы ничего не сломать будущим юзерам. Уже успел вычитать, что лучше арендовать отдельный сервер для dev/test с настройкой контейнеров docker для dev и test. Как это лучше настроить в связки с gitlab ci/cd, amazon и т.д. Может, есть действительно хорошая статья (картинки, пункты и т.п) или видео.

Answer 1

[VoidVolker]

Все настройки ваших серверов сводятся к установке приложения gitlab-runner (либо настройке SSH для CI/CD сервера: т.е. CI/CD сервер подключается к целевому серверу по SSH/SFTP, копирует файлы и выполняет скрипты на целевой машине), а так же настройке требуемых зависимостей вашего проекта. Stage сервер настраивается идентично Prod серверу. Dev сервер настраивается для прямого доступа к нему со стороны разработчиков для отладки и дебага багов, не воспроизводящихся локально. В гитлабе настраивается CI/CD для деплоя через gitlab-runner или SSH, развертывается отдельный CI/CD сервер с приложением gitlab-runner и докером для запуска CI/CD задач и деплоя на серверы. Для каждой ветки настраиваются свои правила и ограничения деплоя под отдельные сервера. Итого у вас должно быть минимум пять серверов: гитлаб, cicd, dev, stage, prod. Плюс еще есть роль VPN сервера - эту роль вполне можно совместить с гитлабом. CI/CD - только отдельный сервер, ибо задачи штука ресурсоёмкая (компиляция, сборка, установка зависимостей и прочее). Еще очень полезная штука - кэширующий сервер для образов докера и пакеты (harbor - топ). Ускоряет работу задач и экономит трафик. Prod сервер может быть как сервером, так и группой серверов - prod-app, prod-db, prod-files и т.п. В идеале stage должен быть идентичной конфигурации, но обычно обходятся простыми виртуалками для экономии ресурсов, в отличии от prod сервера.

Answer 2

[Евгений Хлебников]

Из общих рекомендация по AWS:
1. сделайте второй аккаунт (или два, для дев и тест отдельно) для дев\тест и еще один для root, соедините всё в организацию под root аккаунтом, настройте общий биллинг. Так, чтобы дев аккаунт, в том числе его траты можно было видеть и прогнозировать, а еще для лучшей изоляции прода от тестов
Держать вместе прод и тест довольно опасно, ковыряясь в тесте можно случайно нагнуть прод.
2. поднимите инфраструктуру (желательно скриптами деплоя с прода, если они есть, с изменением параметров под тест\дев) в том отдельном (или отдельных) аккаунте
Заведите отдельные VPC для тест и дев (если они в разных аккаунтах, то вам придется это сделать)
3. деплойте prod-like продукт в тест\дев с изменением параметров Здесь в общем то можно и остановиться но Остапа несло...
4. вы можете создать еще один аккаунт для управления, поместить туда gitlab агенты, прочее ПО участвующее в тестировании, и т.п., предоставив доступ к нужным средам через пиринг или кроссаккаунтно AWS IAM. Так же там могут быть общие вещи для всех сред вещи (например хранилище артефактов, ECR для контейнеров...) и т.п. Здесь же, хотя тоже можно выделить и в отдельный аккаунт ради безопасности, можно организовать единую точку входа через VPN для прода-дев-тест сред для пользователей
5. И еще один аккаунт для бэкапов важных данных, причем бэкапить лучше в другой регион
P.S. я тут расписал как настроить инфраструктуру с точки зрения "не нагнуть прод", VoidVolker в соседнем ответе более специфично погрузился в настройку того что вам надо.

Answer 3

[Refguser]

как лучше настроить сервера для dev/test/

В конфигурации максимально приближенной к

есть боевой сервер с prod

Ваш КЭП.

Answer 4

[Saboteur]

Да просто три енвайрнмента.
1. DEV
удобный доступ для всех, чтобы могли залить, зайти, посмотреть, поковырять. С точки зрения CI/CD возможно автоматический деплоймент на него сразу после сборки. Ну это зависит от проекта.

2. TEST
Максимально близкий сетап к продакшену, доступ закрыть, деплоить только через CD (чтобы тестировалось не только приложение но и сам процесс деплоймента). Возможность потестить перформанс, как на проде.

3. Прод.
ну тут нечего описывать.

Можно немнго варьировать, но это основные предназначения дев и тест. При наличии лишних ресурсов, можно добавлять препрод, DR, различные тестовые, авто, уат и так далее...