Андрей Полуянов

DevOps / SRE инженер

Ханты-Мансийск • удаленный / гибридный формат

andrey@poluyanov:~$ cat aboutme.txt

Начинающий DevOps / SRE инженер.

Не ограничиваюсь теорией: учусь через практику и строю полноценные инфраструктурные проекты.

Пишу статьи на темы, связанные с DevOps. В процессе работы над ними глубоко разбираюсь в конкретных вопросах, а затем в интересной форме делюсь полученными знаниями.

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

andrey@poluyanov:~$

Ключевой проект

Internal AI Knowledge Assistant

End-to-end DevOps/SRE-кейс: в котором я спроектировал и реализовал внутреннего корпоративного AI-ассистента.

Проект развивался поэтапно: сначала локальный MVP в Docker Compose, затем Этап A (4 VM) и Этапы B и C (single-node k3s).

Сервисный стек: Wiki.js, n8n, PostgreSQL, Redis, Ollama.

Технологический стек: Yandex Cloud, Terraform, Ansible, Docker Compose, Nginx, k3s, Helm, GitHub Actions, Prometheus, Alertmanager, Grafana, Loki, Alloy.

Репозиторий Корневой README

Документация Этапа A Документация Этапов B и C

Общая сервисная модель

[ Knowledge author ]
        │ добавляет запись
        ▼
[ Wiki.js ]
  единый источник знаний
        │ сохраняет страницы
        ▼
[ PostgreSQL ]
  Wiki.js pages · n8n internal data · dialog memory

[ Client ]
    │ UI / API / webhook request
    ▼
[ n8n-web ]
    │ кладёт выполнение в очередь
    ▼
[ Redis queue ]
    │ передаёт job
    ▼
[ n8n-worker ]
    │ выполняет agent workflow
    ├──► [ PostgreSQL ] — pages + dialog memory
    ├──► [ Ollama ] — local LLM backend
    └──► [ Guard logic ] ok: save / fail: «Нет данных»
    │
    ▼
[ n8n-worker ] → [ n8n-web ] → [ Client ] → [ HTTP JSON response ]

Эволюция платформы

Этап A

Terraform + Ansible + Docker Compose + Ansible Vault

Инфра-контур: 4 VM в Yandex Cloud (wiki edge, db, n8n, ollama)
Модель деплоя: Docker Compose + Ansible roles/playbooks
Точка входа: Nginx reverse proxy
Выпуск сертификатов: certbot + TLS Let’s Encrypt HTTP-01 (Ansible role edge_tls_acme)
Доступы: взаимодействие с n8n/wiki по HTTPS только из разрешенных allow-list CIDR
Админ-доступ: SSH 22 только из admin allow-list CIDR
Межсервисные правила: потоки между VM разрешены только по нужным направлениям (SG + firewalld), PostgreSQL дополнительно ограничен через pg_hba.conf по /32 для wiki и n8n
Сеть: во внешний периметр выведен только edge/bastion-хост; приватные VM без public IP, прямой внешний доступ к сервисным портам закрыт, доступ к внутренним VM — только через SSH jump (ProxyJump) через bastion
Эксплуатация: smoke checks + backup/restore + runbook-проверки
Секреты: Ansible Vault

Этап B

Terraform + Ansible bootstrap + k3s + Helmfile + SOPS

Инфра-контур: single-node k3s в Yandex Cloud + namespaces
Модель деплоя: Helm/Helmfile (platform/apps слои)
Точка входа: Traefik ingress controller
Выпуск сертификатов: cert-manager + ClusterIssuer + TLS Let’s Encrypt HTTP-01
Доступы: взаимодействие с n8n/wiki по HTTPS только из разрешенных allow-list CIDR
Админ-доступ: SSH 22 и Kubernetes API 6443 только из admin allow-list CIDR
Сетевой контроль: NetworkPolicy default deny + explicit allow для сервисных потоков; (SG + UFW) ограничения доступа к k3s VM
Сеть: zero-trust внутри кластера: baseline default deny и только явные межсервисные allow-правила, включая отдельный доступ к HTTP-01 solver-подам для выпуска/обновления TLS
Эксплуатация: bootstrap smoke + runbook/smoke проверки + backup CronJob + restore/import/model-pull jobs
Секреты: SOPS + encryption at rest в k3s

Этап C

Prometheus + Alertmanager + Grafana + Loki + Alloy + GitHub Actions

Observability + CI/CD поверх Kubernetes-контура
CI/CD: GitHub Actions с self-hosted runner-VM: 1 CI workflow с 5 независимыми джобами и 2 CD workflow для Kubernetes-контура
Диагностика: метрики, логи, алерты и пробы доступности для анализа
Grafana: 3 кастомных дашборда с состоянием кластера, приложений, HTTP-доступности, ресурсов и логов
Алертинг: 6 групп правил для доступности сервисов, ошибок, задержек, рестартов подов, ресурсов, PVC и blackbox-проб
Blackbox monitoring: 2 публичные HTTP-пробы и 5 внутренних проб
Golden signals: метрики и правила алертинга закрывают latency, traffic, errors и saturation на уровне приложений, ingress и ресурсов кластера
SLI/SLO: 13 зафиксированных SLI/SLO для доступности, успешности запросов, задержек и работоспособности критичных сервисов

Материалы этапа

Быстрые переходы к якорям корневого README.

Демо пользовательского сценарияВозможности системы от лица клиента Демо observabilityДашборды и сценарии отказов SLO и SLIЦели, индикаторы и контроль качества Демо CI/CDСценарии автоматических и ручных сценариев CD

Публикации

Andrey172 1 ноя 2025 в 11:13

Как я уменьшил Docker-образ Go-приложения с 1.92 GB до 9 MB

DevOps * Go * Системное администрирование *

Обложка статьи про оптимизацию Docker-образа

Читать полностью

Просмотры33K

Рейтинг+81

Закладки288

Комментарии58

Репосты Хабр

В статье пошагово разобрал оптимизацию Docker-образа для Go-приложения: от наивного подхода до multi-stage с использованием alpine, scratch, distroless в качестве runtime-образов. Бонусом продемонстрировал подход с использованием UPX-сжатия.

~