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

1 500 руб.за час
28 июня 2021, 18:40 • 4 отклика • 61 просмотр
  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)