Жизненный цикл артефактов установки

Доставка артефактов установки

1. 2GIS CLI загружает артефакты установки с публичных серверов обновлений 2ГИС.

2. 2GIS CLI помещает загруженные наборы данных в хранилище артефактов установки. (Docker-образы сервисов могут быть помещены в реестр Docker.)

   Подробнее см. в описании утилиты 2GIS CLI.

   Примечание:

   Хранилище артефактов установки требует регулярного технического обслуживания, в ходе которого удаляются устаревшие артефакты установки. Это помогает предотвратить исчерпание свободного места в хранилище.

   2GIS CLI не отслеживает и не управляет свободным местом в хранилище артефактов установки и в реестре Docker. Рекомендуется настроить мониторинг для этой части инфраструктуры и выполнять регулярное техническое обслуживание.

3. Все артефакты мигрируют из публичного контура в приватный контур (локальную сеть), где становятся доступны для Helm и сервисов программного комплекса 2ГИС.

   Организовать процесс миграции можно разными способами, в зависимости от специфики конкретного проекта.

   Пример:

   Чтобы обеспечить миграцию артефактов установки из публичной сети в приватную, можно установить реестр Docker и S3-совместимое хранилище в приватной сети. Затем останется настроить синхронизацию между ними и соответствующими сущностями, находящимися в публичной сети.

Импорт данных при установке или обновлении сервиса

Установка многих сервисов включает в себя копирование необходимого набора данных из хранилища артефактов (см. предыдущий пункт) в одно или несколько хранилищ, которые будут использованы сервисом при работе — например, в базу данных PostgreSQL. Зачастую для этого предусмотрено отдельное задание импорта Kubernetes (Kubernetes Importer job), обеспечивающее следующий жизненный цикл набора данных:

1. Задание читает из хранилища артефактов файл с манифестом. Такой манифест содержит список объектов в хранилище и их последние версии.

2. С помощью манифеста задание определяет, доступны ли в хранилище артефактов новые наборы данных для сервиса. Если новых данных нет, работа задания завершается.

3. Задание запускает несколько рабочих процессов (workers). Каждый рабочий процесс получает из хранилища требуемые артефакты установки и импортирует новые данные в хранилище данных сервиса (в виде отдельной копии).

4. После того, как все рабочие процессы завершили импорт данных, задание выполняет серию проверок (health checks), чтобы убедиться в целостности новых данных.

   Если все проверки завершились успешно, задание удаляет текущие данные, заменив их новыми.

   Если хотя бы одна проверка завершилась с ошибкой, задание останавливает процесс обновления и требует вмешательства системного администратора. Текущие данные остаются нетронутыми.

Основные сценарии обновления сервисов и их данных

Возможны разные сценарии обновления сервисов и их данных.

• Обновление сервиса с помощью Helm.

  Helm обновляет сервис подобно тому, как задание импорта Kubernetes обновляет данные (см. предыдущий пункт): рядом с существующими инстансами сервисов будут установлены новые инстансы, и при успешном завершении рабочих процессов и проверок трафик перенаправляется на новые инстансы. В случае ошибки Helm останавливает процесс обновления и требует вмешательства системного администратора.

• Обновление сервиса и его данных с помощью Helm (не все сервисы поддерживают этот вариант обновления).

  Сначала Helm запускает задание импорта Kubernetes для обновления данных сервиса, затем выполняет обновление сервиса.

• Обновление только данных сервиса (не все сервисы поддерживают этот вариант обновления).

  Настраивается выполнение по расписанию соответствующего задания импорта Kubernetes: например, на ежедневной основе.

Важное примечание:

Некоторые сервисы могут не поддерживать обновление данных или процесс обновления данных может отличаться от описанного.

Для получения информации о процессе обновления для конкретного сервиса обратитесь к его документации в разделе Обновление продуктов 2ГИС.