cicd

Серверы

1. для CI

   1. прогон линтеров

   2. сборка

   3. прогон тестов

2. прод

   1. раскатка прода

   2. раскатка стейджа (на отдельном поддомене)

   3. раскатка веток (некоторых) фич

гитлаб раннеры

1. тип раннера docker: прогон линтеров, сборка, прогон тестов

2. тип раннера shell: деплой контейнеров на сервер (подготовка env, docker-compose для соответствующего окружения)

Docker-compose

1. один базовый

2. для тестов: базовый + тестовые енвы + оверрайд некоторых строк базового compose

3. для прода: базовый + продовые енвы + оверрайд некоторых строк базового compose

4. для локальной разработки: базовый + оверрайд портов, вольюмов

оверрайдится для каждого окружения:

env’ы для безопасности и от дурака, чтоб одно окружение не залезло случайно в другой при опечатках в коде (в том числе инфраструктурном)

сеть (виртуальная сеть докера) каждая группа сервисов изолируется в одну сеть

домен/поддомен

имя группы сервисов (docker stack)

Контейнеры

web - основной, ждет postgres (статус healthy) и alembic (статус completed)

alembic - основной с оверрайдом CMD на применение миграций. Ждет postgres (статус healthy), применяет миграции и завершается.

db - postgres, есть healthcheck, который становится True после всех инициализаций

Dockerfile

мультистейджем из одного докерфайла будет собираться два образа: базовый и с тулами для дебага, тестов

Сети докера

webproxy

то что смотрит наружу - в одной сети с реверс прокси (traefik)

dev_backend_network

все сервисы dev ветки бэкенда видят друг друга, и изолированы от всего остального

db_network

контейнер БД + pgadmin для управления БД

если будут еще экземпляры постгреса, то будут в этой сети

Docker Registry

гитлабовский (если не хватит можно задействовать Dockerhub)

теги образов:

main - продовая ветка

dev - стейджовая ветка

featureN - тег для конкретной фичи

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

Вспомогательные сервисы:

traefik - реверс прокси

portainer - веб клиент для управление докер контейнерами

pgadmin - веб клиент для управление базами

Postgres

В целях экономии ресурсов используется один контейнер СУБД Postgres с несколькими базами.

Это накладывает небольшие ограничения, что нужно делать несколько ручных операций:

• при создании нового окружения создавать новую базу

• если надо грохнуть/пересоздать базу

pgadmin с этим поможет

Этапы CICD

1. линтеры

прогоняются прямо на раннерах, пакеты закэшированы

все остальный этапы проверки только после сборки и образ берется всегда только из docker regestry !!!

1. сборка образа

docker build, присваивание тега образу и пуш образа в regestry

1. тесты

спуллить собранный образ, запустить тесты

если тесты не провалены, присваивание стабильного тега образу, пуш в regestry

1. деливери

спуллить образ из regestry

старт docker compose с соответствующими параметрами для этого окружения

Все эти этапы комбинируются в разных комбинациях для commit, MR, merge и т.п. + часть джоб можно стартовать/перезапускать из интерфейса гитлаба.

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

На джобы ветки cicd (traefik, server utils) не смотрите. Они запускаются разово при первом старте проекта (сервера).

Если надо переразвернуть сервер в другом месте: достаточно зарегать два гитлаб раннера. И стартануть джобы из cicd.

Логи, мониторинг

Grafana + Loki

Отдельные окружения можно разворачивать из веток. Или из тэгов. Любому коммиту в гитлабе можно присвоить тэг - это будет тригером для запуска пайплайна.