DevOps Ready | IT

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

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

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

➡️ 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 | #практика

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

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

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

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

➡️ 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 | #совет

Ищем самые активные IP в access.log!

Нужно быстро понять, кто сильнее всего нагружает Nginx? Соберём короткую консольную задачу: вытащим IP из access.log, посчитаем количество запросов и покажем топ самых активных клиентов.

В этой задаче:

• Проверяем доступность лог-файла;
• Достаём IP из первой колонки;
• Считаем частоту и сортируем результат.

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

➡️ 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 | #совет

Разберём Docker Compose: 7 команд для диагностики и управления сервисами!

Когда локальное окружение или staging-проект ведёт себя странно, важно быстро смотреть статус контейнеров, логи, итоговый YAML, заходить внутрь сервиса и аккуратно перезапускать нужные части. Эта шпора помогает не тыкать Compose вслепую и быстрее находить проблему.

➡️➡️ DevOps Ready | #шпора

Ускоряем 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 | #практика

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

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

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

/var/log/myapp/app.log

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

sudo nano /etc/logrotate.d/myapp

Минимальная настройка:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

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

Если приложению нужно пересоздать файл после ротации, добавим postrotate:

postrotate
    systemctl reload myapp
endscript

Полный вариант:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    postrotate
        systemctl reload myapp
    endscript
}

Проверить конфиг можно без реальной ротации:

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

А принудительно запустить:

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

После проверки посмотри файлы:

ls -lh /var/log/myapp/

logrotate защищает сервер от бесконечно растущих логов. Это базовая, но очень важная настройка для сервисов, cron-задач и backend-приложений.

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

Шпаргалка по сетевым командам Linux!

Например, ip addr show показывает адреса интерфейсов, dig example.com проверяет DNS, а ss -tuln помогает увидеть открытые порты.
На картинке Linux networking commands: routing, network interfaces, DNS, monitoring, troubleshooting и connectivity-команды для быстрой диагностики серверов.

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

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

📂 Напоминалка по версионированию инфраструктурных изменений!

Изменения в инфраструктуре требуют не меньшего контроля, чем изменения в коде приложения. Грамотное версионирование позволяет отслеживать историю изменений, безопасно выполнять обновления, быстро откатываться при ошибках и обеспечивать прозрачность работы всей команды.
На картинке — 7 практических принципов управления инфраструктурными изменениями: от хранения инфраструктуры как кода и атомарных коммитов до использования Pull Request, автоматизации через CI/CD, документирования изменений, безопасного отката и организации полного жизненного цикла инфраструктурных изменений.

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

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

Как в Linux быстро проверить, кто держит порт?

Иногда сервис не запускается и пишет, что порт уже занят:

bind: address already in use

В такой момент не нужно гадать, какой процесс мешает. Можно сразу посмотреть listening-сокеты через ss:

sudo ss -ltnp

Флаги читаются так:

-l  listening
-t  TCP
-n  не резолвить имена
-p  показать процесс

Если нужен конкретный порт, добавь фильтр:

sudo ss -ltnp 'sport = :8080'

В выводе будет видно адрес, порт, имя процесса и PID:

LISTEN 0 4096 0.0.0.0:8080 users:(("java",pid=2481))

После этого можно проверить процесс:

ps -fp 2481

И уже спокойно решить, что делать, остановить старый сервис, поменять порт или разобраться, почему процесс остался висеть.

Для UDP почти то же самое:

sudo ss -lunp

А если нужно увидеть все соединения к порту:

sudo ss -tanp 'sport = :8080'

ss помогает быстро понять, какой процесс занял порт. Это одна из первых команд при проблемах со стартом сервисов, Docker, Nginx и backend-приложений.

➡️ DevOps Ready | #совет