Я уже неоднократно поднимал тему self-hosted сервисов. Напомню, что, в настоящий момент, практически все сервисы, для которых я сам выступаю хостером, подняты на витруальных машинах (используется VirtualBox), причем, каждый сервис - в своем собственном docker контейнере (или наборе контейнеров). В свое время я принял решение, что буду использовать Docker Compose для развертывания и управления сервисами, даже если сервис - одноконтейнерный.

Сначала я активно перетаскивал в свое собственное облако то, что я использую почти каждый день. Потом, постепенно, дошло дело и до более экзотичных сервисов. Но одно оставалось неизменным: для того, чтобы поднять новый сервис (или обновить уже используемый), я подсоединялся по SSH к нужной виртуалке и, в командной строке, выполнял необходимые действия. А я ведь известный любитель всевозможных пользовательских интерфейсов, и командная строка для меня - как красная тряпка для быка: она заставляет искать какой-нибудь софт для реализации тех же возможностей, но при помощи GUI.

Да, я все понимаю, при (серьезном) администрировании командная строка - очень полезный и удобный инструмент. Она позволяет автоматизировать многие повторяющиеся рутинные процедуры, которые, в противном случае, пришлось бы протыкивать мышкой. Собственно, я сам этим иногда балуюсь. Но для разовых редких операций писать многострочные команды... Бррр... Нет уж, увольте.

Дело замены командной строки на что-то более удобное для работы с мышкой продвигалось постепенно. Сначала, я развернул phpVirtualBox, что позволило работать с виртуальными машинами почти так же, как и из родного для VirtualBox GUI клиента. Но Docker...

Он долго сопротивлялся, тем не менее, пришло и его время. Конечно, я тщательно изучал различные статьи на тему замены командной строки для Docker. Особенно меня интересовали варианты, включавшие развертывание сервера и доступа к нему через web интерфейс. Тут я позволю себе немного отойти в сторону от основной стези повествования и потратить немного времени на то, чтобы рассказать о своем отношении к web интерфейсам.

Если честно, я до сих пор отношусь к ним с опаской и использую их весьма осторожно. Почему? Все просто. Я всю свою сознательную трудовую жизнь работаю разработчиком ПО (или прогером, как говорит моя дочь) - пишу программы. И я знаю, какие неожиданные результаты можно получить, запуская один и тот же софт на двух разных компьютерах, которые отличаются, нет, даже не версией операционной системы, не используемыми драйверами, а просто набором софта, установленным на конкретном устройстве. Поверьте, интерференция иногда приводит к обескураживающим результатам.

В случае же с web приложениями, разработчики в очень грубой и навязчивой форме добавляют пользователю здоровущий слой потенциальных проблем - браузер. Вот вы каким пользуетесь? Какой предпочитаете? Всегда ли вы его обновляете? А какой движок javascript используется в вашем браузере знаете? Нет? Не задумывались? А я на некоторые эти вопросы знаю ответы. Потому и опасаюсь. Ведь теперь надо знать не только особенности разных версий одной и той же операционной системы (если речь про Windows), но и особенности различных версий всевозможных браузеров, их рендиринговых машин и движков javascript. И - да, на различных версиях ОС.

Понятно, что программисты, реализуя какие-то конкретные задачи, используют библиотеки, которые прошли весь цикл разработки и тестирования. Кроме того, они (библиотеки) задействованы в тысячах проектов, но... Эти библиотеки пишут и тестируют обычные люди. А людям свойственно ошибаться.

Казалось бы, после всего сказанного, почему я ищу именно web приложения? Дело в том, что они обладают одним неоспоримым преимуществом - для их использования не требуется установка (речь, конечно же, про клиентскую часть). Для работы вам необходим лишь компьютер (планшет, телефон - выберите, что вам больше нравится) с установленным на нем браузером. То есть, то, что, с моей точки зрения, делает web приложения несколько непредсказуемыми, является и их сильной стороной. Вот такое вот единство и борьба противоположностей. Но, вернемся к теме.

Как давно известно - кто ищет, тот всегда найдет (приключений), нашел и я. У меня сформировался примерно такой список:

• Portainer
• Rancher
• Docker Compose UI

