Находим и чистим старые 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 | #совет

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 | #ресурс