Альтернативный подход к динамическим окружениям: использование Octopod01.11.2021 17:31

Как Octopod помогает сделать динамические окружения доступными для всех

Привет, Хабр! В этой статье я хочу рассказать, как мы в Typeable используем динамические окружения (review- или preview-окружения) в нашей работе, какие проблемы нам удалось решить, почему и как мы применяем свое решение Octopod, а не GitLab Dynamic Environments для этих целей. Если вы не знаете, что такое динамическое окружение, то рекомендую прочесть статью компании Flant, где автор очень подробно рассказал о видах динамических окружений, зачем они нужны и как применяются, а также детально разобрал эту тему на примере GitLab с подробными примерами и описаниями. У нас же есть альтернативный и идеологически несколько отличающийся подход к работе с review-окружениями в Octopod. Про историю создания Octopod и причины, побудившие нас его создать, мы уже писали ранее. Повторяться не будем, а сосредоточимся на отличиях нашего подхода и тех проблемах, которые мы решили.

Для начала нужно сказать, что Octopod является инструментом универсальным и не привязанным к какому-то конкретному способу управления пакетами в Kubernetes. Тем не менее, он главным образом  призван значительно упростить развертывание именно Helm-чартов, как стандарт де-факто в мире Kubernetes. В Typeable мы используем Helm, поэтому стандартная поставка Octopod начиная с версии 1.4 уже включает все необходимое для работы с этой утилитой.

Основные отличия от GitLab