Первым я установил Portainer. И, надо сказать, я был впечатлен. Этот софт делал почти все, что мне было нужно. Тут была возможность подключения нескольких машин с Docker-ом, которыми нужно управлять (у меня их теперь три). По каждому контейнеру можно получить статистику - интересно же, сколько памяти или процентов использования процессора отъедает от ресурсов виртуалки тот или иной контейнер. Можно остановить, перезапустить, удалить нужный набор контейнеров.

И все же, ключевым, в случае с Portainer, является слово "почти". Некоторые приложения, используемые мной, являются многоконтейнерными, и именно для них использование Docker Compose является наиболее оправданным. Но, как раз таки с такими приложениями Portainer и не умеет работать - он их замечательно показывает, но управлять ими, как единым целым - не обучен.

Самостоятельно можно отметить нужные контейнеры и произвести с ними определенные манипуляции. Но вся прелесть Docker Compose заключается именно в том, что вы не просто перечисляете в compose файле нужные сервисы, вы еще определяете и их взаимодействие, зависимости друг от друга, вплоть до порядка запуска. И, один раз описав, больше не думаете об этом. Поэтому я продолжил свои эксперименты, хоть и оставил Portainer - пусть работает.

Следующим на очереди был Rancher. Это значительно более тяжелая система, с точки зрение ресурсов, но и возможностями она обладает очень впечатляющими. По крайней мере, по описаниям. Самое главное, что в различных источниках указывалось, что Rancher умеет работать с compose файлами. Правда, при этом все время упоминался еще и какой-то собственный механизм Rancher stack.

Все было довольно туманно, так что я понял, что ясность может внести только самостоятельное изучение вопроса. Поэтому я засучил рукава и перешел к установке ПО. Выбрал я более старую, по идеологии, версию Rancher Server, так как новая (называется просто Rancher) очень сильно заточена под Kubernetes. Rancher Server же продолжает поддерживаться разработчиками и получать обновления, то есть, не заброшен.

Первым неприятным сюрпризом стало то, что для полноценной работы мало установить сам сервер, надо еще на каждый хост, который вы хотите подключить к серверу, установить специального агента. Почему это стало сюрпризом? Docker позволяет работать с удаленными хостами без какого бы то ни было дополнительного софта. Надо лишь настроить нужные машины, разрешив использовать для этих нужд порт 2375 - именно это я проделал для Portainer, чтобы получить доступ к другим виртуалкам. (Кстати, в документации Docker написано, что порт можно изменить, но крайне не рекомендуется это делать).

А тут выяснилось, что для Rancher Server этого не достаточно. К тому же, мне пришлось устанавливать агента даже на той машине, на которой был развернут сам сервер. Может, конечно, я что-то недопонял и можно было сделать как-то по другому. Но для себя, я нашел следующее оправдание этому феномену: во-первых, агент нужен для того, чтобы дать серверу больше возможностей, чем может предложить стандартный Docker через свой порт 2375; а во-вторых, агент нужен на всех машинах, включая серверную, для унификации взаимодействия - в противном случае пришлось бы функционал агента включать в сервер.

Разобравшись с установкой, я перешел к изучению возможностей Rancher Server. Честно признаюсь, процесс этот был очень короток. Очень быстро я удалил и сервер и агента со всех своих машин. Дело в том, что, по непонятной мне причине, Rancher Server, без каких либо предупреждений, остановил и удалил практически все мои docker приложения, оставив лишь парочку на одной машине.

Делал он это не очень спешно, и я не сразу обратил внимание на то, что список поднятых программ укорачивается. Так что, у меня было время чтобы понять, что с Compose приложениями Rancher Server тоже работает в весьма ограниченном режиме. Потом я заметил, что приложений стало мало. Сначала я списал это на глюк, но чуть позже Docker подтвердил, что это мне не показалось - команда docker ps -a вывела еще более короткий список, чем Rancher чуть раньше, причем, в одной из его строк значилось состояние **Removing**. Поэтому я не очень долго размышлял, прежде чем решил, что Rancher Server-у не место в моем зоопарке софта.

