ISPmanager 6 дозволяє керувати Docker-контейнерами поряд зі звичайними сайтами на одному сервері: панель розгортає модуль, а далі контейнери створюються та обслуговуються або через веб-інтерфейс, або напряму через docker у SSH. Розбираємо встановлення, створення контейнера, типові помилки та межі, за якими керування контейнерами краще винести за межі панелі.

Встановлення модуля Docker для ISPmanager

# Встановлення через CLI
ispmanager plugin.install docker

# Або через інтерфейс:
# ISPmanager → Магазин застосунків → Docker

Модуль встановлює сам Docker Engine, якщо його ще немає в системі, і додає до панелі розділ керування контейнерами. Це окремий пакет, а не частина базового встановлення — якщо розділ не з'явився в меню після встановлення, перевірте ліцензію: модуль Docker доступний не в усіх редакціях ISPmanager. Встановлення триває пару хвилин і потребує перезапуску панелі, щоб новий пункт меню підхопився інтерфейсом.

Створення контейнера через ISPmanager

Після встановлення модуля: Інструменти → Docker → Контейнери → Створити

Образ: nginx:alpine
Порти: 8080:80
Томи: /var/www/myapp:/usr/share/nginx/html:ro
Перезапуск: always

Параметри створення контейнера

Поле	Що означає
Образ (image)	Ім'я і тег образу з Docker Hub або приватного registry
Порти	Проброс порт_хоста:порт_контейнера
Томи	Проброс каталог_хоста:каталог_контейнера, суфікс `:ro` — лише читання
Перезапуск	Політика restart: no / always / on-failure / unless-stopped

Керування через CLI

# ISPmanager зберігає конфіги в /etc/ispmgr/docker/
docker ps --format "table {{.Names}}	{{.Status}}	{{.Ports}}"

# Логи контейнера
docker logs -f mycontainer --tail 100

Контейнери, створені через панель, залишаються звичайними Docker-контейнерами: їх видно і в docker ps, і можна перезапускати штатними командами. Панель лише зберігає декларативний опис поряд зі своєю конфігурацією, щоб при перезавантаженні сервера відновити стан. Це зручно для діагностики: якщо контейнер поводиться не так, як очікувалося, не обов'язково повертатися до веб-інтерфейсу — всі стандартні команди Docker працюють напряму з SSH.

Типові помилки під час роботи з контейнерами

Повідомлення	Що означає
`Error: bind: address already in use`	Порт хоста вже зайнятий іншим процесом або контейнером — наприклад, Apache/Nginx самого сервера слухає 80-й порт
`Error response from daemon: pull access denied`	Образ не знайдено в публічному registry, або потрібна авторизація в приватному registry
`Cannot connect to the Docker daemon`	Служба `docker` не запущена, або користувач панелі не входить до групи `docker`
Контейнер у статусі `Restarting` по колу	Процес усередині контейнера падає одразу після старту — дивіться `docker logs`, зазвичай помилка в конфігу застосунку

Docker Manager в ISPmanager проти чистого CLI: порівняння

Критерій	Через ISPmanager	Через CLI напряму
Швидкість створення одного контейнера	Швидше для простих сценаріїв	Швидше при повторюваних задачах зі скриптами
Docker Compose (стек з кількох сервісів)	Лише в редакції Pro	Завжди доступний
Версіювання конфігурації	Немає вбудованого	docker-compose.yml можна зберігати в git
Доступ для клієнта без SSH	Так — через веб-інтерфейс	Ні, потрібен SSH-доступ

Коли керування через ISPmanager не підходить

Потрібен повноцінний оркестратор з масштабуванням і health-check — це завдання Docker Swarm або Kubernetes, а не панелі хостингу
Стек складається з 5+ пов'язаних сервісів з мережами та залежностями запуску — керувати цим через окремі картки контейнерів в інтерфейсі незручно, потрібен docker-compose або окремий CI/CD
Потрібен автоматичний CI/CD з перезбиранням образу при кожному коміті — панель не замінює пайплайн збирання
Контейнери критичні для аптайму і потрібен моніторинг з алертами — використовуйте окремі інструменти (Prometheus, Grafana), Docker Manager в ISPmanager цього не дає
Кілька серверів мають працювати як один кластер зі спільним станом — панель керує контейнерами лише на тому сервері, де встановлена, без кластеризації між вузлами

Перевірка результату

Після створення контейнера переконайтеся, що він не просто в статусі Up, а дійсно відповідає на пробросі порту.

# Статус контейнера
docker ps --filter "name=mycontainer"

# Перевірка, що порт справді відповідає
curl -I http://127.0.0.1:8080/

Якщо curl зависає або повертає Connection refused при статусі Up — перевірте, що застосунок усередині контейнера слухає 0.0.0.0, а не 127.0.0.1: у другому випадку проброс порту з хоста не дістанеться процесу. Додатково перевірте стан томів: файли, змінені всередині контейнера, мають з'являтися і на хості. Суміжна тема — запуск Node.js та Python-застосунків в ISPmanager без контейнерів.