Обзор IDE Monokle, или Рассказ о неоправдавшихся ожиданиях

В погоне за лучшей или, правильнее сказать, удобной жизнью я начал искать решение, которое помогало бы писать чарты для Kubernetes и лучше разбираться в зависимостях — что, куда и откуда подставляется в созданных чартах. Так я наткнулся на программу под названием Monokle. В ее описании сказано: «Вы сможете составлять чарты, быстро находить какие либо несовместимости или неправильный код, а также деплоить ваши чарты сразу в K8s». Глаза загорелись, я приступил к установке.

Важно: тестировалась версия 1.9; выводы основаны на личных впечатлениях.

Что такое Monokle

Monokle написан на Electron с добавлением React и TypeScript. Проект появился на GitHub’е 21 апреля 2021 года, активно развивается и за прошедшие полтора года набрал почти 600 звёзд. В нем поддерживаются плагины — JSON-файлы (они же темплейты), которые помогают создавать ресурсы. Для создания сейчас доступны: Basic Pod, Basic Job, Basic Service, Deployment, StatefullSet + RBAC. При этом в начальном состоянии плагинов от разработчиков представлено очень мало.

Monokle «из коробки» предлагает:

• проверку правильности составления чартов, отслеживания зависимостей и поиск проблемных мест;

• использование темплейтов для составления с нуля ресурсов кластера;

• возможность деплоить чарты сразу же в кластер прямо из программы;

• сравнивать чарты в кластере с локальными;

• просматривать и редактировать онлайн то, что уже есть в кластере;

• генерировать preview для Helm и Kustomize-ресурсов по заданным values.

Первые шаги и попытки освоиться

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

Недолго думая, я выбрал первый пункт, указав папку, которая была подготовлена для использования с werf (Open Source-утилитой для сборки приложений и их деплоя в Kubernetes), в которой уже лежали YAML-темплейты. Стоит отметить, что werf — это мой единственный инструмент, с которым я сейчас работаю.

Далее всё пошло наперекосяк. Папка открылась нормально, но из всего содержимого были доступны только файлы с расширениями *.yml или *.yaml, да и то как-то выборочно. Например, я не смог открыть файл .gitlab-ci.yml, как бы ни старался. Очень огорчило, что нельзя открыть и редактировать *.tpl-файлы, в которых задана дополнительная логика. В итоге я решил, что делаю всё неправильно и принялся осваивать всё с нуля.

Прежде чем продолжить, остановлюсь на интерфейсе.

Интерфейс пользователя

Окно программы разбито на колонки: первая служит для обзора структуры проекта, вторая — для просмотра созданных в чартах ресурсов, третья — редактор.

Для удобства навигации в первой колонке есть закладки:

1. Файлы проекта.

2. Просмотр структуры Kustomize ( с этим софтом я не знаком, поэтому закладку пропускаю).

3. Просмотр структуры Helm.

4. Images — образы, используемые в проекте (в нашем случае только один: ubuntu:latest).

5. Предварительно подготовленные темплейты, из которых можно создавать новые ресурсы для кластера.

6. Проверка на валидность созданных ресурсов в соответствии с различными версиями Kubernetes.

7. Поиск и замена.

8. Навигатор ресурсов. В этой закладке будут появляться и первично проверятся созданные ресурсы, а также ссылки на ресурсы, созданные в чартах.

9. Окно редактора.

10. Текущее состояние работы Monokle. Может быть: None, Cluster mode, Helm Preview и, возможно, Kustomize preview.

11. Настройки. Здесь можно выбрать версию Kubernetes, задать местоположение .kube/config и настроить, как все это будет работать.

Старт с нуля

В этот раз я выбрал пункт «Создание манифеста с нуля». Создал папку для нового проекта и попробовал накидать в нее файлов из темплейтов. На мой взгляд, наиболее востребованными из темплейтов могут быть: Advanced Pod, RoleBinding and Service Accounts, а также Basic Kubernetes StatefulSet. Я выбрал Advanced Pod, чтобы понять, как происходит этот процесс, и что будет дальше.

В результате получилось что-то визуально похожее на то, с чем можно начать работать.

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

Макет проекта Helm

На этот раз я решил создать макет проекта на Helm.

Командой helm create mytestproject я получил заготовку для будущего проекта. После этого сразу же заполнилась вкладка для работы с Helm-чартами и появилась кнопка Install в правом верхнем углу для установки Helm Chart в Kubernetes (Во второй итерации была только кнопка Deploy, которая делает почти то же самое. Но после нее в кластере очень тяжело будет найти, что и откуда выкатилось. Также K8s не будет следить за тем, живо оно или нет).

