Девопс для Маркетплейса

1. Описание проекта

Веб-приложение, разработанное на Flask/Jinja, PostgreSQL, Minio. Количество REST API endpoint'ов минимально, преимущественно SSR. Классическая монолитная архитектура.

При локальной разработке Flask-приложение запускается в debug-режиме, контейнеризация не используется. По желанию разработчика с помощью docker compose могут отдельно запускаться контейнеры с PostgreSQL и Minio. Использованы миграции (Alembic).

Текущая инфраструктура и окружение проекта:

• Два физических сервера в OVH SYS, виртуализация ESXi, виртуальные машины с ОС Fedora
• GitLab (dockerized, on premise) (VM-1)
• Atlassian JIRA/Confluence (non-dockerized, on premise) (VM-1)
• OpenLDAP + web UI (VM-1) + интеграция GitLab, JIRA/Confluence
• Rancher 2.x (on premise, VM-2, VM-3)
• K8s cluster (via Rancher) (VM-4, VM-5)

На текущий момент в GitLab создан единственный проект, в котором хранится весь код системы, а также вспомогательные скрипты. Используется следующая практика работы с ветками:

• master - стабильная ветка. На данный момент практически не используется
• develop - ветка разработки. Активно используется на этапе текущей разработки
• feature-branches - ветки с реализацией новых функций. Как правило, одна ветка = один разработчик команды. Принято соглашение о наименовании веток (используется для GitLab CI/CD, см. далее)

Merge веток в develop выполняется через GitLab Merge Request (не всегда, иногда правило нарушается - ветки мержатся напрямую).

1. Текущий Deployment

В GitLab настроен CI/CD с использованием стандартного функционала. Реализованы следующие этапы сборки:

• статический анализ (mypy)
• тесты (unit tests / migrations tests)
• сборка (dockerize (gitlab docker registry))
• деплой (bash script + helm chart)

Для деплоймента в k8s используется кастомный bash-скрипт, стандартный функционал GitLab не использован (на момент реализации он не поддерживал ряд функций). Применяется Helm Chart (3.x), помощью которого приложение после сборки образа деплоится на кластер. Helm Chart хранится в репо вместе с кодом. В нем подключен postgresql dependency, база деплоится также в кластер (нужно для feature branches, см. ниже). При создании новой ветки разработчиком весь деплоймент происходит через GitLab, дополнительных действий не требуется.



Реализация в зависимости от ветки:

• master - не реализовано (нет production-окружения, TODO)
• develop - postgresql деплоится через helm chart dependency, настроен Ingress + Xio (no SSL)
• feature branch - аналогично develop, но название pod'а формируется как `fb-XXX`, где XXX - номер задачи, полученный из имени ветки (название ветки всегда формируется как USERNAME/AFO-XXX_description)

Minio также продеплоен в k8s, но инстанс общий для всех стендов.



Шаги 1-2 (статический анализ, тесты) запускаются на каждый коммит. Далее сценарий зависит от ветки:

• develop - каждый коммит запускает сборку и deployment
• feature branch - шаг 3-4 запускается пользователем (разработчиком) в gitlab

При merge request'е также запускаются шаги 1-2 в detached режиме.

1. Задачи

• Перенести информационные системы и необходимые настройки на другие аппаратные мощности или SaaS (Atlassian, GitLab etc.)
• Перенести k8s кластер для dev-окружения (использовать on premise или облако, оценить стоимость поддержки и аренды мощностей\облачного сервиса)
• Актуализировать\оптимизировать деплоймент скрипты и настройки (настройка делалась около года назад, частично устарела, ряд задач мог быть решен не оптимально)
• (!) Подготовить Production-окружение
  • Определить сервис, на котором будет production (on premise, GKE или аналог) - оценить риски, надежность, стоимость, дать рекомендации
  • Установить\настроить инстанс СУБД вне k8s, дать рекомендации
  • Настроить SSL
  • (!) Настроить резервирование (определить частоту и тип бэкапов, дать рекомендации)
  • Настроить системы логирования, мониторинга
  • Настроить green/blue deployment
• По аналогии с Production подготовить Staging-окружение в упрощенном виде
• (!) Для Production/Staging изменить конфигурацию приложения, использовать WSGi сервер (сейчас используется только built-in Flask dev server). Также, возможно, стоит отдавать статику через nginx, вынести ее в отдельный контейнер
• Доработать helm chart и bash-скрипт для деплоймента на production/staging (поменять параметры, отключить postgresql dependency и пр.)
• Закрыть публичный доступ для Staging/Dev окружений
• Для Dev-окружений настроить правильный DNS (вероятно, стоит уйти от Xio или сконфигурировать его корректно)
• Проверить и актуализировать Docker-файлы, минимизировать размер создаваемых образов, удалить ненужные файлы в образе, убедиться, что в образ не попадет ничего лишнего (например, .git или node_modules). Сейчас использован multi-stage build, вероятно, его можно улучшить
• (!) Провести аудит безопасности, убедиться в оптимальности конфигурации всех систем

1. Задачи на дальнейшее сопровождение проекта

• Мониторинг всех систем
• Оперативное реагирование на экстренные ситуации (аварийное отключение сервера, системы) - вопрос времени реакции к обсуждению
• Обновление систем (GitLab, JIRA/Confluence etc.)
• Масштабирование ресурсов по необходимости

1. Known issues

• GitLab Registry не очищается несмотря на политики удаления образов, как следствие периодически забивается дисковое пространство)
• Feature Branches pods не удаляются , в GitLab не обрабатывается событие подтверждения merge request'а, при котором стоит удалять pod. Как следствие, периодически достигается лимит по ресурсам, pod'ы удаляются в ручном режиме (через helm)
• В текущем K8S cluster PVC сделан через hostpath provisioner
• После удаления Pod'а через helm не удаляется PVC
• Для каждого билда в feature branch создается Docker Image с тэгом в виде fb-XXXXXX, где X - хэш коммита, для которого был запущен билд. Это позволяет восстанавливать историю версий, но приводит к большому количеству образов в gitlab registry

1. Материалы

Могут быть переданы следующие материалы и данные:

• Atlassian JIRA, Confluence - стандартные экспорты проектов, сделанные встроенными средствами продуктов
• GitLab - экспорт проекта, скрипты
• Rancher - образ VM (Rancher k8s, load balancer)
• K8S (созданные через Rancher CLI) - образы VM (x2)