Ускоряем CI-пайплайн через оптимизацию слоев Docker.

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

Сначала создадим неоптимальный файл, который сбрасывает кэш при любом изменении в коде:

# Dockerfile-slow
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]

При такой структуре изменение одного символа в коде заставит npm install запускаться заново.

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

# Dockerfile-fast
FROM node:18
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
CMD ["node", "index.js"]

Теперь слой с тяжелыми зависимостями закэшируется и будет пересобираться только при правке package.json.

Проверим разницу в скорости сборки, запустив процесс повторно после небольшого изменения в файле проекта.

time docker build -t fast-app -f Dockerfile-fast .
# Ожидаемый результат: время сборки во второй раз составит доли секунды (CACHED).

Грамотная последовательность шагов это самый дешевый способ ускорить доставку кода. Используйте этот принцип не только в Docker, но и в шагах GitHub Actions или GitLab CI, вынося самые тяжелые и редко меняющиеся операции в начало пайплайна. Всегда проверяйте логи сборки на наличие пометки «Using cache».

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

Зачем в 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 | #практика