DevOps Exercises более 2600 задач и вопросов по DevOps!

В репозитории собраны практические задания, вопросы и готовые разборы по Linux, Docker, Kubernetes, Terraform, Ansible, CI/CD, сетям, облачным платформам и мониторингу. Материалы можно проходить по отдельным темам, использовать для проверки своих знаний или подготовки к собеседованию.

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

➡️ DevOps Ready | #репозиторий

Шпаргалка по безопасной настройке прав в Linux!

Например, chmod 600 ~/.ssh/id_ed25519 закрывает приватный ключ от других пользователей, а режим 2755 включает setgid для каталога и помогает сохранять его группу у новых файлов.

На картинке специальные биты setuid, setgid и sticky bit, рекомендуемые права для SSH, скриптов и web-root, а также причины ошибок Permission denied, особенности символических ссылок, ACL и рекурсивного chmod.

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

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

Почему sudo echo всё равно может вернуть Permission denied?

Часто системный файл пытаются изменить так:

sudo echo "PORT=8080" \
  > /etc/myapp/app.conf

Но команда может завершиться ошибкой доступа, хотя перед echo указан sudo.

Причина в порядке выполнения. sudo запускает с повышенными правами только echo, а перенаправление > обрабатывает текущий shell ещё до запуска команды.

Именно обычный пользователь пытается открыть системный файл для записи.

Для таких случаев удобно использовать tee:

echo "PORT=8080" |
  sudo tee /etc/myapp/app.conf \
  > /dev/null

Здесь файл открывает уже tee, запущенный через sudo.

Чтобы не перезаписывать файл, а добавить строку в конец, используйте -a:

echo "LOG_LEVEL=info" |
  sudo tee -a /etc/myapp/app.conf \
  > /dev/null

Многострочный конфиг можно записать через heredoc:

sudo tee /etc/myapp/app.conf \
  > /dev/null <<'EOF'
PORT=8080
LOG_LEVEL=info
CACHE_ENABLED=true
EOF

Кавычки вокруг 'EOF' запрещают shell подставлять переменные и выполнять команды внутри блока. Содержимое будет записано буквально.

➡️ DevOps Ready | #совет

Шпаргалка по командам Docker CLI!

Например, docker run -p 8080:80 nginx запускает контейнер и публикует его порт, а docker logs -f <container> показывает новые строки логов в реальном времени.

На картинке команды для сборки и удаления образов, запуска и остановки контейнеров, просмотра логов и статистики, открытия shell внутри контейнера, а также загрузки и публикации образов через Docker Hub.

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

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

Bash-конвейер может скрыть ошибку одной из команд!

По умолчанию код завершения конвейера определяется последней командой:

curl -sS "$URL" | jq -r '.version'

Если curl завершится с ошибкой, но jq успешно обработает пустой ввод, весь конвейер может вернуть код 0. Скрипт решит, что команда выполнилась успешно.

Опция pipefail меняет это поведение:

set -o pipefail

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

curl -fsS "$URL" |
    jq -r '.version' > version.txt

Коды отдельных команд последнего конвейера можно посмотреть через PIPESTATUS:

curl -fsS "$URL" | jq -r '.version'
printf '%s\n' "${PIPESTATUS[@]}"

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

set -euo pipefail

-e завершает скрипт при необработанной ошибке, -u запрещает использование необъявленных переменных, а pipefail обнаруживает сбой внутри конвейера.

Ожидаемые ошибки при этом лучше обрабатывать явно:

if ! grep -q "READY" health.log; then
    echo "Service is not ready"
fi

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

➡️ DevOps Ready | #совет

Контроль целостности системных утилит Linux через проверку хэш-сумм.

При компрометации сервера злоумышленники часто подменяют базовые системные бинарники (например, ss, ps или login) на модифицированные версии с бэкдорами. Мы напишем лаконичный bash-скрипт, который создаст эталонные слепки контрольных сумм SHA-256 для критически важных утилит и проверит их на предмет несанкционированных изменений. Этот базовый механизм Host IDS (интрузивного детектирования) позволяет оперативно обнаружить факт присутствия атакующего в системе.

Сформируем базу данных эталонных хэш-сумм для выбранных системных утилит и сохраним её в защищенный файл:

# Создание эталонных хэшей для проверки
sha256sum /bin/ps /bin/ss /usr/bin/whoami > /root/sys_integrity.db

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

Напишем автоматический скрипт валидации, который сверяет текущее состояние файлов с ранее сохраненным эталоном:

# Скрипт проверки и вывода измененных файлов
sha256sum -c /root/sys_integrity.db 2>&1 | grep -v 'OK' || echo "Integrity check: SUCCESS"

Команда выполнит сверку всех строк и выведет предупреждение только в случае несовпадения хэшей.

# проверка (контрольная эмуляция подмены для проверки реакции парсера)
echo "test" >> /root/sys_integrity.db && sha256sum -c /root/sys_integrity.db 2>&1 | grep 'FAILED'

Ожидаемый вывод: /root/sys_integrity.db: FAILED

# cleanup (удаление тестовой базы данных из системы)
rm -f /root/sys_integrity.db

Регулярный запуск такого скрипта через cron помогает вовремя заметить активность руткитов и троянов. Чтобы атакующий не смог подделать саму базу хэшей, обязательно храните эталонный файл sys_integrity.db на удаленном сервере логирования или на флешке в режиме "только чтение".

🚪 Linux Ready | #практика

📂 Напоминалка по локальной отладке CI/CD-скриптов!

Ошибки в пайплайне лучше находить до запуска в CI. Локальная отладка позволяет быстрее проверить логику скриптов, переменные окружения, Docker-окружение и конфигурацию, не тратя время на повторные запуски пайплайна.

На картинке — 7 полезных команд для локальной проверки CI/CD: от shellcheck и docker run до set -x, jq, git diff и других инструментов, которые помогают быстрее находить ошибки и делать пайплайны более надёжными.

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

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

Как в Bash гарантированно удалить временные файлы через trap?

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

tmp_dir=$(mktemp -d)

А потом в конце вручную удаляют её:

rm -rf "$tmp_dir"

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

Для таких случаев в Bash используют trap:

tmp_dir=$(mktemp -d)
trap 'rm -rf "$tmp_dir"' EXIT

Теперь cleanup выполнится при выходе из скрипта почти в любом сценарии:

cp app.log "$tmp_dir/"
grep "ERROR" "$tmp_dir/app.log"

Даже если grep завершится ошибкой, trap всё равно сработает при выходе.

Это удобно сочетать со строгим режимом:

set -euo pipefail

Полный минимальный шаблон:

set -euo pipefail

tmp_dir=$(mktemp -d)
trap 'rm -rf "$tmp_dir"' EXIT

Если нужно выполнить несколько действий при завершении, лучше вынести cleanup в функцию:

cleanup() {
    rm -rf "$tmp_dir"
}

trap cleanup EXIT

Такой подход полезен для архивов, временных конфигов, скачанных файлов, тестовых директорий и промежуточных данных в CI/CD.


➡️ DevOps Ready | #совет

Шпаргалка по kubectl-командам!

Например, kubectl get pods показывает поды, kubectl describe pod помогает посмотреть детали ресурса, а kubectl logs быстро достаёт логи контейнера.

На картинке команды kubectl для просмотра ресурсов, создания и применения YAML, удаления объектов, запуска команд внутри контейнера, работы с логами, kubeconfig и короткими именами Kubernetes-ресурсов.

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

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

Практически любую команду можно запустить в отдельной cgroup!

Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения.

Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run:

systemd-run --user --scope \
  -p MemoryHigh=1536M \
  -p MemoryMax=2G \
  make -j32

Теперь ограничения действуют только на эту команду и всё её дерево процессов. После завершения временная cgroup автоматически исчезнет.

Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу):

systemd-run --user --scope \
  -p CPUQuota=200% \
  npm test

Или собрать сразу несколько политик для ресурсоёмкой задачи:

systemd-run --user --scope \
  -p MemoryMax=4G \
  -p CPUQuota=300% \
  -p IOWeight=100 \
  cargo build --release

Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2).

🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов.

🚪 Linux Ready | #совет

📂 Напоминалка по деплою по веткам и окружениям без микса!

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

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

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

zram в Linux как альтернатива обычному swap!

zram — это механизм Linux, который создаёт сжатое блочное устройство в оперативной памяти и позволяет использовать его как swap. В отличие от обычного swap, данные не записываются на диск — они остаются в RAM, но хранятся в сжатом виде. Это позволяет эффективнее использовать память и уменьшить обращения к медленному дисковому swap.

Особенно полезен zram на небольших VPS, контейнерных серверах и устройствах с ограниченным объёмом RAM, где нужно переживать кратковременные пики нагрузки без резкого падения производительности.

Перед настройкой проверяем текущий swap:

swapon --show
free -h

Загружаем модуль ядра:

sudo modprobe zram

Проверяем появившееся устройство:

zramctl

Задаём размер zram, например 4 GB:

echo 4G | sudo tee /sys/block/zram0/disksize

Размер zram не означает немедленное выделение 4 GB RAM. Фактически память занимает только сжатый объём реально используемых данных.

Выбираем алгоритм сжатия. Чаще всего используют lz4 или zstd: lz4 быстрее, zstd обычно даёт лучшее сжатие. Пример с lz4:

echo lz4 | sudo tee /sys/block/zram0/comp_algorithm

Доступные алгоритмы:

cat /sys/block/zram0/comp_algorithm

Создаём swap и включаем:

sudo mkswap /dev/zram0
sudo swapon /dev/zram0

Проверяем:

swapon --show
zramctl

Теперь Linux использует zram как swap-устройство, но данные находятся внутри RAM в сжатом виде, без постоянной записи на диск.

Для сохранения после перезагрузки обычно используют systemd-zram-generator или zram-tools. В Debian/Ubuntu при использовании zram-tools настройки обычно находятся в:

/etc/default/zramswap

Также стоит учитывать параметр ядра vm.swappiness, который влияет на активность использования swap:

cat /proc/sys/vm/swappiness

zram и zswap — разные механизмы. zram создаёт отдельный swap внутри RAM. zswap работает как кэш перед обычным swap на диске.

Проверка zswap:

cat /sys/module/zswap/parameters/enabled

🔥 Подведем итог: zram не добавляет физическую память, но позволяет эффективнее использовать доступную RAM, уменьшает обращения к дисковому swap и помогает системе стабильнее переживать кратковременные пики нагрузки.

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

Проверяем задержки сети в Linux через mtr!

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

Проблема может быть не в доступности сервера, а в качестве сетевого пути: потерях пакетов, скачках latency, перегруженном участке маршрута или проблемах у провайдера.

Для таких случаев удобно использовать mtr — инструмент, который объединяет возможности ping и traceroute и позволяет увидеть, где именно начинается деградация. Запуск:

mtr api.example.com

MTR показывает маршрут до узла и статистику по каждому промежуточному хопу: задержку, количество отправленных пакетов и возможные потери ответов.

Для длительного тестирования удобно использовать:

mtr -rwbc 100 api.example.com

Параметры:
-r — вывести итоговый отчёт и завершить выполнение; -w — расширенный формат вывода; -b — показывать IP-адреса вместе с именами узлов; -c 100 — отправить 100 пакетов.

Для больших маршрутов иногда удобнее отключить DNS-резолвинг:

mtr -n api.example.com

Сохранить результат для дальнейшего анализа:

mtr -rwbc 100 api.example.com > mtr-report.txt

