Маркетплейс

Требования к приложениям

На Маркетплейсе можно разместить сервис как приложение в формате Ansible Playbook. Ansible Playbook использует параметризованные скрипты для управления конфигурацией и развертывания сложных приложений на множестве виртуальных ресурсов.

В статье описаны требования к Ansible Playbook для размещения приложения на Маркетплейсе:

Содержание плейбука

Структура проекта playbook.yaml регулируется официальной документацией Ansible.

Ниже представлен пример структуры проекта:

ansible-project/
├── ansible.cfg           # Конфигурация ansible (опционально)
├── inventories/          # Каталоги для inventory-файлов разных окружений
│   ├── production        # inventory для production (в формате ini)
│   └── stage             # inventory для stage/dev-среды
├── group_vars/           # Переменные для групп хостов
│   └── all.yml
├── collections/          # Дополнительные пакеты/коллекции
├── host_vars/            # Переменные для отдельных хостов
│   └── hostname.yml
├── playbooks/            # Каталог для всех основных playbook-файлов
│   ├── site.yml
│   └── webservers.yml
├── roles/                # Каталог ролей
│   └── webserver/        # Пример роли со своей структурой
│       ├── tasks/
│       │   └── main.yml
│       ├── handlers/
│       │   └── main.yml
│       ├── files/
│       ├── templates/
│       │   └── config.conf.j2
│       ├── vars/
│       │   └── main.yml
│       ├── defaults/
│       │   └── main.yml
│       ├── meta/
│       │   └── main.yml
│       └── README.md
├── files/                # Общие файлы (например, конфигурации для copy)
├── templates/            # Общие шаблоны Jinja2
├── library/              # Пользовательские модули (опционально)
├── filter_plugins/       # Пользовательские фильтры Jinja2 (опционально)
└── README.md             # Описание проекта

Используемая версия Ansible в плейбуке — не выше 2.14.
Внешние зависимости содержатся в архиве с дистрибутивом.
Чтобы ускорить работу приложения, действия из списка могут выполняться разными плейбуками:
- Install — установка сервиса, выполняется каждый раз при подключении сервиса.
- Uninstall — удаление сервиса, невозвратное действие.
- Backup — резервное копирование.
- Restore — восстановление данных из резервной копии.
- Cleanup — очистка данных, невозвратное действие.
Если в плейбуке используются теги, действия должны выполняться одним плейбуком.
Файл readme заполнен по шаблону и содержит обязательную информацию:
1. Список поддерживаемых операционных систем.
  
  Допустимы к использованию:
  - Ubuntu — версии 24.04 LTS (64-bit), 22.04 LTS (64-bit), 20.04 LTS (64-bit)
  - Debian — версии 12 (64-bit), 11 (64-bit)
  - CentOS 9 (64-bit)
  - Альт — версии 8 СП релиз 9, Сервер 10, Сервер c10f2
  - Astra Linux SE — версии «Воронеж» 1.7.5, «Воронеж»1.7.3, «Смоленск» 1.8.2
  - Ред ОС, сертифицированная редакция 7.3
  - Platform V Sberlinux OS Server 9.0.1
2. Необходимость пользовательского образа операционной системы.
3. Количество виртуальных машин, необходимых для развертывания приложения.
4. Минимальная конфигурация для каждой виртуальной машины.
5. Набор переменных окружения.
6. Шаблон инвентаря (inventory) в формате ini со списком управляемых машин, IP-адресов и доменных имен.
7. Пример строки подключения.
8. Если в плейбуке используются теги, в readme-файле должно быть указано, за какую операцию отвечает каждый тег.
В архив с дистрибутивом приложен лог тестового запуска сервиса через Ansible с минимальной детализацией.

Функционал приложения

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

