Часто типичная домашняя лаборатория представляет собой смесь файлов Docker Compose, нескольких отдельных хостов контейнеров, а также кластера Docker Swarm. При развертывании приложений приходится постоянно следить за обновлением контейнеров во всей среде, а локальные изменения могут перестать соответствовать репозиторию Git. Подобные ситуации не являются критическими, но создают мелкие проблемы. Более серьезная проблема заключается в отсутствии единого источника истины. То, что работает в рабочей среде, не всегда соответствует тому, что находится в коде.
Внедрение подхода GitOps позволяет полностью отказаться от ручного развертывания контейнеров. Ниже описано, как и почему это работает.
Что на самом деле означает GitOps в домашней лаборатории
Термин GitOps может показаться модным словом, актуальным только для крупных корпоративных сред. Но по сути это довольно простая идея. Вместо ручного развертывания приложений абсолютно все определяется в Git. Это включает в себя:
- Манифесты Kubernetes
- Helm-чарты
- Конфигурации приложений
- И даже определения инфраструктуры
После этого репозиторий Git становится источником истины. Если чего-то нет в Git, этого не должно быть и в среде. Любому, кто управляет домашней лабораторией, рекомендуется переходить на подход на основе Git для хранения манифестов, файлов Docker Compose и так далее.
При традиционном подходе некоторые процессы все равно остаются ручными. Конвейеры CI/CD могут автоматически развертывать сервисы при обновлении кода, но не для всех приложений, особенно если используются стандартные публичные образы.
Для обеспечения безопасности и надежности часто используется полноценный кластер Kubernetes на базе ОС Talos Linux под управлением Omni. Это отличное решение для безопасного и эффективного управления Kubernetes.
В сочетании с полноценным кластером Talos целесообразно использовать ArgoCD. ArgoCD — это решение, которое позволяет непрерывно сравнивать то, что работает в кластере, с тем, что определено в Git. Если в кластере происходит смещение конфигурации (drift), ArgoCD автоматически исправляет его.
Это означает полное отсутствие ручных команд kubectl apply или docker compose up -d. Больше не нужно входить на узлы для внесения изменений. Все данные берутся исключительно из Git. В масштабах лаборатории это позволяет перестать думать о самом развертывании приложений и начать мыслить категориями управления желаемым состоянием в репозитории Git. Кроме того, эти навыки напрямую применимы и в промышленных средах.
Как структурировать репозиторий GitOps
Одним из первых шагов является настройка структуры репозитория Git для подготовки к GitOps. Рекомендуется использовать чистую и масштабируемую иерархию.
На верхнем уровне репозиторий может быть организован следующим образом:
- Папка верхнего уровня для сред или кластеров
- Папка для основных компонентов инфраструктуры
- Папка для приложений
Логика заключается в использовании папки bootstrap, где хранятся все манифесты пользовательских ресурсов (custom resource) приложений для развертываний ArgoCD и указывается, где именно в папке «apps» находятся сами манифесты. Папка apps предназначена для различных запущенных приложений, включая сам ArgoCD, который может управлять собой. Папка infra содержит манифесты инфраструктуры для среды Talos.
Возможны любые варианты организации, но иерархическая структура, в которой все логически распределено по назначению в кластере, является предпочтительной. Это также значительно упрощает настройку ArgoCD, поскольку потребуется общее место (путь), на которое он будет ориентироваться при поиске развертываний.
- clusters/
homelab/argocd/
ingress/
storage/ - apps/grafana/
prometheus/
nginx-proxy-manager/
gitea/
freshrss/
Каждая папка приложения содержит либо чистые манифесты Kubernetes, либо конфигурацию Helm-чарта. Ключевым моментом здесь является единообразие. Выбрав определенный шаблон, следует строго придерживаться его для каждого развертываемого приложения.
Настройка ArgoCD в кластере
Установка ArgoCD — одна из самых простых частей процесса. Его можно развернуть, используя простой набор манифестов или Helm-чарт.
После запуска главная сила ArgoCD заключается в том, что он позволяет создать жесткую связь между репозиторием Git, путем внутри репозитория и пространством имен кластера Kubernetes. Достаточно указать ArgoCD, где в Git находится приложение, и он берет на себя заботу о его синхронизации в кластер.
Одним из полезных шаблонов является подход «app of apps» (приложение приложений). Это означает наличие единого корневого приложения в ArgoCD, которое указывает на папку, содержащую пользовательские ресурсы для всех остальных приложений.
ВНИМАНИЕ: Дзен некорректно отображает коды и команды консоли. Для корректного копирования и использования рекомендуем смотреть оригинал статьи на сайте:
Пример кода в файле root-app.yaml выглядит следующим образом:
Default
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: root
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
# -----------------------------------------------------------------------
# ОБНОВЛЕНИЕ: Измените на ваш фактический URL репозитория GitOps
# -----------------------------------------------------------------------
repoURL: https://your-git-instance.com/devops/talos-lab.git
targetRevision: main
path: bootstrap
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- ServerSideApply=true
Когда ArgoCD синхронизирует корневое приложение, он автоматически создает и управляет всеми дочерними приложениями. Благодаря этому новые сервисы появляются и начинают синхронизироваться автоматически сразу при добавлении в репозиторий. Достаточно добавить файл «пользовательского ресурса» в папку bootstrap, который указывает на файлы приложения в папке apps. Таким образом ArgoCD понимает, как выполнять синхронизацию и развертывание.
Ниже показан результат после настройки ArgoCD для управления самим собой и корневым приложением:
Как теперь выглядит развертывание приложений
На этом этапе подход кардинально меняет правила игры. Создается папка для «нового приложения» (например, freshrss, phpipam или traefik). После размещения там файлов манифеста, файл «пользовательского ресурса» помещается в папку bootstrap.
- В папке apps создается директория для размещения файлов манифестов.
- В папку bootstrap помещается файл «пользовательского ресурса».
Пример файла пользовательского ресурса для freshrss представлен ниже. Жирным шрифтом выделены две важные настройки. Первая — это semver, которая указывает ArgoCD обновлять FreshRSS при выходе любой новой версии в рамках релиза 1.0. Это позволяет поддерживать развертывания в актуальном состоянии без использования Watchtower или других аналогичных инструментов.
Вторая настройка — это параметр path. Здесь ArgoCD настраивается на то, где именно искать конкретное приложение.
Default
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: freshrss
namespace: argocd
annotations:
argocd-image-updater.argoproj.io/image-list: freshrss=lscr.io/linuxserver/freshrss,db=mariadb
argocd-image-updater.argoproj.io/freshrss.update-strategy: latest
<strong>argocd-image-updater.argoproj.io/db.update-strategy: semver:^1.0</strong>
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds
notifications.argoproj.io/subscribe.on-sync-succeeded.email: [email protected]
notifications.argoproj.io/subscribe.on-sync-failed.email: [email protected]
notifications.argoproj.io/subscribe.on-health-degraded.email: [email protected]
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
source:
repoURL: https://your-git-repo.com/devops/talos-lab.git
targetRevision: main
<strong>path: apps/freshrss</strong>
destination:
server: https://kubernetes.default.svc
namespace: freshrss
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=false
- ServerSideApply=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
Подобный подход к управлению инфраструктурой дает огромные преимущества. До внедрения GitOps развертывание приложения могло выглядеть так:
- Подключение по SSH к узлу или машине управления.
- Запуск docker compose up или kubectl apply.
- Ручная настройка переменных окружения.
- Проверка логов в надежде, что все работает.
Теперь процесс выглядит следующим образом:
- Создание новой папки в репозитории Git для приложения.
- Добавление Helm-чарта или манифестов.
- Фиксация (commit) и отправка (push) изменений в Git.
- ArgoCD автоматически выполняет развертывание.
На этом все. Огромным преимуществом является то, что инфраструктура принудительно хранится в виде кода, что исключает путаницу при развертывании. ArgoCD обнаруживает изменения и автоматически синхронизирует приложение с кластером. В случае сбоя это немедленно отображается в пользовательском интерфейсе ArgoCD. Кроме того, можно выполнить откат, отменив коммит в Git, или воспользоваться встроенной функцией отката (rollback) изменений непосредственно из интерфейса Argo.
ArgoCD также предоставляет высокий уровень детализации для приложений и ресурсов, работающих в Kubernetes:
Работа с секретами и конфиденциальными данными
Одной из первых проблем, с которой приходится сталкиваться при использовании GitOps, является управление секретами. Хранение паролей или ключей API в виде открытого текста в репозитории Git недопустимо.
Существует несколько способов решения этой задачи. Один из вариантов — использование sealed secrets (запечатанных секретов). Это позволяет шифровать секреты и безопасно хранить их в Git, при этом расшифровать их может только сам кластер. Другой вариант — использование внешних менеджеров секретов. Такие инструменты, как Vault или более простые решения, могут внедрять секреты в кластер во время выполнения. Можно использовать встроенные секреты Kubernetes (Secrets), что является самым простым вариантом для начала. Однако в рабочем процессе GitOps это создает проблему, поскольку секреты, хранящиеся в Git, кодируются только в base64 и не обеспечивают должной безопасности.
Для быстрого тестирования или неконфиденциальных данных встроенные Secret подходят. Но для важных данных, таких как ключи API или пароли, настоятельно рекомендуется использовать sealed secrets или внешние решения для управления секретами, чтобы не раскрывать конфиденциальные данные в репозитории. Главное правило — тщательно продумать способы использования и безопасного хранения секретов.
Когда это может быть нецелесообразно
Несмотря на все преимущества, этот подход не всегда подходит для любых сред и, вероятно, не рекомендуется для начинающих. При запуске небольшого количества контейнеров на одном хосте использование GitOps с ArgoCD будет избыточным. Присутствует ощутимая кривая обучения, требующая времени для освоения всех сложностей интерфейса и логики работы.
Правильная настройка, безусловно, требует времени, но после её завершения обеспечивается бесшовный процесс развертывания. Кроме того, приобретаются реальные навыки, которые можно применять в профессиональной среде для построения сложных стратегий развертывания, способных вывести на новый уровень любую организацию, еще не внедрившую подход GitOps.
Процесс устранения неполадок также может усложниться. При возникновении проблем приходится иметь дело с несколькими уровнями одновременно. Это может отпугивать на начальном этапе. Однако использование ИИ для устранения неполадок Kubernetes значительно повышает уровень экспертизы и скорость решения проблем. Также присутствуют накладные расходы на поддержку работоспособности кластера Kubernetes, что само по себе является ценным навыком. Использование Talos Linux Kubernetes совместно с Omni существенно облегчает задачи по обслуживанию жизненного цикла, позволяя автоматизировать обновления узлов Talos и самого дистрибутива Kubernetes.
Заключение
Переход к полноценному подходу Kubernetes GitOps требует подготовки инфраструктуры, но после выполнения базовых шагов процесс полностью автоматизируется. Теперь вместо фокусировки на отдельных командах и ручных действиях можно сосредоточиться на определении желаемого состояния среды в коде. Хотя изначально это может показаться сложным и запутанным, на практике требуется лишь время на первоначальную настройку. Данный подход обоснованно считается оптимальным решением для управления развертываниями, предоставляющим максимальную эффективность и надежность.
Читайте про Свой умный дом локально:
🌐 Сайт
📱 Телеграм
📰 Дзен