Самое, пожалуй, главное это то, что мы начали работать с review-окружениями раньше, чем в GitLab появился интерфейс для работы с динамическими окружениями. Но есть и ряд других причин, в том числе и наше идеологическое отличие в подходе к реализации и использованию review-окружений. Но, давайте обо всем по порядку.

  1. Мы не храним конфигурацию окружения в коде. Почему? Мы намеренно хотим отвязать окружение от кода и на это у нас есть несколько причин.

    1. Не все сотрудники имеют доступ к коду. Наши процессы выстроены таким образом, что аналитики, тестировщики, менеджеры проектов и другие члены команды, которые не пишут код, доступ в репозиторий обычно имеют только на чтение, а то и не имеют его вовсе. Такой подход позволяет нам лучше управлять кодом и иметь меньше рисков и потенциальных проблем. Но им нужна возможность самостоятельно создавать review-окружения, не привлекая DevOps-инженера или разработчика.

    2. В GitLab для управления динамическим окружением нужно сначала создать, а затем при необходимости модифицировать файл .gitlab-ci.yml. Таким образом, в каждой ветке кода будет свой такой файл с необходимыми настройками окружения. Есть риск того, что настройки «утекут» в основную ветку, и новые окружения будут иметь неверные параметры. Это нужно как-то решать, и gitflow от этого становится только сложнее за счёт потенциального увеличения количества конфликтов и, как следствие, мерджей или ребейзов.

    3. Нам часто приходится вносить изменения в конфигурацию review-окружения. В Octopod легко изменять параметры, переменные окружения, а главное — переключаться между различными endpoint в сервисах, с которыми мы интегрированы. У нас очень много интеграций с внешними системами и не всегда можно протестировать функциональность приложения при подключении к тестовому API. Зачастую требуется взаимодействие с production API.

      Таким образом, настройки review-окружения хранятся в Octopod и управляются через Web-интерфейс или CLI Octopod«а (octo CLI) и полностью изолированы от кода.

  2. Переменные окружения в GitLab глобальны для проекта. Множество параметров review-окружения передается через переменные окружения. GitLab предоставляет интерфейс для указания переменных окружения (Variables) без внесения изменений в .gitlab-ci.yml, но эти переменные имеют глобальный скоуп, то есть распространяются на все динамические окружения проекта. Единственная возможность прописать переменные окружения для конкретного review-environment — это внести их в .gitlab-ci.yml в соответствующей ветке, а это противоречит пункту 1.

    В Octopod мы решили эту проблему с помощью Application Configuration и Deployment Configuration. Octopod генерирует список параметров ключ-значение, который позволяет видеть в UI возможные настройки чарта и управлять ими. Достаточно выбрать нужный ключ и прописать значение. Также можно указывать кастомные ключи, которые отсутствуют в списке. Мы предусмотрели два вида настроек конфигурации: Application Configuration и Deployment Configuration. Application Configuration — это конфигурация (Helm values), которая передается приложению. Например, это может быть строка подключения к базе данных или переменные окружения. Deployment Configuration применяется только на этапе создания окружения. Значения ключей передаются в Helm и позволяют переопределять значения по умолчанию, влияя таким образом непосредственно на процесс развертывания. В качестве примера здесь можно привести версию чарта или URL Helm-репозитория.

    Вот как выглядит конфигурация стейджинга в Octopod:

    image-loader.svg

  3. Ограничение по ресурсам. Review-окружений может быть много, потребляемых ими ресурсов — тоже. В конце концов, ресурсы заканчиваются и с этим нужно что-то делать. Поэтому, мы архивируем окружение, когда тикет в Jira перемещается в колонку Done (Jira, Octopod и GitHub у нас интегрированы между собой). Также, архивацию можно сделать и вручную. Архивация подразумевает подход «scale-to-zero», когда освобождаются Pods, но все остальные ресурсы (Persistent Volumes, например) сохраняются. Это позволяет в случае необходимости разархивировать окружение и очень быстро вернуть его в рабочее состояние. Окружения в архиве старше 14 дней удаляются полностью, то есть происходит cleanup с удалением абсолютно всех ресурсов, включая PVC, сертификаты, и т.д. Автоматизацию этого процесса мы настраиваем с помощью octo CLI — утилиты командной строки Octopod, которая имеет расширенные возможности по сравнению с веб-интерфейсом. В GitLab такой подход тоже можно реализовать, но задача эта нетривиальная и требующая сложной логики в .gitlab-ci.yml.

  4. Требуется четкое отслеживание состояния review-окружения. Один из недостатков Helm заключается в том, что невозможно отследить состояние окружения после того, как оно было развернуто. Helm завершил свою работу, а следить за тем, продолжает ли окружение функционировать, нужно самостоятельно. В процессе работы что-то может пойти не так, review-окружение уже не работает, но мы этого не знаем, пока оно нам не понадобится. Ребята из Flant решили эту проблему с помощью kubedog, который встроен в werf. Octopod следит за состояниями окружений несколько иначе. Все управляющие скрипты для Octopod мы пишем на Rust и используем kube-rs клиент для проверки статусов всех ReplicaSet. Проверка выполняется каждые 5 секунд, поэтому статус состояния review-окружения в Octopod всегда актуален.

  5. Написание скрипта .gitlab-ci.yml может быть достаточно сложной задачей. В Octopod мы решили эту проблему за счет поставки готовых скриптов для Helm, позволяющих деплоить любой валидный Helm-чарт. Во многих случаях это полностью исключает необходимость написания каких-либо скриптов и сводит вовлечение DevOps-инженера к минимуму. В конце статьи мы перейдем к практическому упражнению и развернем инстанс Wordpress в Octopod, используя Helm-чарт от bitnami.

  6. Необходимость создания комплексных взаимозависимых окружений. Если вам нужно создать окружение, которое зависит от инфраструктурных сервисов вроде PostgreSQL или Redis, то эти сервисы могут быть развернуты как отдельные review-окружения с помощью своих Helm-чартов, а параметры подключения к ним переданы через Application Overrides. Так можно использовать, например, один инстанс PostgreSQL или один сервис аутентификации для нескольких review-окружений.

  7. Требуется более тесная и надежная интеграция с кластером Kubernetes. Octopod работает в том же Kubernetes кластере, в котором разворачивает все review-окружения. Проблема с доступом к кластеру и передачей Secrets решена полностью, Octopod работает через Service Account. В GitLab можно настроить бесшовную интеграцию с Kubernetes кластером, что решает проблему передачи секретов. Но если интеграция по какой-то причине не работает, то возникают сложности.

Практика. Устанавливаем Octopod

Есть два основных пути установки Octopod:

  1. Для промышленного использования. Установка производится в кластер Kubernetes с помощью официального Helm-чарта.

  2. Для индивидуального использования и ознакомления с основными возможностями Octopod. Установка производится локально и полностью автоматизирована.

