Жизненный цикл артефактов установки | On‑Premise | 2GIS Documentation
On‑Premise
Личный кабинет

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

  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

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

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

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

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

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

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

Важно:

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

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

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

Если вы обновляете данные для всех сервисов одновременно, вызывайте следующую команду после каждого выполнения dgctl pull:

dgctl manifest cleanup --keep-count N

N — количество последних манифестов, которые нужно сохранить. Команда выше удалит все манифесты и их данные, кроме N+2 самых свежих. Например, если вы обновляете данные ежедневно, сохранятся манифесты за N+2 последних дня.

Если данные разных сервисов обновляются с разной частотой (например, ежедневно и ежемесячно), предыдущий способ очистки не подходит, так как манифесты для ежемесячных обновлений должны храниться дольше, чем для ежедневных. Необходимо избежать случайного удаления манифеста для текущей версии данных, которые обновляются реже, иначе есть шанс потерять эти данные в будущем.

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

  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