Как стать автором
Обновить

Комментарии 62

«Docker делает это с помощью легковесной платформы контейнерной виртуализации»
Сложно назвать всё это «легковесным», когда ваш образ базируется на какой-нибудь убунте. Не всегда возможно использовать что-то лёгкое вроде busybox. Да даже с его использованием может статься, что сам контейнер использует намного больше ресурсов, нежели само приложение.

p.s. для диплоя приложений/сервисов рекомендую пользоваться не голым докером, а чем-то поверх него. Kubernetes, например, или Apache mesos+марафон.
безусловно. Сам пользуюсь mcloud. Цель статьи введение в понятийный уровень.
Легковесность тут имемтся ввиду по отношению к виртуальныйм машинам.
И к весу клонирования. Каждый новый контейнер с Ubuntu будет отнимать совсем мало места.
Образ убунты для докера — 200 мегов.
И в контейнере никакие сервисы сами по себе не стартуют, по сути ваше приложение — это init для контейнера.
Так что не понятно, какие ресурсы может использовать контейнер сами по себе.

Сложно назвать докер тяжелым если контейнер стартует меньше секунды.
команда докеру по созданию и запуску контейнера отрабатывает меньше секунды, подтверждаю, но сам контейнер (готовая виртуалочка) — в зависимости от бустрапа контейнера.
Все верно, но это же не относиться к контейнеру как к таковому!
Это же ваше приложение, оно будет так-же стартовать и вне контейнера.

Смысл «легкости» докера в том что оверхед минимален, в практической жизни — незаметен.

А я и не спорил с аргументом легкости )) вот прямо сейчас вожусь с ним
Создаю из Dockerfile-а: дефолтовые настройки sshd + mysql + python = 360 MB.
Весь смысл в том, что это и так нужно в системе для работы приложения.

А вот если контейнеры используют одну и ту-же начальную последовательность команд в Dockerfile то и получаемые в результате «слои» (т.е. по сути — файлы) будут одинаковые. Поэтому скажем контейнеры
ubuntu + sshd + mysql и ubuntu + sshd + python (кстати полезно выносить базу в отдельный контейнер) будут отличаться только на последний слой, а слои ubuntu + sshd будут общими.

Но опять-же это только особенности реализации, смысл легкости в том что в контейнере нет никаких системных служб, это практически ядро + ваше приложение.
Про БД согласен, но с одной поправкой — управлять связкой сервисов, который работает каждый в своем контейнере — это отдельная нетривиальная задача. ИМХО, поэтому, если количество сервисов ограничено — скажем в районе 5 — то отделять в индивидуальные контейнеры не обязательно. А если связка постоянно меняется и\или набор сервисов стабильно растет, то надо отдельно.
Все зависит не от количества сервисов, а от необходимости масштабирования (ну и изоляцию таки никто не отменял)

Связка постоянно меняется — отлично — делаем кучу контейнеров и экспериментируем.

Запуск пачки можно делать обычным bash-скриптом, что тут сложного — даже полезно.

Ну и docker-compose (бывший fig) позволяет собирать связки легко и просто. Я лично использую make-файлы, make run и все :-)

В парадигме Докера было правильнее создать два контейнера мускул и питон.
Вернее даже заюзать готовые из репы… А sshd вам не нужен в контехнерах.
Согласен
Я для себя вывел практическое правило (с редкими исключениями) — если мне хочется иметь ssh в Docker-контейнере, то я что-то делаю не так. И, скорее всего, мне нужен LXC :)

Docker нужен чаще всего для массового запуска единообразных контейнеров. Которые хранят данные и настройки где-то снаружи. Иначе теряется эффективность, сильно усложняется массовое обновление и т.п. Если контейнер нужно настраивать индивидуально изнутри, то есть прекрасно заточенный под это дело LXC, работа с которым мало отличается от работы с отдельным компьютером.
Можно обойтись без ssh:

docker exec -it some_runnig_container bash
Речь не о конкретном инструменте, а о подходе. Если хочется менять Docker-контейнер изнутри индивидуально, то с высокой вероятностью где-то в архитектуре проекта ошибка.
НЛО прилетело и опубликовало эту надпись здесь
Образ дэбиана 7.8 — вообще 120
Ну и что? это лишь место на диске…
Выберете своим контейнерам базовый имидж и наследуйте от него и будут у вас эти 120 мб один раз на все контейнеры хоста на диске…
Меняет погоду?
Чем больше образ => тем больше в нём файлов/пакетов => тем чаще они требуют обновлений => тем чаще вам нужно пересобирать свои образы.

Используйте 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) важнее независимо от места на диске.
А вот вам и статья для размышлений: Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities. А вы говорите обновлять там нечего…

Просто если захотите посмотреть на мои поделки на Docker Hub: https://registry.hub.docker.com/repos/frolvlad/
Вы не понимаете…
Дело не в том что их нет.
А втом
Вам сравнительно пофиг на потенциальные nashvurnerabilities если ваш контейнер к примеру запускает маленький сервисе на яве.
Можно взять Ubuntu Core как базу, ну или самому debootstrap.

У меня вот другой вопрос: Думаю уйти с openvz, насколько можно переползти с него в docker?
Возникают вопросы с кластером :)
openvz это все-же больше «виртуалки» на базе контейнеров. А docker — это упаковка отдельных приложений и запуск их в контейнерах, причем с уклоном в immutable контейнеры.
Это инструменты под разные задачи, в общем-то.
Можете посмотреть на CoreOS, в которой нет ничего кроме ssh и docker'а, все остальное только в docker контейнерах.

в openvz — вы имеете нормальную виртуалку со всеми необходимыми процессами, в docker — вы имете один процесс с его детьми, например apache. докер — контейнер имени одного процесса, в отличие от полноценного lxc/openvz
Я прекрасно понимаю, что docker несколько иное чем openvz/lxc.
Просто на текущий момент у меня все свелось к изоляции по процессам.
Отдельно nginx, отдельно mysql, от дельно mongo итд.
Просто например хотелось бы некоторых возможностей по миграции. Хотя вроде как все есть в монстре OpenStack.

CoreOS отказалась кстати от Docker в пользу Rocket.
Да, я уже в курсе, спасибо
Docker — это не совсем «несколько иноче, чем LXC». Docker — это оберка над LXC для более удобной работы с ней
Docker начинал как обёртка над LXC, но уже год (?) как отвязался от последнего и работает с cgroups сам. Сейчас Docker и LXC — два независимых способа (разной идеологии) работать с cgroups-контейнерами.
регистр => реестр
спасибо. поправил.
Вижу много статей про докер, но пока не вижу применения докеру: простые приложения можно поднимать прямо на рабочей системе, благо префиксы к именам баз данных все cms ставить умеют. Если что-то сложное где требуется sphinx, mongo + опредленная верия php, то есть Vagrant. Если вы лепите сайты пачками поверх сложной конфигурации, то можно прикрутить Chef к вагранту. При этом у вас будет полноценная ВМ, которую можно будет передать разработчику с почти любой квалификацией. Буду рад, если кто-то доходчиво объяснит какие проблемы решает докер, которые не решает вагрант.
Предвидя ответ, что Vagrant это всё же полновесная виртуалка (против суперлегкого докера, который, к тому же, используется не для деплоя машины, но для деплоя конкретного приложения), все же присоединюсь к вопросу. Я как-то гуглил эту тему, пытаясь понять, а зачем мне, собственно, докер (есть стандартный набор, веб приложение + бд + кеш + нгинкс + job queue, поставил задачу задеплоить на staging/production и иметь похожую среду у всех разработчиков), и из-за малого количества конкретных примеров «как это делают профи и зачем это нужно» так на докере не остановился. Для моих задач хватило чистого Ansible'a, который разворачивает софт на удаленные машины без виртуализации и контейнеров. Собственно, вопрос в том, зачем нам, простым инженерам, это надо (и надо ли?) и как этот агрегат использовать в производстве. Кто-нибудь расскажет про use case?
Не то, чтобы я профи. Я определенно еще новичок в работе с докером, но… попробую ответить.