Важный момент: потери на промежуточном узле не всегда означают реальную проблему. Многие маршрутизаторы ограничивают обработку ICMP или имеют низкий приоритет для таких ответов. Один из хопов может показывать высокий процент потерь, а конечный сервер при этом работать нормально.

Смотреть нужно не на один отдельный узел, а на общую картину: сохраняется ли проблема дальше по маршруту и влияет ли она на конечную точку.

Для проверки конкретного TCP-сервиса можно использовать:

mtr -T -P 443 api.example.com

В этом режиме MTR использует TCP SYN probes вместо ICMP, что ближе к проверке реального пути для сервисов вроде HTTPS, SSH или API. Примеры:

# HTTPS
mtr -T -P 443 api.example.com

# SSH
mtr -T -P 22 server.example.com

Но важно понимать: TCP MTR проверяет сетевую доступность и транспортный уровень. Он не покажет проблемы внутри TLS, HTTP или самого приложения. Полезно сравнивать разные направления:

mtr -T -P 443 server-a.example.com
mtr -T -P 443 server-b.example.com

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

🔥 mtr полезен в ситуациях, когда сеть вроде работает, но есть плавающие тайм-ауты, скачки задержки или проблемы только с отдельными сервисами. Он помогает найти участок маршрута, где начинается деградация, но всегда требует анализа вместе с приложением и другими сетевыми метриками.
➡️ DevOps Ready | #практика

📂 7 команд для откладки деплоев и rollout в Kubernetes 🚀

Когда деплой пошёл не по плану, важно быстро понять, что именно произошло: контейнер не стартует, Pod не готов, rollout завис или новая версия сломала приложение.
На шпаргалке — 7 самых полезных kubectl команд, которые помогают разобраться с большинством проблем при деплое: проверить состояние Pod'ов; изучить логи контейнеров; быстро откатиться на предыдущую версию; найти события кластера и узлов.

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

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

Запускаем команды от имени другого пользователя через sudo -u — без входа в его интерактивную сессию через su!

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

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

sudo -u www-data id

Команда выполнится с UID и GID пользователя www-data, но текущий терминал останется вашим.

Например, можно проверить, имеет ли веб-приложение доступ к нужной директории:

sudo -u www-data ls -la /var/www/app

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

Также можно открыть shell от имени сервисного пользователя:

sudo -u postgres bash

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

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

sudo -iu postgres

При отладке важно учитывать, что sudo -u не всегда воспроизводит реальное окружение работающего сервиса.

Например:

sudo -u node env

Эта команда покажет окружение, сформированное sudo, но оно может отличаться от окружения процесса, запущенного через systemd, Docker, Kubernetes, PM2 или другой менеджер процессов.

Также можно передать временную переменную окружения только для одного запуска:

sudo -u www-data env APP_ENV=testing ./deploy.sh

Переменная APP_ENV будет доступна только этому процессу и его дочерним процессам. Глобальные настройки системы при этом не изменятся. Также важно: возможности sudo -u зависят от правил в sudoers. Разрешение на запуск shell, интерпретатора или произвольного скрипта может дать пользователю широкий доступ от имени целевой учётной записи.

🔥 sudo -u — удобный инструмент для проверки прав, отладки сервисов и запуска отдельных команд от имени системных пользователей без полноценного переключения сессии.

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

DevOps Labs практические лабораторные по Docker, Kubernetes, Terraform и CI/CD!

В этом репозитории собраны hands-on лабораторные для DevOps, DevSecOps и Cloud Engineering: Git, Docker, Kubernetes, Terraform, AWS, CI/CD, GitOps, Ansible, Helm, Prometheus и security-практики. Формат полезный именно для прокачки руками: у каждой лабораторной есть цель, ожидаемый результат и сценарий, похожий на реальные задачи из инфраструктуры, а не просто список ссылок для чтения.

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

➡️ DevOps Ready | #репозиторий