Мы с вами сейчас установим Octopod локально. На данный момент установка поддерживается в Linux и MacOS. Для установки в Windows требуется Windows Subsystem for Linux 2 (Docker Desktop устанавливается в Windows и интегрируется с WSL 2, остальные компоненты устанавливаются в WSL по инструкциям для Linux). Предварительно потребуется установить следующие инфраструктурные компоненты:

  1. Docker Desktop (https://www.docker.com/products/docker-desktop)

  2. Kind (https://kind.sigs.k8s.io/docs/user/quick-start/#installation)

  3. Kubectl (https://kubernetes.io/docs/tasks/tools)

  4. Helm 3 (https://helm.sh/docs/intro/install)

  5. (Только для Windows) WSL 2 (https://docs.microsoft.com/en-us/windows/wsl/install)

Затем запускаем скрипт, который установит Octopod:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/typeable/octopod/master/octopod_local_install.sh)"

Важное замечание при установке Octopod в Windows. WSL 2 может иметь проблемы с подключением к ресурсам по SSL из-за настроек антивирусного ПО с функцией файерволла (https://docs.microsoft.com/en-us/windows/wsl/troubleshooting#no-internet-access-in-wsl). Проявляется это как time out при попытке скачивания данных из репозиториев.

После того, как установка завершена, открываем браузер и в адресной строке вводим http://octopod.lvh.me и видим

image-loader.svg

Наверное, здесь стоит пояснить, что lhv.me — это простой сервис, который на любой запрос возвращает IP-адрес локального хоста 127.0.0.1. Его удобно использовать, чтобы не приходилось каждый раз вносить изменения в /etc/hosts.

Теперь нам нужно создать новый деплоймент. Octopod поставляется с уже предустановленными параметрами для Helm-чартов от bitnami, а в качестве примера используется Wordpress.

Нажмите кнопку NEW DEPLOYMENT. На экране появится окно, в котором необходимо ввести параметры окружения. В самом простом случае достаточно ввести имя. Например, wordpress. Но мы добавим еще два App override (для этого нажмите ADD AN OVERRIDE:

KEY

VALUE

wordpressUsername

admin

wordpressPassword

P@ssw0rd

Мы добавляем эти две переменные только на время создания review-окружения, когда эти переменные будут использованы для инициализации Wordpress. Затем их можно удалить. Естественно, что имя пользователя и пароль мы здесь указываем явно и простым текстом лишь для упрощения и в демонстрационных целях на локальной версии Octopod. В реальных условиях мы используем соответствующие инструменты типа Hashicorp Vault.

image-loader.svg

Нажмите кнопку SAVE.

Через некоторое время review-окружение будет создано.

image-loader.svg

На этом создание review-окружения завершено. Теперь вы можете открыть Wordpress по ссылке, которая указана в колонке Links. Чтобы зайти в админку, добавьте в URL /admin (http://wordpress.lvh.me/admin). Введите имя пользователя и пароль, которые были указаны при создании окружения.

Если все прошло успешно, то переменные wordpressUsername и wordpressPassword можно удалить, а пароль при необходимости можно заменить в админке Wordpress.

Заключение

Мы считаем, что review-окружения могут быть полезны не только разработчикам и тестировщикам, но и другим людям с меньшими техническими скилами. Поэтому мы постарались сделать порог вхождения в Octopod минимальным, интерфейс дружелюбным и понятным, а взаимодействие с пользователем интуитивным и предсказуемым. Именно этим продиктован путь, который мы выбрали для развития Octopod и решения тех проблем, которые описаны в этой статье. Конечно, идеологически Octopod значительно отличается от GitLab Dynamic Environments и применяет другие подходы к решению схожих вопросов. Но свое главное предназначение он выполняет безотказно — DevOps инженеры теперь свободны от рутинных задач по созданию и обслуживанию review-окружений, а это много стоит.

Нам, в свою очередь, очень хотелось бы получать обратную связь от пользователей Octopod. Ждем ваших предложений, пожеланий и PRs на GitHub!

Вам может быть интересно:

  1. Параллельные вселенные для вашего CI/CD пайплайна в Octopod

  2. Когда стоит выбирать микросервисы

  3. В чем польза формальных спецификаций вроде OpenAPI?

  4. Nix: Что это и с чем это употреблять?

Версия на английском языке: https://typeable.io/blog/2021–11–01-octopod

© Habrahabr.ru