Comments 25
Сколько не смотрел на докер, меня все время смущает тот факт, что я не понимаю, как работает создание образа: это бинарный слепок или образ наподобие livecd с последующими загрузкай в облоко и скачиванием?
Оно, нет?
Не очень понимаю, правда, какое это имеет в сути значение.
Не очень понимаю, правда, какое это имеет в сути значение.
Там есть начальный слепок, например, чистая операционная система и специальная файловая система AuFS, которая прозрачно наслаивает снимки на это слепок. Поэтому переключение между контейнерами это что-то типа git checkout. Меня вот в докере смущает тот факт, что например, порт SSH всегда динамический в большом диапазоне значений и этот диапазон жестко зафиксирован в коде: github.com/dotcloud/docker/blob/master/runtime/networkdriver/portallocator/portallocator.go
Это тоже все понятно, меня больше интересует вопрос, что представляет собой этот самый слепок. Или снимок, если хотите. Просто кусок файловой системы наподобие брэнча svc или кусой файловой системы наподобие образа iso, etc… При этом это какой-то свой формат или один из распространненных форматов (так как может работать и с aufs + снимки btrfs or lvm или вообще без всего этого)
Все, что выше — это понятно из сайта докера, мана aufs и тому подобного…
Все, что выше — это понятно из сайта докера, мана aufs и тому подобного…
Это сделано специально, т. к.:
The range 49152–65535 – above the registered ports – contains dynamic or private ports that cannot be registered with IANA..
Заходим на docs.docker.io/en/latest/ и читаем:
Please note Docker is currently under heavy development. It should not be used in production (yet).Так что безусловно интересно, но пока не для продакшн даже несмотря на то, что Яндекс.Cocaine работает на нем.
Как вы переносите данные из одного редис контейнера в другой? Такой же вопрос про базу.
Если для тестов все понятно, то как вы решаете эти вопросы в продакшене?
Если для тестов все понятно, то как вы решаете эти вопросы в продакшене?
По идее база данных живет в отдельном контейнере, так что при выкатке очередной версии в прод, у вас сначала поднимается контейнер с новой версией, затем накатываются миграции в базу (тут видимо важно что бы изменения в базе не влияли на работоспособность предыдущей версии), и просто подменяется контейнер с текущего на новый.
Собственно такой подход можно применить к любому случаю, когда у вас должно использоваться какое-то постоянное хранилище. Причем любой контейнер при необходимости сможет получить к этим данным доступ.
Вы говорите про рельсовую часть, как я понял.
Если вы подменяете контейнеры с базами — как вы поддерживаете их актуальность?
Если вы подменяете контейнеры с базами — как вы поддерживаете их актуальность?
контейнеры с базой и не нужно подменять, они как висят себе так и висят. Просто в момент апдейта у нас два контейнера с приложением, которые работают с одним контейнером базы. Как только накатятся миграции для новой версии, можно подменять контейнеры и тушить старый.
С двумя годами работы с Chef у меня такое же впечатление от работы с ним, что на писание кода для чефа уходит больше времени, чем на инфраструктуру. Надо будет попробовать ansible.
Вдогонку к докеру: www.packer.io/
Кто нибудь знает как запустить Docker на 32 битной машине?
Пользуюсь Chef.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
По началу казалось, что разработка инфраструктуры с chef — это не просто долго, это вечность!
Когда побольше разобрался в нём — дела пошли куда быстрее.
Хотя, от этого он не перестаёт быть сложным и медленным (в плане разработки).
Однако, в защиту Chef могу сказать, что сообщество очень быстро адаптируется и меняется в лучшую сторону.
Появляется всё больше удобных инструментов, которые существенно ускоряют процесс разработки. Потихоньку вырабатываются best practice/chef patterns для работы с cookbooks. Качество community cookbooks (они же library cookbooks) быстро растёт. К моменту выхода chef 12 картина должна существенно улучшиться.
Мой «джентльменский набор» сейчас такой: Chef Zero, Test-Kitchen, Berkshelf, Docker (test kitchen driver for docker), chefspec, bats, serverspec.
Основная причина по которой остаюсь на Chef это orchestration: работа с кластерами, зависимости между серверами.
Конечно, есть тот же etcd который может частично решить проблему.
А вообще, Docker мне очень понравился, отличная идея, отличный проект. Подумываю над тем, чтобы серверами-болванками управлять через Chef, раскатывать проект через Docker (есть cookbook: github.com/bflad/chef-docker), настраивать опять же Chef-ом или каким-нибудь другим сервисом.
Абсолютно с вами согласен.
Когда есть устоявшаяся методология и понимание процесса разработки и дейплоймента — chef прекрасно ложиться на Technical Operations.
Вот кстати тоже интересная ссылка по теме, про интеграцию docker с chef docs.deis.io/en/latest/gettingstarted/concepts/#concepts
Когда есть устоявшаяся методология и понимание процесса разработки и дейплоймента — chef прекрасно ложиться на Technical Operations.
Вот кстати тоже интересная ссылка по теме, про интеграцию docker с chef docs.deis.io/en/latest/gettingstarted/concepts/#concepts
Очень хотел увидеть примеры того, как Вы объединили Docker и Ansible, но вместо этого увидел рассказ о том, как всё круто сделано, но без конкретики. В духе Яндекса, кстати :)
Sign up to leave a comment.
Ansible и Docker, почему и зачем?