Как мы это сделали. DockStation — сервис для управления проектами на Docker

В проекте dev.by «Как мы это сделали» белорусские стартарперы делятся с аудиторией собственным опытом по разработке ИТ-продуктов. Сегодня о своём проекте рассказывает Игорь Козловский, основатель и разработчик DockStation — сервиса для управления проектами, базирующимися на Docker.

Как всё началось: необходимость в едином и автономном окружении для разработки

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

Рано или поздно многие разработчики подходят к той границе, когда появляется необходимость в создании единого и автономного окружения для разработки. Такое окружение без проблем можно перенести с одной машины на другую, отключить одним кликом, поделиться им. С учётом этой необходимости, все дороги вели к Vagrant.

Однако последние два года на слуху была какая-то неведомая и непонятная для меня штука, которая вроде как подходила под мои надобности — Docker. Этот проект часто удостаивается наград и премий, а некоторые и вовсе называют его лучшим из того, что было создано за последние 20 лет. Однако, даже несмотря на то, что по ночам я немного DevOps-ил (пока никто не видит), для меня все эти «изолированные контейнеры» были тёмным лесом. Тем не менее, я решил разобраться в этой интересной вещице.

Docker: как всем этим управлять?

Первые шаги в освоении были не совсем простыми, но в некоторых моментах мне помогали ребята из сообщества dev.by в Slack-чате.

Хотя Docker позиционирует себя как инструмент для деплоя, я понял, что он полностью удовлетворяет всем моим требованиям к среде для разработки.

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

Собрав и перенеся свои личные и рабочие рабочие проекты и получив по итогу более полусотни контейнеров, я столкнулся с вопросом: «Как всем этим управлять?». Знаю по своему опыту: если есть что-то консольное, то должно быть что-то «мышко-юзабельное» на GUI. Начались поиски приложения, которое помогло бы управлять всем этим делом.

Конкуренты «не решают глобальных вопросов»  

Первое, на что я наткнулся, был Kitematic — GUI-приложение от Docker, которое позволяет производить манипуляции с контейнерами. К слову, эти ребятам сейчас уже являются нашими косвенными конкурентами, а может, и будущими партнерами, кто знает.

Можно без вопросов остановить, перезапустить, удалить контейнер, произвести многие манипуляции с ним, такие как просмотр логов или быстрый доступ в контейнер.

Но это не решало мою проблему: разобрать контейнер от такого проекта — задача не из простых. Да и никаких глобальных вопросов оно не решало, лишь немного помогало работать с контейнерами и мониторить их состояние. Затем я рассмотрел Rancher, но снова не то: этот инструмент предназначен и заточен для деплоя, и для разработчика он не совсем подходит. Были найдены схожие инструменты, но все они были аналогами Rancher. Что ж, раз решения под нужную задачу не существует, сделаем решение своими руками.

DockStation: полгода кропотливой работы

Одному такой проект тянуть было бы очень сложно, разработка «в одно лицо» заняла бы много времени. В декабре 2016 года я пришёл с этой идеей и с предложением совместной разработки к своему другу Павлу Лозко. Он работал с Docker, поэтому быстро понял общий смысл проекта и дал согласие на участие. 

Через два месяца я перешёл на фул-тайм работу над проектом.

В итоге мы нарушили все правила, проигнорировали советы великих стартап-гуру о том, что нужно запускаться уже на стадии Hello World и, имея на руках только лишь идею, бежать к инвесторам за деньгами на MVP. Спустя шесть месяцев кропотливой и тяжёлой работы проект вышел в свет.

В основе проекта изначально лежали принципы:

1. Не обязательно учить тонны документации на начальном этапе, чтобы начать работу с Docker и Docker Compose. Хотя саму философию и принципы всё же понять нужно.

2. Приложение должно быть нативным, чтобы не пришлось танцеать с бубном для простого запуска (привет, Rancher).

3. Обратная совместимость. Все сгенерированные проекты должны запускаться как в приложении так и через CLI. Аналогично как и наличие возможность импорта сторонних Docker Compose проектов в приложение.

4. Всё, что можно, максимально перенести в GUI.

Что мы умеем сегодня:

1. Быстро создавать проекты на лету.

  • импортировать уже имеющийся проекты, просто указав путь к директории в которой лежит docker-compose.yml файл конфигурации

  • парсить Docker команды (beta). Для тех, кто всегда пользовался только docker run командами, есть возможность импортировать проект, просто введя эти команды, они будут переведены в Compose проект.

  • создавать проект с нуля просто одним кликом мыши

