Как не создавать тестовые площадки руками и сделать динамические feature окружения с помощью Gitlab CI, traefik и docker-compose

Что такое динамические feature окружения?

Это окружения, которые создаются в MR в гитлабе по кнопке и поднимают из ветки экземпляр приложения, доступного по адресу https://имяприложения-имяветки.stage.example.com

Как сделать?

1. Нам потребуется сгенерировать wildcard сертификат для домена *.stage.example.com (Я сгенерил с помощью Lets Encrypt, но пока не автоматизировал renew такого сертификата)
2. Создаем на сервере сеть, которую будет слушать traefik: docker network create traefik-public
3. Traefik живет и деплоится отдельным приложением в своем репозитории. Я подготовил для вас пример - http://surl.li/qirno
4. А вот пример, как можно деплоить backend приложение - http://surl.li/qiroq

Что имеем в итоге:

При нажатии на deploy-feature-stage поднимается backend приложение по адресу https://api-имяветки.stage.example.com. База доступна для подключения по адресу db-имяветки.stage.example.com на порту 5433

При закрытии MR или мерже в master окружение автоматически останавливается и не тратит ресурсы сервера

В следующий раз расскажу как мы связываем backend и frontend при такой схеме

CozyStack.io

Сегодня узнал про прикольную штуку - https://cozystack.io/
Это опенсорсная платформа для создания своего собственного облака.
Т.е. можно на своих железках в серверной (Или железных серверах в ДЦ) сделать себе практически тоже самое, что предоставляют Cloud провайдеры. Есть даже Managed Postgres.

Сам я пока не щупал, но выглядит очень перспективно. На первый взгляд должно быть гораздо проще и удобнее, чем OpenStack, который используют популярные облака в РФ.

Подробнее можно посмотреть в подкасте https://t.me/kubernetes_ru/800561

Как мы в Happy Inc связываем frontend и backend в feature окружениях

Здесь у нас есть несколько схем, в зависимости от задачи:

1. Бэкендеры что-то доработали и им нужно задеплоить frontend приложение для каких-нибудь ручных самопроверок

2. Фронтендеры что-то доработали и им нужно проверить только frontend, backend не менялся

3. Доработка была совместная и нужно протестировать frontend и backend в связке

Как это реализовать с помощью Gitlab CI:

1. В гитлабе есть такая штука, как downstream pipelines. Мы можем запустить из пайплайна backend репозитория дочерний из frontend репозитория, передав ему какие-то переменные окружения. Соответственно сначала мы нажимаем deploy-feature-stage, затем deploy-feature-stage-frontend. Получем frontend приложение, которое смотрит на наш задеплоенный backend. Обратите внимание на deploy-prod action в frontend репозитории, там прописана rules секция, чтобы избежать деплоя на прод при запуске downstream пайплайна. При закрытии или мерже MR - оба окружения схлопываются.

2. Тут просто деплоим feature-stage фронтенда. По умолчанию он смотрит на master backend, который деплоится автоматически при каждом деплое в master на бэке. Смотрите action deploy-master-feature-stage в бэкендовом .gitlab-ci.yml

3. Тут можно пойти различными путями. Я решил сделать в таком ключе - в MR на бэкенде и фронтенде прописывается milestone с одинаковым именем, например test. Бэкендовый и фронтовый .gitlab-ci.yml дорабатываются таким образом, что если прописан milestone - окружение деплоится с именем из milestone. Фронты и бэки деплоят свои приложения независимо, в MR прописан milestone, таким образом фронт смотрит на нужный бэк. Доработка тестируется с изменениями и на фронте и на бэке

Доработанный backend pipeline - .gitlab-ci.yml
Пример frontend pipeline - .gitlab-ci.yml

Если у вас остались какие-то вопросы или есть идеи как реализовать все попроще - добро пожаловать в комментарии

tree

Пока готовлю пост про настройку логов - хочу поделиться свежим открытием. Консольная утилита tree в удобном виде показывает дерево каталогов. Вводим tree -a . и получаем вот такую красоту

Установка Grafana

Решил разбить пост про настройку сборки логов на несколько частей.
Сегодня начнем с установки Grafana.
Будем использовать подход Infrastructure as a Code, почти ничего на сервере руками не настраиваем, все деплоим в докер с помощью Gitlab.

