В первой статье мы обзорно осветим ключевые элементы платформы. В следующих статьях рассмотрим каждый компонент подробно. Будем рады конструктивной критике, замечаниям и предложениям, которые помогут устранить недостатки и усовершенствовать платформу.
Контейнеризация Docker и кластер Kubernetes
Первой важнейшей задачей стала унификация запуска всех компонентов платформы и проектов, которые впоследствии на ней будут развертываться. Универсальным и модным на сегодняшний день решением является запуск приложений в Docker контейнерах в кластере Kubernetes.
Большинство разработчиков программного обеспечения создали официальные Docker образы для своих продуктов и выкладывают их на сайте hub.docker.com. Если официального образа приложения нет, всегда можно собрать свой Docker образ на базе официального. Мы, например, собираем образы микросервисов на базе официальных легковесных образов Alpine Linux.
Кластер Kubernetes для платформы устанавливается на “голое железо” или VPS (Bare Metal) с предустановленной ОС Ubuntu или Debian, что позволяет строить платформу с нуля в ванильном Kubernetes.
Gitea и непрерывная интеграция CI
На данном этапе установили в кластер Git-сервер Gitea, реализующий функции хостинга кода и системы управления версиями.
Это позволило иметь в составе платформы собственный Git-сервер и не зависеть от сторонних продуктов вроде GitHub, в работе с которым тоже возникли некоторые трудности.
Git-сервер решает 2 основные задачи:
организация совместной разработки кода командой программистов
Код каждого микросервиса хранится в main-ветке Git-репозитория. Программист клонирует репозиторий микросервиса к себе на лаптоп, создает свою под-ветку, выполняет задание и делает запрос pull request на вливание изменений из своей ветки в main-ветку. В команде появляется человек, ответственный за прием запросов на слияние от программистов и организованно создающий запросы merge request на вливание изменений из веток программистов в main-ветку разрабатываемого микросервиса.
реализация подхода - инфраструктура как код IaC
Для каждого микросервиса (frontend, backend, mysql, postgresql, redis, memcached и т.д) создали Git-репозиторий в Gitea
Git-репозиторий микросервиса содержит: Dockerfile с описанием слоев Docker образа микросервиса, конфигурационные файлы программы в контейнере микросервиса, helm чарт развертывания микросервиса в кластере Kubernetes и Jenkinsfile с описанием пайплайнов сборки и доставки микросервиса в кластер Kubernetes. Код программы микросервиса находится в директории src.
Jenkins и непрерывная доставка CD
Для решения данной задачи установили Jenkins в кластер Kubernetes и для каждого микросервиса создали пайплайн сборки и доставки.
Для внесения изменений в код или конфигурацию микросервиса достаточно сделать правки в соответствующие файлы его Git-репозитория и сделать push. Push автоматически заставит Gitea послать web-хук в Jenkins.
Jenkins по web-хуку из Gitea автоматически скачает содержимое Git-репозитория микросервиса и выполнит job-ы в Jenkinsfile
Скопирует исходный код микросервиса из директории src Git-репозитория в Docker образ и скомпилирует его, если микросервис написан на компилируемом языке программирования. Соберет Docker образ микросервиса, используя Dockerfile. Выполнит деплой микросервиса в кластер Kubernetes, используя helm чарт.
В пайплайнах Jenkins реализовали следующие Job-ы:
review - сборка и доставка микросервиса в динамическое окружение разработчика в development контур
staging - сборка и доставка микросервиса в staging контур
production - промоушен микросервиса из staging контура в production
rollback - откат на одну из предыдущих версий в случае ошибки
Keycloak и единый вход SSO
Всем участникам проекта, который будет развернут на платформе, нужно предоставить доступ к web-интерфейсам: Gitea, Jenkins, Grafana, Phpmyadmin, Pgadmin. Каждый из них требует аутентификации и имеет собственную базу данных пользователей и паролей. С ростом числа участников проекта администрирование большого числа аккаунтов в нескольких базах данных станет трудно выполнимой задачей.
Тут на помощь пришел Keycloak и технология единого входа SSO.
Установили в платформу Keycloak и создали в нем единую базу данных пользователей. Добавили 2 группы: admins и devs. Группу admins ассоциировали с ролью admins, дающей участникам группы административные права во всех сервисах. Группу devs ассоциировали с ролью devs, дающей участникам группы права только Read Only.
На web-интерфейсе каждого сервиса есть кнопка “войти с помощью Keycloak”.
Пользователь нажимает на эту кнопку и его направляет на форму аутентификации Keycloak.
Пользователь вводит логин и пароль, и, в случае удачной аутентификации, Keycloak направляет пользователя уже аутентифицированным обратно в сервис, из которого тот пришел в Keycloak. Пройдя аутентификацию в Keycloak, пользователь получает доступ к web-интерфейсам всех сервисов платформы, без надобности повторного ввода логина и пароля в каждом из них.
Prometheus, Grafana и мониторинг платформы
Задачу мониторинга платформы решили, установив в кластер Kubernetes стек Prometheus + Grafana. Визуализировали в Grafana метрики node-exporter, дающие представление о нагрузке на основные подсистемы хоста, на котором установлена платформа: CPU, ОЗУ, HDD, сетевой стек и т.д.
Настроили Alertmanager и отправку предупреждений о критических проблемах на e-mail.
Подключили сбор бизнес метрик с проекта, развернутого на платформе, и визуализировали в Grafana на отдельном Dashboard.
SSL и безопасный доступ к сервисам платформы
Установили в платформу Cert-manager, который сгенерировал инфраструктурный доменный wildcard-сертификат и СА сертификат удостоверяющего центра организации, которым подписал доменный сертификат. Доменный сертификат подключили к web-интерфейсам сервисов платформы, а CA сертификат выдали участникам проекта. Это позволило сделать инфраструктуру платформы независимой от внешних удостоверяющих центров. К главному домену проекта, развернутого на платформе, подключили Let`s Encrypt сертификат и настроили автоматическое его обновление каждые 3 месяца.
Zero Trust и сетевая безопасность
Сетевую безопасность на платформе настроили в соответствии с подходом Zero Trust – закрыли весь трафик, как из Интернета в платформу, так и локальный трафик в кластере Kubernetes. Из Интернета открыли на платформу доступ только к трем портам: 22 – ssh на хост, 443 – HTTPs к web-интерфейсам и 2222 – работа с Git по ssh. В кластере Kubernetes инстансы инфраструктурных сервисов, контуры development, staging и production разместили в отдельных namespace и изолировали на сетевом уровне друг от друга. Разрешили трафик в пределах namespace и минимальный трафик между namespace, необходимый для взаимодействия инфраструктурных сервисов.
Заключение
В следующей статье мы рассмотрим тонкости непрерывной интеграции CI в Gitea. Просим тех, кто в данный момент на своих проектах использует CI/CD, в комментариях написать, какой функционал следует добавить в платформу, и проголосовать ниже. Спасибо.
