Как перейти от управляемых GitLab приложений Kubernetes
Управляемые приложения GitLab были функцией интеграции платформы с Kubernetes, которая обеспечивала установку общих кластерных приложений одним щелчком мыши. Эта итерация функции устарела в цикле выпуска GitLab 13 и полностью удалена в июньском выпуске 14.0. Вот как можно перенести управляемые приложения на поддерживаемую модель развертывания.
Отказ от управляемых приложений
Управляемые приложения были разработаны как способ упростить настройку и работу с новым кластером Kubernetes. GitLab предоставил шаблоны для таких приложений, как NGINX Ingress, Cert Manager и Prometheus.
Было предложено два разных метода установки: в один клик и CI/CD. Метод одним щелчком предоставил пользовательский интерфейс в GitLab, в котором перечислены доступные приложения, и вы можете щелкнуть, чтобы установить. Некоторые приложения также раскрывали основные параметры конфигурации. Метод CI/CD предлагал шаблон GitLab CI для добавления приложений в кластер как часть конвейера.
Установки в один клик теперь вообще нет. Метод CI остается функциональным, но устарел и будет удален в GitLab 15.0. Хотя управляемые приложения значительно упростили установку, они только подходят для этого этапа жизненного цикла кластера. Приложения либо устанавливались, либо удалялись, поэтому вам нужно было быстро перейти на обычные инструменты управления Kubernetes для обслуживания и настройки.
Несмотря на удаление этой функции, существующие установки управляемых приложений продолжат работать в GitLab 14.0. Вы можете безопасно обновить GitLab, не беспокоясь о простоях вашего кластера. Однако при обновлении будет удален пользовательский интерфейс управляемых приложений, поэтому вы не сможете просматривать или удалять приложения из GitLab.
Получение контроля над вашими приложениями
Миграция с управляемых приложений не обязательно требует каких-либо немедленных действий с вашей стороны. Поскольку ваши приложения останутся в рабочем состоянии, вы можете оставить их как есть, если вас устраивает, что они остаются в пространстве имен gitlab-managed-apps.
Поскольку приложения — это просто развертывания Helm в вашем кластере, вы можете управлять ими с помощью kubectl и двоичных файлов командной строки Helm. Они будут отображаться как обычные ресурсы Kubernetes.
Вы можете перечислить ресурсы кластера, которые были установлены GitLab, с помощью этой команды Kubectl:
kubectl get all -n gitlab-managed-apps
Это позволяет вам проверить, что работает в вашем кластере, в отсутствие старой страницы «Приложения» GitLab.
Вы можете столкнуться с проблемами с приложениями, установленными старыми версиями GitLab. Возможно, они были добавлены с помощью Helm v2, который несовместим с современными клиентами Helm v3. Если вы не уверены, установлены ли у вас приложения v2, используйте следующую команду для проверки:
kubectl get all -n gitlab-managed-apps | grep 'helm.sh/release'
Приложения, которые показаны в выходных данных этой команды, были установлены Helm v3. Сравните список с более ранней командой get all, чтобы идентифицировать приложения, добавленные Helm v2.
Если выяснится, что ваши приложения используют Helm v2, вам нужно вручную просмотреть руководство по миграции Helm, чтобы обновить их. Рекомендуется перейти на Helm v3, если вы собираетесь сохранять приложения в долгосрочной перспективе. В качестве альтернативы, установив Helm v2 на свой компьютер, вы сможете взаимодействовать с приложениями для внесения немедленных исправлений и обслуживания.
Обновление до новой модели кластерных приложений GitLab
Главная цель управляемых приложений — упрощение настройки кластера — не была полностью отброшена GitLab. GitLab 14.0 фокусируется на «проектах управления кластером» как на новой модели развертывания для подготовки кластера.
GitLab предоставляет шаблон проекта, который можно использовать для установки приложений в кластеры Kubernetes. Это устраняет первоначальные проблемы с управляемыми приложениями, обеспечивая полный контроль над развертываемыми диаграммами Helm. Вы клонируете шаблон, подключаете проект к своему кластеру, затем редактируете и удаляете диаграммы отдельных приложений по мере необходимости. Запуск конвейера непрерывной интеграции развернет выбранные приложения в вашем кластере.
Вы можете перенести существующие управляемые приложения в формат проекта управления. Это позволяет вам продолжать использовать их, используя подход, одобренный GitLab. Мы предполагаем, что у вас уже есть кластер Kubernetes, подключенный к вашему экземпляру GitLab, благодаря вашим существующим развертываниям.
Начните с создания нового проекта GitLab с помощью кнопки «плюс» в правом верхнем углу. Нажмите «Создать из шаблона», затем прокрутите вниз до шаблона «GitLab Cluster Management». Нажмите кнопку «Использовать шаблон». На следующем экране дайте вашему проекту имя и нажмите «Создать проект».
Шаблон предоставляет серию диаграмм Helm для развертывания приложений в вашем кластере. Диаграммы отдельных приложений хранятся в каталоге applications. Каждое приложение получает свой собственный подкаталог.#
Начните с редактирования helmfile.yaml в корне вашего проекта либо в GitLab Web IDE, либо путем клонирования репозитория с помощью Git. Этот файл ссылается на отдельные шаблоны приложений. Включите приложения, которые вы используете, раскомментировав соответствующие строки. В этом примере мы ранее установили Ingress и Cert Manager как управляемые приложения GitLab, поэтому мы включаем их в проекте управления кластером.
Далее вам нужно выяснить, какая версия диаграммы уже развернута в вашем кластере. Этот шаг важен, чтобы вы непреднамеренно не заменили свое приложение другой версией.
Вы можете получить версию приложения, запустив helm ls -n gitlab-managed-apps. Найдите приложение в выходной таблице и запишите версию, отображаемую в столбце CHART. Это будет иметь формат app-name-X.Y.Z; вам нужна только часть X.Y.Z.
Вернитесь в новый проект GitLab и откройте файл helmfile.yaml, связанный с приложением, например applications/ingress/helmfile.yaml. Измените поле version, чтобы оно соответствовало версии, которую вы записали.
Наконец, замените values.yaml по умолчанию существующим набором значений Helm. Используйте Helm для загрузки YAML-представления файла значений вашего приложения:
helm get values ingress -n gitlab-managed-apps -a --output yaml
Замените ingress именем развертывания вашего приложения. Скопируйте весь вывод YAML и используйте его для перезаписи файла applications/ingress/values.yaml. Не забудьте настроить путь к файлу в соответствии с вашим приложением. Теперь вы готовы запустить развертывание проекта управления кластером.
Конвейер развертывания запустится автоматически, когда вы объедините свои изменения в ветку по умолчанию (которая обычно является main для новых проектов в GitLab 14.0). Используйте Git, чтобы зафиксировать ваши изменения и объединить их в:
git checkout -b my-branch git add . git commit -m "Migrate existing GitLab Managed Apps" git checkout main git merge my-branch git push -u origin main
Трубопровод будет запущен. Если изменения шаблона были правильными, это не должно повлиять на ваши запущенные приложения. Некоторые безобидные метаданные могут быть изменены по мере изменения механизма развертывания.
Теперь вы готовы использовать проект управления кластером для текущего обслуживания ваших приложений. Например, вы можете обновить приложение до новой версии, изменив поле version в его helmfile.yaml. Слияние изменений с main побудит Helm применить изменения внутри вашего кластера.
Заключение
Управляемые приложения GitLab помогли многим пользователям сделать первые шаги в Kubernetes. Однако простота этой функции в конечном итоге оказалась слишком ограничивающей, поэтому теперь ее удаляют в ходе многоэтапного процесса.
К счастью, завершить миграцию с управляемых приложений довольно просто. В них нет ничего особенного — это просто обычные развертывания Helm, которые живут в пространстве имен вашего кластера gitlab-managed-apps. Это означает, что ваши рабочие нагрузки останутся доступными, даже если вы обновитесь до GitLab 14.0, что позволит вам переходить в своем собственном темпе.
Двигаясь вперед, проекты управления кластерами являются предпочтительным подходом для использования GitLab для установки популярных приложений в Kubernetes. Хотя эта модель немного сложнее с технической точки зрения, она дает вам гораздо больше контроля и помогает управлять вашей инфраструктурой как кодом.