1. Нужно подготовить чистый сервер к работе, создать юзера, прописать ключи вашего юзера на сервер и т.д. Я для этого использую свой ansible playbook. (Для этого на вашем компьютере должен быть установлен ansible и должен быть доступ по ssh на целевую машину).
2. Создаем на сервере пользователя gitlab-deploy и добавляем его в группу docker. Команды adduser gitlab-deploy и usermod -a -G docker gitlab-deploy (Этот и следующий пункт я еще не автоматизировал с помощью ansible).
3. Теперь нужно на сервере, где у вас запускается gitlab runner скопировать публичный ключ пользователя gitlab-runner на наш новый сервер. Для этого выполняем sudo su - gitlab-runner и ssh-copy-id -p 1234 -i ~/.ssh/id_rsa.pub gitlab-deploy@example.com.
4. Теперь можем деплоить traefik на сервер. Создаем проект в гитлабе, регистрируем для него gitlab runner и прописываем CI/CD переменную TRAEFIK_USERS. Значение для переменной можно сгенерировать с помощью команды htpasswd -n traefik. Соответственно логин будет traefik, а пароль тот, который вы зададите.
5. Пушим в репозиторий следующее содержимое (Поправить пример под себя). Получаем задеплоенный traefik на сервере. Отличие от traefik на feature-stage в том, что тут сертификаты автоматически получаются с помощью Let's Encrypt.
6. Теперь создаем проект для grafana, регистрируем для него gitlab-runner и прописываем CI/CD переменную POSTGRES_GRAFANA_PASSWORD.
7. Пушим в репозиторий следующее содержимое (Поправить пример под себя).
8. Когда отработает pipeline в гитлабе - можно открывать https://grafana.example.com/ (тут будет ваш домен) и логиниться под дефолтным логином admin и паролем admin. Система сразу попросит изменить пароль. Я также советую в настройках Administration / Users сразу поменять и логин.

ncdu

Я немного приболел, поэтому на этой неделе продолжения по настройке логов не будет.
Но спешу с вами поделиться ещё одной полезной утилитой.
Наверняка многие знают команду du. А вот про ncdu не все слышали.
Запускаем в нужной директории и видим вот такую красоту. Плюс можно перемещаться по файловой системе, как в mc

Grafana loki

Сегодня мы добавляем loki для сбора и хранения логов + добавляем datasource в графану, чтобы она увидела loki. Loki наружу не пробрасываем, так как логи должны (в идеале) литься внутри локальной сети.

1. Делаем свой Dockerfile для loki. Нам нужно создать папку для хранения данных и выдать ей соответствующие права, иначе при монтировании named volume в контейнер у пользователя в контейнере не будет прав на запись. Плюс добавляем curl, для того чтобы сделать healthcheck.
2. Пишем конфиг для loki. Я руководствовался вот этой статьей и добавил немного отсебятины, вроде зачистки данных в хранилище логов старше 1 недели.
3. Пишем datasource для графаны, чтобы она увидела loki. Ничего не добавляем ручками, все можно сделать с помощью кода!
4. Правим docker-compose.yaml и .gitlab-ci.yml, чтобы это добро заработало.
5. Пушим все в репозиторий, дожидаемся выполнения pipeline.
6. Заглядываем в графану в раздел Connections -> Data sources и убеждаемся, что loki подключился.

Всё готово! В следующей статье будем учиться лить логи приложения в loki.

Льем логи приложения в loki

Сегодня учимся отправлять логи приложения в наш loki. Для примера задеплоим приложение на тот же сервер.

1. Устанавливаем на сервер docker driver client для loki.
2. Открываем 3100 порт на хост машине, так как лить логи, используя только сеть докера не получилось (В продовом окружении все равно порт будет открыт в локальную сеть, так как графана и локи, вероятнее всего, будут стоять на отдельной машине для сбора логов от всех систем).
3. Берем обычное приложение на symfony и конфигуриуем его так, чтобы логи писались в файл в формате json

when@prod:
    monolog:
        handlers:
            main:
                type: stream
                path: '%kernel.logs_dir%/%kernel.environment%.json'
                formatter: monolog.formatter.json

4. В продовом конфиге docker compose создаем отдельный контейнер, который будет лить логи приложения в loki (Основной контейнер в stdout шлет логи RoadRunner, с помощью которого запускается наше приложение, их тоже можно лить в loki, если требуется). За отправку в loki отвечает эта секция:

logging:
            driver: loki
            options:
                loki-url: http://172.17.0.1:3100/loki/api/v1/push

Тут вписан ip docker host, в реальном приложении впишите сюда ip сервера, где крутится ваш loki.
5. Пушим изменения, дожидаемся выполнения pipeline.
6. Заходим в графану, раздел Explore, делаем запрос {compose_project="app-example"} |= `` | json и видим наши логи.

Всё готово! На этом завершаю цикл постов про графану и локи. Если есть непонятные моменты - велкам в комментарии. Также в комментах можете предлагать темы для следующих постов, которые вам интересны