вы упоминаете что скрипты используют unix way (обработка сигналов, коды возврата), неужели этого оказалось мало и понадобился отдельный unified API? Если вы избавитесь от него, то система станет намного проще и гибче, без необходимости взваливать на себя груз поддержки 72+ существующих языков программирования (72 взял с потолка).
на самом деле как раз наоборот, черезчур много. Ведь все это надо будет поддерживать — а это большая ответственность. У Ansible и без того уже давно наблюдаются проблемы с поддержкой плагинов. А кто будет поддерживать эти reusable automation scripts? Стоит ли разводить всю эту мешанину из различных способов, если потом нельзя будет точно сказать что будет работать, что уже deprecated, а что вообще уже не работает.
Если пишем на чем хотим, то откуда взялись ограничения (Perl, Ruby, Bash)? Если бы было бы просто, то наверно таких ограничений не было бы, согласитесь?
Использовать YAML для разработки сценариев — это боль. Не учили видать разработчики Ansible историю, и продолжают настойчиво продвигать свою идею.
Sparrow — противоположная крайность, т.е. запутанная и очень сложная, в основе которой все та же идея — не дать разработчику сценария свернуть не туда (или они думают, что такое решение действительно упрощает решение задачи деплоя?), а это в итоге приводит к порождению множества костылей всех форм и размеров.
Deploy системы об этом никак не заботятся, об этом, как вы верно заметили, заботится Kubernetes, или, как в данном случае, это должен делать сам Docker. То есть, оркестрация не входит в задачи инструментов для деплоя.
Вот с emacs как раз не всё так просто. Люди врастают в него корнями.
вот этого я хотел бы избежать на самом деле. Например, мне нравится IDEA для macOS тем, что там есть готовая раскладка, которая во многом повторяет горячие клавиши самой ОС — очень удобно.
Только решили, или уже посмотрели? Как результат?
Если коротко, то — «вырви глаз» :) Уж очень я привык к намного более приятному дизайну IDEA, плавной прокрутке и оптимизации под Retina дисплеи.
Соглашусь с вами в том, что у продуктов Jetbrains есть большие проблемы со стабильностью. Сам постоянно сталкиваюсь с багами в новых версиях даже в старом функционале. И уже успел завести привычку всегда делать резервную копию перед апгрейдом IDE. Кто не замечает проблем с новыми версиями Jetbrains, тот просто не использует IDE на полную мощь. Советующих использовать VIM/Emacs/Sublime text я вообще не понимаю.
Версия 2016.3 меня настолько сильно разочаровала, что я снова решил поглядеть на Eclipse/Liclipse, на которые не глядел уже лет 5.
Очень хочу попробовать Python Tools for Visual Studio, но пока не решаюсь перейти на Windows. Жду когда их можно будет запустить на macOS/Linux.
В вопросе масштабирования довольно рискованно доверять автоматическим системам. Решение о введении в строй новых инстансов все равно должно приниматься человеком.
И все-таки я считаю, что Docker обеспечивает «все те же возможности», может не «один в один», но основное уже точно реализовано. А может я просто фанат Docker )
Pod — еще один уровень абстракции в дополнение к уже существующим (образ, контейнер, сервис). Но на самом деле его обязанности чрезвычайно размыты (pod — для него даже названия нормального не нашлось). Возможно необходимость в нем и была на каком-то этапе развития технологии Docker, но сейчас она (эта абстракция) стала совершенно ненужной и только вводит людей в заблуждение.
Можно создать сервис с опцией --mode global, в этом случае Docker будет создавать по одному контейнеру на всех доступных нодах. В этом режиме количество реплик равно количеству нод. Возможно, что в этом случае внутренней балансировки не происходит, и ее полностью можно делегировать внешнему балансировщику.
В сварм моде не сделаешь --network=container:<name|id> — reuse another container's network stack.
В контексте сервисов это было бы странной фичей. В сервисе же мы не можем сказать точно где какой контейнер в данный момент работает. Нет, можем конечно, если обратимся к менеджеру с соответствующим запросом. Но ведь контейнер в любой момент может «переехать» на другой хост, и как в таком случае должен будет повести себя… кстати, вы хотите сервис к имеющемуся контейнеру подключить?
--IPC — был кейс года был нужен IPC неймспейс поделить хостовой с контейнером.
Опять же, хостов в кластере много, с каким именно хостом делить IPC namespace?
--network сервису Docker задать можно. При помощи этой опции и задается отдельный namespace для контейнеров сервиса. IPC — видимо пока нет. Не использовал последнюю опцию. Можете рассказать какие преимущества дает это в работе с контейнерами? Когда это целесообразно применять?
Ваш случай ( я про баг) довольно нетипичен для стандартных сценариев использования контейнеров. Конечно, это не повод не иметь возможности гибкого управления healthcheck, но думаю тут вопрос в приоритетизации задач.
Плюс, странно, что вы зная, что это вызовет проблемы, все же применили такое решение. Мне кажется, что в таких случаях стоит подумать о том, чтобы решать задачи длительных вычислений не в процессе инициализации контейнера, а, например, производить эти вычисления заранее, до старта контейнера. Либо делать это асинхронно, давая возможность healthcheck скрипту отдать вменяемый ответ на соответствующий запрос.
Насчёт volumes — вполне логично, что для распределённых систем реализация данной концепции не является простой штукой. И мое мнение в том, что надо избегать использования volumes для сервисов. Сервисы предназначены для stateless систем. А если состояние все-же нужно шарить между контейнерами сервиса, то для этого лучше использовать БД, которую запускать не как сервис, а как несколько обычных контейнеров на разных хостах.
Насколько я понял, на каждой ноде хранится какое-то количество «бэкапов», и при достижении их количества определенного значения они начинают ротироваться. Во всяком случае я не видел ситуации, когда на одной ноде их было бы больше 4-х для одного сервиса.
попробуйте в swarm mode сделать аналог куберовского пода
Исходя из этого описания пода, я так понимаю, что это не более чем логическая группа контейнеров со своими «namespaces and shared volumes». Так чего же из этого нет сейчас в Docker?
Не понимаю откуда столько негатива. Автор статьи, на которую вы дали ссылку, всего лишь попытался популярным языком описать современные тенденции, и мне кажется ему это удалось, хотя и было несколько противоречивых моментов. Но прошу заметить, что он ни словом при этом не обмолвился о рекламе какого-то коммерческого решения.
Вы же говорите о каком-то непонятном продукте и даже не намекаете о том, что это такое и почему только из-за его существования все остальные компании являются лузерами аутсайдерами.
на самом деле как раз наоборот, черезчур много. Ведь все это надо будет поддерживать — а это большая ответственность. У Ansible и без того уже давно наблюдаются проблемы с поддержкой плагинов. А кто будет поддерживать эти reusable automation scripts? Стоит ли разводить всю эту мешанину из различных способов, если потом нельзя будет точно сказать что будет работать, что уже deprecated, а что вообще уже не работает.
Полная свобода написания каких угодно костылей — вот как я это понимаю. Польза от такого подхода весьма сомнительна.
Если пишем на чем хотим, то откуда взялись ограничения (Perl, Ruby, Bash)? Если бы было бы просто, то наверно таких ограничений не было бы, согласитесь?
Sparrow — противоположная крайность, т.е. запутанная и очень сложная, в основе которой все та же идея — не дать разработчику сценария свернуть не туда (или они думают, что такое решение действительно упрощает решение задачи деплоя?), а это в итоге приводит к порождению множества костылей всех форм и размеров.
На самом деле ещё во втором питоне можно было получать третий словарь путём слияния двух других:
вот этого я хотел бы избежать на самом деле. Например, мне нравится IDEA для macOS тем, что там есть готовая раскладка, которая во многом повторяет горячие клавиши самой ОС — очень удобно.
Если коротко, то — «вырви глаз» :) Уж очень я привык к намного более приятному дизайну IDEA, плавной прокрутке и оптимизации под Retina дисплеи.
Версия 2016.3 меня настолько сильно разочаровала, что я снова решил поглядеть на Eclipse/Liclipse, на которые не глядел уже лет 5.
Очень хочу попробовать Python Tools for Visual Studio, но пока не решаюсь перейти на Windows. Жду когда их можно будет запустить на macOS/Linux.
В вопросе масштабирования довольно рискованно доверять автоматическим системам. Решение о введении в строй новых инстансов все равно должно приниматься человеком.
В контексте сервисов это было бы странной фичей. В сервисе же мы не можем сказать точно где какой контейнер в данный момент работает. Нет, можем конечно, если обратимся к менеджеру с соответствующим запросом. Но ведь контейнер в любой момент может «переехать» на другой хост, и как в таком случае должен будет повести себя… кстати, вы хотите сервис к имеющемуся контейнеру подключить?
Опять же, хостов в кластере много, с каким именно хостом делить IPC namespace?
Плюс, странно, что вы зная, что это вызовет проблемы, все же применили такое решение. Мне кажется, что в таких случаях стоит подумать о том, чтобы решать задачи длительных вычислений не в процессе инициализации контейнера, а, например, производить эти вычисления заранее, до старта контейнера. Либо делать это асинхронно, давая возможность healthcheck скрипту отдать вменяемый ответ на соответствующий запрос.
Насчёт volumes — вполне логично, что для распределённых систем реализация данной концепции не является простой штукой. И мое мнение в том, что надо избегать использования volumes для сервисов. Сервисы предназначены для stateless систем. А если состояние все-же нужно шарить между контейнерами сервиса, то для этого лучше использовать БД, которую запускать не как сервис, а как несколько обычных контейнеров на разных хостах.
Исходя из этого описания пода, я так понимаю, что это
не более чем логическаягруппа контейнеров со своими «namespaces and shared volumes». Так чего же из этого нет сейчас в Docker?Вы же говорите о каком-то непонятном продукте и даже не намекаете о том, что это такое и почему только из-за его существования все остальные компании являются
лузерамиаутсайдерами.