COMAS

COnfiguration MAnagement Service

Сервис Управления Конфигурациями

[[TOC]]

Назначение

Управление изменениями файлов конфигурации приложений.

1. Собрать в одном месте все настройки, которые нужны приложению
2. По этим настройкам, используя шаблоны, сгенерить все необходимые приложению конфиги
3. Проверить корректность полученных конфигов, если такое поддерживается приложением
4. Выполнить рестарт приложения с новым конфигом, сделав откат при неудаче
5. Опционально:
   1. Активировать для приложения одну из подготовленных ранее ревизий настроек
   2. Предоставить интерфейс для удобного редактирования настроек (типы данных, умолчания, описание)
   3. Выполнять действия выше удаленно

Обозначения

• Шаблон - темплейт, по которому создается файл конфигурации приложения (golang template)
• Метаданные - описание шаблонов, настроек, команд для переключения приложения на новую конфигурацию
• Чарт - совокупнось метаданных и указанных в них шаблонов
• Настройка - имя и значение переменной, которые передаются в сервис для изменения конфигурации приложения
• Ревизия - совокупнось настроек + идентификатор ревизии

См. Также

• A chart is a collection of files that describe a related set of Kubernetes resources..
• Heroku’s classic buildpack for Go applications

Первичный алгоритм

1. Получить новые настройки приложения
2. Сгенерить файл(ы) конфигурации
3. Выполнить команду загрузки в приложение новой конфигурации

Целевые приложения

1.  HTTP-сервер (nginx)
2.  docker compose app
3.  SIP-сервер (asterisk)

Функционал

В настройках comas задается список приложений, доступных для управления. Эти приложения управляются через CLI или API.

Для разрешенного приложения доступен функционал (см API):

1.  Создать и активировать ревизию настроек, изменив её полностью или частично, с её валидацией и рестартом сервиса
2.  Вернуть список имеющихся резервных копий настроек
3.  Вернуть настройки ревизии для текущего или заданного ID
4.  Активировать заданную ревизию
5.  Удалить ревизию в статусе REV_AVAILABLE
6.  Вернуть список описаний настроек, которые можно изменить в п.1
7.  Выполнить команду из заданного в чарте списка.
8.  Обработать статус рестарта с позиции клиента (иначе по таймауту будет откат)
9.  (Возможно) Прием запроса про статус приложения и время его изменения

Примеры использования

Сервис

Терминал 1

• Создать .env

$ make config

• Запустить сервис

$ make test-run

Терминал 2

• Отправить настройки через curl

$ make test-run-nginx
Test for app running at port 8082
{
  "id": "250901160402",
  "generated": [
    "site.conf.250901160402"
  ],
  "result": {
    "commands": [
      {
        "name": "validate",
        "out": [
          "nginx -t"
        ]
      },
      {
        "name": "reload",
        "out": [
          "nginx -s reload"
        ]
      }
    ]
  }
}

CLI

Выгрузить копию встроенных чартов

$ ./comas --dump_fs=dir

Конфиги будут выгружены в dir (там смотрим на nginx/).

Эти файлы можно менять и они будут использованы, если при старте указать --core.static=dir.

Обновление конфига по файлу настроек

$ ./comas --run_once=sample1.json --core.static=dir --log.debug

Конфигурация сервиса

Общая - конфигурация сервиса в целом, задается при старте (аргументы или ENV) 1. static/chart - Путь к чартам 2. root - Путь с генерируемым файлам 3. Интервал рестарта

Чарт - конфигурация для каждого приложения, размещена в static/chart/NAMESPACE/NAME 1. Общие - пути к файлам шаблонов и конфигурации 2. Список описаний настроек (название, коммент, тип, правила валидации) 3. Имя группы пользователя приложения 4. Шаблоны файлов конфигурации

Ограничение доступа

• Каждое приложение запускается под своими пользователем U и группой G
• Создаваемые конфиги должны принадлежать этой группе G с доступом по чтению
• Пользователь, под которым запускается сервис, должен входить в группы всех приложений
• Рестарт и валидация конфига делается через sudo -g

Алгоритм приема новых настроек на примере nginx

Если не указано иначе, размещение файлов - root/nginx.

1. HTTP-handler: получить JSON с новыми настройками и провалидировать его
2. Загрузить текущие настройки приложения (из файла .YY, на который указывает симлинк comas.json, если он есть)
3. Добавить новые настройки к текущим и сохранить в comas.json.XX
4. По настройкам и шаблону сгенерить файл site.conf.XX
5. Симлинк comas.json перенести в tmp/
6. Симлинк /etc/nginx/conf.d/site.conf перенести в tmp/ (если это не симлинк - сохраняем как .00)
7. Создать симлинк comas.json -> comas.json.XX
8. Создать симлинк /etc/nginx/conf.d/site.conf -> site.conf.XX
9. Выполнить валидацию конфигурации (nginx -t)
10. Выполнить загрузку конфигурации (nginx -s reload)
11. Если в п.7,8 возникает ошибка - восстановить симлинки из tmp/
12. Если ошибки нет - удалить симлинки в tmp/
13. Отправить Клиенту отчет о результатах работы (успех или описание ошибки)
14. (Возможно) если на старте сервиса каталог tmp/ не пуст - выполнить п.11

Алгоритм добавления нового приложения (чарта) в сервис

1. Определиться со списком нужных файлов конфигурации
2. Для каждого файла подготовить шаблон (golang-template)
3. Подготовить описание используемых в шаблонах переменных (yaml - тут нужны комменты)
4. Значения переменных из п.3 будут прилетать в сервис в формате json (это межсервисный обмен)

Пример чартов

• nginx
• docker compose / NATS

Аргументы запуска

См. config.md

Версии

См. CHANGELOG.md

См. также

• https://ebogdum.github.io/konfigo/
• https://github.com/yarlson/ftl
• https://atmos.tools/

Статистика исходного кода

Лицензия

Copyright 2024 Vinteo

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.