DevOps Daily собирает материалы по инфраструктуре!

На сайте есть разборы Docker, Kubernetes, Terraform, Linux, сетей и CI/CD. Отдельные разделы посвящены симуляторам, упражнениям, тестам и инструментам для повседневной работы.

Можно пройти сценарий с DNS, потренироваться в Kubernetes, открыть упражнение по Nginx или проверить себя на вопросах по Git. Материалы разнесены по темам, поэтому легко выбрать конкретную задачу и постепенно углубиться в неё.

Оставляю ссылочку на DevOps Daily

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

Шпаргалка по жизненному циклу Pod в Kubernetes!

На картинке показано, как запрос проходит через API server, как scheduler выбирает узел и что kubelet делает перед запуском контейнеров. Отдельно разобраны фазы Pod и последовательность его завершения.

Например, Pending означает, что Pod принят кластером, но контейнеры ещё не готовы к запуску. Если он долго остаётся в этой фазе, полезно проверить события, доступность образа, ресурсы узлов и ограничения планирования.

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

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

Проверяем итоговую конфигурацию Docker Compose перед запуском!

Когда проект использует базовый compose.yaml и отдельный файл для production, легко ошибиться с портом, переменной окружения или переопределением сервиса. Docker Compose умеет показать итоговую конфигурацию ещё до запуска контейнеров.

Пусть основной файл задаёт приложение, а второй меняет образ и параметры окружения. Посмотрим объединённый результат:

docker compose -f compose.yaml -f compose.prod.yaml config

Для проверки синтаксиса в CI не нужен длинный вывод. Достаточно тихого режима:

docker compose -f compose.yaml -f compose.prod.yaml config --quiet

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

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

docker compose -f compose.yaml -f compose.prod.yaml config --services
docker compose -f compose.yaml -f compose.prod.yaml config --images

Это помогает заметить, что нужный сервис пропал из файла или production по-прежнему ссылается на старый тег образа.

Переменные подстановки можно проверить отдельно:

docker compose -f compose.yaml -f compose.prod.yaml config --environment

Это особенно полезно после изменений в нескольких Compose-файлах или окружениях.

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

Этот инструмент поможет поять из чего на самом деле состоит Docker-образ!

Он содержит терминальную утилиту для просмотра слоёв Docker и OCI-образов. Можно открыть конкретный слой, увидеть добавленные и удалённые файлы и найти данные, которые занимают место в образе без пользы.

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

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

⚡️5 фундаментальных курсов по ИБ по цене одного

Это предложение для тех, кто готов войти в новую профессию прямо сейчас!

🔥Пакет курсов за 50 000 ₽ вместо 250 000 ₽:
▪️ Linux CyberPunk - обычная цена 49 500 ₽ (+ Курс идет с официальным дипломом системного администратора!)
▪️ SQL для хакера - обычная цена 15 000 ₽
▪️ HackerPoint - обычная цена ~70 000 ₽
▪️ HackerPoint (Blue vs Red Team) - обычная цена 43 500 ₽
▪️ AI-помощники на Python - обычная цена 71 500 ₽

Вы экономите 200 000 ₽ и получаете полную базу: от работы с терминалом и базами данных до разработки ИИ-агентов и взлома систем.

🔒 Квота: набор на программу ограничен по количеству мест.

🦔Отправь промокод DevOps в чат с менеджером, чтобы закрепить за собой скидку и узнать подробности:
👉@cyacademy_support

Знали, почему настройки systemd-сервиса лучше менять через systemctl edit?

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

Сначала посмотрите, из каких файлов сейчас складывается конфигурация сервиса:

systemctl cat myapp.service

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

Для своей настройки откройте редактор override-файла:

sudo systemctl edit myapp.service

Добавьте в открывшийся файл только изменяемые параметры:

[Service]
Restart=on-failure
RestartSec=5s

По умолчанию systemctl edit создаёт отдельный override.conf рядом с unit-файлом в каталоге myapp.service.d. Исходный unit при этом остаётся нетронутым.

Проверьте итоговую конфигурацию и запустите сервис заново в подходящий момент:

systemctl cat myapp.service
sudo systemctl restart myapp.service

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

systemctl status myapp.service
systemctl show myapp.service -p Restart

Если нужно отменить изменение, сначала проверьте все локальные дополнения. Команда systemctl revert удаляет не только этот override, а все локальные переопределения указанного unit, поэтому использовать её вслепую опасно.

➡️ DevOps Ready | #совет

DigitalOcean Community собирает подробные руководства по Linux!

В разделе Linux Basics есть материалы про командную строку, права доступа, пользователей, процессы, сеть и администрирование сервера. Пошаговые статьи дают команды, поясняют результат и помогают пройти тему от основы до конкретной настройки.

Оставляю ссылочку на DigitalOcean Community

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

Изоляция процессов в Linux через Unshare без Docker и тяжелых утилит.

Мы научимся использовать системный вызов unshare для создания изолированного пространства имен (namespaces), что является фундаментом контейнеризации в Linux. Это позволяет запустить процесс с собственной таблицей хостов или файловой системой, не влияя на основную ОС. Техника незаменима для безопасного тестирования скриптов и понимания того, как работают Docker и Podman изнутри.

Сначала создадим изолированную среду с собственной сетевой петлей и новым пространством имен для имени хоста:

sudo unshare --fork --uts --net bash

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

Внутри новой оболочки зададим уникальное имя хоста, чтобы убедиться в полной изоляции UTS namespace:

hostname sandbox-env && hostname

Имя хоста изменится только для этой сессии, в то время как основная система сохранит прежнее название.

Для полной демонстрации сетевой изоляции попробуем поднять интерфейс, который будет существовать только в этом пространстве:

ip link set lo up && ip addr show lo

Внутри этого пространства вы увидите чистый сетевой стек, полностью отделенный от физических интерфейсов сервера.

Проверка работоспособности:

hostname

Ожидаемый вывод: ваше старое имя хоста (подтверждает, что изоляция работает).

Использование namespaces напрямую через unshare — это мощный способ отладки и запуска недоверенных приложений с минимальным оверхедом.
Помните, что для некоторых флагов изоляции (например, монтирования) требуются права суперпользователя или настройка User Namespaces.

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

📂 Напоминалка по единообразию Dockerfile в команде!

Единые правила помогают сократить количество ошибок, упростить ревью и сделать сборку сервисов предсказуемой. На картинке 7 шагов: от определения базовых стандартов и общего шаблона Dockerfile до автоматических проверок в CI, использования общих образов, обучения команды и регулярного улучшения процесса. Такой подход помогает быстрее подключать новые проекты и поддерживать одинаковые практики во всей команде.

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

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

На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем»

В программе только важные аспекты:

— troubleshooting Docker и образов
— диагностика сетевых проблем
— настройка readiness/liveness probes
— отладка pod’ов, деплоев и ingress
— анализ логов контейнеров и кластера
— разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других

Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам

48 часов доступен со скидкой 25%

↗️ Пройти курс на Stepik

Знали, почему jq без -e может пропустить неготовый сервис?

Допустим, проверка здоровья возвращает JSON с признаком готовности:

{"ready": false}

В скрипте хочется прочитать поле и продолжить работу только после готовности. Кажется логичным проверить статус команды:

jq '.ready' health.json
echo "$?"

jq напечатает false, но сама команда успешно обработала JSON и завершится с кодом 0. Если использовать её напрямую в if, скрипт ошибочно пойдёт по ветке успеха.

Для проверки результата добавьте -e:

jq -e '.ready' health.json >/dev/null
echo "$?"

Теперь false или null дают ненулевой код. Но любой другой результат, в том числе число 0 или непустая строка, считается успешным. Поэтому для строгой проверки булевого поля лучше сравнить его с true:

if jq -e '.ready == true' health.json >/dev/null; then
    echo "service is ready"
else
    echo "service is not ready" >&2
    exit 1
fi

Если поле отсутствует, выражение тоже вернёт false. А если JSON сломан, jq завершится с ошибкой разбора, и скрипт не примет его за успешный ответ.

➡️ DevOps Ready | #совет