Komodo - оркестрация на docker-compose

[KRom]

Нашел на просторах интернета очень крутой проект Komodo

Что что-то типа кубера, дженкинса и ансибла в одном флаконе, но для docker-compose.

Почему я не выбрал кубер для дома?

1. Чистый K8S мега прожорлив и требует кучу серверов
2. k3s, minikube и аналоги поинтересней для 1 сервера, но если у вас 2-3 ноды, то не все нормально кластеризируются
3. Я пользую не только кубер, иногда чистый линукс, иногда виртуалки
4. Кубер stateless работа с хранилищами не всегда оптимальна, быстра, и есть. Если у вас облако с безконечным выделением дисков, то один вопрос, если мини ПК, то вместо полноценного PVC имеем какие-то папки на сервере
5. Довольно таки сложная конфигурация сервисов, если вы их сами пишете управляете, то это удобно, но для большинства самохостинг проектов есть docker run и все, в последнее время часто docker compose предлагается
6. У меня несколько нод проксмокса, но я сам распределяю сервисы по назначению, нагрузке на хранилище, наличию всяких аппаратных компонентов типа корала, размазывать условный vaultwarden с БД на одной ноде и сервером на другой смысла не вижу, мне проще хранить все в одном компоненте и при желании переносить на другие ноды, заморачиваться с этим в кубере нет желания
7. Самое простое бекапирование сервисов реализуется в Proxmox простым бэкапом контейнера

Мой подход к домашнему самохостингу описал в теме про Pulse, но если кратко, то

1. Кластер Proxmox
2. LXC контейнер с Alpine Linux и docker (смотрю в сторону podman) для каждого сервиса
3. В LXC контейнере
   3.1. docker-compose с сервисом или сервисами если они связаны, например, frigate, doubletake, compreface
   3.2. вспомогательные агенты типа docke, portainer-agent, komodo-periphery
   3.3. proxmox-backup-client в docker-compose с сервисом для бэкапирования файлов на сервер PBS
4. LXC контейнеры бэкапятся на PBS целиком
5. Для критически важных сервисов Proxmox HA

Что я пробовал еще

1. SSH и руки, но понятно, что не очень круто, зато работает
2. CI/CD в целом, ок для деплоя, для мониторинга то-то надо искать
3. Dockge - круто, что умеет docker run to docker-compose, но не очень круто работает с агентами, хорошо работает с существующими стеками
4. Portainer - швейцарский нож, но у меня не удалось нормально работать с существующими стеками, надо создавать из самого портейнера
5. Arcane - новый и перспективный проект, работает с существующими стеками, но агенты у него работают через одно место и очень плохо
6. Komodo - пока понравился, умеет очень многое и даже больше, с существующими стеками не очень хорошо работает, но их можно типа импортировать
7. Semaphore - это ansible UI, пока не осилил, но аналог 2 пункта с деплоем сервисов

Что умеет komodo

1. Управлять стеками docker-compose, причем, как это сделано в dockge когда создается папка с именем стека и туда складывается compose.yaml файл, портейнер мне не понравился тем, что у него свои правила
2. Работать с несколькими серверами, причем, это самая крутая тулза из всех
3. Собирать образы
4. Деплоить стеки
5. Всякие автоматизации
6. Мотиторинг, консоль, уведомления

Пока только первый день щупаю, ниже буду описывать сценарии использования

[KRom]

Сценарий 1

Самый просто сценарий

1. Заходим в komodo
2. Заходим в стеки
3. Жмакаем создать новый стек и вводим имя
4. Выбираем сервер для разворачивания (по-умолчанию это сам komodo, но можно добавить еще)
5. Выбираем тип UI Defined и заполняем compose файл
   
   
6. Далее жмакаем сохранить, деплой, и ждем успеха

Ну тут все как в docke, portainer особого смысла не вижу останавливаться подробно

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

[KRom]

Сценарий 2

Чуть сложнее, мне нравится больше, может на нем остановлюсь

1. Создаем GIT репозиторий на вашем Git сервере, это может быть github ну или в режиме самохостинга я остановился на Forgejo
   
   
2. Создаем ветку с названием сервиса, например pulse и добавляем туда README и compose.yaml
   
   
   
   Причем, важно, чтобы был именно compose.yaml
3. Создаем пользователя в GIT и добавляем креды в Komodo, ну понятно, это чтобы он мог скачать репу
   
   
4. Создаем стек
   
   
   
   Тут надо указать сервер с репой, аккаунт, название репы и ветку
   Поскольку, у нас будет один репозиторий и в нем для каждого сервиса своя ветка, то указываем нужную ветку
5. Настраиваем вебхук
   
   
   
   Тут по поводу Force deploy я пока не уверен
6. Нажимаем Save а потом Deploy
   
   
   
   Видим, что у нас сервис задеплоился, мы сюда ее добавили ссылку
