Стоит задача сдавать в аренду приложение. Каждому клиенту - свой экземпляр.
Как вариант решения - docker или rkt контейнеры. Серверов несколько в разных частях планеты. Приложение выдаётся строго один клиент - один экземпляр. Контейнер запускается, останавливается и перезагружается по желанию клиента клиентом через веб-морду.
1. Вопрос: как это дело лучше организовать? Как контролировать множество хостов с докером с одного сервера?
Я попробовал docker-machine, вроде этого достаточно, т.к. она сама настраивает докер-хосты и делает возможным работу с удалёнными докер демонами через API с сертификатами. Но docker-machine выглядит как тулза для разраба, а не как средство контроля разных серверов с docker.
2. И ещё до кучи вопросик. Приложение работает с файлом базы данных. Оно его при старте читает, при завершении пишет. Его надо как-то загонять в контейнер перед запуском и забирать при завершении работы контейнера. Файл надо забирать с некого хранилища и складывать в это же хранилище, и желательно с бэкапами. Для этого написал bash скрипт, который вроде работает и даже успевает зиповать этот файл базы данных. Но нет ли какого-то решения, которое позволяет монтировать в контейнер некое хранилище из удалённого источника, которое потом автоматом улетит обратно в этот же удалённый источник и ещё и чтобы версионность была?
Сервера в разных частях планеты контролируются полностью Вами, либо это по-сути, чужие сервера, куда Вы просто отдаете отдаете контейнер с инструкцией запуска, и потом к нему доступа особо не имеете?
Распишите, пожалуйста, подробнее предполагаемую схему взаимодействия с клиентами. Какие обязанности у каждой из сторон? (в рамках рассматриваемой задачи, разумеется)
Tyranron: В теории серверы контролируются, это несомненно. По факту я не умею нормально работать с докером, поэтому хочу понять, как это делать правильно. Сейчас я осилил такой финт ушами: докер-машина провизит удалённый сервер, настраивая докер как правильно; я беру сертификаты и тупо подключаюсь по ip типа
Так что да, я имею полный доступ к сервакам. Это решение сейчас это мой хайтек и лучшее что я из себя выдавил. Но оно явно костыльное.
Распишите, пожалуйста, подробнее предполагаемую схему взаимодействия с клиентами. Какие обязанности у каждой из сторон? (в рамках рассматриваемой задачи, разумеется)
Приходит человек на сайт, тыкает "создать сервер" и с сервера сайта на докерный хост отсылается docker run с параметрами и пробрасывается порт наружу. А человеку даётся адрес докер хоста с портом и он к нему подключается и что-то там шуршит неделями. В итоге однажды приложение завершается либо само, либо по команде с сайта, пишет инфу в файл, и контейнер переходит в мир иной.
Вот если оно как-то не так завершается или как-то не так пишет в файл, то нужно сохранить старую версию.
Клиент создает "приложение" или именно "сервер"? Если речь идет о некоем подобии IaaS и создании легковесных виртуальных серверов, то контейнеры тут не зайдут. Недостаточная изоляция по ресурсам.
Если же это именно экземпляр готового приложения, с которым клиент просто работает через интерфейс, не имея возможности менять что-то внутри, то подходит.
Tyranron: приложенька, да. реальная обычная классическая. Я её запихиваю в контейнер насильно. И наружу выставляю один порт с которым работает уже клиент.
igordata: то есть Вам из одного приложения нужно просто запускать другие в контейнерах на разных серверах по миру.
Из-коробочного, увы, ничего не подскажу, да ещё и такого, которое бы ещё и имело кастомные хуки при старте/остановке которые забирают/заливают файл из хранилища. Вот этот кастомный обвяз придется продумывать и реализовывать самостоятельно.
То, что у Вас в схеме есть master, который размещает приложения на worker нодах, очень само по себе напоминает контейнерную кластеризацию. Посмотрите на Docker Swarm и Kubernetes, к примеру. Возможно Вам подойдет какой-то распределенный Kubernetes-кластер, и небольшое свое приложение, работающее с его API и запускающее нужный Вам контейнер на нужном хосте в Pod'е с нужным обвязом. Там, к слову, в комплекте сразу идет и etcd хранилище распределенное.
Вообще говоря Kubernetes не советуют размазывать по нескольким датацентрам, но все как всегда зависит от задачи и деталей. В Вашем случае, если master ноды с etcd будут собраны в одном датацентре, а разные woker ноды раскиданы по миру - то должно быть вполне себе ОК, учитывая что Ваше приложение не требует постоянного и быстрого общения с другими нодами за пределами своего датацентра.
Простой
Средний
