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 без контейнеров.