## Мой стек DevOps в 2026 году

опубликовано 1 мар. 2026 г. ~ 5 мин чтения теги: #devops#docker#kubernetes#cloudflare

Контекст

Я DevOps-инженер в movecloser - польском софтверном бюро, где строю и поддерживаю инфраструктуру для клиентских проектов. Параллельно веду собственные проекты с открытым исходным кодом (donata, starlight-auth, этот сайт) и инфраструктуру Flightcore Studios. Мой стек должен работать на двух уровнях: корпоративном (movecloser) и личном (собственные серверы, домашние лаборатории).

Эта статья - обзор инструментов, которые я реально использую в 2026 году. Не список «интересных технологий с Hacker News», а набор, прошедший естественный отбор ежедневного использования.

Контейнеризация - Docker повсюду

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

Многоэтапная сборка

Стандартом является многоэтапная сборка - отдельный этап с полным инструментарием, отдельный рантайм с минимальным образом. Для приложений Node.js это разница между образом в 1,2 ГБ и 180 МБ.

# Этап сборки
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build

# Продакшн-этап
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
CMD ["node", "dist/index.js"]

Docker Compose для разработки

Для локальной разработки - docker-compose.yml с полным стеком: база данных, кеш, приложение, обратный прокси. Одна команда docker compose up - и среда идентична продакшну. В movecloser у каждого проекта свой compose с предустановленными сидами и миграциями.

Оркестрация - Kubernetes там, где это имеет смысл

Kubernetes - не ответ на каждый вопрос. Для моих личных проектов - VPS с Docker Compose достаточно. Но в movecloser, где мы управляем десятком с лишним сервисов с разными циклами развёртывания, требованиями масштабирования и SLA, - Kubernetes решает реальные задачи.

Что K8s делает хорошо

Скользящие обновления - развёртывание без простоя с автоматическим откатом. Один неудачный билд не кладёт продакшн.
Лимиты ресурсов - изоляция ресурсов между сервисами. Одна утечка памяти не убивает остальные.
Управление секретами - интеграция с external secrets operator, ротация без перезапусков.

Чего избегаю

Переинженеринг - Helm-чарты с сотнями параметров для простого CRUD-приложения. Обычный набор YAML-манифестов читаемее и проще для отладки.
K8s насильно - личные проекты (donata, szymongwozdz.pl) работают на обычном Docker Compose за Cloudflare Tunnel. Им не нужно автомасштабирование или service mesh.

Инфраструктура как код - Terraform

Terraform управляет облачной инфраструктурой - ресурсы AWS/GCP, DNS-записи в Cloudflare, кластеры K8s. Ключевой принцип: если я могу кликнуть это в консоли, я могу описать это в HCL.

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

Удалённое состояние в S3 с блокировкой в DynamoDB. У каждой команды в movecloser свой workspace. Для личных проектов - Terraform Cloud на бесплатном плане, потому что поддерживать собственный бэкенд состояния для трёх проектов - перебор.

# Типичный рабочий процесс
terraform plan -out=tfplan
# просмотр плана
terraform apply tfplan

Модуляризация

Собственные модули для повторяющихся паттернов - VPC с предопределённой топологией, кластер EKS с разумными настройками по умолчанию, бакет S3 с политиками хранения. Модули версионируются в отдельном репозитории, ссылки через git-теги.

CI/CD - GitHub Actions

После экспериментов с GitLab CI, Jenkins и CircleCI - GitHub Actions победил за счёт интеграции с экосистемой, в которой я уже живу. Репозитории на GitHub, ревью кода в PR, рабочие процессы рядом с кодом.

Паттерны, которые работают

Переиспользуемые рабочие процессы - общие конвейеры (сборка → тесты → развёртывание) как отдельные workflow, вызываемые из репозиториев проектов. Изменение в одном месте распространяется повсюду.
Правила защиты окружения - развёртывание на продакшн требует подтверждения. Автоматическое развёртывание на staging при каждом слиянии в main.
Агрессивное кеширование - кеш Docker-слоёв, кеш зависимостей, артефакты сборки. Разница между 12 минутами и 3 минутами на конвейер.

# Фрагмент workflow с кешированием
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: ${{ runner.os }}-npm-

Периферия и CDN - Cloudflare

Cloudflare - моё решение по умолчанию для периферии - DNS, CDN, WAF, Tunnel, Workers. Этот сайт (szymongwozdz.pl) раздаётся статически с Cloudflare Pages - ноль серверов для обслуживания, автоматическое развёртывание из GitHub, SSL без настройки.

Cloudflare Tunnel

Для сервисов, которым нужен публичный доступ, но которые работают на частном сервере, - Tunnel вместо открытия портов. Donata, моя self-hosted система донатов для стримеров, работает именно так: Docker Compose на VPS, Cloudflare Tunnel как единственная точка входа. Никаких публичных IP, никаких открытых портов, никаких стресс-тестов файрвола.

Workers и KV

Лёгкие функции на периферии - перенаправления, A/B-тестирование, валидация токенов. Для сайта Flightcore Studios я использую Workers для обработки контактных форм без серверного бэкенда.

Что изменилось за последние годы

Отказался от Ansible в пользу контейнеризации. Конфигурация сервера - теперь Dockerfile + compose, а не плейбук с сотней задач.
Меньше AWS, больше Cloudflare - для личных проектов. AWS - мощный инструмент, но ценовая модель требует выделенного бухгалтера.
Упрощённый мониторинг - с Prometheus + Grafana + AlertManager перешёл на uptime-kuma + логи в stdout. Для малых проектов полный стек наблюдаемости - это издержки, которые не окупаются.
PostgreSQL как база по умолчанию - после лет экспериментов с MongoDB, Redis как основным хранилищем, SQLite - PostgreSQL решает 95% задач и не преподносит сюрпризов.

Итого

Мой стек в 2026 году: Docker для упаковки, Kubernetes для оркестрации (там, где это оправдано), Terraform для управления инфраструктурой, GitHub Actions для CI/CD, Cloudflare на периферии. Он не идеален, но проверен боем - каждый из этих инструментов я использую ежедневно минимум два года.

Главный урок? Хороший стек - тот, который ты знаешь достаточно хорошо, чтобы отлаживать его в три часа ночи. А не тот, у которого больше всего звёзд на GitHub.