DevOps

Если ты до сих пор делаешь next build прямо на продакшен-сервере — твой сервер действительно страдает. CPU в полку, OOM-kill, 502-е ошибки и долгие простои — это классика, которой пора положить конец.

В 2026 году стандарт индустрии — это раздельная сборка:

1. Собираем минимальный standalone-образ в облаке GitHub Actions.
2. Пушим его в GHCR (GitHub Container Registry).
3. На сервере делаем только pull + атомарный перезапуск.

Глава 1. Идеальный Dockerfile (Multi-stage + Standalone)

Весь секрет маленького и быстрого образа — в режиме standalone. Next.js сам вычисляет, какие файлы и части node_modules реально нужны для работы сервера, и копирует только их.

Когда проект выходит за рамки локальной разработки и начинает использовать CI/CD, возникает фундаментальный вопрос: каким образом безопасно передавать конфигурационные параметры в пайплайны сборки и деплоя. Речь идет не только о паролях к базам данных, но и о токенах контейнерных реестров, SSH-ключах, ключах подписи JWT, строках подключения к очередям сообщений и любых других параметрах, которые нельзя хранить в открытом виде.

Попадание чувствительных данных в Git-репозиторий — это не просто плохая практика. История коммитов сохраняется навсегда. Даже если секрет был удален в следующем коммите, он уже стал частью истории и может быть извлечен через git log, git show или при клонировании форка. В корпоративной среде это превращается в реальный риск при аудитах, расширении команды или при утечке доступа к репозиторию.

Было несколько проблем касаясь как технической части так и понимания в целом. Михаил быстро ответил на запрос, помог разобраться и решил проблеммы технические и помог разобраться в понимании, за что отдельное спасибо. Результатом доволен.

Ответ: Спасибо за отзыв! Рад помочь!

Все было сделано быстро и четко. Рекомендую

Представьте ситуацию: вы работаете над крутым проектом всю ночь. К 4 часам утра всё готово, вы делаете финальный git push и со спокойной душой идёте спать. А утром обнаруживаете, что ваш баланс в AWS обнулён, а на серверах запущен майнер. Что произошло? Оказывается, в одном из файлов вы оставили строчку: AWS_ACCESS_KEY_ID = "AKIA...".

Это классическая ошибка, через которую проходили тысячи разработчиков. В этой статье мы разберём, почему «просто удалить пароль» не поможет и как настроить автоматическую защиту, которая физически не даст вам совершить ошибку.

Написать Dockerfile просто: FROM node, COPY ., CMD run. Это работает, и для локальных тестов этого часто достаточно. Но когда такой образ попадает в CI/CD или, не дай бог, в продакшн, начинаются проблемы: сборка длится вечность, образ весит гигабайты, а безопасники хватаются за голову.

Разница между «работает» и «работает правильно» колоссальна. Давайте разберем четыре уровня оптимизации, которые отделяют любительскую поделку от надежного инженерного решения.

1. Фундамент: Выбор образа и детерминизм

Всё начинается с инструкции FROM. Многие по привычке берут полные образы (например, стандартную ubuntu или python:3.9), не задумываясь о последствиях.

Если вы занимаетесь self-hosting’ом, держите домашнюю лабораторию или управляете небольшим VPS, то наверняка знакомы с Portainer. Это де-факто стандарт: мощный, всеобъемлющий «швейцарский нож» для Docker.

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

Недавно я открыл для себя Dockge — инструмент от того же разработчика, что и популярный Uptime Kuma. Он заставил меня полностью пересмотреть подход к управлению контейнерами. В этой статье расскажу, почему Dockge может стать идеальной заменой Portainer для многих сценариев.

При работе с реальными проектами (смена CDN, миграция, рефакторинг) часто нужно массово заменить один URL на другой.

На первый взгляд задача кажется тривиальной: sed -i 's|old|new|g' **/* — и готово.

В реальности такой подход — это русская рулетка.

Неосторожная замена приводит к:

• 💀 Повреждению бинарных файлов (images, pdf, archives);
• 📉 Мусору в git-истории (бинарники помечаются как изменённые);
• 🚫 Невозможности чистого отката, если бэкап не был сделан.

В этой заметке разберём production-grade алгоритм: меняем только текст, не трогаем бинарники, делаем точечный бэкап.

Jitsi Meet из коробки отлично решает задачу видеоконференций. Связка Jitsi Meet + Jibri позволяет записывать встречи — и на этом многие установки останавливаются.

Но как только Jitsi начинает использоваться не эпизодически, а в рабочем процессе, очень быстро появляются вопросы:

• Где централизованно хранить записи?
• Как автоматически публиковать ссылки для команды?
• Как избавиться от тяжёлых MP4 и перейти к потоковому просмотру?
• Как раздавать записи по HTTPS, не раскрывая структуру каталогов?
• Как сделать всё это автоматически, без ручного участия администратора?

Ниже — полноценный продакшн-конвейер с кодом: от финализации записи Jibri до публикации в Notion и асинхронного транскодинга MP4→HLS с раздачей через Caddy.

В последние десять лет индустрия развёртывания веб-приложений прошла путь от FTP-скриптов и rsync до сложнейших систем оркестрации. Сегодня разработчики и небольшие команды всё чаще оказываются перед непростым выбором:

• либо платить серьёзную наценку за удобство PaaS-платформ (Heroku, Render, Fly.io),
• либо погружаться в когнитивную и операционную сложность Kubernetes.

Kamal предлагает третий путь: удобство современных облачных сервисов — на вашем собственном сервере.

Что такое Kamal

Kamal — это open-source CLI-инструмент от компании 37signals (создателей Basecamp и Ruby on Rails), предназначенный для деплоя веб-приложений поверх Docker без Kubernetes.