DevOps Ready | IT

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

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

Делаем проверяемый бэкап PostgreSQL!

Резервная копия полезна только тогда, когда её можно восстановить. Поэтому после pg_dump стоит сразу проверить содержимое архива и периодически поднимать базу из этого файла.

Сначала сохраняем параметры подключения вне команды.
export PGHOST=db.internal
export PGDATABASE=app
export PGUSER=backup

Формат custom удобен для восстановления, потому что pg_restore умеет показать состав архива и выбирать объекты. Имя с датой помогает не перезаписать вчерашний дамп.
mkdir -p backups
pg_dump --format=custom --no-owner \
--file "backups/app-$(date +%F).dump"

Проверяем архив до того, как объявлять задачу успешной. Команда выведет таблицы, схемы и другие объекты без реального восстановления.
pg_restore --list backups/app-$(date +%F).dump
test ${PIPESTATUS[0]} -eq 0

Для теста создаём отдельную базу и восстанавливаем туда копию.
createdb app_restore
pg_restore --dbname=app_restore backups/app-$(date +%F).dump

Автоматизация должна логировать дату, размер файла и результат проверки. Ещё полезно настроить хранение нескольких копий вне основного сервера, иначе поломка диска уничтожит и базу, и бэкап одновременно.

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