# Запустила контейнери на Podman і Quadlet

Розгорнула контейнерну платформу на Podman і Quadlet під systemd, а не на Docker, бо Docker публікує порти контейнерів із вищим пріоритетом, ніж власні правила фаєрвола хоста, — а для розгортань виділила непривілейованого користувача з однією фіксованою командою замість root.

вересень 2026

**Ситуація.** Платформі потрібне було місце для запуску контейнерів застосунків. Очевидним вибором був галузевий стандарт, і для цього хоста він не годився з цілком конкретної причини: він переписує правила пакетного фільтра ядра й публікує порти контейнерів із вищим пріоритетом, ніж правила брандмауера, які встановлює роль посилення захисту, тож контейнер непомітно стає доступним з інтернету, хоч би що було прописано в брандмауері.

**Завдання.** Треба було обрати контейнерне середовище, яке не обходить брандмауер, не додає другого супервізора поруч із тим, якому вже довіряють, і не вимагає root‑доступу, щоб випустити реліз.

**Дія.** Це середовище — контейнерний рушій без демона, який керує юнітами, згенерованими власним супервізором операційної системи. Другого менеджера процесів немає: контейнери — це служби, вони запускаються так само, як служби, і описані в тій самій декларативній формі, що й усе інше. Контейнери використовують мережу хоста й не публікують жодного порту, тож питання обходу брандмауера не пом'якшено, а знято. Юніти працюють на системному рівні, а не в rootless‑режимі, і це записано як компроміс: автоматизація лишається нескладною та звичною ціною суворішої ізоляції, яку дав би rootless‑режим, а в примітці сказано, у який бік рухатися, якщо втеча з контейнера колись важитиме більше за простоту автоматизації. Розгортання відокремлено від підготовки хоста: root один раз налаштовує шлях розгортання, а далі непривілейований користувач перерозгортає застосунок, запускаючи один фіксований скрипт через вузьке правило, яке дозволяє саме цю команду й жодних аргументів. Зібрати образ, перезапустити службу. Жодної root‑оболонки, жодних довільних команд.

**Результат.** Контейнери працюють під супервізором, якому вже довіряли, за брандмауером, який уже було задекларовано, а звичайний реліз не потребує привілейованого доступу. Відмову від стандартного варіанта записано разом із причиною, і це важить більше за сам вибір: наступній людині кожна стаття, яку вона прочитає, радитиме взяти стандартний.

---

- Роль: Інженер з автоматизації інфраструктури
- Категорії: [DevOps](https://engineer.company/uk/categories/devops/), [Інфраструктура](https://engineer.company/uk/categories/infrastructure/), [Контейнери (Docker/Kubernetes)](https://engineer.company/uk/categories/containers/), [Автоматизація та CI/CD](https://engineer.company/uk/categories/automation/), [Linux та сервери](https://engineer.company/uk/categories/linux/), [Безпека](https://engineer.company/uk/categories/security/)
- Послуги: [Хмарна інфраструктура та міграція](https://engineer.company/uk/services/cloud-infrastructure/), [DevOps та автоматизація CI/CD](https://engineer.company/uk/services/devops-cicd/), [Контейнеризація та оркестрація](https://engineer.company/uk/services/containerization/), [Безпека та керування доступом](https://engineer.company/uk/services/security-access/)

<https://engineer.company/uk/portfolio/ran-containers-on-podman-and-quadlet/>