Кстати, при его удалении я наткнулся на еще одну неприятную особенность. И сервер, и агент запускаются одной командой docker run, но контейнеров создается больше - я так понимаю, что Rancher сам подтягивает дополнительные сервисы. И вычищать все это богатство мне пришлось вручную, хотя, может, я был невнимателен и просто не нашел, как сделать это одной командой. В общем, я понял, что не дорос я еще до использования Rancher, с наскока его не взять, надо иметь больше знаний и времени.

Третьим я опробовал Docker Compose UI. И им я остался вполне доволен. Как и любой софт, этот тоже оказался не без заковырок, но, в конечном итоге, все заработало более-менее сносно. Итак, несколько слов о том, что и как умеет делать Docker Compose UI.

Ставится он просто, никаких дополнительных сервисов не подгружает и не запускает. Для управления приложениями, запущенными с использованием Docker Compose, ему требуется доступ к соответствующим YML файлам. При этом, программа предполагает, что файлы эти должны лежать каждый в своем подкаталоге, которые, в свою очередь, должны принадлежать одному родительскому каталогу. Особенностью моего случая было то, что у меня, как раз, имелась в наличии нужная структура - каждый файл docker-compose.yml у меня лежит в собственном каталоге (в домашнем каталоге пользователя, от имени которого запускается приложение), а все эти каталоги принадлежат одному родительскому каталогу - /home. И на первой своей виртуальной машине, на которой я поднял приложение Docker Compose UI, я просто подмонтировал в качестве родительского каталога с нужной структурой свой каталог /home на виртуалке, после чего все сразу заработало без каких либо вопросов.

Что же можно сделать при помощи Docker Compose UI? На самом деле, не мало. По каждому поднятому приложению можно получить информацию, какие используются контейнеры, какие порты замаплены, какие тома используются.

Как видите, есть также доступ ко всем основным командам Docker Compose: stop, start, down, up, pull и другие. Можно посмотреть содержимое docker-compose.yml файла приложения, логи, более подробную информацию о запущенном контейнере. В общем, есть все, для чего я, ранее, пользовался командной строкой.

Можно также попробовать управлять приложениями, выполняемыми на удаленном Docker хосте.

Правда, для этого необходимо иметь локальные копии файлов docker-compose.yml приложений, организованные в такую же структуру каталогов. Я не захотел перетаскивать это все с удаленного хоста, решив просто поднять там такое же приложение. И вот тут я столкнулся с первой, назовем это так, особенностью обсуждаемого софта.

На второй виртуалке у меня поднято значительно больше контейнеров, и, хотя все файлы docker-compose.yml размещены точно так же, как и на первой виртуалке (каждый в своем каталоге пользователя, являющимся подкаталогом каталога /home), тем не менее, после монтирования каталога /home и запуска контейнера, список найденных приложений был пуст.

Я какое-то время пытался разобраться, в чем дело, что именно отличает две виртуалки, но был к тому моменту уже довольно сильно вымотан всевозможными закидонами исследуемого софта (напомню, это было уже третья изучаемая программа), поэтому решил взять передышку. И это-то меня и спасло от многочасового выяснения причин фантомной неработоспособности ПО. Когда, спустя, примерно, полчаса, я вернулся к ранее открытому окну браузера, то с удивлением обнаружил в нем список запущенных программ - все, как положено.

И тут меня осенила догадка - Docker Compose UI, видимо, сканирует все дерево каталогов, начиная с корня, в качестве которого я указал /home. Надо сказать, что на этой виртуалке почти у каждого домашнего каталога пользователя был подкаталог с данными, разделяемыми с запущенным в Docker соответствующим приложением, и, в некоторых случаях, это были очень большие структуры - например, моя книжная библиотека, или, скажем, фильмотека, да и музыкальная коллекция ничуть не меньше. И Docker Compose UI , видимо, сканировал все это богатство, на что требовалось довольно много времени.

Я решил проверить догадку - создал подкаталог в домашней папке пользователя, от имени которого запускал Docker Compose UI, скопировал туда все актуальные файлы docker-compose.yml (каждый в свой подкаталог) и перезапустил конейнер, указав ему вместо /home новый родительский каталог. И что вы думаете? Все прекрасно заработало.

В результате проведенного марафона, у меня осталось два установленных приложения: Portainer и Docker Compose UI, причем, последнее - в трех экземплярах, по одному на каждый хост с Docker. Такие вот дела.