Pull to refresh

Comments 11

Панель меняла свое название, вот, например, тут она называлась 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.

Да, все верно вы поняли.

Реальные кейсы - например, поднятие контейнера с Redis для кэширования WordPress сайта. Или поднятие контейнера с MongoDB опять же для нужд сайта.

Докер файлом или docker-compose.yml никто не мешает пользоваться в командной строке хоста.

Кстати, фича реквест за интеграцию с Kubernetis вот тут имеется

Система оркестрации контейнеров называется не Kubernetis, а Kubernetes

Название Kubernetis неверное ;-)

После того как контейнеры запустились, вы можете просмотреть их журналы с помощью команды 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 есть.

Sign up to leave a comment.