DevOps Ready | IT

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

Изоляция процессов в 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 | #практика