Зачем в DevOps использовать timeout для долгих команд?

Иногда команда может зависнуть: сетевой запрос, backup, healthcheck, rsync, миграция или скрипт в CI. Если не ограничить время выполнения, job может висеть бесконечно.

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

curl https://api.example.com/health

Если соединение подвиснет, следующий шаг pipeline может так и не начаться.

Для таких случаев есть timeout:

timeout 10s curl https://api.example.com/health

Теперь команда получит максимум 10 секунд.

Это удобно для healthcheck-ов:

timeout 5s ./check-service.sh

И для команд внутри CI/CD:

timeout 2m ./run-migrations.sh

Если команда не завершилась вовремя, timeout остановит её и вернёт ошибочный exit code. Это можно обработать:

if ! timeout 10s curl -f http://localhost:8080/health; then
    echo "service is not ready"
    exit 1
fi

Для более жёсткого завершения можно указать сигнал:

timeout -s KILL 30s ./worker-test.sh

Но обычно лучше начинать с обычного timeout, чтобы процесс успел завершиться аккуратно.

➡️ DevOps Ready | #совет

Почему временные файлы лучше создавать через mktemp?

В shell-скриптах часто нужен временный файл: сохранить вывод, собрать промежуточный конфиг или передать данные другой команде.

Плохой вариант выглядит так:

tmp="/tmp/app.log"
echo "data" > "$tmp"

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

Чуть лучше, но всё ещё не идеально:

tmp="/tmp/app-$$.log"

$$ добавляет PID процесса, но это не полноценная защита от гонок и предсказуемых имён.

Нормальный способ — mktemp:

tmp="$(mktemp)"

Команда создаёт уникальный файл и сразу возвращает путь к нему:

echo "data" > "$tmp"
cat "$tmp"

А чтобы временный файл точно удалился при выходе из скрипта, добавляют trap:

tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT

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

➡️ DevOps Ready | #совет

Шпаргалка по Linux Performance Observability Tools!

Например, top и vmstat помогают быстро посмотреть нагрузку на CPU и память, iostat и iotop понять проблемы с диском, а tcpdump и ss проверит сетевую активность.

На картинке карта инструментов наблюдаемости Linux по слоям системы: приложения, системные библиотеки, syscalls, VFS, файловые системы, сеть, scheduler, CPU, DRAM, диски и устройства.

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

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

Находим и чистим старые Docker-образы!

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

Сначала смотрим, сколько места занимает Docker:

docker system df

Так можно быстро понять, что именно разрослось: images, containers, volumes или build cache.

Посмотрим список образов вместе с датой создания:

docker images --format \
"{{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.CreatedSince}}\t{{.Size}}"

Если нужно найти dangling-образы, которые не имеют тега, используем фильтр:

docker images -f dangling=true

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

Перед удалением лучше сделать безопасный dry-run через список ID:

docker images -f dangling=true -q

Если список выглядит ожидаемо, удаляем их:

docker image prune

Для более агрессивной очистки можно удалить все неиспользуемые образы:

docker image prune -a

Но тут важно помнить: будут удалены не только <none>, а все образы, которые сейчас не используются контейнерами.

Если нужно ограничить очистку по времени, добавляем фильтр:

docker image prune -a \
  --filter "until=168h"

Так Docker удалит неиспользуемые образы старше 7 дней.

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

docker system df

Такая практика помогает держать Docker-хост в порядке и не ловить внезапное “no space left on device” во время деплоя.

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

iximiuz Labs практический DevOps-полигон прямо в браузере!

На сайте можно тренироваться на реальных Linux-серверах, Docker-хостах и Kubernetes-кластерах без локальной установки и долгой настройки окружения. Внутри есть playgrounds, guided labs, challenges, learning paths по Linux, Docker, Kubernetes и networking, плюс возможность подключаться через браузер или SSH. Это хороший ресурс, если хочется не просто читать про DevOps, а руками ломать, чинить, запускать контейнеры, проверять команды и разбираться с инфраструктурой в живой среде.

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

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

Почему переменные окружения лучше не подставлять без кавычек?

В shell-скриптах часто используют переменные в командах:

rm -rf $TARGET

На вид обычная строка, но без кавычек shell сначала выполнит word splitting и glob expansion. Если в переменной есть пробелы, значение превратится в несколько аргументов.

Например:

TARGET="/tmp/app cache"

printf '<%s>\n' $TARGET

Вывод будет не одним путём, а двумя словами:

</tmp/app>
<cache>

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

printf '<%s>\n' "$TARGET"

Теперь значение передаётся как один аргумент:

</tmp/app cache>

То же самое касается путей, имён файлов, URL и пользовательского ввода:

cp "$SOURCE" "$DEST"
grep "$PATTERN" "$LOG_FILE"
mkdir -p "$APP_DIR"

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

Для списков лучше использовать массивы:

files=("app log.txt" "error log.txt")

printf '%s\n' "${files[@]}"

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

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

Шпаргалка по GitHub Actions!

Например, on задаёт событие запуска workflow, jobs описывает набор задач, а runs-on выбирает окружение, где будет выполняться job.

На картинке базовый синтаксис GitHub Actions: структура workflow-файла, события push и pull_request, ветки и теги, jobs, needs, runs-on, env-переменные, secrets и пример YAML-конфига.

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

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

Настраиваем простой healthcheck для Docker-контейнера!

Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.

Представим простой HTTP-сервис, который отвечает на /health:

curl -f http://localhost:8080/health

Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.

В Dockerfile можно добавить HEALTHCHECK:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

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

Соберём образ:

docker build -t app-with-health .

Запустим контейнер:

docker run -d --name app app-with-health

Теперь статус будет виден прямо в списке контейнеров:

docker ps

В выводе можно увидеть состояние:

Up 2 minutes (healthy)

Если нужно посмотреть healthcheck подробнее, используем inspect:

docker inspect --format '{{json .State.Health}}' app

А чтобы вывести только текущий статус:

docker inspect --format '{{.State.Health.Status}}' app

Ожидаемый результат:

healthy

Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.

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

Знали, зачем в 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 | #совет