Знали, зачем в Bash иногда используют exec вместо обычного запуска команды?

Обычно команду запускают так:

nginx -g 'daemon off;'

Shell остаётся родительским процессом, а nginx запускается как дочерний процесс.

В обычном терминале это почти незаметно. Но в Docker-контейнерах, entrypoint-скриптах и service-wrapper’ах это может стать проблемой: сигналы приходят в shell, а не напрямую в основной процесс.

Например, такой entrypoint выглядит рабочим:

#!/usr/bin/env bash

nginx -g 'daemon off;'

Но если контейнер останавливают через docker stop, сигнал SIGTERM сначала получает shell. Если он не передаст сигнал дочернему процессу корректно, приложение может завершаться не так, как ожидается.

Для основного процесса лучше использовать exec:

#!/usr/bin/env bash

exec nginx -g 'daemon off;'

exec не создаёт новый дочерний процесс, а заменяет текущий shell указанной командой.

То есть nginx становится главным процессом:

PID 1 -> nginx

А не так:

PID 1 -> bash -> nginx

Это особенно важно для контейнеров:

docker stop app

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

exec также полезен в скриптах-обёртках:

#!/usr/bin/env bash

export APP_ENV=prod
exec ./server

После подготовки окружения shell больше не нужен, поэтому его можно заменить настоящим процессом приложения.

➡️ DevOps Ready | #совет

Kubernetes Basics — вход в Kubernetes от официальной документации!

На сайте собран пошаговый раздел по базовым возможностям Kubernetes: создание кластера, деплой приложения, просмотр Pod и Deployment, масштабирование сервиса, rolling update и базовая отладка. Материал хорошо подходит тем, кто хочет разобраться, как Kubernetes управляет контейнерами, сервисами и обновлениями приложения без лишней теории и хаоса.

Оставляю ссылочку: Kubernetes Basics

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

Делаем безопасный backup конфига перед изменением!

Перед правкой nginx, systemd unit, docker-compose.yml или любого важного конфига полезно сначала сохранить копию. Это занимает секунды, но сильно упрощает откат.

Зададим путь к файлу:

file="/etc/nginx/nginx.conf"

Добавим timestamp:

stamp="$(date +%Y%m%d-%H%M%S)"

Соберём имя backup-файла:

backup="${file}.${stamp}.bak"

Перед копированием проверим, что файл существует:

test -f "$file" || {
  echo "Файл не найден: $file"
  exit 1
}

Теперь создаём копию с сохранением прав и владельца:

sudo cp -a "$file" "$backup"

После этого можно редактировать конфиг:

sudo nano "$file"

Если это nginx, сначала проверяем конфигурацию:

sudo nginx -t

И только потом перезагружаем сервис:

sudo systemctl reload nginx

Если что-то пошло не так, откат простой:

sudo cp -a "$backup" "$file"
sudo systemctl reload nginx

Для удобства можно посмотреть последнюю копию:

ls -lt /etc/nginx/nginx.conf.*.bak | head

Backup перед изменением конфига это маленькая привычка, которая часто экономит часы восстановления после неудачной правки.

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

Kubernetes The Hard Way — репозиторий для понимания Kubernetes изнутри!

В этом репозитории Kubernetes собирается вручную, без готовых скриптов и магии managed-сервисов. Материал проходит через подготовку машин, сертификаты, kubeconfig, encryption config, etcd, control plane, worker nodes, pod network routes, kubectl и smoke test. Хорошо подойдёт тем, кто уже запускал Kubernetes, но хочет понять, что реально происходит под капотом: как компоненты связаны между собой, зачем нужны сертификаты, где живёт etcd и почему кластер не ограничивается одной командой установки.

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

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

Docker Docs — официальный гид по Docker, контейнерам и образам!

На сайте собраны материалы по установке Docker, первым контейнерам, Dockerfile, образам, volumes, networking, Docker Compose, registry, best practices и деплою приложений. Это хороший ресурс для тех, кто хочет не просто выучить пару команд, а нормально понять весь путь: как собрать образ, запустить контейнер, связать сервисы, сохранить данные и подготовить приложение к запуску в реальной инфраструктуре.

