Обзор раздела — Linux, Docker и эксплуатация

Любой фронтенд, любой бэкенд, любой пайплайн в итоге бежит на чужом железе под чужой ОС — и в 99 % случаев это Linux. В краткой версии учебника ты прошёл базу: пакетный менеджер, systemd-юниты, LVM и BTRFS, nftables, SSH-туннели, базовый bash и первый Compose-стек. Этого хватает, чтобы поднять сервер и не потерять его. Но эксплуатация — это когда серверов много, когда скрипты работают месяцами без присмотра, когда контейнеры живут не у тебя на ноутбуке, а в продакшене, где ошибка стоит денег и нервов.

Зачем углубляться

Представь три реальных сценария. Первый: бэкап-скрипт, который молча полгода не бэкапил базу, потому что одна команда в пайпе вернула не тот код выхода — и set -e его не остановило. Второй: приложение в контейнере падает раз в сутки с OOMKilled, и никто не понимает, почему — потому что никто не видел cgroups-лимит под капотом mem_limit. Третий: в образ уехал .env с паролем от базы, и он лежит в реестре для всех желающих, потому что слои аддитивны и «удалить файл» в следующем слое — значит только спрятать его.

Во всех трёх случаях проблема решается не магией, а пониманием механизма: как интерпретируется код выхода пайпа, как ядро режет память через cgroups, как устроены слои образа. Этот раздел — про эти механизмы.

Что внутри раздела

Раздел построен как путь эксплуатационного инженера: от инструмента, которым ты управляешь машиной (bash), через то, что держит машину живой (systemd, сети), к тому, что ты на ней запускаешь (контейнеры и их безопасность).

1. Владение shell — bash как полноценный язык, а не набор однострочников. Разбор set -euo pipefail до последнего флага, массивы и ассоциативные массивы, тонкости [[ ]] против [ ], семейство подстановок ${var:-default}, чтение файлов без обрезания строк, функции с локальными переменными, trap и корректная обработка сигналов, практика на awk/sed/jq/curl и финал — полноценный скрипт бэкапа, который не молчит об ошибках.

2. systemd и сети — то, что держит сервер. Полный разбор директив [Unit]/[Service]/[Install], timer-юниты против cron, изоляция зависимостей через systemctl и sandbox-директивы, journalctl как база данных логов. Плюс сетевой блок: ip addr/route, ss, диагностика DNS, полный firewall на nftables, tcpdump-фильтры для расследования инцидентов и SSH-туннели как инструмент проброса.

3. Docker под капотом — что реально происходит при docker run: namespaces, cgroups, UnionFS, пошаговый жизненный цикл контейнера. Слои и кэширование, BuildKit, полноценный multi-stage Dockerfile для Node.js, сборка с аргументами и таймстемпами, анализ образа через Dive и системный подход к уменьшению размера.

4. Compose в продакшене — не демо-стек, а боевой: приложение + PostgreSQL с healthcheck + Redis + Nginx, две изолированные сети, depends_on с условиями, профили, env-файлы и секреты, политики рестарта, драйверы логов с ротацией, ресурсные лимиты и стратегия бэкапа томов.

5. Реестры и безопасность образов — как устроены Docker Hub, GitHub Container Registry, Gitea и собственный registry 2.0 с TLS и htpasswd. Сканирование Trivy, подпись Cosign, запуск не от root, read-only filesystem, capabilities drop, seccomp/AppArmor и runtime-лимиты.

Как работать с разделом

Выполняй всё на живой машине. Заведи тестовую VM (или используй pet-сервер) и каждый пример прогоняй руками — особенно скрипты и firewall.
Пиши свой скрипт бэкапа. Раздел shell-mastery заканчивается эталонным скриптом — а в практике просят свой. Не копируй, пиши по памяти механизмов.
Ломай и чини. Настрой firewall, закрой себя SSH (спойлер: через консоль провайдера всегда можно зайти), потом почини. Так запоминается навсегда.

Минимальный инструментарий

Нужна одна машина с Linux (VM на любом провайдере сгодится), Docker и ShellCheck — линтер bash, который станет главным ревьюером твоих скриптов:

ssh user@твой-сервер   # дальше весь раздел живёт здесь
docker version         # Docker Engine 24+, Compose v2 плагин
shellcheck --version   # линтер bash, ставится пакетным менеджером

Полезно сразу завести привычку держать открытыми два терминала: один — под редактирование конфигов, второй — под логи (journalctl -f / docker compose logs -f). Именно так и работает эксплуатация.