Управлять несколькими докер хостами с одного сервера

1) у Docker есть rest api для деланья всего что ты можешь сделать с руки через /bin/docker . Есть биндинги для pytohn и go, найти в сети или написать свои для другого языка не проблема.

2) Docker останавливая контейнер удаляет все изменения в фс, тебе надо примонтировать директорию через volume читай тут https://docs.docker.com/engine/tutorials/dockervolumes/ .Саму директорию тебе надо примонтировать через некую сетевую фс или что то подобное, так у тебя будет надёжно всё сохраняться не только по остановки контейнера но и всегда.

Вообще Docker подходит для одного приложения на контейнер, оставь там прикладную программу и вынеси бд во вне. Не знаю можно ли в rkt запускать несколько процесов но если у тебя всё таки стоит задача иметь в контейнере свою изолированную базу, то lxc (или lxd - rest) наверно единственный вариант.

Спасибо, понял. Файл БД там sqlite, приложенька его читает, приложенька его пишет. Я надеюсь она пишет только по окончании работы - по сети не охота гонять лишний траф.

По факту получается идеологичненько - один процесс на один контейнер. А то что внутри там у процесса sqlite это уже второй вопрос.

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

Идея дать ему жить с sqlite связана с тем, что приложение старое и не умеет нормально работать в условиях такого масштабирования. Ему надо чтобы его данные были строго привязаны к номеру его инстанса. Не очень понятно, зачем ему вообще этот номер и эта привязка. С документацией туго.

иметь в контейнере свою изолированную базу, то lxc (или lxd - rest)

Почему?

Да, если sqlite то использование Docker и любой другой системы контейнерезации подойдёт как нельзя кстати. По поводу танцев с базой, наверно в твоём случае будет тогда хорошим вариантом примонтировать просто локальный каталог и скриптом по завершению работы клиента с контейнером копировать базу и другие файлы (если они есть) кудато, вариантов как это организовать масса, или делать копии раз скажем в 5 минут.

пытаясь оценить, как оно будет, если бд будет далеко-далеко

А зачем его далеко далеко? почему нельзя локально? Можно поднять локальную базу и настроить репликацию, и не надо шаманить как выше описаном варианте. Для изоляции создавай на каждый инстанс свою баззу внутри мускула. А доступ к базе по сети на другой физически разнесённый хост будет всегда болью, тем более если приложение плохо написано.

Почему?

Ну потому что это единственный боле мене вариант если было бы требование иметь 2 процесса - приложение и субд за которыми должна смотреть система инициализации. Есть варианты связывать их черех localhost через Docker compose или rkt чегото там, но это проблеммы т.к. тут приплетаеться целая система оркестрации и на одну логическую сущность получается сразу 2 контейнера, да и к томуже зачем иметь копии инстансов СУБД, они неплохо отожрут ресурсов, СУБД именно на то и СУБД что позволяет управлять множеством баз данных.

1) у Docker есть rest api для деланья всего что ты можешь сделать с руки через /bin/docker . Есть биндинги для pytohn и go, найти в сети или написать свои для другого языка не проблема.

Поддерживаю сего оратора, однако, прежде чем пойи по этому пути, следует подумать, точно ли ты хочешь писать свою собственную кривую, глючную, недокументированную реализацию кубернетиса?

точно ли ты хочешь писать свою собственную кривую, глючную, недокументированную реализацию кубернетиса?

Да! Ещё бы! Я уже скачу галопом по этому пути. Тут надо прикинуть, че мне проще, дёргать этой командой, что я выше привёл, или пыжиться освоить кубер, хотя я не админ нишиша.

Есть варик нанять админа за денежку, но я сейчас на мели, и поэтому пока вот репу чешу.

будет тогда хорошим вариантом примонтировать просто локальный каталог и скриптом по завершению работы клиента с контейнером копировать базу и другие файлы (если они есть) кудато, вариантов как это организовать масса, или делать копии раз скажем в 5 минут.

Ну вот я сейчас замутил мегакрутой чудоскриптик на баше, который трапает сигналы завершения и киляет приложение, оно штатно завершается, а скриптик успевает файлик зазиповать и перекинуть в шареную папку.

