Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
в mesos и mesosphere это довольно легко решается:
1) порты мапятся случайным образом
2) раз в минуту (отдельный тупой скрипт, который узнает где что лежит) пересобирается конфиг для haproxy
3) снаружи можно всегда обратиться по конкретному адресу и порту к сервисам
1) порты мапятся случайным образом
2) раз в минуту (отдельный тупой скрипт, который узнает где что лежит) пересобирается конфиг для haproxy
3) снаружи можно всегда обратиться по конкретному адресу и порту к сервисам
А как в mesosphere решается вопрос локального хранилища, с учетом того, что сервис может быть потенциально запущен где угодно?
в целом — можно для mesos slave проставить теги, например, на конкретной машине будет только база запускаться. в этом случае диск будет один и тот же. ну и к докеру монтироваться будет конкретная папка.
а вообще, запускать базу в докере это очень странная идея. только если для тестов или побаловаться
а вообще, запускать базу в докере это очень странная идея. только если для тестов или побаловаться
почему странная? я нахожу идею запуска всего в докере очень даже хорошей. Я бы CoreOS использовал, если бы не специфика с ядром и сетью.
шаринг ресурсов как минимум. а так, база это место куда и пишут и читают, так что если она упадет (а месос это подразумевает), то всем будет фигово. обычно в месос и в докерах запускают приложения, в нескольких инстансах. тогда если упадет один контейнер, месос узнает об этом и можно разделить трафик на остальные контейнеры,
в это же время месос развернет в другом месте новый контейнер заместо упавшего.
p.s. я тут не рассматриваю вариант master-master, это отдельный разговор
в это же время месос развернет в другом месте новый контейнер заместо упавшего.
p.s. я тут не рассматриваю вариант master-master, это отдельный разговор
Я тут себе когда думал тот же постгрес в докер запихать, потом посмотрел на выделенную для докера /8 и подумал что ну его нафиг, пересобирать с новым конфигом каждый раз. Опять же, бекапы. (не, ну конфиг для слейва можно и подбросить, но статические IP для докер контейнеров я не осилил)
А вот запихать все сайты в шаредхостинге в разных инстансах одного контейнера с подключенными /var/www/$site, указав им в качестве MySQL — конкретный айпишник молотилки SQL — очень даже неплохая идея.
Вот сейчас я эту идею активно думаю применить на шаредхостинге — один контейнер на всех, много инстансов под каждый сайт с подмонтированными /var/www и логами, и хост система чистая, ну и уязвимостей меньше.
а снаружи nginx и при старте докер контейнеров обновляется a запись $site.docker.loc.
опять же, работа в режиме кластера, но это отдельная интересная тема.
А вот запихать все сайты в шаредхостинге в разных инстансах одного контейнера с подключенными /var/www/$site, указав им в качестве MySQL — конкретный айпишник молотилки SQL — очень даже неплохая идея.
Вот сейчас я эту идею активно думаю применить на шаредхостинге — один контейнер на всех, много инстансов под каждый сайт с подмонтированными /var/www и логами, и хост система чистая, ну и уязвимостей меньше.
а снаружи nginx и при старте докер контейнеров обновляется a запись $site.docker.loc.
опять же, работа в режиме кластера, но это отдельная интересная тема.
пересобирать с новым конфигом каждый разразные механизмы discovery (в том числе, DNS) это же решают как раз?
возможно, но проще узнать у самого месоса какой адрес у контейнера
ну или так. Я к тому что — в чем проблема запихать постгрес в докер?
то есть вы хотите сказать, что в вашем случае, иметь 2 разных контейнера с базой, в которые пишут сначала в одну, потом в другу — это нормально? я не могу представить кейс, когда запуск второго контейнера не даст простоя всего остального
А что не так с ядром и сетью? В CoreOS можно своё кустомное ядро собирать, или это как раз и напрягает?
А есть что почитать? Я так поверхностно понял, что корось может внезапно обновиться и все, что было не в докере, идет лесом.
Обновляется только read-only партиция. Конфиги и прочие /opt не трагаются.
Почитать можно здесь: coreos.com/docs/sdk-distributors/sdk/modifying-coreos/
Почитать можно здесь: coreos.com/docs/sdk-distributors/sdk/modifying-coreos/
В kubernetes на каждой машине висит специальный прокси-сервер (по функциям аналог haproxy), который сам отслеживает изменения конфигурации через etcd и моментально меняет адреса бэкендов, если они поменялись.
Установить нужный софт не всегда просто. У одного разработчика стоит gentoo, у другого нестабильная ubuntu, в продакшне стабильный debian. Потом оказывается, что у одного версия библиотеки слишком старая, у другого поменялись пути, у дебиане вообще в дистрибутиве её нет. В случае контейнеров все работают в идентичном окружении.
Когда используете чужие репозитории, привязывайтесь к конкретной версии. Периодически, когда вы явно этого захотите, можете передвигать версию на более свежую, тестировать всё, и если ок, то коммитить изменения Dockerfile.
Когда используете чужие репозитории, привязывайтесь к конкретной версии. Периодически, когда вы явно этого захотите, можете передвигать версию на более свежую, тестировать всё, и если ок, то коммитить изменения Dockerfile.
vagrant везде одинаковый. Всем ставим одинаковый начальный образ и инструкцию.
И все довольны.
Зачем поверх vagrant ставить docker?
Если я вас правильно понял, то вопрос заключается в том мол зачем мне docker, если у меня виртуалка есть созданная vagrant, правильно?
В такой постановке вопроса действительно докер скорее всего лишний. Нужно либо одно, либо другое.
Докер это другой тип виртуализации — контейнерной, у нее образы занимаю сильно меньше места на диске, в памяти, быстрее стартуют и т.п., если вам это не интересно, то докер вам не нужен конечно.
Виртуальные машины — это не только очень удобно, но ещё и большие накладные расходы по ресурсам, такие как предвыделенная ОЗУ, например, или заметно медленнее выполнение программы. Docker по производительности близок к железу (в разных тестах потеря варьируется в переделах 0.5-3% производительности). Docker поверх vagrant имеет смысл ставить только для систем, где докер не поддерживается (Windows, Mac OS, старый Linux (спорно, там может и vagrant не взлететь тогда)).
Вы что-то неправильно прочитали или я ночью плохо что-то написал. Я считаю Docker прекрасным решением! Только, к сожалению, почему-то большинство не понимает как им правильно пользоваться… Я вот сел и недельку вдумчиво изучил ситуацию, зато теперь я представляю что где и как, только теперь я не могу со спокойной душой взять первый попавшийся образ из Docker Hub, так как 99% там хлам, к сожалению.
И для разработки и для продакшена подходит отлично. Только сначала научиться нужно пользоваться.
Если ваш юзкейс — деплой на Linux и/или другая ОС, то Docker вам подходит или частично подходит.
Рассмотрим случай деплоя только на Linux. Все разработчики хотят они или не хотят, но должны запускать код тоже на Linux, при этом версии либ/пакетов должны совпадать с продакшеном.
Ваш вариант с виртуалками:
+ привычно/удобно
+ абсолютно точно работает одинаково (медленно) и на Linux хостах и на Windows/Mac OS
- весит образ 3-4ГБ(?)
- обновление образа — ждём пока весь образ скачается (3-4ГБ) или мучаемся с Puppet/Chef/Ansible/CFEngine (только не говорите, что это ж просто, например, для докера этого делать не нужно (хотя некоторые особо извращённые товарищи зачем-то продолжают это делать))
- отъедает какую-то часть ОЗУ прямо на старте (браузер + виртуалка + IDE — для некоторых это может стать «выберите два»)
Вариант с докером:
+ абсолютно точно работает одинаково (быстро) на любом дистре Linux
+ образ весит (возьмём худший случай с ubuntu образом, хотя я и не люблю его) 200МБ + зависимости приложения + приложение <500МБ
+ обновление образа — луковичная ФС качает только обновившиеся уровни
+ ОЗУ потреляет только ваше приложение (на Linux)
То есть ваши разработчики должны сам озаботиться любым дистром Linux в виртуалке, в котором будет стоять Docker, например для этого сделали минимальный образ boot2docker. А дальше уже метод разворачивания образа Docker одинаковый и для продакшена, и для разработчиков, у которых уже стоит Linux!
С периодическими проблемами Docker Hub нужно бороться приватным Docker Hub — поднимаете на своих серверах и пользуетесь на здоровье. Альтернативно можно вообще в tar-архивы образы заталкивать на CI и так и распространять.
Если ваш юзкейс — деплой на Linux и/или другая ОС, то Docker вам подходит или частично подходит.
Рассмотрим случай деплоя только на Linux. Все разработчики хотят они или не хотят, но должны запускать код тоже на Linux, при этом версии либ/пакетов должны совпадать с продакшеном.
Ваш вариант с виртуалками:
+ привычно/удобно
+ абсолютно точно работает одинаково (медленно) и на Linux хостах и на Windows/Mac OS
- весит образ 3-4ГБ(?)
- обновление образа — ждём пока весь образ скачается (3-4ГБ) или мучаемся с Puppet/Chef/Ansible/CFEngine (только не говорите, что это ж просто, например, для докера этого делать не нужно (хотя некоторые особо извращённые товарищи зачем-то продолжают это делать))
- отъедает какую-то часть ОЗУ прямо на старте (браузер + виртуалка + IDE — для некоторых это может стать «выберите два»)
Вариант с докером:
+ абсолютно точно работает одинаково (быстро) на любом дистре Linux
+ образ весит (возьмём худший случай с ubuntu образом, хотя я и не люблю его) 200МБ + зависимости приложения + приложение <500МБ
+ обновление образа — луковичная ФС качает только обновившиеся уровни
+ ОЗУ потреляет только ваше приложение (на Linux)
То есть ваши разработчики должны сам озаботиться любым дистром Linux в виртуалке, в котором будет стоять Docker, например для этого сделали минимальный образ boot2docker. А дальше уже метод разворачивания образа Docker одинаковый и для продакшена, и для разработчиков, у которых уже стоит Linux!
С периодическими проблемами Docker Hub нужно бороться приватным Docker Hub — поднимаете на своих серверах и пользуетесь на здоровье. Альтернативно можно вообще в tar-архивы образы заталкивать на CI и так и распространять.
Не хотите — не используйте. Если у вас ничего на Linux нет — вам Docker не нужен совсем, забудьте, Linux — слишком сложен. Если вы не готовы менять привычки — вам тоже Docker не нужен.
P.S. Просто оставлю это здесь: Kitematic a Docker GUI Joins the Docker Family.
P.S. Просто оставлю это здесь: Kitematic a Docker GUI Joins the Docker Family.
Больше всего мне нравится, что изначально Линуксовая технология докер, но в GUI нет ни слова о LInux или о хотябы упоминания в Roadmap
Это как спорить о apt-get/yum/emerge/pacman VS virtualenv/RMV/bundler. Вы и в продакшен vagrant выкатываете? Или у вас два набора скриптов для деплоя на vagrant и на продакшен?
То есть ради того чтобы приложению положить разные настройки вы пишите два разных скрипта по разворачиванию вашего проекта. Удобно, ничего не скажешь. «разные пакеты» — а потом у вас всё валится с криком «у меня же работает!»
В общем, я не гуру и вам виднее как поступать со своими проектами. Желаю вам всяческих успехов. Откланиваюсь.
В общем, я не гуру и вам виднее как поступать со своими проектами. Желаю вам всяческих успехов. Откланиваюсь.
3-4 гига?
Сударь вы либо целенаправленно лжете, либо наивно заблуждаетесь.
Размер образа тот же что у docker.
И что за настройка? Если вам дают уже настроенный образ, или для докера вам дают готовый докер файл или готовый шаблон, а для kvm, xen, virtual box, VMware вам дают только полуфабрикат?
Память, ну да, наверно. 50-100 мегабайт на виртуальную машину это финиш…
А в lxc у вас все контейнеры сделаны грамотно, стартует только один нужный процесс, ну ну. Верю.
Сударь вы либо целенаправленно лжете, либо наивно заблуждаетесь.
Размер образа тот же что у docker.
И что за настройка? Если вам дают уже настроенный образ, или для докера вам дают готовый докер файл или готовый шаблон, а для kvm, xen, virtual box, VMware вам дают только полуфабрикат?
Память, ну да, наверно. 50-100 мегабайт на виртуальную машину это финиш…
А в lxc у вас все контейнеры сделаны грамотно, стартует только один нужный процесс, ну ну. Верю.
Сударь вы либо целенаправленно лжете, либо наивно заблуждаетесь.
Размер образа тот же что у docker.
В докере как минимум оптимизация в том, что дублирующиеся данные не хранятся, т.е. если есть десяток образов на основе убунты, сама убунта будет храниться 1 раз. Ну и плюс, для докера обычно используются минимизированные образы ОС, для чаще виртуалок беруться стандартные.
Память, ну да, наверно. 50-100 мегабайт на виртуальную машину это финиш…
А в lxc у вас все контейнеры сделаны грамотно, стартует только один нужный процесс, ну ну. Верю.
Не знаю как насчет lxc, а в докере за счет того, что каждый старт процесса нужно описывать отдельно — ничего лишнего не стартует
Чаще != всегда
А что докер без lxc уже работать может?
Докер это всего лишь утилита над lxc namespace + diff ы файловой системы
Контейнеры вещь давно известная, и lxc из них не самая опробированная технологи.
Namespace — как бы и без докера сами по себе живут
«Луковичная файловая система» — тоже без докера имею место быть.
Так что же докер такое?
А что докер без lxc уже работать может?
Докер это всего лишь утилита над lxc namespace + diff ы файловой системы
Контейнеры вещь давно известная, и lxc из них не самая опробированная технологи.
Namespace — как бы и без докера сами по себе живут
«Луковичная файловая система» — тоже без докера имею место быть.
Так что же докер такое?
А что докер без lxc уже работать может?
Да может
Контейнеры вещь давно известная, и lxc из них не самая опробированная технологи.
Namespace — как бы и без докера сами по себе живут
«Луковичная файловая система» — тоже без докера имею место быть.
Так что же докер такое?
Что-то вы удалились от обсуждения плюсов/минусов докера.
Да они ничего революционного сами не изобрели, а удачно скомпилировали и распиарили, плюс сделали docker.hub с очень большой базой готовых образов, уменьшили порог входа для использования контейнерной виртуализации.
Хм, парни запилили свою прослойку на go.
Молодцы.
«Second, we are introducing a new built-in execution driver which is shipping alongside the LXC driver. This driver is based on libcontainer, a pure Go library which we developed to access the kernel’s container APIs directly, without any other dependencies.»
А теперь по теме.
С тем что ничего нового и революционного мы определились. Ок.
Плюсы мне понятны, минусы тоже, но вы как инженер, будьте любезны сами их озвучивать, а не рисовать картинки втаптывая в грязь технологии и разработки на которых докер основан.
Вот и вся мысль
Ну и резюмирую:
Докер это набор утилит по взаимодействию с api ядра linux написанный на go + api
Никаких новых технологий он не несет, но упрощает использование контейнерной виртуализацией для не специалистов, плюс имеет хорошую маркетинговую поддержку.
Молодцы.
«Second, we are introducing a new built-in execution driver which is shipping alongside the LXC driver. This driver is based on libcontainer, a pure Go library which we developed to access the kernel’s container APIs directly, without any other dependencies.»
А теперь по теме.
С тем что ничего нового и революционного мы определились. Ок.
Плюсы мне понятны, минусы тоже, но вы как инженер, будьте любезны сами их озвучивать, а не рисовать картинки втаптывая в грязь технологии и разработки на которых докер основан.
Вот и вся мысль
Ну и резюмирую:
Докер это набор утилит по взаимодействию с api ядра linux написанный на go + api
Никаких новых технологий он не несет, но упрощает использование контейнерной виртуализацией для не специалистов, плюс имеет хорошую маркетинговую поддержку.
при разработке это не реализуемо, ведь у всех разные ОС.
Так в том то и дело, что докер изолирует вас от ОС, хоть вы в убунте сидите, хоть в арче — докер всегда работает одинаково.
Уважаемый автор, помоему у Вас просто руки чесались костылей понаписать, вот Вы их и понаписали… Прочитайте про Docker Machine, Docker Swarm, и Docker Compose (да, тот самый fig). Можно начать отсюда.
А вы сами читали статью, на которую ссылаетесь?
Docker Machine к теме поста вообще отношения не имеет. Зачем вы предлагаете автору почитать про Compose, если он явно написал, что пользовалься fig'ом и ему он не понравился? Как Swarm решит проблему dns, анонсирования сервисов и балансировки?
Docker Machine к теме поста вообще отношения не имеет. Зачем вы предлагаете автору почитать про Compose, если он явно написал, что пользовалься fig'ом и ему он не понравился? Как Swarm решит проблему dns, анонсирования сервисов и балансировки?
Читал, поэтому и дал ссылку.
> Docker Machine к теме поста вообще отношения не имеет.
Автор использует ansible вместо Docker Machine.
> Зачем вы предлагаете автору почитать про Compose, если он явно написал, что пользовалься fig'ом и ему он не понравился?
Конечно, не понравился, когда проще на коленке писать полотна bash'a
> Как Swarm решит проблему dns, анонсирования сервисов и балансировки?
DNS решается Docker Compose, который по links прописывает нужные обновления в контейнеры в /etc/hosts. Анонсировать ничего не надо. Масштабирование — Docker Swarm + Docker Compose scale. Балансировкой заниматься должен балансер (Nginx/HAProxy/...), вот как можно это настроить — www.centurylinklabs.com/auto-loadbalancing-with-fig-haproxy-and-serf/
Ещё вопросы?
> Docker Machine к теме поста вообще отношения не имеет.
Автор использует ansible вместо Docker Machine.
> Зачем вы предлагаете автору почитать про Compose, если он явно написал, что пользовалься fig'ом и ему он не понравился?
Конечно, не понравился, когда проще на коленке писать полотна bash'a
> Как Swarm решит проблему dns, анонсирования сервисов и балансировки?
DNS решается Docker Compose, который по links прописывает нужные обновления в контейнеры в /etc/hosts. Анонсировать ничего не надо. Масштабирование — Docker Swarm + Docker Compose scale. Балансировкой заниматься должен балансер (Nginx/HAProxy/...), вот как можно это настроить — www.centurylinklabs.com/auto-loadbalancing-with-fig-haproxy-and-serf/
Ещё вопросы?
Автор использует ansible вместо Docker Machine.
То для чего у автора используется ansible вообще не имеет к тому для чего предначначен Docker Machine никакого отношения. Docker Machine предназначен для создания и управления виртуалками (локальными или в облаке) с установленным docker'ом.
> Зачем вы предлагаете автору почитать про Compose, если он явно написал, что пользовалься fig'ом и ему он не понравился?
Конечно, не понравился, когда проще на коленке писать полотна bash'a
По вопросу кастомных наколеночных решений я с вами согласен. Но справедливости ради надо сказать, что swarm и compose были анонсированы совсем недавно и до сих пор они еще не production-ready.
DNS решается Docker Compose, который по links прописывает нужные обновления в контейнеры в /etc/hosts. Анонсировать ничего не надо. Масштабирование — Docker Swarm + Docker Compose scale. Балансировкой заниматься должен балансер (Nginx/HAProxy/...), вот как можно это настроить — www.centurylinklabs.com/auto-loadbalancing-with-fig-haproxy-and-serf/
Ну как же анонсировать ничего не надо, если по вашей же ссылке используется serf для service discovery?
То для чего у автора используется ansible вообще не имеет к тому для чего предначначен Docker Machine никакого отношения. Docker Machine предназначен для создания и управления виртуалками (локальными или в облаке) с установленным docker'ом.Виноват, снова Docker Swarm с Docker Machine спутал, действительно Docker Machine в конкретном топике ни при делах. В общем, суть в том, что если поднять на своих серверах Docker Swarm, то не нужно заходить по ssh (ansible) на эти машины и делать docker run.
По вопросу кастомных наколеночных решений я с вами согласен. Но справедливости ради надо сказать, что swarm и compose были анонсированы совсем недавно и до сих пор они еще не production-ready.Да, Swarm совсем свежий, но Compose (fig) развивается давно. Тут сложно сказать что менее production ready — наколеночный костыльный скрипт или специализованное решение. Но выбор за каждым. Просто иногда лучше не советовать ничего, чем советовать вредные подходы.
Ну как же анонсировать ничего не надо, если по вашей же ссылке используется serf для service discovery?Тут я опять неверно выразился. В случае реализации того решения, что у автора, без динамического масштабирования, анонсировать ничего не надо. А в красивом подходе, конечно прийдётся что-то в духе Serf использовать.
Ещё вопросы?
Используете линки в работе? Как решаете проблему рестарта линкованого контейнера? Рестартуете всю цепочку?
Как делаете двусторонние линки?
Да, использую линки. А какая проблема? Вот набросал docker-compose.yml (нужен bash и nc, под рукой был ubuntu образ, можете любой другой использовать с указанными утилитами):
qq2 слушает входящие соединения, выводит, что там пришло и в ответ кидает REPLY со своим IP+именем.
Запуск:
В соседней консоли:
Вывод на первой консоли:
Двусторонних линков пока не приходилось делать, можно пример, пожалуйста?
qq1:
image: ubuntu
links:
- qq2
command: "bash -c 'for i in `seq 1000`; do echo $i | nc qq2 10000 ; sleep 1; done'"
qq2:
image: ubuntu
command: "bash -c \"while true; do bash -c 'for i in `seq 1000`; do echo REPLY $(getent hosts `hostname`) ; sleep 0.5; done' | nc -l -p 10000 0.0.0.0 ; done\""
qq2 слушает входящие соединения, выводит, что там пришло и в ответ кидает REPLY со своим IP+именем.
Запуск:
$ docker-compose up
В соседней консоли:
$ docker-compose restart qq2
Вывод на первой консоли:
$ sudo docker-compose up
Recreating tmp_qq2_1...
Recreating tmp_qq1_1...
Attaching to tmp_qq2_1, tmp_qq1_1
qq2_1 | 1
qq1_1 | REPLY 172.17.1.2 de8138e439ae
qq1_1 | REPLY 172.17.1.2 de8138e439ae
...
...
qq2_1 | 11
qq1_1 | REPLY 172.17.1.5 de8138e439ae
qq1_1 | REPLY 172.17.1.5 de8138e439ae
Двусторонних линков пока не приходилось делать, можно пример, пожалуйста?
Двусторонние линки — два сервиса должны знать друг о друге. Получается проблема курицы и яйца.
По вашему примеру. Он у меня не заработал и я его немного переделал.
По вашему примеру. Он у меня не заработал и я его немного переделал.
$ cat docker-compose.yml
qq1:
image: ubuntu
links:
- qq2
command: "bash -c 'while true; do data=$RANDOM; echo REQUEST: $data; nc qq2 10000 <<< $data; sleep 1; done'"
qq2:
image: ubuntu
command: "bash -c 'while true; do echo RESPONSE: $(nc -l 10000); sleep 0.5; done'"
$ docker-compose up
Recreating compose_qq2_1...
Recreating compose_qq1_1...
Attaching to compose_qq2_1, compose_qq1_1
qq2_1 | RESPONSE: 24896
qq1_1 | REQUEST: 24896
qq1_1 | REQUEST: 16226
qq2_1 | RESPONSE: 16226
qq1_1 | REQUEST: 23182
qq2_1 | RESPONSE: 23182
qq1_1 | REQUEST: 10674
qq2_1 | RESPONSE: 10674
qq1_1 | REQUEST: 7200
qq2_1 | RESPONSE: 7200
qq1_1 | REQUEST: 30534
qq2_1 | RESPONSE: 30534
... тут происходит docker-compose restart qq2 ...
qq1_1 | REQUEST: 7482
qq1_1 | REQUEST: 30388
qq1_1 | REQUEST: 21044
qq1_1 | REQUEST: 4143
qq1_1 | REQUEST: 11100
qq1_1 | REQUEST: 21941
qq1_1 | REQUEST: 5191
qq1_1 | REQUEST: 27923
Я знаком с понятием двусторонний. Приведите пример такого проекта!
По вашему коду:
Всё работает, просто вы вывод больше не видите от qq2 в этой консоли, если бы не работало, вы бы получали timeout или порт закрыт (я сейчас с телефона и не могу проверить что именно будет видно в консоли). Я response посылал обратно в nc от qq2 — поэтому у меня и видно вывод.
P.S. «он у меня не заработал» — ей богу вам тестировщики тоже баги репортят «у нас что-то сломалась»? Как именно не заработал?
По вашему коду:
Всё работает, просто вы вывод больше не видите от qq2 в этой консоли, если бы не работало, вы бы получали timeout или порт закрыт (я сейчас с телефона и не могу проверить что именно будет видно в консоли). Я response посылал обратно в nc от qq2 — поэтому у меня и видно вывод.
P.S. «он у меня не заработал» — ей богу вам тестировщики тоже баги репортят «у нас что-то сломалась»? Как именно не заработал?
P.S. «он у меня не заработал» — ей богу вам тестировщики тоже баги репортят «у нас что-то сломалась»? Как именно не заработал?
Получаю такой вывод:
$ docker-compose up
Recreating compose_qq2_1...
Recreating compose_qq1_1...
Attaching to compose_qq2_1, compose_qq1_1
qq2_1 | 1
qq2_1 | 14
qq2_1 | 27
qq2_1 | 40
qq2_1 | 53
qq2_1 | 66
qq2_1 | 78
qq2_1 | 91
qq2_1 | 104
Не увидел никакого REPLY 172.17.1.5 de8138e439ae.
Всё работает, просто вы вывод больше не видите от qq2 в этой консоли
Ваша правда. Все работает и это круто!
Я знаком с понятием двусторонний. Приведите пример такого проекта!
Хочу чтоб 2 веб-сервиса могли дергать друг друга за апи. Думал, может подскажете какой-то вариант.
А как вы рулите линками между хостами? Например 2 веб-сервера, на разных хостах и БД на отдельном. Как этим красиво рулить?
P.S. Большое спасибо.
Очень подозрительно, что это там с docker-compose. У меня версия 1.2.0rc1, а у вас?
На счёт двухстороннего взаимодействия, я вижу два разных пути решения:
1. на уровне приложений — один дёргает другого и говорит куда тому коннектиться в следующий раз. Такое решение не очень красивое, но в зависимости что там за сервисы — это может иметь смысл.
2. делать третью сторону, регистратор обоих приложений (я пока не имею большого опыта в этой области, но начать можно с таких проектов: registrator, serf, consul, skydns)
На счёт нескольких хостов — Docker Swarm + Docker Compose скрывают подробности того, где именно запущен образ и links работает прозрачно. Однако, это в теории, я БД в Swarm ещё не запихивал, она у меня просто на одном сервере запущена через Compose.
На счёт двухстороннего взаимодействия, я вижу два разных пути решения:
1. на уровне приложений — один дёргает другого и говорит куда тому коннектиться в следующий раз. Такое решение не очень красивое, но в зависимости что там за сервисы — это может иметь смысл.
2. делать третью сторону, регистратор обоих приложений (я пока не имею большого опыта в этой области, но начать можно с таких проектов: registrator, serf, consul, skydns)
На счёт нескольких хостов — Docker Swarm + Docker Compose скрывают подробности того, где именно запущен образ и links работает прозрачно. Однако, это в теории, я БД в Swarm ещё не запихивал, она у меня просто на одном сервере запущена через Compose.
дел
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker и костыли в продакшене