[Из песочницы] Когда docker-compose не хватает
Комментарии (7)
7 июня 2017 в 23:33
+4↑
↓
Какая-же боль — такое читать. Вроде давно уже космические киты бороздят просторы амазона, а тут — какие-то обвязочные шелл-скрипты, как в старо-древние времена.
Kubernetes, nomad, ansible, в конце-концов.
А вы, как у меня сложилось впечатление по прочтению — «принятыми соглашениями» превращаете самые простые стейтлесс контейнеры в какой-то ад.
8 июня 2017 в 11:22
0↑
↓
Docker (+swarm mode), docker-compose и bash-скрипты вполне позволяют решать задачи по разворачиванию систем в различных окружениях без умножения сущностей, без усложнения поддержки со стороны эксплуатации, слабо представляющей, что такое докер вообще. От них требуем только установить докер на новых нодах, подключить к кластеру, попрописать DNS, настроить мониторинг и бэкапы. Остальное делают разработчики: пишут докерфайлы, ямлы для композа и сварм-стэка (почти не отличающиеся). Зачем вводить новые сущности с высоким порогом входа типа кубернейтса, если вся обвязка системы из пары десятков помещается меньше чем в 1000 строк ямла и 100 строк баша для ВСНХ мыслимых окружений?
8 июня 2017 в 08:09
0↑
↓
Хм… А можно ли посмотреть как вы ваш бинарничек собирали? Не очень хочется качать что-то исполняемое неизвестно как собранное. И заодно посмотрите вот на такой проект — https://github.com/dmitrykuzmenkov/yoda. Идеи похожи, но реализован и оформлен он получше.8 июня 2017 в 08:11
0↑
↓
Собирается PyInstaller’ом. В корне есть файлик make.py — он все и делает. За ссылку спасибо, глянем.8 июня 2017 в 09:55
0↑
↓
Я немного обманул. Сейчас заметил, что файл для сборки не попал в репу. Добавил, так что при необходимости можете подсмотреть.
SirEdvin
8 июня 2017 в 10:38
0↑
↓
Для параллельной работы над несколькими проектами требуется установка всех сервисов необходимых каждому из них. В первую очередь мы создали репозиторий, в котором располагался файл конфигурации для docker-compose, а также конфигурации требуемых для работы образов. Все довольно быстро заработало и на какое-то время это нас устроило. Как оказалось, в дальнейшем данный подход решал нашу проблему частично. По мере добавления проектов в новую экосистему этот репозиторий наполнялся файлами конфигураций и различными вспомогательными скриптами. Это привело к тому что при работе над одним единственным проектом разработчику приходилось либо тащить зависимости всех проектов, либо же править docker-compose.yml, отключая лишние сервисы. В первом случае приходилось ставить лишние контейнеры, что нам казалось не лучшим решением, а во втором нужно было знать какие контейнеры требуются для работы приложения. Хотелось иметь более гибкое решение, которое позволит устанавливать только необходимые компоненты, а также, если не исключит, то минимизирует ручную работу. И вот к чему мы пришли…
Не совсем понятно, как у вас так получилось. Один проект — один docker-compose файл, разве нет? Или у вас там космическое число микросервисов?
8 июня 2017 в 10:54
0↑
↓
Не космическое конечно, но хватает. Даже при малом количестве неудобно было бы, переключаясь между проектами, тушить одно окружение и поднимать другое. Сейчас это выглядит также, как если бы мы запускали docker-compose up с несколькими конфигурационными файлами. Т.к. сервисы в различных проектах во многом пересекаются, пришлось бы дублировать их в каждом docker-compose файле. Сейчас общая часть вынесена в пакет, а нюансы указываются в конфиге проекта.