2. Мониторинг проектов и сервисов. В любой момент можно узнать, работает ли проект, а если нет, то какой из сервисов не работает. С помощью логов найти, в чём заключается проблема.

3. Управление сервисами и контейнерами.

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

4. Приятные дополнения вроде установки локального хоста для контейнера.

Поскольку IP контейнеров меняются при перезапуске, управлять проектом, используя локальное хост-имя, становится не совсем просто. Мы решили эту задачу: при смене IP контейнера будет установлена актуальная хост-запись в /etc/hosts.

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

Также проектом заинтересовалась компания Docker. В данный момент ведутся переговоры о сотрудничестве, но пока делать какие-то прогнозы преждевременно. Мы очень стараемся и надеемся, что подружимся с ними.

В планах — монетизация, инвестиции, партнёрские отношения

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

В арсенале у нас имеется несколько планов по заработку. Основной — публикация проекта как Open Source с применением двойного лицензирования, c платной поддержкой и персональной доработкой под какие-то узкие потребности. По схожей модели успешно работает тот же Rancher.

Также в запасе пару других моделей, на случай, если что-то пойдёт не по плану.

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

Советы и полезные ссылки 

1. Убедитесь, что проблема существует на самом деле. Желательно решать проблемы, с которыми вы сталкиваетесь лично. В идеале — проблемы той сферы, в которой вы имеете профессиональные компетенции. Чтобы потом в один прекрасный момент не оказалось, что проблему, которую вы так рьяно решали, либо уже давно решили, либо её не существовало вовсе.

2. Слушайте, но думайте. Вы повстречаете много советчиков, которые будут с видом экспертов рассуждать, как нужно и правильно что-то делать, почему ваш проект bullshit и т.п. Нет единого алгоритма сделать проект успешным. Просто принимайте решения, как посчитаете нужным, своей головой, а не чужой.

3. Не советовал бы гоняться за трендами лишь с единой целью — сделать стильный-модный-молодёжный стартап. Если вы прикрутите нейронные сети к микроволновке, маловероятно, что вас купит Google. Не нужно совать AI, AR, NN куда попало лишь потому, что это сейчас на волне популярности.

4. Просите — и получите, ищите — и найдёте, стучите — и вам откроют. 

Полезные ссылки

  • devby.slack.com — сообщество dev.by в Slack. 
  • addthis.com — сервис обмена ссылками в социальных сетях
  • themeforest.net — площадка по продаже шаблонов, где можно найти красивый шаблон, позволяющий быстро создать сайт или лэндинг страницу проекта
  • bitbucket.org — распределённая система контроля версий, которая позволяет бесплатно создавать приватные репозитории
Источник: dev.by

Обсуждение

7df30b74d305843fa914ee4b84813649?1497632917
-1

Я боюсь, что все эти инструменты, позволяющие в GUI накидать нужную тебе конфигурацию, имеют проблемы, схожие с ORM (и даже в чем-то даже с курсами программирования за месяц).

Вот ты накидал в полуавтоматическом режиме что-то работающее. Вопрос: ты понимаешь что происходит внутри? Что ты будешь делать, если тебе нужно что-то подтюнить (прикрутить что-то нестандартное)? Что будет, если автоматическая конфигурилка уже подзагнулась (давно не обновлялась), а ты уже завязал свою инфраструктуру на неё?

Дырявая (или текущая) абстракция получается, если короче. https://en.wikipedia.org/wiki/Leaky_abstraction

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

093e089c91f183049994214e7c4ed749?1398265251
+5

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

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

По поводу завязки. Вы видимо не очень невнимательно читали. Мы не привязываем никого ни к себе, ни к приложению, т.к. важным пунктом является обратная совместимость. Мы генерируем чистый и нативный docker-compose.yml, который без проблем можно будет запустить из терминала даже без нашей аппы, так что завязка будет только на Dcoker и Docker Compose.

Быстрый старт выбирается от потребности, и в большинстве своем это стандартные вещи.

7df30b74d305843fa914ee4b84813649?1497632917

Парни. Я ж не засираю :) Болью делюсь, скорее.

Для того, чтобы что-то конкретное говорить о вашем продукте, нужно им попользоваться и попользоваться долго. Иначе - балабольство. В другую сторону (я имею в виду расхваливание создателями только-только появившегося чего-то) это тоже работает - но кажется здесь этим не занимаетесь, так что проехали.

Потому что "косяки" подобных инструментов раскрываются спустя некоторое время и обычно внезапно. Условно говоря, вышел docker-compose версии 4 (а на сегодняшний день актуальная версия 3, насколько я знаю), юзеры пытаются его распарсить-сгенерить - а не могут. Или наоборот: юзеры сегодня нагенерили себе конфигов версии 3, а через 2 года захотели что-то поправить. А тул не может - ибо старьё, не поддерживаем.

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

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