Чтобы обеспечить безопасность, приложение:
- Сохраняет работоспособность и целостность данных при некорректных действиях пользователя и нештатном завершении работы.
- Поддерживает резервное копирование и восстановление данных, описанные в сопровождающей документации.
При выполнении логирования:
1. Уровень логирования конфигурируется и поддерживает следующие значения:
  - DEBUG — все виды событий для отладки системы или сервиса.
  - INFO — ошибки, предупреждения и сообщения.
  - WARN — ошибки и предупреждения.
  - ERROR — все ошибки, нарушающие работу, но не требующие немедленного вмешательства.
  - (Опционально) TRACE — детализированные записи для отладки сложных процессов.
  - (Опционально) NOTICE — важные, но не критические события, которые требуют внимания, но не являются ошибками.
  - (Опционально) CRITICAL — критические ошибки, требующие срочного реагирования.
  - (Опционально) ALERT — аварийные ситуации, когда необходимы срочные действия администратора.
  - (Опционально) EMERGENCY — система или сервис неработоспособна, требуется экстренное вмешательство.
  - (Опционально) FATAL — фатальные ошибки, после которых система или сервис не может продолжать работу.
2. Для определенных уровней логирования есть возможность передавать полную информацию о действиях пользователей с данными сервиса, например: внесение данных, изменение, удаление.
3. Сбор, обработка и пересылка лог-сообщений реализованы с использованием сервиса Fluent Bit — кроссплатформенное решение по сбору, обработке и маршрутизации логов с открытым исходным кодом. Может использоваться в качестве агента на уровне сервера и агента на уровне подов с последующей передачей в централизованную систему аудита.
  См.также
  
  Передача логов с виртуальной машины с помощью Fluent Bit logaas plugin
  
  Официальная документация Fluent Bit
4. Записи журнала передаются с использованием REST или gRPC API системы диагностики в формате плоского JSON и содержат следующие поля:
  - datetime — дата и время события по Unix-времени;
  - className — имя класса, породившего событие;
  - message — описание события;
  - traceId — идентификатор, который позволяет отследить события в разных сервисах в рамках одного входящего запроса;
  - logLevel — уровень журналирования;
  - serviceName — имя сервиса, однозначно определяющее его при поиске событий;
  - serviceVersion — версия сервиса;
  - instanceId — уникальный идентификатор сервиса.
При выполнении мониторинга:
1. Метрики передаются в формате Prometheus.
2. Приложение передает обязательные метрики, например:
  - Метрики использования системных ресурсов: CPU, RAM, Memory.
  - Время исполнения входящих запросов.
  - Количество успешных и/или неуспешных выполнений входящих запросов.
  - Время исполнения исходящих запросов или обращений к приложению.
  - Количество успешных и/или неуспешных выполнений исходящих запросов или обращений к приложению.
При выполнении аудита безопасности события, связанные c действиями пользователей, фиксируются в централизованной системе аудита. Приложение должно поддерживать отправку таких событий. Для реализации отправки событий безопасности в приложении вы можете использовать один из двух способов:
- Вызов REST API или gRPC.
- Сервис Fluent Bit — кроссплатформенное решение по сбору, обработке и маршрутизации логов с открытым исходным кодом. Может использоваться в качестве агента на уровне сервера и агента на уровне подов с последующей передачей в централизованную систему аудита.
См.также
Передача логов с виртуальной машины с помощью Fluent Bit logaas plugin

Официальная документация Fluent Bit
При отправке событий приложение передает обязательные параметры:
- (Опционально) tags — сквозные идентификаторы и метки для группировки событий.
- datetime — время возникновения события в миллисекундах, прошедших с полуночи по Unix-времени.
- serviceName — уникальный идентификатор сервиса.
- serviceVersion — версия сервиса.
- name — название события.
- params — список параметров аудита, включающий:
  - name — название события;
  - value — значение события.
- userLogin — логин пользователя.
- (Опционально) sessionID — идентификатор сессии.
- (Опционально) userName — имя пользователя.
- (Опционально) userNode — узел, с которого пользователь выполняет действия, например: IP или FQDN.

Предыдущая статья

Требования к плагинам

Следующая статья

Концепции

Эта статья полезна?

Поддержка Юридические документы