INFRASTRUCTURE Chapter #1 https://github.com/ephmann/team_tools Не кодом единым жив проект. И здесь я расскажу об одном из самых интересных и лучших с точки зрения работы, менеджмента и развития проекта, в которых мне когда либо доводилось участвовать.
Вводные данные: Набор слабо связанных или не связанных между собой компонентов, написанных на питоне, которые находились в одном репзитории на Gitlab и имели внутри каждого пакета файлы с зависимостями и один общий конфигурационный файл, который представлял из себя портянку на примерно 500 строк в формате JSON. Два пакета из общего набора можно было условно считать ядром данного проекта, потому что при запуске любого пакета зависимости разной степени важности и разного количества тянулись из этих пакетов. Запуск производился командами установки зависимостей и запуском из виртуального окружения исполняемых файлов. Так как все модули лежали в одном каталоге, то запуск приводил к тому, что весь код участвовал и был доступен в рантайме, даже если он был совершенно не нужен. Некоторые пакеты не запускались даже не уровне установки зависимостей, конфиги были доступны на запись в рантайме и на чтение всем желающим. Импорты в коде были ужасны. Начиная со ссылок на два каталога вверх и заканчивая python ellipsis (!!). Я не шучу! Эти парни на полном серьезе писали три точки после слова import. На самом деле по коду было очень много вопросов (не самых приятных), но в этой заметке не об этом.
Постановка задачи: Декомпозиция проекта. Вынос модулей в отдельные репозитории и установка переиспользуемых сущностей. Выделение исполняемых сущностей и вспомогательных. Планирование процесса разработки и поставки контента в продакшн. Запуск и состояние сервисов. Service Management, Service Discovery, Alert Managers, Scaling, Logging, Package Tracking, Integration and Delivery, Role Based Access, Secerts Managenement, Secret States (Runtime and Stored), Secrets Separation, User Friendly Commands and Interfaces.
Реализация планов: Написано много и довольно туманно. Все требует уточнений и пояснений. Все сводится к тому, что мы перестаем хранить секреты в plain text и давать возможности изменять их в рантайме как угодно и кому угодно. Мы выделяем сущности логически и собираем их в python пакеы, которые в последствии будут устанавливаться в образы докер и работать исключительно со своим окружением и только с теми секретами, которые нужны этому приложению. Основное деление пакета происходит на ветках gitlab. Два типа окружения (доступно любое количество, но нам не нужно): DEV и STABLE. Все сервисы имеют в своих названиях суффикс _dev или _stable. Допустим пакет (или сервис) имеет название team_exchange. Значит он везде автоматиччески будет фигурировать как team_exchange_stable. Или, соответственно, dev. Эта логика протянута через всю архитектуру и пакет всегда доедет только в то окружение, которое должен. Docker образы собираются из шаблонов налету и собирают нужные переменные из менеджера секретов. Секреты доступны только в рантайме и только заранее описанные в конфигурационном файле. В конфиге доступы переменные выделяющие ресурсы сервиса (память и проц), а так же нода, на которую поедет данный сервис. Нам хватало EAST и WEST, тут же определялся порт, который слушает сервис. Конфиг для сервиса небольшой, но его можно как угодно расширить, потому что он прочитается весь, что бы там ни было и скормит это приложению. Кроме этого существует глобальный конфиг, котоый нужен всем приложениям, он хранит базовые настройки инфраструктуры и общие данные. При запуске оба этих конфига склеиваются и передаются приложению. После этого приложение стартует из консольного скрипта, описанного в python setup в определенном окружении (production или development) на определенной ноде (east или west), с определенным портом и определенными uri, которые регулярными выражениями собираются proxy_rewrite модуле нашего API GateWay. А как это работает и какие инструменты использованы я расскажу во второй части, потому что я уперся в лимит Сетки :)