7df30b74d305843fa914ee4b84813649?1497632917

p.p.s. В Heroku даже используют термин "erosion-resistant", говоря о поддержке софта и сопутствующих инструментах в долгосрочной перспективе - https://devcenter.heroku.com/articles/erosion-resistance#erosion-is-a-problem-for-apps

093e089c91f183049994214e7c4ed749?1398265251

Владимир, не бегите впереди поровоза. Там была небольшая строчка с упоминанием переговоров напрямую с Docker Inc., где как раз эти вопросы рассматривались также. Если вам будет интересно, можете подписаться на рассылку и будете в курсе событий последний новостей.

093e089c91f183049994214e7c4ed749?1398265251

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

Если так судить, то вообще можно ничего не делать, ведь через N-времени это станет не актуально. Пока мы серьезно заняты этим продуктом и поддерживаем все самые актуальные решения. Но пока за все время, Докер ничего особо не ломал в плане обратной совместимости. А загадывать что-то на 10 лет вперед наверное преждевременно.

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

Контраргнумент наверное относится к условиям эксплуатации, а не к знаниям внутреннего устройства. Т.к. можно не знать устройства ДВС, но можно знать что воду в бак заливать нельзя, иначе поломается, а про природу гидроудара и что станет с блоком, поршнямии и т.д. знать уже не так и обязательно.

7df30b74d305843fa914ee4b84813649?1497632917

Мне есть что вам возразить, но в том, что касается вашего продукта вы правы. Поэтому я не буду с вами спорить. Мне кажется свою нишу вы займете. Успехов!

093e089c91f183049994214e7c4ed749?1398265251

Спасибо :)

Missing-male
SaZ
– Qt expert в iCCup

+3

Вы гитом (или какой там у вас cvs) через консоль пользуетесь? Лично я в основном использую atlassian stash. При этом я прекрасно понимаю, как гит устроен изнутри, просто через GUI значительно удобнее. Если нужно что-то экзотическое - то я открываю консоль и делаю.

Missing-male
SaZ
– Qt expert в iCCup

+1

З.Ы. естессно SourceTree. Хотя и stash (который bitbucket server) тоже использую :)

093e089c91f183049994214e7c4ed749?1398265251

+1 за SourceTree

7df30b74d305843fa914ee4b84813649?1497632917

Так это... а я в комменте о чём? О том, что есть два пути: "не знаю как устроено внутри - но есть же GUI, больше ничего не нужно, пока что прокатывает". Это плохой путь. И путь получше: "знаю как устроено изнутри, но пользуюсь GUI (или чем там еще... скриптами, сторонними тулами) - потому что осознанно к этому пришел". Понимаете?

093e089c91f183049994214e7c4ed749?1398265251

Ну наверное лучше прочесть вступительную часть. Перед тем как начать делать GUI пришлось познавать что внутри. После пришлось столкнуться с использованием инструмента в реальности. Далее были опрошены знакомые, кто использует Docker тоже в качестве DEV среды, и которые как оказалось имеют те же самые неудобства, и для частичного решения этих неудобств используют инструменты у которых совершенно другое предназначение (Portainer и Rancher). Далее поиск готового решения. Создание своего решения.

Я это к тому, что если есть желание узнать что внутри, без проблем, узнавайте. Только после познания все равно столкнетесь с тем же с чем и сталкиваются все другие. Вот эти основные проблемы мы и покрыли. Я просто предполагаю, что вы напрямую не сталкивались с проблемами которые мы решаем, оттого объективно оценивать наше решение так же не сможете.

Missing

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

и проблема в том, что как правило тому как все будет запускаться, крутиться и мониториться в продакшене уделяется очень много внимания, а как какой-то там разраб набросает себе среду для разработки вообще плевать. вот и вся суть)

конечно многим придется по вкусу и упростит жизнь.

ну и интересно на чем писали gui?

093e089c91f183049994214e7c4ed749?1398265251

Ну это не серьезно, вы через строчку читали. Писалось же, что нет готового решения для толковой работы разработчикам, не DevOps-ам и не админан. Оттого приходится разработчикам изворачиваться такими монстрами типа Rancher-а, у которого совершенно другое прдназначение. С балалайкой так же бы поспорил, т.к. накидывание образов это 5% от всего функционала который там есть.