Vagrant — управление конфигурациями + виртуализация, с 1.1 работает с докером тоже. То есть создание виртуалки по конфигу. Это конкретно обертка над управлением конфигурацией и виртуализацией. Можно использовать разные менеджеры конфигураций и разные системы виртуализаций. Причем системы виртуализаций могут быть разного типа.

Ansible — как правильно было замечено, работает с уже работающими машинами. AFAIR можно прикручивать к железным машинам и виртуальным. то есть это управление конфигурациями, но без создания виртуалки. немного другой инструмент.

docker же вместе с docker-compose — это (опять же, как я это понимаю) аналого вагранта, но нативные инструменты (не обёртки как вагрант) для полного цикла виртуализации для приложений. Можно применять для разработки и для продакшена.

Причем основной плюс докера в том, что он использует систему контроля версий для обновления виртуальной. Никакие другие системы виртуализации этим не могут похвастаться, вроде как.

> можно поднимать прямо на рабочей системе

(Чото тэг цитирования не сработал)

Конечно, можно, но уверен, что изолированное приложение и\или сервисы лучше чем неизолированные.

Еще пример — использование одного и того же сервиса разных версий. в изолированном виде это в разы легче добавить и удалить.
>>Причем основной плюс докера в том, что он использует систему контроля версий для обновления виртуальной.

По теории так же можно с гитом считать дельту и коммитить то что получилось от ОпенВЗ. Просто что в Докере — это одна из фишек, которая доведена до ума.
Докер — это больше про деплой, нежели про разработку. Очень удобно деплоить контейнеры на большое количество серверов
НЛО прилетело и опубликовало эту надпись здесь
Вы не могли бы описать чем вы занимаетесь? Как часто вы создаете контейнеры для чего-то по работе? Вы используете традиционные сервера для деплоя или что-то вроде AWS?
НЛО прилетело и опубликовало эту надпись здесь
Если вы хотите приблизится к теме Докера со стороны виртуалок я бы предложил вам почитать на
начиная вот с это-го ответа:
stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine/25938347#25938347

Это именно заче он нужен девелоперам.
А выше про техническии отличия от виртуалок.
Я скорее хочу понять какой процент разработчиков и в какого типа конторах использует Docker. Чтобы знать насколько мне необходимо быть в курсе этой технологии.
За вагрант не скажу, но вот с докером например надо мне на сервер вордпрес — одна команда, надо могу — одна команда, надо vpn-server, почтовый сервер, блог на руби — «одна» команда, и все это будет работать на одном сервере без конфликтов, один контейнер — как один продукт(программа).
А раньше без докера мне бы пришлось для каждого сервиса читать кучу манов, делать костыли, разруливать конфликты и т.д. и потом это не перенести на другой сервер если что.
Хотите что-б у клиента запустился Ваш сервис — даете ему один докер-файл (по чату/почте/github...), и по одной команде у него все запускается.
даете ему один докер-файл
даже файл давать не обязательно, можно просто сказать команду, все приедет из docker hub.
Открыл статью и ожидал почитать Минусы докера, отдельным пунктом. Где?
Сколько можно клепать статьи «А что такое Докер?», без указания на его явные неудобства и недостатки.
Хотелось бы видеть:
«Что сейчас имеется у Докера, чего пока не хватает, для чего и как можно использовать уже сейчас, принимая во внимание его недостатки и чем можно помочь сообществу в развитии продукта»
А как можно написать о минусах не зная о контексте применения?
Ведь докер это тут сам посебе и может быть применен для решения многих задач…
Так что если вы опишите зачем он вам может вы сами и напишите что вам мешает в докере.
Вот например ребята из 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? И т.д.
Слишком много вопросов возникает :) Для тестирования всё конечно прекрасно, но для продакшена это страшно всё использовать, пока рано. Может через годик-два.
Ну что бы навести в этом порядок надо наверное определить задачи:
Вот есть контейнер и самое важно в контейнере это то что он стандартизирован… Снаружи он выглядит одинакого независимо что внутри… конечно он кушает разные проперти и вест поразному но это не важно…
Так вот если остаться в парадиогме архитектуры микросервисов (докер именно её упрощает прежде всего) то докер или Рокет в приницепе не вазно, свою задачу по запуску и мэнедзменту контейнеров они выполнят…
Другое дело если мы рассматриваем аппликацию состоящую из контейнеров и тут уже какраз вся сложность распределенных приложений… И хорошо что там есть конкуренция…
И что выбрать вопсро не легкий…
У само-го руки не доходят…
я в продукции пока польжусь ручными скриптами… но кошусь в сторону 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.
вопрос — а есть ли смысл?