Вот теперь я уже приблизился к тому, что хотел увидеть: структура в левом столбце очень напоминала мне ту, с которой я постоянно работаю — здесь создался полноценный макет проекта.

При выборе файла values.yaml справа от него появляется кнопка  Preview, при нажатии на которую темплейты заполняются значениями из этого файла. Вот так выглядит созданный чарт:

Текущее состояние Monokle перешло в Helm Preview. В этом режиме в среднем блоке Navigator можно просматривать, какие ресурсы будут созданы в кластере. Этот режим, как следует из названия, не позволяет ничего редактировать, но зато дает возможность установить сгенерированное в Kubernetes и посмотреть, не появились ли какие-либо нестыковки в ресурсах.

Дальше я решил попробовать что-нибудь задеплоить в предварительно поднятый на машине Minikube. Теперь в дело пошла кнопка Install: нужно выбрать файл values.yaml, а затем либо предварительно перейти в Helm Preview и посмотреть, что же будет деплоиться, либо, если это уже готовый чарт, который нужно просто установить.

Так как я ничего не кастомизировал, появилось еще одно окно с выбором:

После создания нового пространства имен test-helm Helm-чарт успешно задеплоился:

Далее можно много рассказывать о том, что где находится, как создавать ресурсы, как их редактировать, как сверять то, что в чартах, с тем, что в кластере… Но я остановился на этом этапе, по одной простой причине: я понял, что Monokle лично мне не подходит.

Плюсы и минусы Monokle

Что мне понравилось в Monokle и, возможно, заставит читателя обратить свое внимание на продукт (а он несомненно этого заслуживает):

• Можно создать почти любой ресурс Kubernetes через GUI (подробнее про создание ресурсов).

• Встроенные ссылки по описанию текущего ресурса на kubernetes.io. Доступно в Preview Mode и в окне редактора.

• Подсветка синтаксиса. Например, если ошибся в написании имени Secret’а, то Monokle подскажет, что такого Secret’а нет (неявное указание на ошибку в имени). Аналогично и с другими ресурсами, где есть перекрестные ссылки:

  

  

• Проверка на ошибки всего чарта целиком. В блоке навигатора чарты с ошибками или предупреждениями будут подсвечены соответствующим символом:

  • желтый треугольник с восклицательным знаком — показывает ссылки на несуществующие ресурсы;

  • восклицательный знак в красном кружке — сообщает о синтаксических ошибках. Подробнее с этими функциями можно ознакомиться в официальной документации.

• В Preview Mode можно перемещаться туда, где задана сущность, а не искать ее вручную по всем файлам. Сделать это можно с помощью кнопки.

• При работе в режиме Helm доступно использование различных команд Helm’a. Так, например, можно задавать окружения через Preview Configuration:

  

• Возможность подключения к кластеру через .kube/config и просмотра уже имеющихся сущностей:

  

• Режим сравнения, в котором можно сравнить свой чарт с тем, что уже есть в Kubernetes (выбирается в окне Navigator кнопкой с двойными синими стрелочками):

  

• Декодирование base64 при наведении курсора мыши:

  

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

Что не понравилось:

• Не все файлы можно открыть на редактирование (многое уже исправлено в версии 1.10).

• Нет поддержки Git’а. При необходимости придется пользоваться терминалом или сторонними утилитами.

• Конфиги Preview Configuration сохраняются в самом Monokle и не привязаны к проектам.
  Таким образом, вы получаете полный набор конфигов от разных проектов для всех проектов сразу.

• Отдельно стоит отметить, что Monokle несовместим со структурой папок и темплейтов утилиты werf. Поэтому лично для меня софт оказался не настолько полезным, как я себе представлял.

Ну что же, остаюсь на VsCode от Microsoft — старом добром редакторе с кучей плагинов, в том числе и для Kubernetes.

Заключение

В статье я рассмотрел свой личный опыт тестирования Monokle, программы для управления чартами в Kubernetes. Мои ожидания не оправдались. Но впечатления субъективны, поэтому другим эта программа может показаться, наоборот, удобной и полностью удовлетворяющей запросы.

У Monokle хороший набор инструментов для создания почти любого ресурса Kubernetes, он позволяет легко выбрать необходимую сущность. Утилита может пригодиться в освоении K8s. Ее можно использовать как справочный материал.

Если у вас уже есть Helm-чарты, однозначно советую присмотреться и попробовать Monokle. При этом назвать его самодостаточным софтом я не могу, лучше использовать его в связке с другими решениями как дополнение.

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

P.S.

Читайте также в нашем блоге:

• «Обзор Kalm — веб-интерфейса для деплоя приложений и управления ими в Kubernetes»;

• «Обзор фреймворка cdk8s для «программирования» Kubernetes-манифестов»;

• «Обзор Lens — IDE для Kubernetes».