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

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

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

  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), чтобы убедиться в целостности новых данных.

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

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

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

Первый шаг при обновлении любого сервиса — получение артефактов установки через режим pull утилиты 2GIS CLI. В этом режиме создаётся файл манифеста, который содержит информацию о сервисе, включая его версию. При каждом вызове утилиты в режиме pull создаётся новый файл манифеста, старые файлы не изменяются.

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

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

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

Чтобы обновить сервис, укажите нужную версию в флаге --version при выполнении команды helm upgrade, например:

helm upgrade --version=VERSION --atomic --values ./values-search.yaml search-api 2gis-on-premise/search-api
предупреждение

Версии сервисов внутри компонента должны быть одинаковыми и совпадать с версией компонента.

Обновление сервиса и его данных​

примечание

Этот сценарий доступен не для всех сервисов.

Cценарий обновления происходит в два этапа:

  1. Helm запускает задание импорта Kubernetes для обновления данных сервиса. Чтобы задание распознало наличие новых данных, укажите новый манифест в параметре dgctlStorage.manifest в конфигурационном файле сервиса values.yaml.
  2. Helm выполняет обновление сервиса до версии, указанной в флаге --version (см. предыдущий сценарий).

Обновление только данных сервиса​

Различия в процессе обновления

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

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

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

Чтобы не обновлять версию сервиса, укажите его текущую версию в флаге --version при выполнении команды helm upgrade. Чтобы задание импорта распознало наличие новых данных, укажите новый манифест в параметре dgctlStorage.manifest в конфигурационном файле сервиса values.yaml.

Чистка старых данных​

Чтобы освобождать место в хранилище, регулярно очищайте неактуальные данные. При этом сохраняйте манифесты для текущих и нескольких предыдущих версий данных, чтобы откатиться в случае проблем.

Если вы используете утилиту 2GIS CLI версии 3 и выше, вы можете удалить все манифесты, которые были созданы ранее, до разделения данных на компоненты.

Очистите данные в несколько этапов:

  1. Для первой чистки:

    1. Получите список всех манифестов нужного компонента в хранилище:

      dgctl manifest list

    2. Удалите из полученного списка манифесты, на которых развёрнуто ваше окружение.

    3. Удалите остальные манифесты:

      dgctl manifest delete --manifest-name <manifest-name>.json

  2. Создайте два файла со списками манифестов для ежедневной и ежемесячной выгрузки.

  3. Для последующих чисток:

    1. После каждого выполнения команды dgctl pull записывайте название полученного манифеста в конец соответствующего файла.

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

    3. Удалите остальные манифесты:

      dgctl manifest delete --manifest-name <manifest-name>.json