когда томкат приложения в принципе поставляются сами в себе… и иногда даже просто в одном war.

те, если руби требует какие то системные библиотеки — тот же рвм (но с рвм не все всегда гладко), то в этом ключе я понимаю смысл докера.
тоже самое я прекрасно понимаю, если человек пишет на пхп и питоне.

а вот с явой — появился вопрос. ведь ява — это микро виртуалка, насколько я знаю.
Лично моё ИМХО, Джаву тоже упаковывать нужно — уж больно большой зоопарк самих JVM и тот же Tomcat меня своими настройками прав доступа долго удивлял. (Я не пишу код на Java, но меня попросили развернуть один проектик у себя на сервере.)

Ну и вообще, ввиду минимальных накладных расходов на Docker — я вижу только позитивные аспекты его применения (воспроизводимость, переносимость, изолированность и тд).
Как ответил frol смысл есть…
Да конечно яву можно запокавать в джарчик и потом? Копировать руками везде? Можете rpm строить и деплоить… уже неплохо…
Но саму яву с версиями тоже надо провизионировать… все это начинает разростатся…
Вопрос не в яве… А скорее хотите вы связывайтся с контейнерами или нет…
Помотрите немного вперед. Сегодня у вас ява а завтра nginx на fronend, послезавтра redis, потом
экспериментальный сервис на Go и вообще вы решили предоставлять кластеру мэнеджмент контейнеров — где чему бежать и хотите чтоб все это работало в продакшн так-же как на вашем лэптопе…
Вот в этом Докер вам поможет.
Господа.
Присоединяюсь к заданным вопросам выше: как его использовать-то? Не, ну вот правда! Сколько раз хотел попробовать, но как-то не сложилось.
Вот есть желающие, я так себе думаю, заработать +миллион в карму, а? (-:
Вот взять и написать маленький туториал практического использования докера для продакшина…
Предлагаю даже содержание того, что было бы лично мне интересно:
1. на входе — nginx с sticky sessions в качестве балансировщика
2. балансирует он это всё 3-4 копии node-приложения, разнесённых в разные дата-центры, для отказоустойчивости. Для интереса пусть приложения стартуют тоже в nginx+passanger…
3. приложения имеют дело с кластером монги

Вот как это делать без докера — я знаю, а как это всё сделать на докеровских контейнерах и предназначено ли всё это для такого типа задач.
Ну вот честно, совсем без шуток, хочется такой туториал. Может есть что-то подобное в английской версии — буду признателен за ссылку.
ИМХО, вредная статья для изучения, но полезная с точки зрения как делать не надо.
Ужас ужасный, да
Чуть позже в твитере проскочила вот такая статья blog.sunsama.com/meteor-docker-opsworks/
Вот это туториал, вот это значительно лучше.
Ну смотрите, докер может использоваться по типу виртуализации любого типа. В контейнерной виртуализации меньше оверхед чем в полной, выше скорость работы и часто выше удобство администрирования. LXC в мейнлайне, не нужно тянуть отдельные ядра и т.д. (как в ОпенВЗ)

Да, докерные фишки с гитом, возможно, не так часто применимы и скорее для девелоперов могут быть удобными.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.