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

🔄 Безопасный арсенал практических инструкций, курсов и инструментов

👩‍💻 Linux & Bash

🤔 Хакинг & ИБ

🖥 Курсы & GitHub

📱 Python

🥷 OSINT

📂 Сохрани подборку и начни с того, что пригодится тебе уже сегодня.

Проверяем итоговую конфигурацию 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 | #совет