Только это костыль и бесит, т.к. приходится делать два баш-скрипта, т.к. я не знаю или не умею как отловить момент завершения процесса. Поэтому первый скрипт стартует второй, внутри второго стартует процесс приложения, а первый крутит бесконечный while sleep 1 и трапает сигнал. Когда сигнал приходит, то цикл прерывается, потом он тупо ждёт несколько секунд, которых (по счастливому совпадению) хватает второму скрипту, который просто продолжается после запуска и выхода приложения, и успевает зазиповать базу. Но если он будет долго канителиться, то первый скрипт выйдет и докер прибьёт контейнер. Т.е. получается, мне надо в первом скрипте на глаз ляпать слип и молиться, что каждый раз будет хватать. Жесть. Велосипед из костылей.

А зачем его далеко далеко? почему нельзя локально?

Чтобы гонять файлы между физическими серваками.

Для изоляции создавай на каждый инстанс свою баззу внутри мускула. А доступ к базе по сети на другой физически разнесённый хост будет всегда болью, тем более если приложение плохо написано.

Плодить базы не охота, сейчас это всё штатно живёт в одной. Иногда падает. По факту я уже решил забить на sqlite, т.к. сейчас приложение одно для всех, и если падает то у всех. А когда будут контейнеры, то если оно у кого-то упало, то тут же и встало и поху

СУБД именно на то и СУБД что позволяет управлять множеством баз данных.

Факт. Плодить по бд на каждый инст приложения я точно не буду. sqlite ничем не хуже и не лучше, тоже по общей базе не пошаришься, тоже всё живёт на честном слове. Я сейчас склоняюсь к идее оставить общую БД, благо разделение данных по клиентам предусмотрено в самом приложении. И забить. Тогда и масштабировать проще, и гонять файлы не надо, и работать будет на штатных механизмах удалённого подключения к мускулу.

В данный момент я пытаюсь понять, почему lib*mariadb.so не цепляется к приложению. Возможно потому, что докер-контейнер куцый:

FROM scratch
ADD rootfs.tar.xz /

Сошка sqlite цепляется, а сошка марии - нет. Чешу репу дальше.

Есть варик нанять админа за денежку, но я сейчас на мели, и поэтому пока вот репу чешу.

Сколько вообще это может стоить? Настроить и поддерживать переодически.

k8s не такой уж и страшный. И https://github.com/kubernetes-incubator/kargo, говорят, уже достаточно зрел для использования.

В любом случае поставить по мануалу и освоить k8s с помощью парочки туториалов будет быстрее, чем городить всю эту лабуду самостоятельно.

я пытаюсь я не уверен, что мне это нужно сейчас.

Т.е. если я это проверю и оно заработает - то да. По факту я не админ и мне не платят за это, я делаю это потому, что у меня нет админа. :D

ТС нужен просто контейнер с базой внутри, куберенетес все только усложнит. Хоть он и запускается в дефолтном режиме с полпинка, у ТС по дороге выплывет куча проблем, таких как: изолировать контейнеры друг от друга по сети, свелосипедить мультизонность, зароутить трафик из интернета в контейнеры, настроить аутентификацию и авторизацию на объекты кластера (поды, RC и т.д.). Это просто то, что навскидку пришло в голову. Наивно считать, что это можно быстро осилить, тем более не-админу.

хорошее название, какраз вокруг этого кубернейта - сложился эдакий карго-культ.

для закидываяния контейнера на кучу машин есть swarm от разработчиков докера, и этого тс-у хватит с головой

Спасибо, мужик! Теперь я не считаю себя отсталым.

За неимением опыта я хотел бы спросить вот что: Мне каждый контейнер надо запускать со своими настройками с указанием какой порт светить наружу и какие данные забирать из БД. Я же по мере читания про Swarm и Swarm mode почему-то пришел к выводу, что он нужны для другого - превратить пачку сереров в одном ДЦ в как бы один большой докер хост. А у меня по одному серваку в разных ДЦ по миру.

ну не совсем так, сварм и его приемник позволяют именно через одну точку входа (swarm собственно, или мастер-ноды в случае swarm-mode) запускать контейнер на произвольной ноде (сервере), причем как на «любой», так и указав ее через constraints

да, т.к. они разрабатывались в первую очередь для управления кластерами то поддерживают «скалирование» - когда надо запускать несколько одинаковых контейнеров и балансировать нагрузку меж ними, но никто не запрещается запускать разных контейнеров.

единственная заморочка - нужен будет доступ к docker-api каждого сервера, а торчать этим апи наружу - очень нехорошо, придется городить некий vpn