Перейти к основному содержимому

Обзор

Администрирование

Сервисы

Сервис — это отдельная единица развёртывания, определённая на платформе. Простейшее определение сервиса выглядит следующим образом:

driver: docker

Здесь мы указываем, что сервис является Docker-контейнером.

Драйвер

Драйвер сервиса — это изолированная среда развёртывания. Абстракция драйвера включает следующие методы:

  • Ps — получить текущий статус сервиса
  • Up — запустить сервис
  • Down — остановить сервис

На данный момент платформа поддерживает следующий набор драйверов:

  • docker — контейнеризированное приложение в кластере Swarm

Выбор драйвера и подготовка всех необходимых артефактов (например, создание Dockerfile) — задача разработчика. С точки зрения администратора, все сервисы скрыты за абстракцией драйвера.

Менеджер сервисов

Менеджер сервисов — это промежуточное ПО для обеспечения унифицированного доступа к сервисам платформы и их конфигурациям с использованием абстракции драйвера.

Менеджер сервисов предоставляет REST API и интерфейс командной строки. Подробнее см. в документации менеджера.

Сборка и запуск

Система сборки

Репозиторий платформы является полиглотным. Каждое семейство языков использует свою специфическую систему сборки. Несмотря на это, от администратора не требуется знание всех систем сборки в проекте. Для достижения этой цели был введён простой слой сборки: Taskfile.

Просмотреть все доступные задачи и их описания:

task --list-all

Например, чтобы развернуть платформу, можно выполнить команду

task deploy

Помимо служебных задач, каждый сервис определяет собственные задачи для сборки и запуска. Структура задач полностью соответствует структуре репозитория. Так, для сервиса, расположенного в jvm/em-es задачи будут иметь вид jvm:em-es:*.

Для большинства сервисов предусмотрена команда image для сборки соответствующиего Docker образа. Например, чтобы собрать образ менеджера сервисов, достаточно выполнить команду

task platform:sm:image

Конфигурация

Конфигурации, специфичные для сервисов, расположены в директории config. После развертывания, эта директория будет доступна в сети по протоколу NFS и смонтирована во все запущенные на платформе сервисы в режиме чтения. Таким образом, каждый сервис может получить все интересующие его конфигурации средствами файловой системы.

Изменения конфигураций, вносимые через платформу оператора, делаются в директории config. Это обеспечивает единый источник истины и открывает возможности для версионирования (т.к. директория config находится в репозитории под управлением Git). Так, могут быть зафиксированы изменения за некоторый период времени, восстановлена предыдущая версия и обеспечена синхронизация с удаленным репозиторием.

Следует обратить особое внимание, что конфигурации сервисов не должны содержать конфиденциальной информации. Процесс внедрения такой информации в сервисы рассмотрен далее.

Конфигурации сервисов платформы расположены в каталоге platform/config. В отличие от конфигураций обычных сервисов, которые монтируются напрямую каждому сервису, конфигурации платформы регистрируются в Docker Swarm Secrets и доступны каждому сервису индивидуально.

Переменные и секреты

Для более гибкого и безопасного управления инфраструктурой, предусмотрены переменные и секреты. Они задаются в виде переменных окружения (Environment Variables) и располагаются в директории platform/env:

  • secret.env — содержит конфиденциальные переменные, такие как информация для доступа к БД;
  • build.env — содержит обычные переменные.

Различие между секретами и обычными переменными только в том, что секреты не индексируются в VCS.

Переменные и секреты внедряются в конфигурационные файлы платформы и инфраструктурные файлы командой

task sync

Как было указано выше, конфигурационные файлы сервисов не должны содержать переменных окружения. Однако, если сервису нужно сообщить значение некоторой переменной, это можно сделать через инфраструктурные файлы. Например, для Docker сервисов переменные окружения будут внедряться в соответствующие compose.yaml файлы.

Ввод в эксплуатацию

Для ввода платформы в эксплуатацию достаточно выполнить одну команду:

task deploy

Необходимые файлы будут синхронизированы, переменные внедрены и сервисы платформы будут запущены на кластере Docker Swarm в соответствии с platform/compose.yaml.

Руководство по эксплуатации

Всё, что нужно оператору коллайдера VEPP-2000, доступно непосредственно с портала оператора. Каждый сервис представлен как отдельное приложение, включая его конфигурацию, визуализацию и документацию.