Шпаргалка по 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 | #ресурс

Знали, зачем в curl использовать --fail вместе с проверками в скриптах?

Обычный curl может завершиться успешно даже тогда, когда сервер вернул HTTP-ошибку:

curl https://example.com/missing

Если сервер ответил 404, команда всё равно может вернуть exit code 0, потому что сетевой запрос технически выполнился.

В shell-скриптах это опасно:

curl "$URL" -o app.tar.gz
tar -xzf app.tar.gz

Можно скачать HTML-страницу с ошибкой вместо архива и узнать об этом только на следующем шаге.

Для таких случаев добавляют --fail:

curl --fail "$URL" -o app.tar.gz

Теперь HTTP-коды 400/500 будут считаться ошибкой команды.

Чаще всего это комбинируют с --silent и --show-error:

curl --fail --silent --show-error \
  "$URL" -o app.tar.gz

Для CI/CD или deploy-скриптов удобно сразу останавливать выполнение:

curl --fail --silent --show-error "$URL" -o app.tar.gz
tar -xzf app.tar.gz

Если нужен retry:

curl --fail --retry 3 --retry-delay 2 \
  "$URL" -o app.tar.gz

Так временные сетевые ошибки можно пережить, а настоящие HTTP-ошибки не будут замаскированы под успешную загрузку.

➡️ DevOps Ready | #совет

Killercoda - DevOps-лабы прямо в браузере!

На сайте можно запускать готовые сценарии по Linux, Docker, Kubernetes, Git, Grafana, Argo, Istio, Falco и другим инструментам. Всё открывается как интерактивная среда с терминалом, поэтому можно не просто читать, а сразу выполнять команды.

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

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

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

🔍Тестовое собеседование с Head of DevOps уже завтра

18 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.

Как это будет:
📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Александру

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot

Реклама.
О рекламодателе.

Настраиваем ротацию логов через logrotate!

Если приложение постоянно пишет в один файл, лог может незаметно вырасти до гигабайтов. В итоге диск заполняется, поиск ошибок становится медленнее, а сервис может начать падать просто из-за нехватки места.

Допустим, приложение пишет сюда:

/var/log/myapp/app.log

Для таких файлов удобно завести отдельное правило в logrotate.

Создадим конфиг:

sudo nano /etc/logrotate.d/myapp

Сначала указываем, какие логи нужно обрабатывать:

/var/log/myapp/*.log {

Теперь добавим ежедневную ротацию:

daily

Оставим только последние семь архивов:

rotate 7

Чтобы старые логи занимали меньше места, включим сжатие:

compress

Если файла временно нет, это не должно ломать весь запуск logrotate:

missingok

Пустой лог тоже нет смысла перекладывать в архив:

notifempty

Для простых приложений часто добавляют copytruncate. Он копирует текущий лог в архив, а исходный файл обрезает до нуля:

copytruncate

Это полезно, когда приложение не умеет переоткрывать лог-файл после сигнала. Минус тоже есть: в момент копирования можно потерять несколько строк, если приложение пишет очень активно.

В конце закрываем правило:

}

Перед применением лучше проверить конфиг в debug-режиме:

sudo logrotate -d /etc/logrotate.d/myapp

Так команда покажет, что собирается сделать, но не будет реально трогать файлы.

Если всё выглядит нормально, можно принудительно выполнить ротацию:

sudo logrotate -f /etc/logrotate.d/myapp

Потом проверяем каталог с логами:

ls -lh /var/log/myapp

В рабочей системе logrotate обычно запускается автоматически по таймеру или cron. Поэтому после настройки достаточно один раз проверить правило и дальше следить, что архивы появляются ожидаемо.

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

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

Шпаргалка по Linux permissions!

Например, chmod 755 даёт владельцу полный доступ, а группе и остальным оставляет чтение и запуск. А chmod 600 часто используют для приватных ключей и конфигов с секретами.

На картинке разобраны права владельца, группы и остальных пользователей, числовые значения r/w/x, а также SUID, SGID и sticky bit.

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

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