Как упростить развертывание контейнерных программ

1656637691 kak uprostit razvertyvanie kontejnernyh programm

Омер Леви Хеврони

ulCZyWum4B47VZ37bmrkdeMnsd0EQHuWbMzz
Фотография Ilze Lucero на Unsplash

Я задал себе этот вопрос, когда начал учить Kubernetes: как мы можем упростить развертывание контейнерных программ? На первый взгляд развертывание контейнерных программ кажется достаточно простым. Все, что вам нужно, это куча файлов YAML и с помощью kubectl (утилита командной строки Kubernetes), служба будет запущена в кластере Kubernetes.

Но хотя развертывание одной программы является легкой задачей, как развернуть сотни программ? В Soluto у нас более 100 живых микросервисов, и это количество продолжает расти. Итак, когда мы начали думать о переносе рабочей нагрузки на наш кластер Kubernetes, мы столкнулись с несколькими проблемами:

Во-первых, развертывание Kubernetes действительно сложнее. Есть много движущихся частей, которые нужно правильно настроить: модуль автомасштабирования, ресурсы модуля, вход и т.д. Для этих частей требуется определенный опыт работы Kubernetes, и неправильная настройка может вызвать проблемы в производстве. В идеале мы могли бы упростить это, чтобы разработчики могли сосредоточиться на написании своего кода и меньше беспокоиться о развертывании.

Во-вторых, безопасность тоже является проблемой. Все рабочие службы должны иметь определенные вещи, такие как защита транспортного уровня (TLS). Это не обязательно сложные вещи, но все же о них нужно позаботиться. Мы хотели бы предварительно настроить их, чтобы любое новое развертывание было защищено по умолчанию.

Поиск решения

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

С другой стороны, нам нужно было быть осторожными, чтобы не скрывать слишком многое — разработчики должны иметь возможность понять, что происходит, чтобы они могли решать проблемы производства. Нам нужно было найти правильный уровень абстракции, который облегчит развертывание в Kubernetes, не скрывая лишних деталей.

Имея это в виду, мы стали искать решения. Попробовав несколько вещей, мы обнаружили Хелма. Helm – это менеджер пакетов для Kubernetes. Вы можете использовать его для установки любого приложения на своем кластере, а Helm позаботится о получении всех необходимых конфигурационных файлов и их установке на вашем кластере. Helm также поддерживает обновление развертываний, откат и многие другие интересные функции. Каждый пакет Helm называется «Диаграмма», и диаграммы хранятся в репозитории. С помощью helm установить Mongo, например, так же просто helm install stable/mongodb.

Звучит как отличное решение! Мы можем определить диаграмму для каждого типа службы – например, одну для всех наших веб-API, которые будут обрабатывать такие вещи, как балансировка нагрузки и TLS – и разработчику просто нужно указать необходимые параметры с помощью файлов конфигурации Helm.

4P0D8IGfVHiObVNHgAdPTrrhcNFOŽ2irhoj
Я и мой товарищ по команде, когда мы нашли Хелма

Хелм: Давайте посмотрим, как это делается

Чтобы использовать Helm, нам сначала нужно его установить. Helm имеет два компонента: клиент Helm, работающий на вашем компьютере, и Tiller, серверный компонент, работающий на вашем кластере. Затем нам нужно создать диаграмму с помощью этой простой команды Helm CLI: helm create web-api

После выполнения этой команды вы заметите создание новой папки под названием web-api. В этой папке вы найдете все знакомые файлы конфигурации Kubernetes: развертывание, обслуживание, вход и т.д. Теперь пора немного настроить: мы можем добавить горизонтальный модуль автомасштабирования, определить ресурсы по умолчанию, которые нужны модулю, и, конечно, включить TLS по умолчанию.

Всё можно настроить на основе механизма шаблонов Go. Следовательно, все, что мы добавляем, позже может быть заменено разработчиком, если стандартная конфигурация не работает должным образом.

Итак, теперь у нас диаграмма, но как мы можем ее использовать? Диаграмма должна существовать в хранилище Helm, которое в основном является сервером с несколькими архивами Zip (это все диаграммы в хранилище) и одним файлом индекса, который потребляет CLI. Вы можете вручную настроить репо с помощью любой службы хранения, например Azure Blob или AWS S3, но самым простым вариантом является Chart Museum.

Музей диаграмм – это хранилище Helm с CRUD API для управления вашими диаграммами. Он поддерживает базовую аутентификацию, поэтому вы можете ограничить, кто может отправлять новые диаграммы в ваше хранилище Helm. Helm не предоставляет никакого решения «музей как услуга», так что вам придется развернуть собственно. Но это очень просто – просто используйте его образ докера.

Теперь мы можем создать конвейер CI/CD для нашей диаграммы web-api, чтобы облегчить процесс ее модификации:

  • Выполните некоторые тесты, чтобы убедиться, что новая версия не сломана. В следующем параграфе я расскажу, как.
  • Упакуйте новую диаграмму с помощью Helm CLI.
  • Отправьте новый пакет к нашему экземпляру Chart Museum с помощью API Chart Museum.

Тестирование

Теперь наша диаграмма готова к использованию разработчиками! Но подождите… как мы можем знать, что диаграмма действительно работает? И как мы можем убедиться, что он будет работать? Вот почему нам нужно писать тесты для нашей диаграммы (как мы пишем для чего-либо другого).

WGGYmgftYuRQOqzlognwNV8yF4IFx6etjAF2

В основном мы хотим проверить две вещи.

  1. Мы хотим проверить наш шаблон – например, если вход должен существовать с TLS и определенными правилами (определенными разработчиком), мы должны проверить сгенерированный шаблон и убедиться, что вход создан правильно.
  2. Мы хотим проверить, являются ли файлы действительными конфигурациями Kubernetes и что они работают должным образом.

Тестирование первой вещи относительно просто – просмотрите этот пример репо, чтобы увидеть, насколько это просто.

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

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

Второе дело — проверить подлинность файлов Kubernetes — несколько сложнее. В Soluto мы используем механизм версии Helm: каждая диаграмма имеет версию, и все наши службы будут использовать последнюю стабильную версию. Когда приходит новая версия диаграммы, мы можем проверить эту версию на определенной службе. Если он работает правильно, обновите другие службы. Другой вариант – проверить это с помощью minikubeно это было слишком сложно для наших нужд.

Наконец: развертывание!

Теперь у нас есть конвейер CI/CD для наших диаграмм Helm, и мы подготовили диаграмму Helm, которую разработчики могут использовать. Теперь, когда новый разработчик хочет развернуть новую службу по производству, все, что ему нужно сделать, это:

1. Добавьте наш репозиторий к своему локальному Helm с помощью helm repo add chartmuseum http://<chart-museum-url>
2. Создайте новый конфигурационный файл Helm и укажите необходимые параметры (например, образ докера службы)
3. Run helm upgrade —install <service-name> chartmusuem/web-api -f<path_to_config_file> и все. Служба жива.

И, чтобы было еще легче понять, я создал репозиторий образцов. Репозиторий содержит все, что я обсуждал в этой публикации в блоге: общую диаграмму для веб-приложения, которую можно развернуть с помощью этой диаграммы, и музей диаграмм. Просмотрите его, чтобы лучше понять, что происходит – и есть даже пошаговая инструкция, которая поможет вам начать.

Спасибо, что читаете вместе. Если у вас возникли вопросы или вам нужна помощь, чтобы начать работу с Helm, не стесняйтесь связаться по комментариям здесь или через Twitter.

Счастливого Хельминга!

Первоначально опубликовано в блоге Soluto

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *