Делаем простой release через symlink!

Иногда приложение нужно выкладывать так, чтобы новая версия появлялась почти мгновенно, а откат занимал одну команду. Для этого часто используют директории releases и ссылку current.

Структура может быть такой:

/opt/app/releases/2026-08-29_1200
/opt/app/current -> /opt/app/releases/2026-08-28_1800

Сначала создаём новую папку релиза:

release="/opt/app/releases/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$release"

Потом копируем туда собранные файлы:

rsync -a ./dist/ "$release/"

До переключения current пользователи всё ещё смотрят на старую версию. Это удобно, потому что подготовка релиза не ломает рабочее приложение.

Переключение делается через ln -sfn:

ln -sfn "$release" /opt/app/current

Теперь current указывает на новую директорию. Само переключение происходит быстро, потому что меняется ссылка, а не копируются файлы поверх боевой папки.

Если нужен откат, можно вернуть ссылку на прошлый релиз:

ln -sfn /opt/app/releases/2026-08-28_1800 /opt/app/current

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

Такой подход полезен для простых серверов, статических сайтов, внутренних тулов и приложений без сложной deploy-платформы.

➡️ DevOps Ready | #практика

Linux Journey - маршрут по Linux с практическими темами!

На сайте собраны уроки по командной строке, файловой системе, процессам, permissions, пакетам, устройствам, networking, DNS, routing, logging и другим темам, которые нужны DevOps-инженеру и backend-разработчику.

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

Оставляю ссылочку на Linux Journey

➡️ DevOps Ready | #ресурс

📂 Шпаргалка по настройке оповещений в DevOps!

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

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Penguin Gym Linux - тренировка Linux-команд!

На сайте можно практиковать Linux-команды прямо в браузере. Есть виртуальный terminal, пошаговые уроки, задания, квизы, материалы по beginner Linux, LPIC-1 и отдельный маршрут в сторону DevOps.

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

Оставляю ссылочку на Penguin Gym

➡️ DevOps Ready | #ресурс

📂 Напоминалка по распределению конфигурации между Git и переменными окружения!

Правильное разделение настроек помогает безопасно управлять разными окружениями, не хранить секреты в репозитории и не создавать хаос в конфигурации. На картинке показаны 7 практик: от классификации параметров и принципов 12-Factor до работы с секретами, разделения dev, staging и prod, автоматической проверки и документирования конфигурации. Главное правило: код хранится в Git, значения приходят через ENV, а секреты находятся в защищённом хранилище.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Знали, почему readinessProbe не стоит заменять livenessProbe?

В Kubernetes часто добавляют health checks, но readinessProbe и livenessProbe нужны для разных вещей.

livenessProbe нужна, чтобы понять, жив ли контейнер вообще. Если приложение зависло и уже не может восстановиться, Kubernetes перезапустит Pod.

Простой пример проверки:

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

readinessProbe решает другую задачу. Она говорит, можно ли прямо сейчас отправлять трафик в этот Pod.

Например, приложение уже запустилось, но ещё прогревает кэш, ждёт миграции, подключение к базе или загрузку конфигурации. Перезапускать его в этот момент не нужно.

Для этого лучше сделать отдельный endpoint:

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080

Если readiness падает, Pod просто убирается из endpoints сервиса. Новые запросы туда не идут, но контейнер продолжает работать и может вернуться в строй.

А если slow start долгий, добавляют startupProbe:

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

Она даёт приложению время на старт и не позволяет livenessProbe убить контейнер слишком рано.

Состояние проб удобно смотреть через describe:

kubectl describe pod api-7f9c

liveness отвечает за перезапуск, readiness отвечает за трафик, startupProbe отвечает за долгий старт.

➡️ DevOps Ready | #совет

Знали, зачем в shell-скриптах иногда задают umask?

Когда скрипт создаёт файлы, права зависят не только от chmod в самом скрипте. На итоговые права влияет umask текущего процесса.

Обычный временный файл может получиться доступнее, чем хотелось бы:

touch backup.env
ls -l backup.env

Если внутри лежат токены, пароли или дампы конфигов, это уже опасно. Особенно на сервере, где есть несколько пользователей или служебных аккаунтов.

umask позволяет заранее запретить лишние права для новых файлов:

umask 077

После этого новые файлы обычно будут доступны только владельцу. Группа и остальные пользователи не получат чтение по умолчанию.

Например, так можно безопаснее создавать файл с секретами:

umask 077
printf '%s\n' "$TOKEN" > token.txt

Проверить результат можно через ls:

ls -l token.txt

Ожидаемый формат будет похож на 600. То есть владелец может читать и писать, а остальные не имеют доступа.

Для директорий это тоже работает:

mkdir private-backups

При umask 077 новая директория обычно получит права 700. Это удобно для backup, временных ключей, ssh-конфигов и артефактов деплоя.

Если файл уже создан с неправильными правами, umask его не исправит. Тогда нужен chmod:

chmod 600 token.txt

umask хорошо закрывает простой класс ошибок. Скрипт перестаёт случайно создавать приватные файлы слишком открытыми.

➡️ DevOps Ready | #совет

Шпаргалка по Infrastructure as Code!

Например, Docker помогает упаковать приложение в контейнер, Kubernetes управляет запуском контейнеров, Terraform описывает инфраструктуру, а Ansible настраивает серверы через playbook.

На картинке собрана общая схема IaC-подхода. Есть containerization, Kubernetes orchestration, Git как source of truth, CI/CD pipeline, Terraform, Ansible, cloud servers и on-premise servers.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Собираем Makefile для частых DevOps-команд!

В проектах часто есть набор повторяющихся команд. Запустить тесты, собрать образ, применить миграции или открыть shell.

Держать всё в голове не удобно. А с помощью Makefile можно приварить их в короткие сценарии.

Начнём с понятной цели для логов:

logs:
    docker compose logs -f app

Таб перед командой важен. В Makefile команда внутри target должна начинаться именно с tab.

Добавим перезапуск сервиса:

restart:
    docker compose restart app

Для проверки можно сделать отдельный target:

check:
    docker compose config
    docker compose ps

Теперь команды становятся короче:

make logs
make restart
make check

Для deploy лучше добавить dry-run или отдельный подготовительный шаг, чтобы случайно не выполнить опасную команду.

Например, можно сначала показать текущий git commit:

release-info:
    git rev-parse --short HEAD
    git status --short

Такой Makefile не заменяет CI/CD, но сильно снижает ручную работу. Особенно в маленьких командах, где одни и те же операции часто выполняют разные люди.

➡️ DevOps Ready | #практика

kubectx и kubens - переключатели контекста Kubernetes!

В этом репозитории лежат две маленькие утилиты для kubectl. kubectx помогает быстро переключаться между Kubernetes context, а kubens делает то же самое для namespace.

Инструменты особенно важны, когда приходится работать с несколькими кластерами, окружениями и namespace. Вместо длинных команд kubectl config можно быстро выбрать нужный контекст, посмотреть список доступных вариантов и не путаться между dev, stage и prod.

Оставляю ссылочку на GitHub

➡️ DevOps Ready | #репозиторий