Кому плевать? Мне вот к примеру не плевать, кто из нас прав? Мне приходит issue что на node v4.2 падает приложение, а на v6.10 разботает, и что делать? Использовать костыли в виде NVM и каждый раз переключаться? А если используется инструменты у которого нет аналога менеджера версий? А что когда проектов 20, а что когда у этих проектов разный тех. бэкграунд? Очень круто делать из своего компьютера пыхтящий комбайн, либо же инсталить 20 виртуалок. Здесь выручает докер. А потом поуправляйте этими всеми проектами, когда каждый проект имеет 3-4 контейнера. Я бы лично даже и пальцем не пошевелил будь возможность хотя бы покрыть эти вопросы 2-3 составными сторонними приложениями.

Ну так-то вроде как многим пришлось по вкусу. :)

ANT

Missing

вы описали кейс зачем собственно нужен докер, но не описали кейс зачем нужна ваша тулза. без ранчера, кубернетеса и прочих приблуд девопсить проект сложно, а набросать docker-compose для пары контейнеров это пара минут) и в большинстве случаев управляется двумя командами - docker-compose up -d и docker-compose stop. гуй это хорошо, гуй это удобно, но у вас такие планы на интерпрайз...

093e089c91f183049994214e7c4ed749?1398265251

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

Не могу понять почему вы прицепились к созданию проектов. Создание проекта перетягивалкой мыши это одна из функций, причем это кстати не основная функция. Хочешь, сам накидай проект через GUI, хочешь возьми сторонний конфиг, либо попроси чтобы тебе его накидал DevOps. Управляй как проектами, так и по отдельности сервисами и контейнерами, мониторь состояния этих контейнеров, мониторь логи, делай байнд портов, линковку волумсов и прочее, легкая смена версий образов (не нужно куда-то лезть и смотреть какие теги для обраща есть), привязывай hostanme для контейна у которого непостоянный IP, легкий доступ внутрь контейнера по клику. От одного парсера docker run команды в compose формат приходили в дикий восторг и говорили что вообще дажу эту фичу уже можно было бы делать отдельной тулзой. В ближайшее время выйдет серьезный апдейт для более легкой работы со всеми контейнерами в системе (схоже как сейчас это есть в Kitematic), причем с контейнерами не только на локальной машине, но и на удаленной. Ну да, планы на энтерпрайз и вроде как функционал вполне соответствующий чтобы его можно было использовать в качестве софта для разработчика (на энтерпрайзе разработчики точно среду не будут сами делать, но они смогут с легкостью импортировать compose конфиг от девопса в аппу и полноценно работать со всем через GUI).

Missing

Восторг восторгом, но тот же докер имеет проблемы в виде того, что часть функционала его доступна через cli, но не через compose файлы. И наоборот.

093e089c91f183049994214e7c4ed749?1398265251

Т.к. я ни разу не devOps, то если не сложно, поделитесь своим опытом, с чем столкнулись в реальности, что можно реализовать только нативом через docker команду, но нельзя сделать через композ.

Второй момент в том, что я уже который раз повторюсь, ну небыло у нас цели сделать продукт для деплоя, развертывания и прочего devOps-ового, т.к. для этого есть другие инструменты. Того функционала что предоставляет Compose на 10 голов больше чем нужно обычному разработчику для поднятия и управления окружением для разработки.

Missing

Пожалуйста.

Из свежеисправленного - возможность переключать endpoint_mode между dnsrr и vip. До версии 17.05 это можно было сделать только через docker service, но не в compose. Или переключение режимов проброса портов между host-mode и ingress

Из до сих пор неисправленного - назначать алиасы сервисам можно только через compose, но не через cli.

В итоге это выливается в франкенштейна в виде набора как compose так и скриптов с docker service create/update, что доставляет немало боли и не всегда корректно работает

Существует целый epic в саппорте docker по соответствию между cli/compose

https://github.com/moby/moby/issues/25303

093e089c91f183049994214e7c4ed749?1398265251

Из всего вышеперечисленного с чем сталкивался в реальной практике, так это с алиасами. Все остальное так же понятно, как и понятно что это devOps-овская специфика.

Missing

Я понимаю, что цели ваши другие, просто мне, как разработчику и как devops, было бы интересно иметь один инструмент как для работы локально, так и для управления кластером. Это как бы соответствует самой парадигме docker, где один и тот же образ используется как локально так и для production/stage/test/dev

093e089c91f183049994214e7c4ed749?1398265251

Да мы бы с радостью. Только вроде как нужно учитывать, что нас 2 человека в команде, что проект то вообще только стартанул, что мы и так уже пол года бустрапил фуллтайм на свои собственные.

