Комментарии 62
«Docker делает это с помощью легковесной платформы контейнерной виртуализации»
Сложно назвать всё это «легковесным», когда ваш образ базируется на какой-нибудь убунте. Не всегда возможно использовать что-то лёгкое вроде busybox. Да даже с его использованием может статься, что сам контейнер использует намного больше ресурсов, нежели само приложение.
p.s. для диплоя приложений/сервисов рекомендую пользоваться не голым докером, а чем-то поверх него. Kubernetes, например, или Apache mesos+марафон.
Сложно назвать всё это «легковесным», когда ваш образ базируется на какой-нибудь убунте. Не всегда возможно использовать что-то лёгкое вроде busybox. Да даже с его использованием может статься, что сам контейнер использует намного больше ресурсов, нежели само приложение.
p.s. для диплоя приложений/сервисов рекомендую пользоваться не голым докером, а чем-то поверх него. Kubernetes, например, или Apache mesos+марафон.
Образ убунты для докера — 200 мегов.
И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
Так что не понятно, какие ресурсы может использовать контейнер сами по себе.
Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
Так что не понятно, какие ресурсы может использовать контейнер сами по себе.
Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
команда докеру по созданию и запуску контейнера отрабатывает меньше секунды, подтверждаю, но сам контейнер (готовая виртуалочка) — в зависимости от бустрапа контейнера.
Все верно, но это же не относиться к контейнеру как к таковому!
Это же ваше приложение, оно будет так-же стартовать и вне контейнера.
Смысл «легкости» докера в том что оверхед минимален, в практической жизни — незаметен.
Это же ваше приложение, оно будет так-же стартовать и вне контейнера.
Смысл «легкости» докера в том что оверхед минимален, в практической жизни — незаметен.
А я и не спорил с аргументом легкости )) вот прямо сейчас вожусь с ним
Создаю из Dockerfile-а: дефолтовые настройки sshd + mysql + python = 360 MB.
Создаю из Dockerfile-а: дефолтовые настройки sshd + mysql + python = 360 MB.
Весь смысл в том, что это и так нужно в системе для работы приложения.
А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.
Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.
Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
Про БД согласен, но с одной поправкой — управлять связкой сервисов, который работает каждый в своем контейнере — это отдельная нетривиальная задача. ИМХО, поэтому, если количество сервисов ограничено — скажем в районе 5 — то отделять в индивидуальные контейнеры не обязательно. А если связка постоянно меняется и\или набор сервисов стабильно растет, то надо отдельно.
Все зависит не от количества сервисов, а от необходимости масштабирования (ну и изоляцию таки никто не отменял)
Связка постоянно меняется — отлично — делаем кучу контейнеров и экспериментируем.
Запуск пачки можно делать обычным bash-скриптом, что тут сложного — даже полезно.
Ну и docker-compose (бывший fig) позволяет собирать связки легко и просто. Я лично использую make-файлы, make run и все :-)
Связка постоянно меняется — отлично — делаем кучу контейнеров и экспериментируем.
Запуск пачки можно делать обычным bash-скриптом, что тут сложного — даже полезно.
Ну и docker-compose (бывший fig) позволяет собирать связки легко и просто. Я лично использую make-файлы, make run и все :-)
В парадигме Докера было правильнее создать два контейнера мускул и питон.
Вернее даже заюзать готовые из репы… А sshd вам не нужен в контехнерах.
Вернее даже заюзать готовые из репы… А sshd вам не нужен в контехнерах.
Я для себя вывел практическое правило (с редкими исключениями) — если мне хочется иметь ssh в Docker-контейнере, то я что-то делаю не так. И, скорее всего, мне нужен LXC :)
Docker нужен чаще всего для массового запуска единообразных контейнеров. Которые хранят данные и настройки где-то снаружи. Иначе теряется эффективность, сильно усложняется массовое обновление и т.п. Если контейнер нужно настраивать индивидуально изнутри, то есть прекрасно заточенный под это дело LXC, работа с которым мало отличается от работы с отдельным компьютером.
Docker нужен чаще всего для массового запуска единообразных контейнеров. Которые хранят данные и настройки где-то снаружи. Иначе теряется эффективность, сильно усложняется массовое обновление и т.п. Если контейнер нужно настраивать индивидуально изнутри, то есть прекрасно заточенный под это дело LXC, работа с которым мало отличается от работы с отдельным компьютером.
Образ дэбиана 7.8 — вообще 120
Ну и что? это лишь место на диске…
Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
Меняет погоду?
Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
Меняет погоду?
Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.
Используйте Alpine образ (недавно наконец его добавили в официальный) — 5МБ включает в себя busybox + apk пакетный менеджер. Так, например, dnsmasq образ, основанный на Alpine весит 6МБ. Вот это я понимаю, Докер-приложение, а когда для dnsmasq 100500 альтернативных образов лежит от убунты наследованных по 200МБ — это выше моего понимания. Другой пример: официальный образ python в Docker весит 750МБ(!), собранный мною из Alpine получается 46МБ со всеми потрохами.
Используйте Alpine образ (недавно наконец его добавили в официальный) — 5МБ включает в себя busybox + apk пакетный менеджер. Так, например, dnsmasq образ, основанный на Alpine весит 6МБ. Вот это я понимаю, Докер-приложение, а когда для dnsmasq 100500 альтернативных образов лежит от убунты наследованных по 200МБ — это выше моего понимания. Другой пример: официальный образ python в Docker весит 750МБ(!), собранный мною из Alpine получается 46МБ со всеми потрохами.
Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.
Ну хорошо, в этом есть логика…
Но только не совсем та что вы описываете…
Нет Docker это не puppet — не нужно ему никаких обновлений часто… Вы любите докер за то что он позволяет вам выстроить ваш релизпайплан на базе Immutable images.
Конечно у вас есть какая-то инфраструктура на которй бегут контейнеры, например кластер виртуальных машин. Вот там вы и беспокойтесь об очередном ssl heartbleed.
А в контейнере вас совершенно не интересует, вышла ли новая версия vi или нет…
Конечно и уровень приложений в контеэнре иноигда надфо обоновить иза внешних факторов… Но это как-бы не проблема размера имиджа…
Если вы начинаете оптимировать размер базового имиджа, то значит можно позавидовать вашей прочей инфраструктуре ;)))
Я — перфекционист и это многое объясняет. На счëт обновлений — тем не менее базовые образы обновляются, хотим мы этого или нет и если не обновляться вслед за ними, то если у вас много своих образов наследованных от одного базового, но разного времени тухлости — докер вам никак место не сэкономит — вы вынуждены пересобирать свои образы. Обновления в LTS выходят только с исправлениями безопасности, например дырку в bash вы же захотите залатать?
Если перфекционист то, да начинайте оптимировать базовые имиджы ;)
Я стараюсь прибывать в балансе между перфекционизмом и прагматизмом…
Дырка в баше меня не интересует в контейнере в котором бежит какой-нибудь микросервис ничего не делающис с башем (у меня к примеру все такие ;))
Но да если обновлять от разных базовых имиджей (и если вы подошли к вопросю серьезно то базовые имиджи ваши) вы имеете возможность ссылаться на конкретные весрии (это рекомендую)
но даже если у вас будет на хосте рознящиеся aufs layers. Вы действительно беспокоитесь? Ну ок как перфекционист видимо да…
Хорошо но это задача релизмэнедежмента а именно:
1) с головой переезжать на новые версии
2) чисть неиспользуемые имиджы на хостах… и что-бы ни гига лишнего не валялось ;)
Вроде решаемо если так приспичило…
Мне 1) важнее независимо от места на диске.
Я стараюсь прибывать в балансе между перфекционизмом и прагматизмом…
Дырка в баше меня не интересует в контейнере в котором бежит какой-нибудь микросервис ничего не делающис с башем (у меня к примеру все такие ;))
Но да если обновлять от разных базовых имиджей (и если вы подошли к вопросю серьезно то базовые имиджи ваши) вы имеете возможность ссылаться на конкретные весрии (это рекомендую)
но даже если у вас будет на хосте рознящиеся aufs layers. Вы действительно беспокоитесь? Ну ок как перфекционист видимо да…
Хорошо но это задача релизмэнедежмента а именно:
1) с головой переезжать на новые версии
2) чисть неиспользуемые имиджы на хостах… и что-бы ни гига лишнего не валялось ;)
Вроде решаемо если так приспичило…
Мне 1) важнее независимо от места на диске.
А вот вам и статья для размышлений: Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities. А вы говорите обновлять там нечего…
Просто если захотите посмотреть на мои поделки на Docker Hub: https://registry.hub.docker.com/repos/frolvlad/
Просто если захотите посмотреть на мои поделки на Docker Hub: https://registry.hub.docker.com/repos/frolvlad/
Можно взять Ubuntu Core как базу, ну или самому debootstrap.
У меня вот другой вопрос: Думаю уйти с openvz, насколько можно переползти с него в docker?
Возникают вопросы с кластером :)
У меня вот другой вопрос: Думаю уйти с openvz, насколько можно переползти с него в docker?
Возникают вопросы с кластером :)
openvz это все-же больше «виртуалки» на базе контейнеров. А docker — это упаковка отдельных приложений и запуск их в контейнерах, причем с уклоном в immutable контейнеры.
Это инструменты под разные задачи, в общем-то.
Можете посмотреть на CoreOS, в которой нет ничего кроме ssh и docker'а, все остальное только в docker контейнерах.
в openvz — вы имеете нормальную виртуалку со всеми необходимыми процессами, в docker — вы имете один процесс с его детьми, например apache. докер — контейнер имени одного процесса, в отличие от полноценного lxc/openvz
Можете посмотреть на CoreOS, в которой нет ничего кроме ssh и docker'а, все остальное только в docker контейнерах.
в openvz — вы имеете нормальную виртуалку со всеми необходимыми процессами, в docker — вы имете один процесс с его детьми, например apache. докер — контейнер имени одного процесса, в отличие от полноценного lxc/openvz
Я прекрасно понимаю, что docker несколько иное чем openvz/lxc.
Просто на текущий момент у меня все свелось к изоляции по процессам.
Отдельно nginx, отдельно mysql, от дельно mongo итд.
Просто например хотелось бы некоторых возможностей по миграции. Хотя вроде как все есть в монстре OpenStack.
CoreOS отказалась кстати от Docker в пользу Rocket.
Просто на текущий момент у меня все свелось к изоляции по процессам.
Отдельно nginx, отдельно mysql, от дельно mongo итд.
Просто например хотелось бы некоторых возможностей по миграции. Хотя вроде как все есть в монстре OpenStack.
CoreOS отказалась кстати от Docker в пользу Rocket.
регистр => реестр
НЛО прилетело и опубликовало эту надпись здесь
Предвидя ответ, что Vagrant это всё же полновесная виртуалка (против суперлегкого докера, который, к тому же, используется не для деплоя машины, но для деплоя конкретного приложения), все же присоединюсь к вопросу. Я как-то гуглил эту тему, пытаясь понять, а зачем мне, собственно, докер (есть стандартный набор, веб приложение + бд + кеш + нгинкс + job queue, поставил задачу задеплоить на staging/production и иметь похожую среду у всех разработчиков), и из-за малого количества конкретных примеров «как это делают профи и зачем это нужно» так на докере не остановился. Для моих задач хватило чистого Ansible'a, который разворачивает софт на удаленные машины без виртуализации и контейнеров. Собственно, вопрос в том, зачем нам, простым инженерам, это надо (и надо ли?) и как этот агрегат использовать в производстве. Кто-нибудь расскажет про use case?
Не то, чтобы я профи. Я определенно еще новичок в работе с докером, но… попробую ответить.
Vagrant — управление конфигурациями + виртуализация, с 1.1 работает с докером тоже. То есть создание виртуалки по конфигу. Это конкретно обертка над управлением конфигурацией и виртуализацией. Можно использовать разные менеджеры конфигураций и разные системы виртуализаций. Причем системы виртуализаций могут быть разного типа.
Ansible — как правильно было замечено, работает с уже работающими машинами. AFAIR можно прикручивать к железным машинам и виртуальным. то есть это управление конфигурациями, но без создания виртуалки. немного другой инструмент.
docker же вместе с docker-compose — это (опять же, как я это понимаю) аналого вагранта, но нативные инструменты (не обёртки как вагрант) для полного цикла виртуализации для приложений. Можно применять для разработки и для продакшена.
Причем основной плюс докера в том, что он использует систему контроля версий для обновления виртуальной. Никакие другие системы виртуализации этим не могут похвастаться, вроде как.
> можно поднимать прямо на рабочей системе
(Чото тэг цитирования не сработал)
Конечно, можно, но уверен, что изолированное приложение и\или сервисы лучше чем неизолированные.
Еще пример — использование одного и того же сервиса разных версий. в изолированном виде это в разы легче добавить и удалить.
Vagrant — управление конфигурациями + виртуализация, с 1.1 работает с докером тоже. То есть создание виртуалки по конфигу. Это конкретно обертка над управлением конфигурацией и виртуализацией. Можно использовать разные менеджеры конфигураций и разные системы виртуализаций. Причем системы виртуализаций могут быть разного типа.
Ansible — как правильно было замечено, работает с уже работающими машинами. AFAIR можно прикручивать к железным машинам и виртуальным. то есть это управление конфигурациями, но без создания виртуалки. немного другой инструмент.
docker же вместе с docker-compose — это (опять же, как я это понимаю) аналого вагранта, но нативные инструменты (не обёртки как вагрант) для полного цикла виртуализации для приложений. Можно применять для разработки и для продакшена.
Причем основной плюс докера в том, что он использует систему контроля версий для обновления виртуальной. Никакие другие системы виртуализации этим не могут похвастаться, вроде как.
> можно поднимать прямо на рабочей системе
(Чото тэг цитирования не сработал)
Конечно, можно, но уверен, что изолированное приложение и\или сервисы лучше чем неизолированные.
Еще пример — использование одного и того же сервиса разных версий. в изолированном виде это в разы легче добавить и удалить.
Докер — это больше про деплой, нежели про разработку. Очень удобно деплоить контейнеры на большое количество серверов
НЛО прилетело и опубликовало эту надпись здесь
Если вы хотите приблизится к теме Докера со стороны виртуалок я бы предложил вам почитать на
начиная вот с это-го ответа:
stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine/25938347#25938347
Это именно заче он нужен девелоперам.
А выше про техническии отличия от виртуалок.
начиная вот с это-го ответа:
stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine/25938347#25938347
Это именно заче он нужен девелоперам.
А выше про техническии отличия от виртуалок.
За вагрант не скажу, но вот с докером например надо мне на сервер вордпрес — одна команда, надо могу — одна команда, надо vpn-server, почтовый сервер, блог на руби — «одна» команда, и все это будет работать на одном сервере без конфликтов, один контейнер — как один продукт(программа).
А раньше без докера мне бы пришлось для каждого сервиса читать кучу манов, делать костыли, разруливать конфликты и т.д. и потом это не перенести на другой сервер если что.
Хотите что-б у клиента запустился Ваш сервис — даете ему один докер-файл (по чату/почте/github...), и по одной команде у него все запускается.
А раньше без докера мне бы пришлось для каждого сервиса читать кучу манов, делать костыли, разруливать конфликты и т.д. и потом это не перенести на другой сервер если что.
Хотите что-б у клиента запустился Ваш сервис — даете ему один докер-файл (по чату/почте/github...), и по одной команде у него все запускается.
Открыл статью и ожидал почитать Минусы докера, отдельным пунктом. Где?
Сколько можно клепать статьи «А что такое Докер?», без указания на его явные неудобства и недостатки.
Хотелось бы видеть:
«Что сейчас имеется у Докера, чего пока не хватает, для чего и как можно использовать уже сейчас, принимая во внимание его недостатки и чем можно помочь сообществу в развитии продукта»
Сколько можно клепать статьи «А что такое Докер?», без указания на его явные неудобства и недостатки.
Хотелось бы видеть:
«Что сейчас имеется у Докера, чего пока не хватает, для чего и как можно использовать уже сейчас, принимая во внимание его недостатки и чем можно помочь сообществу в развитии продукта»
А как можно написать о минусах не зная о контексте применения?
Ведь докер это тут сам посебе и может быть применен для решения многих задач…
Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
Вот например ребята из CoreOS считают что докер и так уже слишком много задач начинает решать и предлагают сконцентрироваться на контейнерах предлагая свой вариант
Ведь докер это тут сам посебе и может быть применен для решения многих задач…
Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
Вот например ребята из CoreOS считают что докер и так уже слишком много задач начинает решать и предлагают сконцентрироваться на контейнерах предлагая свой вариант
Да, CoreOS и Docker жёстко разошлись во мнениях относительно недавно… Что конечно напугало, но говорит о том, что технологии управления контейнерами бурно развиваются и это хорошо, раньше никто особо не обращал внимания на lxc, jail и solaris zones.
На счёт недостатков — уже описанная например «the PID 1 problem», управление init/логами/прочими процессами, некоторые разницы в версиях, большое количество велосипедов поверх вроде apache mesos и google Kubernetes — зачем вообще они нужны и почему они появляются? Чего не хватает нативному docker/docker-api/swarm/machine/compose? Почему разошлись во мнениях CoreOs/Docker команды? Почему не пилят дальше DockerUI? И т.д.
Слишком много вопросов возникает :) Для тестирования всё конечно прекрасно, но для продакшена это страшно всё использовать, пока рано. Может через годик-два.
На счёт недостатков — уже описанная например «the PID 1 problem», управление init/логами/прочими процессами, некоторые разницы в версиях, большое количество велосипедов поверх вроде apache mesos и google Kubernetes — зачем вообще они нужны и почему они появляются? Чего не хватает нативному docker/docker-api/swarm/machine/compose? Почему разошлись во мнениях CoreOs/Docker команды? Почему не пилят дальше DockerUI? И т.д.
Слишком много вопросов возникает :) Для тестирования всё конечно прекрасно, но для продакшена это страшно всё использовать, пока рано. Может через годик-два.
Ну что бы навести в этом порядок надо наверное определить задачи:
Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
И что выбрать вопсро не легкий…
У само-го руки не доходят…
я в продукции пока польжусь ручными скриптами… но кошусь в сторону CoreOS и потом Kubernetes
по моей ссылке сверху описано почему…
видит семя на уровне оркестрации контейнерво и их устроил бы докер проект который занимается только контейнерами а экосистемой…
Поэтому они видят опасность что Докер разрастется слишком. В принципе я сними даже согласен… Хорошо что есть конкуренция.
Помоему докер со врменем сильно повлияет на архитектуру приложений… И в этой архитектуре совершенно не больно перестартануть контейнер.
Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
И что выбрать вопсро не легкий…
У само-го руки не доходят…
я в продукции пока польжусь ручными скриптами… но кошусь в сторону CoreOS и потом Kubernetes
Почему разошлись во мнениях CoreOs/Docker команды?
по моей ссылке сверху описано почему…
видит семя на уровне оркестрации контейнерво и их устроил бы докер проект который занимается только контейнерами а экосистемой…
Поэтому они видят опасность что Докер разрастется слишком. В принципе я сними даже согласен… Хорошо что есть конкуренция.
DockerUIне нужно… Я один раз поставил и понял что я в консоли быстре… Она ничего не предвносит нового по функционалу
the PID 1 problem
Помоему докер со врменем сильно повлияет на архитектуру приложений… И в этой архитектуре совершенно не больно перестартануть контейнер.
а кто-нибудь использует докер для java?
Да, никаких особых проблем нет. Например, мои образы tomcat8 — github.com/grossws/docker-comp-tomcat8, solr4 — github.com/grossws/docker-comp-solr4 (на основе tomcat8, надо подкладывать конфиги, иначе не заработает).
Можно попробовать с помощью docker pull grossws/tomcat8.
Можно попробовать с помощью docker pull grossws/tomcat8.
Да. Какие вопросы?
Наследуйте ваш докерфайл от одного из базового (например мои: registry.hub.docker.com/u/shuron/java_8/ registry.hub.docker.com/u/shuron/debian-openjdk-7/ )
и вперед…
Наследуйте ваш докерфайл от одного из базового (например мои: registry.hub.docker.com/u/shuron/java_8/ registry.hub.docker.com/u/shuron/debian-openjdk-7/ )
и вперед…
вопрос — а есть ли смысл?
когда томкат приложения в принципе поставляются сами в себе… и иногда даже просто в одном war.
те, если руби требует какие то системные библиотеки — тот же рвм (но с рвм не все всегда гладко), то в этом ключе я понимаю смысл докера.
тоже самое я прекрасно понимаю, если человек пишет на пхп и питоне.
а вот с явой — появился вопрос. ведь ява — это микро виртуалка, насколько я знаю.
когда томкат приложения в принципе поставляются сами в себе… и иногда даже просто в одном war.
те, если руби требует какие то системные библиотеки — тот же рвм (но с рвм не все всегда гладко), то в этом ключе я понимаю смысл докера.
тоже самое я прекрасно понимаю, если человек пишет на пхп и питоне.
а вот с явой — появился вопрос. ведь ява — это микро виртуалка, насколько я знаю.
Лично моё ИМХО, Джаву тоже упаковывать нужно — уж больно большой зоопарк самих JVM и тот же Tomcat меня своими настройками прав доступа долго удивлял. (Я не пишу код на Java, но меня попросили развернуть один проектик у себя на сервере.)
Ну и вообще, ввиду минимальных накладных расходов на Docker — я вижу только позитивные аспекты его применения (воспроизводимость, переносимость, изолированность и тд).
Ну и вообще, ввиду минимальных накладных расходов на Docker — я вижу только позитивные аспекты его применения (воспроизводимость, переносимость, изолированность и тд).
Как ответил frol смысл есть…
Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
Вот в этом Докер вам поможет.
Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
Вот в этом Докер вам поможет.
Господа.
Присоединяюсь к заданным вопросам выше: как его использовать-то? Не, ну вот правда! Сколько раз хотел попробовать, но как-то не сложилось.
Вот есть желающие, я так себе думаю, заработать +миллион в карму, а? (-:
Вот взять и написать маленький туториал практического использования докера для продакшина…
Предлагаю даже содержание того, что было бы лично мне интересно:
1. на входе — nginx с sticky sessions в качестве балансировщика
2. балансирует он это всё 3-4 копии node-приложения, разнесённых в разные дата-центры, для отказоустойчивости. Для интереса пусть приложения стартуют тоже в nginx+passanger…
3. приложения имеют дело с кластером монги
Вот как это делать без докера — я знаю, а как это всё сделать на докеровских контейнерах и предназначено ли всё это для такого типа задач.
Ну вот честно, совсем без шуток, хочется такой туториал. Может есть что-то подобное в английской версии — буду признателен за ссылку.
Присоединяюсь к заданным вопросам выше: как его использовать-то? Не, ну вот правда! Сколько раз хотел попробовать, но как-то не сложилось.
Вот есть желающие, я так себе думаю, заработать +миллион в карму, а? (-:
Вот взять и написать маленький туториал практического использования докера для продакшина…
Предлагаю даже содержание того, что было бы лично мне интересно:
1. на входе — nginx с sticky sessions в качестве балансировщика
2. балансирует он это всё 3-4 копии node-приложения, разнесённых в разные дата-центры, для отказоустойчивости. Для интереса пусть приложения стартуют тоже в nginx+passanger…
3. приложения имеют дело с кластером монги
Вот как это делать без докера — я знаю, а как это всё сделать на докеровских контейнерах и предназначено ли всё это для такого типа задач.
Ну вот честно, совсем без шуток, хочется такой туториал. Может есть что-то подобное в английской версии — буду признателен за ссылку.
Как-то так: habrahabr.ru/post/253999/
Ну смотрите, докер может использоваться по типу виртуализации любого типа. В контейнерной виртуализации меньше оверхед чем в полной, выше скорость работы и часто выше удобство администрирования. LXC в мейнлайне, не нужно тянуть отдельные ядра и т.д. (как в ОпенВЗ)
Да, докерные фишки с гитом, возможно, не так часто применимы и скорее для девелоперов могут быть удобными.
Да, докерные фишки с гитом, возможно, не так часто применимы и скорее для девелоперов могут быть удобными.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Понимая Docker