Comments 85
по мне, consul-template, как и крон выносятся на хост тачку.
Хотя тут и есть вопросы с swarm и прочим.
1) в этом случае контейнер перестаёт быть самодостаточной сущностью.
2) конфиг консул-темплейта на хосте становится сложным и зависит от состава запущенных контейнеров.
3) нужно монтировать внутрь ещё и конфиги.
т.е. выходит циклическая зависимость хост <-> контейнер, которую хотелось бы избежать.
1) точно так же он перестает ей быть, когда начинается решение неспецифических задач в нем. Например 2 сервиса, или куча шаблонизаторов конфигов.
2) я решил лейблами докер-сервиса
3) с моей точки зрения это гораздо удобнее, чем контролировать сервисы внутри.
Ну а так выходит непредсказуемость поведения контейнера.
2) а можно меня носом в мануал ткнуть, пожалуйста? я поизучаю на досуге.
3) это неудобно только тем, что неправильный шаблон может обнаружиться только после сборки тестинга (имеем поломанный билд). зато это очень удобно, что ты можешь выкинуть контейнер на любую машинку в и он сам себя правильно сконфигурит. Среда корректно определяется тем, какой консул-кластер — test / stage / prod.
1) опять же, ваш выбор. я разницы, где держать конфиги, не вижу. А вот доп сервисы в контейнере вижу.
2) https://docs.docker.com/engine/userguide/labels-custom-metadata/ отталкиваться от сюда. В swarm указываю, при старте конейнеров, условно, запустить 10 штук, на машина с лабелом блабла.
3) Опять же, не вижу тут проблем. Вопрос решается системой управления конфигурации.
Внесу небольшое дополнение по третьему пункту:
Конфигурация внутри контейнера — это совсем не удобно. Ее очень сложно быстро поменять, потому что нужно ждать пересборку контейнера, что бы сделать все правильно.
Но при этом, ему не место в БД с обычными данными.
Прокидывать его через переменные окружения — чудовищная идея, которая ещё и принуждает меня контейнер рестартовать, когда можно дать команду на перечитывание конфига.
Т.е. любое стороннее приложение, разработчиков которого более чем устраивают простые текстовые файлы (иногда длинные).
consul-template пусть и неизящно, но позволяет подрихтовать конфиг на лету (без рестарта контейнера, что важно).
Или приложение уже давным-давно написано и не хочется лезть и менять в его код — мы просто пакуем его в контейнер, подкладываем рядом consul-template и небольшой entrypoint, который позаботится, чтоб всё хорошо стартовало-умирало.
Так мы относительно дёшево получаем неизменный артефакт для деплоя (здесь я мысленно проклял npm и миллиарды зависимостей).
А обучение приложения работать напрямую с consul по api — уже отдельная задача, которую можно спокойно выкинуть в беклог с невысоким приоритетом.
Докер даёт очень хорошую гарантию — в прод едут ровно те бинари и те npm-пакеты. которые проверялись на тестинге.
Плюс при грамотной упаковке элементов в контейнеры становится плевать, на какой физической машинке они бегут и сколько экземпляров одинакового сервиса поднято — и это тоже удобно.
Наши приложения в большинстве своём stateless, поэтому docker или аналоги напрашивались. Опять же на решение влияет хайп, количество готовых костылей и подпорок^W^W^W инструментов, чтоб это работало.
Это можно решать через зипованные образы lxc / openvz, но количество готовых костылей и подпорок для них меньше, чем для докера.
И зачем мне использовать LXC, если у меня уже есть удобный, масштабируемый и единообразный для всех компонентов инструмент запуска приложений в контейнерах и проверенный временем и всем знакомый планировщик задач (cron)?
Но вы решаете что такое «аппликация» и сколько процессов она должна стартануть что быть самодостаточной.
Понимая проблему, можно находить решения, которые удачно вписываются в концепцию Docker, хотя на первый взгляд может показаться, что это не так.
что приведет к невозможности нормального функционирования контейнераА в чём это будет проявлятся?
Т.е. требуется что-то вроде supervisord для рулёжки процессами в контейнере.
Ну и неудобства в виде одного единственного stdout/stderr на весь контейнер, например.
Т.е. нужно лишний раз включать голову и решать вопросы, которых бы и не возникло, не пользуйся мы докером.
docker контейнер и запуск более чем одного приложения в нем, ну это как бы даже не соответствует документации по docker, там написано что в одном контейнере лучше запускать не более одного приложения.
Приложения, сервиса… и не обезательно что это один процесс, хотя проще, да…
И вам решать что есть именно ваше приложение… Для микросервица очень вазжна акакрза его самодостаточность и его как можно меньшая зависимость от внешнего мира в плане конфигурации и прочих предположений о среде…
Честно говоря, я с трудом представляю юзкейсы, где такое надо (про велосипеды молчим). Мне видится более удобным вариантом запускать контейнер системным кроном. Возможно на выделенной тачке.
этакий кластер-менеджмент для бедных.
Мне думается это ошибка в архитектуре. Я не говорю о том, что таких кейсов не может быть. Но все таки контейнеру подразумевают какое-то CI и систему управления конфигурацией.
Это может быть вполне нормальным решением для портирования старой системы масштабирования вместо переезда на kubernetes / nomad / etc.
P.S. у нас джобы по расписанию запускаются контейнеров, только они сделаны велосипедными библиотеками для nodejs.
кстати, надо посомтреть поподробнее, что там предлагается.
Я думаю, что крон — это изменение данных в некой центральной точке. Потому проще держать отдельный инстанс.
Досылка данных в очередь, если мгновенная отправка не прошла по какой-то причине (все сервисы должны уметь в семантику one or more), файлообмен с внешними системами итд.
Каждый адаптер для внешней системы — это отдельный сервис и нелогично отделять его работу по расписанию от него самого.
Он или много не умеет и нужны костыли или, что еще хуже, его пытаются запихнуть туда где он в принципе не нужен, но тупо моден сейчас
Вот либо я не умею готовить, либо руки кривые, либо еще что-то. Но факт остается фактом…
Пару лет назад, наверное, решил таки приспособить Vagrant для PHP разработки. Ведь все же кругом говорят о вагранте. Да и PhpStorm его круто поддерживает. Куча статей, мануалов, скринкастов… А MAMP же — это не круто, не модно и не молодежно. Началось уже не помню с чего, но, как оказалось, с Parallels (параллели использовал для запуска виндовой машины по работе, соответственно, без параллелей никак) Vagrant дружил не очень. Хорошо, давай ставить VirtualBox. Ой, VirtualBox не может жить вместе c Parallels? Пичалька… Ладно, давай разбираться как подружить Vagrant c параллелями. А, ну вот же, подружились! Запускаем!!! Ой, а чего так медленно читаем shared folder? Ведь параллели обещали, что все должно летать. Что, монитровать проект по ssh? Исходники на одной машине, а база на другой? Как-то непривычно. Ведь в MAMP'е же все лежит в одном месте! Э-э-э, ладно, MAMP, дружок, рано я от тебя отказался… Давай поработаем с тобой еще.
Настает время Docker'а. Все вокруг, докер, да докер. MS — Docker, AWS — Docker, все нарядно и молодежно! Да вот уже и готовые есть Dockerfile'ы и docker-compose для моих фреймворков. Как же хорошо-то! Ладно, давай пощупаем, что это за докер такой. А, не виртуалка… ага… понятно… слава тнб, не вагрант снова. Да и приходится на виндовом десктопе работать. А MySQL ставить на винду как-то не красиво… ОК, буду приспосабливать MySQL работать в Docker'е! Ага, понятно, $ docker run mysql. Ура!!! Заработало!!! Ой, а что это скорость у MySQL вапще никакая?! И это так у всех (после непродолжительного гугления)? Хорошо, Docker, я с тобой не прощаюсь. Но давай, всего хорошего тебе, до лучших времен.
В сухом остатке… ИМХО декларируемые фичи — это, безусловно, все очень круто и здорово. Но каждый раз натыкаешься на маленькие "но", которые практические перечеркивают все эти радости. И по сравнению с затраченным уже временем на ощупывание этих технологий быстрая сборка виртуалки в вагранте или мгновенный запуск контейнера докер уже не так греют душу.
Стоит заметить, что это лишь средство для конфигурации виртуальных машин, и ничего особо сложного он делает. Другое дело, что поддерживает не все возможности всех платформ, но про это можно было прочитать.
Про Docker:
На Windows в официальных релизах docker создает виртуальную машину с минимальным линуском и запускает все в ней. То есть к обычном докеру еще все проблемы вашей виртуалки приехали. Судя по предыдущему опыту, они от нее.
Ну не нужен он вам, не используйте.
Вот тут может о том почему это не замена виртуалке и не об этом вообще
http://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-normal-virtual-machine/25938347#25938347
В rkt пытаются сделать то же самое правильно, вроде неплохо получается.
А вот от рынка виртуализации можно ожидать появления легковесных виртуальных машин, в Microsoft это уже сделали, начиная с Windows 2012 имеется такая фича. Что в конечном итоге и убьет хипсторские контейнеры.
Тем не менее контейнеры почему-то полетели.
Меня в докере подкупила идея разделения понятия образа и контейнера, а также иммутабельных слоёв ФС — это по-своему правильно и хорошо.
Стало на порядок проще воспроизводить тот бардак зависимостей (npm-пакетов), с которыми у меня сейчас сервис в проде работает — взял ворох докер-образов таких же, как на проде — и ковыряешь.
И докер не опоздал лет на 10, а пришёлся как раз вовремя — много компаний доросли до кластеров и начали задумываться над вопросом, а что делать, если нужно будет валить с одного облачного провайдера в другой.
Сам концепт то очень хорош, но уж больно костыльная реализация, что тоже выше уже заметили :)
Костыли начинаются, когда приходится поднимать сервисы, которым гораздо лучше без docker. Например, когда у сервиса есть любое внутреннее состояние, когда перезапуск != удалить контейнер и создать новый.
Стало на порядок проще воспроизводить тот бардак зависимостей (npm-пакетов)
Поэтому и взлетел, с Rails такая же ерунда.
можно ожидать появления легковесных виртуальных машин, в Microsoft это уже сделали, начиная с Windows 2012
В 2012 ускорили загрузку обычных ВМ, а в 2016 сделают поддержку docker. VMware умеет форкать ВМ и это тоже используется для docker в vSphere Integrated Containers (хз кто ими пользуется, но всё же).
А Instant Clones ещё используются для VDI, но это совсем другая тема.
Нет никакой особой разницы как именно генерируется этот «специальный сигнал по времени» внутри контейнера. Можно прикрутить нечто прямо в процесс сервиса если есть такое религиозное неприятие к второму процессу, но оно ничем не лучшее обычного крона.
У вас небольшая проблема в примере:
Если данные нужно скачивать на жесткий диск хостовой системы, то переносимость давно убита. А если оно просто прокидывается куда-то дальше, то разницы, откуда вызывать скрипт нет, то это можно делать и из хостовой машины.
Если брать более сложный случай, и нам нужна система, которая бы по расписанию запускала различные таски, написанные, скажем, на Python, то для таких задач есть более умные и простые системы, типа Celery или, скажем, nats.io.
Cron используют для простых задач, которые не требуют мониторинга, отслеживания и прочего. И тут не совсем понятно, какой будет профит от того, что бы обернем его в docker контейнер.
Есть много случаев, когда задачи по расписанию чего-то в контейнере – это его внутреннее дело. Например, есть микросервис, который раз в день берет немного данных из внешнего мира, парсит их и вносит новые в некий store, специально для этого сервиса существующий. А все остальное время этот сервис отдает данные по запросам. Мониторинг к этому всему слабо относится — т.е. он никак не мешает мониторить как процесс так и конечное состояние.
docker run --name cron --detach project_image start-cron
В этом случае cron заданиям будут доступна вся файловая система образа проекта.
docker run --detach --name project_container project_image
docker run --detach --name cron_container project_image start-cron
docker run --detach --volume /var/project/data:/data --name project_container project_image
docker run --detach --volume /var/project/data:/data --name cron_container project_image start-cron
--link позволяет объединять контейнеры в общую сеть, позволяя им обращаться друг к другу по имени.
Хм… а передача сразу в команду docker run
параметра --env-file=[] не может помочь в таком случае?
Запуск cron внутри Docker-контейнера