Комментарии 11
Правильное название панели ispmanager, а не ISPmanager: https://www.ispmanager.ru/materials
Панель меняла свое название, вот, например, тут она называлась ISPmanager:
https://habr.com/ru/company/ruvds/blog/472044/
https://www.isplicense.ru/services/ispsystem/ispmanager4/
https://www.reg.ru/hosting/ispmanager?utm_source=google.com&utm_medium=organic&utm_campaign=google.com&utm_referrer=google.com
Но при использовании Docker и систем оркестрации, таких как Swarm и Kubernetes, а также инструмента Ansible панели управления серверами не устанавливаются на узлы кластера. Просто незачем.
Я читал, что в ispmanager будут встроены средства управления контейнерами Docker:
https://docs.ispmanager.ru/ispmanager6-lite/docker
Но у меня пока нет ясности, как они будут соотноситься (если будут) с системами оркестрации.
Установить Docker на сервер и запустить docker-compose нетрудно и без панели. Но системы оркестрации позволяют реализовать основные преимущества контейнеров, такие как отказоустойчивость и горизонтальное масштабирование. Вот тут как раз интересно, что сможет предложить ispmanager.
С мая 2022 года, когда компания стала самостоятельной, она называется ispmanager. Старое название ISPmanager неверное.
Поддержка докера уже реализована. Там все на уровне управления контейнерами, образами. Монтирование томов, директорий, маппинг портов. Все из интерфейса. Все, что чаще всего востребовано обычными пользователями.
Правильно ли я понял, что контейнеры работают только в рамках одного хоста, где установлена панель, там же находится репозиторий, и никакие средстве оркестрации не используются, а интеграция со Swarm и Kubernetes не планируется?
В этом случае, на мой взгляд, теряется основное преимущество контейнеров — реализация отказоустойчивости и масштабирования для высоконагруженных проектов.
Что же касается монтирования томов и маппинга портов, то на мой взгляд, это куда удобнее делать через файл docker-compose.yml. Этот файл потом можно скачать из registry (GitHib, Harbor и т.п.) и развернуть перечисленные в нем контейнеры на любом хосте одной командой.
На самом деле было бы интересно почитать, для чего и как именно используются средства управления контейнерами ispmanager. То есть описания реальных кейсов с применением ispmanager.
Кстати, фича реквест за интеграцию с Kubernetis вот тут имеется, можете поддержать: https://www.ispmanager.ru/community/feature-request-7
После того как контейнеры запустились, вы можете просмотреть их журналы с помощью команды docker logs:
docker logs gift-docker_app_1
В качестве параметра этой команде нужно передать имя контейнера. Имена всех работающих контейнеров легко определить с помощью команды “docker ps”.
Господи, у вас же compose, к чему все эти приседания с ps и суффиксами _1 ?
Ну и набирайте сразу docker compose logs -f app (если cli свежий, а если старьё, то docker-compose logs -f app)
Let’s look at the logs using the docker compose logs -f command. You’ll see the logs from each of the services interleaved into a single stream.
Правильно ли я понимаю, что логи от всех контейнеров попадут в один поток? А нужно ли так? Все же там несколько контейнеров.
Аргумент передайте, с именем сервисаdocker compose logs -f выдаст все контейнеры в один потокdocker compose logs -f mariadb или docker compose logs -f memcached выдаст логи единственного контейнера, сами догадайтесь какого именно. Или app укажите, или app_config, какие там еще в вашем примере docker-compose.yml есть.
Перенос в Docker монолитного SAAS-сервиса