AgenticOps, часть №2 - базовые компоненты
Начну с того, на чём стоит сама платформа - с набора базовых инфраструктурных компонентов.
Общие принципы подбора компонентов
● self-hosted
● для полноценной работы не нужен интернет
● наличие стабильного внешнего API
● ничего не конфигурируется ad-hoc, только IaC/CaC, с занесением в git
● современные LLM хорошо знают каждый компонент
Допущения
● упрощенная модель безопасности (всё-таки это homelab)
● в кубере только свои приложения, всё остальное - за его пределами, в контейнерах
● без распределенной файловой системы (пока что)
● это всё постоянно живёт и меняется, но теперь уже не бесконтрольно
● ремонт невозможно закончить, его можно только прекратить (с)
Provisioning
● Ubuntu, macOS, Synology NAS - всё пошло в дело в качестве хостов разных сервисов :)
● Incus - системные контейнеры, внутри них живут ноды кубера и CI-раннеры
● k3s - легковесный flavor кубера. Взял именно его вместо ванильного k8s: один бинарь, просто ставится через Ansible - для homelab в самый раз.
Прагматизм придушил желание собрать кубер руками (да что ж я, зря чтоль CKA(D)?)
● Ansible - вся настройка хостов, OS, системных и прикладных сервисов кодом (в планах pyinfra, чтобы уйти от YAML-программирования)
● Pulumi - для управления ресурсами, которые нужны приложениям (базы, очереди, DNS-записи, s3, креденшиалы к ним и т.п.).
Ansible+Pulumi дают инвентаризацию инфры - машиночитаемую, верифицируемую и синхронизируемую с актуальным состоянием - это маст хэв и для людей, и для агентов
Доставка
Упор - на шустрый и программно управляемый путь от коммита до деплоя.
● Gitea + Actions - локальный git и CI на своём железе, без завязки на GitHub (у которого доступность недавно потеряла все девятки 😱)
● Zot - реестр образов для контейнеров. Переехал на него с Docker Registry, потому что Zot - сразу OCI-нативный и полегче
● Argo CD - GitOps/CD-контроллер для кубера. Берёт желаемое Kustomize-состояние из gitops-репозитория и синкает k3s-кластер под него
● Nexus - прокси-кэш пакетов npm/pip/NuGet/etc, чтобы не дёргать внешние реестры на каждый билд. Плюс, тут же и кэш весов моделей с HuggingFace
Данные
● Postgres + pgvector + pg_trgm, Redis, RabbitMQ - ну тут очевидно
● MinIO - S3-совместимое хранилище (в планах - переезд в Garage)
AI
● Llama.cpp и vLLM - инференс LLM-моделей, эмбеддеров и реранкеров
● Whisper, Parakeet - локальное распознавание речи для видео, звонков и просто диктовки
● LiteLLM - как AI-гейтвей для запросов со стороны приложений
● MLflow, Arize Phoenix - для работы с данными экспериментов и эвалов
Наблюдаемость
Тут всё ради дебага агентами - они должны уметь быстро искать ошибки, сопоставлять их с тем, что ещё могло происходить в системе в это время и отслеживать цепочки событий, которые к ним привели.
Это требует культуры и со стороны самого приложения, так что соответствующие практики форсятся на уровне кодинговых агентов.
● Alloy - OTLP-endpoint для того, чтобы принимать логи и трейсы со всех приложений и агентов
● Prometheus - сбор метрик
● логи - в Loki, трейсы - в Tempo, графики - в Grafana (о, а это пропеть можно)
Разное
● SOPS/age - тулинг для шифрования секретов, в частности позволяет их хранить в git (для не совсем уж параноиков) и не бояться, что агент их случайно прочитает
● step-ca - внутренний certificate authority. Нужен, чтобы локальные домены получали настоящий TLS без постоянных предупреждений о self-signed сертификатах
● Technitium DNS - свой DNS для адресов в локалке, чтобы забыть про hosts как страшный сон и не плодить кучу srv01:83, my-pc:4443
● MailPit - ловушка для исходящей почты в деве, чтобы тестовые письма не улетали реальным людям, ну и ещё чтобы агенты сами почту проверять могли
Ничего экзотического тут нет, и это намеренно - обычный production-подобный набор, просто адаптированный для homelab и быстрых экспериментов.
Плюс, с экзотикой было бы намного сложнее почти всё поднять с помощью агентов.
Собственно платформенная часть начинается слоем выше, и об этом расскажу дальше.
#ai #agentic_ops #devops
Начну с того, на чём стоит сама платформа - с набора базовых инфраструктурных компонентов.
Общие принципы подбора компонентов
● self-hosted
● для полноценной работы не нужен интернет
● наличие стабильного внешнего API
● ничего не конфигурируется ad-hoc, только IaC/CaC, с занесением в git
● современные LLM хорошо знают каждый компонент
Допущения
● упрощенная модель безопасности (всё-таки это homelab)
● в кубере только свои приложения, всё остальное - за его пределами, в контейнерах
● без распределенной файловой системы (пока что)
● это всё постоянно живёт и меняется, но теперь уже не бесконтрольно
● ремонт невозможно закончить, его можно только прекратить (с)
Provisioning
● Ubuntu, macOS, Synology NAS - всё пошло в дело в качестве хостов разных сервисов :)
● Incus - системные контейнеры, внутри них живут ноды кубера и CI-раннеры
● k3s - легковесный flavor кубера. Взял именно его вместо ванильного k8s: один бинарь, просто ставится через Ansible - для homelab в самый раз.
Прагматизм придушил желание собрать кубер руками (да что ж я, зря чтоль CKA(D)?)
● Ansible - вся настройка хостов, OS, системных и прикладных сервисов кодом (в планах pyinfra, чтобы уйти от YAML-программирования)
● Pulumi - для управления ресурсами, которые нужны приложениям (базы, очереди, DNS-записи, s3, креденшиалы к ним и т.п.).
Ansible+Pulumi дают инвентаризацию инфры - машиночитаемую, верифицируемую и синхронизируемую с актуальным состоянием - это маст хэв и для людей, и для агентов
Доставка
Упор - на шустрый и программно управляемый путь от коммита до деплоя.
● Gitea + Actions - локальный git и CI на своём железе, без завязки на GitHub (у которого доступность недавно потеряла все девятки 😱)
● Zot - реестр образов для контейнеров. Переехал на него с Docker Registry, потому что Zot - сразу OCI-нативный и полегче
● Argo CD - GitOps/CD-контроллер для кубера. Берёт желаемое Kustomize-состояние из gitops-репозитория и синкает k3s-кластер под него
● Nexus - прокси-кэш пакетов npm/pip/NuGet/etc, чтобы не дёргать внешние реестры на каждый билд. Плюс, тут же и кэш весов моделей с HuggingFace
Данные
● Postgres + pgvector + pg_trgm, Redis, RabbitMQ - ну тут очевидно
● MinIO - S3-совместимое хранилище (в планах - переезд в Garage)
AI
● Llama.cpp и vLLM - инференс LLM-моделей, эмбеддеров и реранкеров
● Whisper, Parakeet - локальное распознавание речи для видео, звонков и просто диктовки
● LiteLLM - как AI-гейтвей для запросов со стороны приложений
● MLflow, Arize Phoenix - для работы с данными экспериментов и эвалов
Наблюдаемость
Тут всё ради дебага агентами - они должны уметь быстро искать ошибки, сопоставлять их с тем, что ещё могло происходить в системе в это время и отслеживать цепочки событий, которые к ним привели.
Это требует культуры и со стороны самого приложения, так что соответствующие практики форсятся на уровне кодинговых агентов.
● Alloy - OTLP-endpoint для того, чтобы принимать логи и трейсы со всех приложений и агентов
● Prometheus - сбор метрик
● логи - в Loki, трейсы - в Tempo, графики - в Grafana (о, а это пропеть можно)
Разное
● SOPS/age - тулинг для шифрования секретов, в частности позволяет их хранить в git (для не совсем уж параноиков) и не бояться, что агент их случайно прочитает
● step-ca - внутренний certificate authority. Нужен, чтобы локальные домены получали настоящий TLS без постоянных предупреждений о self-signed сертификатах
● Technitium DNS - свой DNS для адресов в локалке, чтобы забыть про hosts как страшный сон и не плодить кучу srv01:83, my-pc:4443
● MailPit - ловушка для исходящей почты в деве, чтобы тестовые письма не улетали реальным людям, ну и ещё чтобы агенты сами почту проверять могли
Ничего экзотического тут нет, и это намеренно - обычный production-подобный набор, просто адаптированный для homelab и быстрых экспериментов.
Плюс, с экзотикой было бы намного сложнее почти всё поднять с помощью агентов.
Собственно платформенная часть начинается слоем выше, и об этом расскажу дальше.
#ai #agentic_ops #devops