Будет финансирование, будет больше комманда, будет потребность, все обязательно сделаем. Сейчас же у нас приоритет по покрытию базовых потребностей для dev. Когда закончим с ними, с радостью примем в команду опытного devOps-а и будем покрывать его проблемы :)

Missing
+1

Отлично, удачи, буду за вами наблюдать)

093e089c91f183049994214e7c4ed749?1398265251

Спасибо. Если есть желание, то можете зайти в Slack чат, где могли бы побеседовать. Могли бы подсказать чего Вам, как dev + devOps-у, хотелось бы видеть в идеале.

Missing

Есть. Вы на devby.slack.com или у вас свой?

093e089c91f183049994214e7c4ed749?1398265251

Да, присутствую и на devby.slack.com и на dockstation.slack.com

Missing

Этот инструмент исключительно для локальной работы? Я так понял, поддержки swarm и его compose файлов нет?

093e089c91f183049994214e7c4ed749?1398265251

В swarm mode так же работает, но до деплоя конфига.

Missing

Я имею ввиду нативный режим docket swarm. Т.е. версии compose file v3 и выше

093e089c91f183049994214e7c4ed749?1398265251

Что значит нативный? Swarm mode можно как включить, так и отключить. Compose v3 так же работает с отключенным Swarm mode.

Если вы работаете с включенным Swarm mode, то можете полноценно работать с композ конфигом до того времени пока не задеплоите его. С задеплоеным уже работать не получится.

Уже задавали подобный вопрос.

https://twitter.com/igor_lemon/status/859738741212151816

Missing

У докера есть по крайней мере три вида оркестрации - это docker-swarm, требующий внешнего KV хранилища, нативный(он так и называется в документации), использующий собственный KV с версии 1.12 и еще есть немного непонятный swarmkit.

Вопрос именно про нативный, так как он описывает не только сервисы, но и сети и тома. Т е работа как будто запуск docker deploy --compose-file с созданием стека и управлением им как единой сущностью.

Или ваш инструмент просто транслирует compose в соотв. команды docker run?

093e089c91f183049994214e7c4ed749?1398265251

Чтобы не мешать тогда все в кучу и понимать друг друга. Здесь всегда речь шла только за "натив", за отдельный standalone Swarm вообще речи и не было. И выше я говорил за Docker с версии 1.12, в который был встроен Swarm, собственно который включается либо отключается по желанию. Вы у меня спросили или работает в Swarm, я вам ответил, что до момента деплоя конфига, в Docker с включенным Swarm mode он работает. В сл. апдейте кстати будет возможность работы с контейнерами и после деплоя как на локальной так и на удаленной машине.

Нет, мы не ретранслируем compose в docker run команды, мы работаем просто напрямую с docker-compose и с поднятымии через него контейнерами.

Missing

Вот тут хочу уточнить - как это, выключить swarm? Что под этим подразумевается? выполнение docker swarm leave? Когда создается swarm командой swarm init, то после нода становится мастером и по сути кластером. "Выключить" его можно только удалив из кластера. Сделать docker service create на машине без кластера не получится, только docker run. В swarm режиме можно сделать и service и run.

И второй глупый вопрос - что такое "до момента деплоя конфига и после"? Имеется ввиду команды docker service create (до деплоя) и docker service  update (после деплоя) ?

093e089c91f183049994214e7c4ed749?1398265251

Да, про docker swarm leave --force

До docker stack deploy --compose-file docker-compose.yml app и после

Missing

Есть docker classical swarm и есть swarm mode. Не мешайте в кучу.

093e089c91f183049994214e7c4ed749?1398265251

Мне если честно больше интересно зачем разработчику Swarm, т.к. для поднятия кластеров и деплоя есть куда более крутые инструменты :)

Missing
+1

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

Этому здорово помогает виртуальная ифраструктура в виде compose файла, где описаны все нужные для запуска вещи.

093e089c91f183049994214e7c4ed749?1398265251

Да. Без проблем, набрасываете все в compose, и работаете. До 100% покрытия функционала в GUI конечно как до неба, да и вопрос нужно ли это 100% покрытие, но я понимаю что вы опытный пользователь и GUI для набрасывания конфига и его управлением не нужен как таковой. Но для мониторинга состояниями и для управления контейнерами проектов можете использовать.

Missing

Может portainer? (присматриваюсь к нему)

Missing

Я использую portainer, он немного сыроват, но постепенно матереет.

Missing

С первого взгляда подумал что скриншоты от kitematic, ваш дизайн почти не отличить )

093e089c91f183049994214e7c4ed749?1398265251

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

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


Авторизуйтесь, чтобы оставлять комментарии

© 2008-2017 Частное предприятие "Дев Бай"
Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси