Infrastracture schema
На данный момент инфраструктура Брокарда упрощённо может быть представлена в виде следующей упрощенной схемы:
Где у нас есть 2 кластера, 3 сервера, 4 окружения.
BRD new prod: это кластер для нового продакшена, в нем находится одно окружение - new prod env на одном сервере.
BRD infra old: это старый кластер, в котором находится два сервера и три окружения. На этих серверах очень медленная дисковая подсистема, и как раз их мы и хотели обновить.
Вспомогательные инструменты кластера
В каждом кластере мы поднимаем определенное количество вспомогательной инфраструктуры, для обслуживания размещенных в кластере окружений. Элементы инфраструктуры:
- Portainer: консоль управления кластером
- Loki: система хранения логов
- Grafana: просмотр логов
- Traefik: точка входа для служб внутри кластера и окружений
Состав окружения
Окружение состоит из группы основных и вспомогательных служб. Основные службы:
- nginx: веб сервер
- php-fpm: запуск php
- mariadb: база данных
- redis: кеш и управление очередями Вспомогательные службы:
- cron: запуск задач по таймеру
- walg: бекапы базы
- restic: бекапы файлов
Так же к каждому окружению подключен один из доступных s3 бакетов, для загрузки в него ассетов.
Обновление старых серверов
Старые сервера объединены в один кластер, с единой точкой входа в виде traefikOld. Пере мигрировать один из них на новое окружение, не сломав кластер, не представляется возможным из-за особенностей сети. Поэтому предлагается поднять рядом новый BRD infra stage, внутри которого поднять базовую инфраструктуру, после чего на него пере мигрировать сами окружения.
Важно: при миграции будет гарантированный даунтайм. После миграции старые сервера можно будет вывести из эксплуатации и освободить привязанные к ним ip.
CI/CD
На данный момент у нас есть следующие окружения:
- NewProd: ветка production в git
- OldProd: ветка old-prod
- Stage: ветка master
- Feature: ветка feature Каждое окружение представляет собой независимый инстанс PIM со своей базой и всеми независимыми сервисами.
Деплой
- отправка нового кода в git
- сборка контейнера с актуальным кодом (docker build)
- публикация контейнера в Docker Registry (в нашем случае это Harbor)
- рендер настроек конкретного окружения в docker app
- отправка запроса на обновление окружение в демон соответствующего кластера
- кластер скачивает из registry новые образы контейнеров
- окружение перезапускается с новыми настройками и новыми контейнерами