Оставляю ссылочку: Docker Docs

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

Шпаргалка по iptables!

Например, iptables -L -v показывает текущие правила, а iptables -I INPUT -s IP -j DROP блокирует входящий трафик от конкретного адреса.
На картинке базовые команды iptables: просмотр правил, блокировка IP и подсетей, удаление правил, блокировка портов, разрешение трафика, сохранение правил и удаление по номеру строки.

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

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

Проверяем HTTP endpoint из shell-скрипта!

Иногда нужно быстро понять, жив ли сервис: API, health endpoint, nginx location или внутренний backend.

Начнём с URL:

url="https://example.com/health"

Получим только HTTP-код:

code="$(curl -s -o /dev/null -w "%{http_code}" "$url")"

Теперь проверим диапазон:

if [ "$code" -ge 200 ] && [ "$code" -lt 300 ]; then
  echo "OK: $code"
else
  echo "FAIL: $code"
fi

Добавим timeout, чтобы скрипт не завис:

code="$(curl -sS --max-time 5 \
  -o /dev/null -w "%{http_code}" "$url")"

Если нужен retry:

for i in 1 2 3; do
  code="$(curl -s --max-time 5 -o /dev/null -w "%{http_code}" "$url")"

  [ "$code" = "200" ] && break
  sleep 2
done

После этого можно вернуть exit code для CI:

[ "$code" = "200" ] || exit 1

Такую проверку удобно использовать в deploy-скриптах, cron, CI/CD и простом мониторинге.

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

📂 Напоминалка по организации безопасного отката релизов!

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

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

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

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

Знали, как не дать cron-задаче запуститься второй раз поверх первой?

Иногда скрипт запускается по расписанию, но предыдущий запуск ещё не закончился. Например, backup, импорт данных, rsync или очистка логов могут выполняться дольше обычного.

Обычный cron выглядит так:

* * * * * /opt/jobs/backup.sh

Если backup занимает больше минуты, следующий запуск начнётся параллельно:

backup.sh
backup.sh
backup.sh

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

Для таких случаев используют flock:

flock -n /tmp/backup.lock /opt/jobs/backup.sh

Файл /tmp/backup.lock здесь не хранит данные. Он нужен как точка блокировки.

Ключ -n означает: если lock уже занят, не ждать, а сразу выйти:

flock -n /tmp/backup.lock ./backup.sh

В cron это можно записать так:

* * * * * flock -n /tmp/backup.lock /opt/jobs/backup.sh

Если первый запуск ещё работает, второй просто не стартует.

Для более явного варианта можно использовать shell:

flock -n /tmp/backup.lock \
  bash -c 'echo start; ./backup.sh'

А если нужно немного подождать lock, есть timeout:

flock -w 10 /tmp/backup.lock ./backup.sh

Так команда подождёт до 10 секунд, а потом завершится, если блокировка всё ещё занята.

➡️ DevOps Ready | #совет

kube-prometheus — готовая база для мониторинга Kubernetes!

В этом репозитории собран полноценный monitoring stack для Kubernetes: Prometheus Operator, Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics, готовые dashboards и alert rules. Хороший вариант, чтобы посмотреть, как в реальности собирают наблюдаемость кластера не из одного контейнера, а из набора Kubernetes-манифестов и связанных компонентов.

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

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

📂 Напоминалка по архитектуре минимального, но рабочего CI/CD-пайплайна!

Часто при настройке автоматизации возникает соблазн сразу построить огромный комбайн с кучей проверок, из-за чего пайплайн постоянно падает, а релизы застревают.

На этой схеме — пошаговый гайд о том, как спроектировать лаконичный и стабильный CI/CD-пайплайн для одного микросервиса, который закроет 80% потребностей команды и не будет перегружен лишней логикой.

Сохрани в закладки, чтобы использовать как готовый шаблон для своих проектов!

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