7. Можем посмотреть что там у нас задеплоилось
   
   
   
   
   
   
   И даже провалиться в консоль контейнера
   
   
   
   А еще для сервера посмотреть системные ресурсы
   
   
8. Идем в GIT и добавляем CI/CD с тригером деплоя сервиса
   
   

У меня ChatGPT вот такой скрипт написал

# Определяем текущую ветку без refs/heads/
        BRANCH="${GITHUB_REF#refs/heads/}"

        echo "Deploying branch: $BRANCH"

        # Подставляем ветку в URL
        URL="${KOMODO_URL/\{BRANCH\}/$BRANCH}"
        echo "Final webhook URL: $URL"

        # Готовим payload в формате GitHub push event
        PAYLOAD=$(jq -n \
          --arg ref "$GITHUB_REF" \
          --arg repo "$GITHUB_REPOSITORY" \
          --arg pusher "$GITHUB_ACTOR" \
          '{ref: $ref, repository: {full_name: $repo}, pusher: {name: $pusher}}'
        )

        echo "Payload: $PAYLOAD"

        # Считаем подпись
        SIGNATURE="sha256=$(echo -n "$PAYLOAD" | openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" | sed 's/^.* //')"

        echo "Signature: $SIGNATURE"

        # Отправляем запрос и сохраняем ответ
        RESPONSE=$(mktemp)
        HTTP_CODE=$(curl -s -w "%{http_code}" -o "$RESPONSE" -X POST "$URL" \
          -H "Content-Type: application/json" \
          -H "X-Hub-Signature-256: $SIGNATURE" \
          -d "$PAYLOAD")

        echo "---- Komodo Response ----"
        cat "$RESPONSE"
        echo "-------------------------"

        if [ "$HTTP_CODE" -lt 200 ] || [ "$HTTP_CODE" -ge 300 ]; then
          echo "❌ Webhook failed with HTTP status $HTTP_CODE"
          exit 1
        fi

        echo "✅ Webhook sent successfully! Status: $HTTP_CODE"

Тут важно учесть, что ветка в гите должна называться аналогично названию стека в komodo т.к. ссылка для webhook генерируется на основе ветки и CD тригеррит именно тот стек, который у нас сейчас обновился
9. Настраиваем секреты и переменны и коммитим код

Видим, что при коммите происходит обновление сервиса, а на 6 шаге видно было, что он деплоился

Ну и в качестве бонуса: можно создать шаблон сервиса, чтобы меньше вводить при его создании

[KRom]

Сценарий 3

Вот еще статья по настройке https://nickcunningh.am/blog/how-to-automate-version-updates-for-your-self-hosted-docker-containers-with-gitea-renovate-and-komodo
Но я пока не понял момент с Renovate

Статья описывает похожий на Сценарий 2

1. Но разделение на стеки идет не на уровне веток, а одна ветка с каталогами стеков
2. Далее, через Komodo идет скачивание GIT репозитория на сервер
3. Стеки создаются на на основе git репы, а на основе файлов на сервере
4. Через Renovate и вебхуки идет нотификация Komodo
5. Komodo обновляет стеки при изменении
6. В конце статьи еще описывается механизм обновления в случае выхода новых версий docker образов или типа того, но надо разбираться, сам komodo умеет обновлять стеки

Кстати, по поводу 6 пункта, из всех опробованных мною проектов только komodo имеет в бесплатной версии функционал отслеживания обновлений образов, watchtower подобные проекты остаются только.

[KRom]

Сценарий 0

Начал осваивать Semaphore UI - веб сервер для запуска Ansible, Python, Terrafor, Terragrunt, OpenTofu и что-то там еще

Написал Ansible Playbook, который получает на вход чистую операционку

1. Обновляет пакеты, настраивает часовой пояс и прочее
2. Устанавливает докер
3. Устанавливает туда komodo агента
4. Регистрирует сервер в Komodo

---
- name: Настройка ноды Komodo
  hosts: komodo_nodes
  gather_facts: false
  become: false
  roles:
    - common
    - docker
    - komodo_periphery
    - komodo_register

Полную версию тут не публикую по причине сырости и размеров

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

[KRom]

Сценарий 2.1

В продолжение спама про данный продукт
Освоил шаблоны для серверов и стеков

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

• Я шаблон сервера использую при регистрации нового сервера ansible
• Шаблоны стеков, например, для моего кластера трафика
• Ну и мой основной шаблон стека git-template где заполнены все поля, при создании нового стека достаточно заполнить

1. Название стека
2. Север для разворачивания
3. Название ветки в git репозитории

Все остальные данные заполняются автоматом, даже CI/CD описанный мною выше работает автоматически

[admin]

@KRom

В продолжение спама

не согласная я(с)

Очень хорошая заметка-статья получается.
Уверен, что найдет своего читателя.

Ром, лайк \ подписка \ колокольчик.