Чем Docker отличается от виртуальной машины?


3694

Я продолжаю перечитывать документацию Docker, чтобы попытаться понять разницу между Docker и полной виртуальной машиной. Как ему удается обеспечить полную файловую систему, изолированную сетевую среду и т. Д., Не будучи таким тяжелым?

Почему развертывание программного обеспечения в образ Docker (если это правильный термин) проще, чем простое развертывание в согласованной рабочей среде?


11
Анализ производительности Docker и KVM: bodenr.blogspot.com/2014/05/…
HDave

1
Если вы ищете разницу между их изображениями - stackoverflow.com/questions/29096967/…
devesh-ahuja

21
Docker не виртуальная машина - это инструмент управления конфигурацией.
aaa90210

3
Проще говоря: VM -> три виртуальных слоя должны быть запущены, чтобы разрешить запуск вашего приложения, если вы хотите, чтобы виртуализация сервера была в порядке, но если вы хотите только запустить веб-приложение, это не лучшее решение. DOCKER -> Только один слой между вашим настоящим процессором и вашим веб-приложением. Более мощное и лучшее клонирование / зеркалирование, если вам нужно только запустить свое веб-приложение для виртуализации тех, кому я его рекомендую
Davide Castronovo

6
давайте не будем забывать, что Docker для Mac и Docker для Windows используют уровень виртуализации.
Shapeshifter

Ответы:


3435

Изначально Docker использовал контейнеры LinuX (LXC), но позже переключился на runC (ранее известный как libcontainer ), который работает в той же операционной системе, что и его хост. Это позволяет ему совместно использовать много ресурсов операционной системы хоста. Кроме того, он использует многоуровневую файловую систему ( AuFS ) и управляет сетью.

AuFS - это многоуровневая файловая система, поэтому вы можете иметь часть только для чтения и часть записи, которые объединяются вместе. Можно иметь общие части операционной системы только для чтения (и совместно использовать их для всех ваших контейнеров), а затем дать каждому контейнеру собственное монтирование для записи.

Итак, допустим, у вас есть изображение контейнера в 1 ГБ; если вы хотите использовать полную виртуальную машину, вам потребуется 1 ГБ x количество виртуальных машин, которое вы хотите. С Docker и AuFS вы можете разделить большую часть 1 ГБ между всеми контейнерами, и если у вас есть 1000 контейнеров, у вас все еще может быть только чуть более 1 ГБ пространства для ОС контейнеров (при условии, что все они работают под одним и тем же образом ОС) ,

Полностью виртуализированная система получает собственный набор ресурсов, выделенных для нее, и осуществляет минимальное совместное использование. Вы получаете больше изоляции, но она намного тяжелее (требует больше ресурсов). С Docker вы получаете меньшую изоляцию, но контейнеры легки (требуют меньше ресурсов). Таким образом, вы можете легко запустить тысячи контейнеров на хосте, и он даже не будет мигать. Попробуйте сделать это с Xen, и если у вас нет действительно большого хоста, я не думаю, что это возможно.

Полностью виртуализированная система обычно запускается за несколько минут, тогда как контейнеры Docker / LXC / runC занимают секунды, а часто даже меньше секунды.

Есть плюсы и минусы для каждого типа виртуализированной системы. Если вам нужна полная изоляция с гарантированными ресурсами, то вам нужна полная виртуальная машина. Если вы просто хотите изолировать процессы друг от друга и хотите запустить тонну из них на хосте разумного размера, то, похоже, вам подойдет Docker / LXC / runC.

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

Почему развертывание программного обеспечения в образ докера (если это правильный термин) проще, чем простое развертывание в согласованной рабочей среде?

Развертывание согласованной производственной среды легче сказать, чем сделать. Даже если вы используете такие инструменты, как Chef и Puppet , всегда есть обновления ОС и другие вещи, которые меняются между хостами и средами.

Docker дает вам возможность снимать ОС в общий образ и упрощает развертывание на других хостах Docker. Локально, dev, qa, prod и т.д .: все одно и то же изображение. Конечно, вы можете сделать это с помощью других инструментов, но не так легко и быстро.

Это отлично подходит для тестирования; Допустим, у вас есть тысячи тестов, которые необходимо подключить к базе данных, и каждый тест требует первоначальной копии базы данных и внесет изменения в данные. Классический подход к этому состоит в том, чтобы сбрасывать базу данных после каждого теста либо с помощью пользовательского кода, либо с помощью таких инструментов, как Flyway - это может занять очень много времени и означает, что тесты должны выполняться последовательно. Однако с помощью Docker вы можете создать образ вашей базы данных и запустить один экземпляр на тест, а затем запустить все тесты параллельно, поскольку вы знаете, что все они будут работать с одним и тем же снимком базы данных. Поскольку тесты выполняются параллельно и в контейнерах Docker, они могут выполняться одновременно на одном и том же блоке и должны заканчиваться намного быстрее. Попробуйте сделать это с полной виртуальной машиной.

Из комментариев ...

Интересно! Полагаю, меня все еще смущает понятие «снимок ОС». Как это сделать без создания образа ОС?

Что ж, посмотрим, смогу ли я объяснить. Вы начинаете с базового образа, затем вносите свои изменения и фиксируете эти изменения с помощью Docker, и он создает изображение. Это изображение содержит только отличия от базы. Когда вы хотите запустить ваше изображение, вам также нужна база, и она накладывает ваше изображение поверх базы, используя многоуровневую файловую систему: как упоминалось выше, Docker использует AuFS. AuFS объединяет разные слои, и вы получаете то, что хотите; вам просто нужно запустить его. Вы можете продолжать добавлять все больше и больше изображений (слоев), и он будет продолжать сохранять только различия. Поскольку Docker обычно строится поверх готовых образов из реестра , вам редко приходится «снимать» всю ОС самостоятельно.


239
Кен, в некоторых местах вы отождествляете ОС с ядром. Все контейнеры на хосте работают под одним и тем же ядром, но остальные файлы ОС могут быть уникальными для каждого контейнера.
Энди

22
Интересно! Полагаю, меня все еще смущает понятие «снимок ОС». Как это сделать без создания образа ОС?
zslayton

7
@ murtaza52 они добавляют поддержку для различных файловых систем, поэтому уход Aufs не должен быть проблемой. Не уверен, когда будет добавлена ​​32-битная поддержка, не думаю, что спрос был высоким, поэтому в списке приоритетов он низкий, но я могу ошибаться.
Кен Кокрейн

21
@Mike: ... который, несомненно, был вдохновлен тюрьмами FreeBSD HISTORY The jail utility appeared in FreeBSD 4.0.
Стефан Палетта

21
Для тех, кому интересно, на какой комментарий @ Mike мы отвечаем, поскольку он, кажется, был удален, он выглядит следующим образом: <Единственное, чего не хватает, так это ссылки на тот факт, что Linux-контейнеры являются клоном истинного источника вдохновения. : Солярис Контейнеры. Еще в 2004 году ... Это революционная концепция и отличный, отличный способ сделать доступные, размещенные виртуальные машины действительно эффективными. Джойент был первым, кого я знаю ...>
Джеффри 'jf' Лим

559

Хорошие ответы. Просто чтобы получить представление изображения контейнера против VM, взгляните на изображение ниже.

введите описание изображения здесь

Источник


20
<strike> Насколько я понимаю, над "механизмом докеров" должно быть общее ядро ​​Linux. Тогда обычно есть даже общие бины / библиотеки. Сначала идут бины / библиотеки и приложения, специфичные для каждого контейнера. Пожалуйста, поправьте меня, если я ошибаюсь. </ Strike> Я был неправ. Образы Docker делят ядро ​​с хостом, см. Superuser.com/questions/889472/… . Однако, чтобы проиллюстрировать объединенную файловую систему контейнеров, может быть общий слой libs / bins непосредственно над механизмом докера.
Бетамос

13
У меня проблема с изображением выше, потому что гипервизор может быть установлен на голом железе / инфраструктуре, но Docket не может (пока)
reza

@reza, я согласен, что Hypervisor можно установить на Bare metal, но дело в том, что Docker рекомендуется для контейнеризации приложений и как ограничивать или избегать виртуализацию, которая не нужна / не подходит для некоторых сценариев. Кен Кокрейн объясняет это более подробно stackoverflow.com/a/16048358/2478933
manu97

4
Это не проясняет, что такое Docker Engine . Очень абстрактные картинки.
kyb

9
Между контейнером и ядром нет слоя «Docker Engine», контейнер - это просто процесс со специальными настройками в ядре (пространства имен, cgroups и т. Д.)
Павел Пранжак

504

Может быть полезно понять, как виртуализация и контейнеры работают на низком уровне. Это многое прояснит.

Примечание: я немного упрощаю описание ниже. Смотрите ссылки для получения дополнительной информации.

Как работает виртуализация на низком уровне?

В этом случае диспетчер виртуальных машин захватывает кольцо ЦП 0 (или «корневой режим» в более новых процессорах) и перехватывает все привилегированные вызовы, сделанные гостевой ОС, чтобы создать иллюзию того, что гостевая ОС имеет собственное оборудование. Интересный факт: до 1998 года считалось невозможным достичь этого в архитектуре x86, потому что не было никакого способа сделать такой перехват. Люди в VMWare были первыми, кто задумал переписать исполняемые байты в памяти для привилегированных вызовов гостевой ОС, чтобы добиться этого.

В результате виртуализация позволяет запускать две совершенно разные ОС на одном и том же оборудовании. Каждая гостевая ОС проходит весь процесс начальной загрузки, загрузки ядра и т. Д. У вас может быть очень строгая защита, например, гостевая ОС не может получить полный доступ к хост-ОС или другим гостям и испортить ситуацию.

Как контейнеры работают на низком уровне?

Примерно в 2006 году люди, в том числе некоторые сотрудники Google, внедрили новую функцию уровня ядра, называемую пространствами имен (однако эта идея задолго до того существовала во FreeBSD).). Одной из функций ОС является обеспечение совместного использования глобальных ресурсов, таких как сеть и диск, процессам. Что если эти глобальные ресурсы были обернуты в пространства имен, чтобы они были видны только тем процессам, которые выполняются в одном и том же пространстве имен? Скажем, вы можете получить кусок диска и поместить его в пространство имен X, а затем процессы, выполняющиеся в пространстве имен Y, не смогут увидеть или получить к нему доступ. Точно так же процессы в пространстве имен X не могут получить доступ к чему-либо в памяти, которая выделена для пространства имен Y. Конечно, процессы в X не могут видеть или взаимодействовать с процессами в пространстве имен Y. Это обеспечивает своего рода виртуализацию и изоляцию для глобальных ресурсов. Вот как работает Docker: каждый контейнер работает в своем собственном пространстве имен, но использует точно так жеЯдро, как и все другие контейнеры. Изоляция происходит потому, что ядру известно пространство имен, которое было назначено процессу, и во время вызовов API оно обеспечивает доступ к ресурсам только в своем собственном пространстве имен.

Теперь ограничения контейнеров и виртуальных машин должны быть очевидны: вы не можете запускать совершенно разные ОС в контейнерах, как в виртуальных машинах. Однако вы можете использовать разные дистрибутивы Linux, потому что они используют одно и то же ядро. Уровень изоляции не такой сильный, как в ВМ. Фактически, в ранних реализациях для гостевого контейнера был путь к хосту. Также вы можете видеть, что при загрузке нового контейнера вся новая копия ОС запускается не так, как в VM. Все контейнеры имеют одно и то же ядро . Вот почему контейнеры имеют легкий вес. Кроме того, в отличие от ВМ, вам не нужно предварительно выделять значительный кусок памяти для контейнеров, потому что мы не запускаем новую копию ОС. Это позволяет запускать тысячи контейнеров в одной ОС, одновременно помещая их в «песочницу», что может быть невозможно, если бы мы работали с отдельной копией ОС на ее собственной виртуальной машине.


26
Вау, спасибо за отличное объяснение низкого уровня (и исторические факты). Я искал это и не нашел выше. Что вы подразумеваете под «вы можете запускать разные дистрибутивы Linux, потому что они используют одно и то же ядро». ? Вы говорите, что гостевой контейнер должен иметь точно такую ​​же версию ядра Linux, или это не имеет значения? Если это не имеет значения, что если я вызову команду ОС на гостевой, но поддерживается только в гостевом ядре. Или, например, ошибка, исправленная в гостевом ядре, но не в ядре хоста. Все гости проявят ошибку, правильно? Хотя гости были залатаны.
Jeach

7
@Jeach: у контейнеров нет собственного ядра, они совместно используют одно из хостов. Таким образом, вы не можете запускать контейнеры с разными ядрами на одной машине / виртуальной машине.
user276648 26.09.16

2
Вопрос: Вы пишете, что некоторые сотрудники Google были задействованы в ядре пространств имен примерно в 1996 году, но Google не был основан до 1998 года. Вы имели в виду «людей, которые впоследствии станут сотрудниками Google»?
Мартин Гьялдбек

3
@martin - спасибо, что обратили внимание на 2006 год. Также я должен упомянуть, что различные типы пространств имен существовали в Linux с 2002 года, но именно работа в 2006 году заложила основу для контейнеризации. Я обновил ответ со ссылкой.
Шиталь Шах

20
+1 Это должен быть помеченный ответ, в то время как другие ответы дают некоторые пояснения, только объяснение нижнего уровня может прояснить, как работает эта технология, «процессы, сгруппированные в собственное пространство имен = контейнер». Большое вам спасибо, теперь я понял.
Тино Макларен

328

Мне нравится ответ Кена Кокрейна.

Но я хочу добавить дополнительную точку зрения, подробно не освещенную здесь. На мой взгляд, Docker отличается и во всем процессе. В отличие от виртуальных машин, Docker (не только) обеспечивает оптимальное совместное использование ресурсов оборудования, более того, он обеспечивает «систему» ​​для упаковки приложений (предпочтительно, но не обязательно, как набор микросервисов).

Для меня это вписывается в разрыв между инструментами, ориентированными на разработчика, такими как rpm, пакеты Debian , Maven , npm + Git с одной стороны, и инструментами ops, такими как Puppet , VMware, Xen, вы называете это ...

Почему развертывание программного обеспечения в образ докера (если это правильный термин) проще, чем простое развертывание в согласованной рабочей среде?

Ваш вопрос предполагает некоторую согласованную производственную среду. Но как сохранить это последовательным? Рассмотрим некоторое количество (> 10) серверов и приложений, этапов в конвейере.

Чтобы синхронизировать это, вы начнете использовать что-то вроде Puppet, Chef или ваших собственных сценариев инициализации, неопубликованных правил и / или большого количества документации ... Теоретически серверы могут работать неограниченное время и быть полностью согласованными и актуальными. Практика не позволяет полностью управлять конфигурацией сервера, поэтому существуют значительные возможности для отклонения конфигурации и неожиданных изменений в работающих серверах.

Таким образом, существует известный способ избежать этого, так называемый неизменный сервер . Но неизменный шаблон сервера не был любим. Главным образом из-за ограничений виртуальных машин, которые использовались до Docker. Работа с большими изображениями в несколько гигабайт, перемещение этих больших изображений, просто чтобы изменить некоторые области в приложении, было очень и очень трудоемким. Понятный ...

В экосистеме Docker вам никогда не придется перемещаться в гигабайтах при «небольших изменениях» (спасибо aufs и Registry), и вам не нужно беспокоиться о потере производительности, упаковывая приложения в контейнер Docker во время выполнения. Вам не нужно беспокоиться о версиях этого изображения.

И, наконец, вы даже часто сможете воспроизводить сложные производственные среды даже на своем ноутбуке с Linux (не звоните мне, если в вашем случае это не сработает;))

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

PS Между тем Docker использует собственную реализацию "libcontainer" вместо LXC. Но LXC все еще можно использовать.


1
Кажется странным включать git в группу инструментов, таких как rpm и dpkg. Я упоминаю об этом, потому что я вижу, что попытки использовать системы контроля версий, такие как git, как инструмент для распространения / упаковки, вызывают много путаницы.
blitzen9872

2
он не ошибается, однако, git можно использовать для управления пакетами, например, bower внутренне очень удобен для загрузки тегов git.
roo2

2
упаковка приложений в контейнеры - интересный и обоснованный подход. Однако, если вы упаковали его в Docker, это было бы излишним, так как не было бы прямой поддержки зависимостей или каких-либо общих библиотек. Это именно то, чего пытаются достичь новые технологии упаковки, такие как Ubuntu Snap и Flatpak для Redhat. По моему мнению, одна из этих технологий упаковки выиграет и станет будущим упаковки в Linux.
yosefrow

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

@yosefrow разработать "излишний". Проверьте идею и преимущества паттерна «неизменный сервер», конечно, есть некоторые недостатки ... Если вы видите перегиб, не используйте его ..
aholbreich

245

Докер не методология виртуализации. Он опирается на другие инструменты, которые фактически реализуют виртуализацию на основе контейнеров или виртуализацию на уровне операционной системы. Для этого Docker изначально использовал драйвер LXC, затем перешел на libcontainer, который теперь переименован в runc. Docker в основном занимается автоматизацией развертывания приложений внутри контейнеров приложений. Контейнеры приложений предназначены для упаковки и запуска одного сервиса, тогда как системные контейнеры предназначены для запуска нескольких процессов, например, виртуальных машин. Таким образом, Docker рассматривается как инструмент управления контейнерами или развертывания приложений в контейнерных системах.

Чтобы узнать, чем она отличается от других виртуализаций, давайте пройдемся по виртуализации и ее типам. Тогда было бы легче понять, в чем разница.

Виртуализация

В своей задуманной форме он рассматривался как метод логического разделения мэйнфреймов, позволяющий запускать несколько приложений одновременно. Однако сценарий радикально изменился, когда компании и сообщества с открытым исходным кодом смогли предоставить метод обработки привилегированных инструкций тем или иным образом и обеспечить одновременную работу нескольких операционных систем в одной системе на базе x86.

гипервизор

Гипервизор управляет созданием виртуальной среды, в которой работают гостевые виртуальные машины. Он контролирует гостевые системы и обеспечивает выделение ресурсов для гостей по мере необходимости. Гипервизор находится между физической машиной и виртуальными машинами и предоставляет услуги виртуализации виртуальным машинам. Чтобы реализовать это, он перехватывает операции гостевой операционной системы на виртуальных машинах и эмулирует работу в операционной системе хост-машины.

Быстрое развитие технологий виртуализации, прежде всего в облаке, привело к дальнейшему использованию виртуализации, позволяя создавать несколько виртуальных серверов на одном физическом сервере с помощью гипервизоров, таких как Xen, VMware Player, KVM и т. Д., И включение аппаратной поддержки в такие стандартные процессоры, как Intel VT и AMD-V.

Типы виртуализации

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

  • эмуляция
  • Паравиртуализация
  • Контейнерная виртуализация

эмуляция

Эмуляция, также известная как полная виртуализация, полностью запускает ядро ​​ОС виртуальной машины в программном обеспечении. Гипервизор, используемый в этом типе, известен как гипервизор типа 2. Он устанавливается в верхней части операционной системы хоста, которая отвечает за перевод кода ядра гостевой ОС в программные инструкции. Перевод сделан полностью программно и не требует участия оборудования. Эмуляция позволяет запускать любую немодифицированную операционную систему, которая поддерживает эмулируемую среду. Недостатком этого типа виртуализации является дополнительная нагрузка на системные ресурсы, которая приводит к снижению производительности по сравнению с другими типами виртуализаций.

эмуляция

Примеры в этой категории включают VMware Player, VirtualBox, QEMU, Bochs, Parallels и т. Д.

Паравиртуализация

Паравиртуализация, также известная как гипервизор 1-го типа, выполняется непосредственно на аппаратном уровне или «голым железом» и предоставляет услуги виртуализации непосредственно для виртуальных машин, работающих на нем. Это помогает операционной системе, виртуализированному оборудованию и реальному оборудованию сотрудничать для достижения оптимальной производительности. Эти гипервизоры, как правило, занимают довольно мало места и сами по себе не требуют обширных ресурсов.

Примеры в этой категории включают Xen, KVM и т. Д.

Паравиртуализация

Контейнерная виртуализация

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

Контейнерная виртуализация

Концепция контейнера стала возможной благодаря функции пространств имен, добавленной в ядро ​​Linux версии 2.6.24. Контейнер добавляет свой идентификатор для каждого процесса и добавляет новые проверки контроля доступа к каждому системному вызову. Доступ к нему осуществляется клоном () системного вызова который позволяет создавать отдельные экземпляры ранее глобальных пространств имен.

Пространства имен можно использовать по-разному, но наиболее распространенный подход заключается в создании изолированного контейнера, который не имеет видимости или доступа к объектам вне контейнера. Процессы, выполняющиеся внутри контейнера, по-видимому, выполняются в обычной системе Linux, хотя они совместно используют базовое ядро ​​с процессами, расположенными в других пространствах имен, то же самое для других типов объектов. Например, при использовании пространств имен пользователь root внутри контейнера не рассматривается как root вне контейнера, что добавляет дополнительную безопасность.

Подсистема Linux Control Groups (cgroups), следующий основной компонент, обеспечивающий виртуализацию на основе контейнеров, используется для группировки процессов и управления их совокупным потреблением ресурсов. Обычно он используется для ограничения потребления памяти и ЦП контейнерами. Поскольку контейнерная система Linux имеет только одно ядро, а ядро ​​имеет полную видимость в контейнерах, существует только один уровень распределения и планирования ресурсов.

Для контейнеров Linux доступно несколько инструментов управления, включая LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVZ, Docker и т. Д.

Контейнеры против виртуальных машин

В отличие от виртуальной машины, контейнеру не нужно загружать ядро ​​операционной системы, поэтому контейнеры могут быть созданы менее чем за секунду. Эта функция делает виртуализацию на основе контейнеров уникальной и желательной по сравнению с другими подходами к виртуализации.

Поскольку виртуализация на основе контейнеров практически не увеличивает нагрузку на хост-машину, виртуализация на основе контейнеров имеет почти естественную производительность

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

Все контейнеры на хост-машине совместно используют планировщик хост-машины, что экономит потребность в дополнительных ресурсах.

Состояния контейнера (образы Docker или LXC) имеют небольшой размер по сравнению с образами виртуальных машин, поэтому их легко распространять.

Управление ресурсами в контейнерах осуществляется через cgroups. Cgroups не позволяет контейнерам потреблять больше ресурсов, чем выделено им. Однако на данный момент все ресурсы хост-машины видны в виртуальных машинах, но не могут быть использованы. Это может быть реализовано путем бега topили htopна контейнерах и хост - машине одновременно. Выходные данные во всех средах будут выглядеть одинаково.

Обновить:

Как Docker запускает контейнеры в системах, отличных от Linux?

Если контейнеры возможны из-за функций, доступных в ядре Linux, то очевидный вопрос заключается в том, как системы, не являющиеся Linux, запускают контейнеры. Как Docker для Mac, так и Windows используют виртуальные машины Linux для запуска контейнеров. Docker Toolbox используется для запуска контейнеров в виртуальных машинах Virtual Box. Но последняя версия Docker использует Hyper-V в Windows и Hypervisor.framework в Mac.

Теперь позвольте мне подробно описать, как Docker для Mac запускает контейнеры.

Docker для Mac использует https://github.com/moby/hyperkit для эмуляции возможностей гипервизора, а Hyperkit использует hypervisor.framework в своей основе. Hypervisor.framework - это родное гипервизорное решение для Mac. Hyperkit также использует VPNKit и DataKit для пространства имен сети и файловой системы соответственно.

Виртуальная машина Linux, которую Docker запускает в Mac, доступна только для чтения. Тем не менее, вы можете взломать его, запустив:

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty,

Теперь мы можем даже проверить версию ядра этой виртуальной машины:

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux,

Все контейнеры работают внутри этой виртуальной машины.

Есть некоторые ограничения для hypervisor.framework. Из-за этого Docker не раскрывает docker0сетевой интерфейс в Mac. Таким образом, вы не можете получить доступ к контейнерам с хоста. На данный момент docker0доступно только внутри виртуальной машины.

Hyper-v является родным гипервизором в Windows. Они также пытаются использовать возможности Windows 10 для естественного запуска систем Linux.


1
Очень хороший пост. Спасибо огромное! Другой вопрос, который у меня есть, - это то, что я могу создать 32-битный образ docker arm7v на компьютере Mac x86_64. Тем не менее, я не могу собрать тот же образ на Ubuntu, установленном на компьютере x86_64. Это связано с упомянутым вами решением гипервизора Mac?
jiashenC

1
Ваш единственный ответ на вопрос "Как Docker запускает контейнеры в системах, отличных от Linux?" Эту информацию очень трудно найти где-либо. Все подчеркивают, что «контейнеры полностью отличаются от виртуальных машин!», Быстрее, легче и т. Д., Но единственный способ запустить контейнер в системе, отличной от Linux, - это раскрутить виртуальную машину ...!
Богатырь

@Bogatyr IINM, это одна виртуальная машина для всех контейнеров.
Дстромберг

147

В этом посте мы проведем некоторые различия между виртуальными машинами и LXC. Давайте сначала определим их.

ВМ :

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

В этом контексте виртуальная машина называется гостем, а среда, в которой она работает, называется хостом.

LXC s:

Контейнеры Linux (LXC) - это возможности уровня операционной системы, которые позволяют запускать несколько изолированных контейнеров Linux на одном управляющем хосте (хосте LXC). Контейнеры Linux служат легкой альтернативой виртуальным машинам, поскольку они не требуют наличия гипервизоров. Virtualbox, KVM, Xen и др.

Теперь, если вы не были одурманены Аланом (Заком Галифианакисом - из серии «Похмелье») и не были в Вегасе в течение последнего года, вы будете очень осведомлены об огромном всплеске интереса к технологии контейнеров Linux, и если я укажу конкретный один контейнер Проект, который за последние несколько месяцев вызвал оживление во всем мире, - это Докер, который привел к некоторому повторяющемуся мнению, что средам облачных вычислений следует отказаться от виртуальных машин (ВМ) и заменить их контейнерами из-за их меньших издержек и потенциально лучшей производительности.

Но главный вопрос в том, возможно ли это? Будет ли это разумным?

а. LXCs относятся к экземпляру Linux. Это могут быть разные варианты Linux (например, контейнер Ubuntu на хосте CentOS, но это все-таки Linux.) Точно так же контейнеры на основе Windows теперь относятся к экземпляру Windows, если мы посмотрим на виртуальные машины, они имеют более широкую область применения и используют Гипервизоры не ограничиваются операционными системами Linux или Windows.

б. LXC имеют низкие накладные расходы и имеют лучшую производительность по сравнению с виртуальными машинами. Инструменты, а именно Докер, созданный на основе технологии LXC, предоставил разработчикам платформу для запуска своих приложений и в то же время предоставил операционным сотрудникам инструмент, который позволит им развертывать один и тот же контейнер на производственных серверах или в центрах обработки данных. Он пытается сделать взаимодействие между разработчиком, запускающим приложение, загружающим и тестирующим приложение, и оперативным сотрудником, развертывающим это приложение, беспроблемным, потому что именно в этом заключается вся проблема, и цель DevOps - сломать эти бункеры.

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

Отказаться от виртуальных машин на данный момент нецелесообразно. Таким образом, как виртуальные машины, так и LXC имеют свое индивидуальное существование и важность.


4
Ваша часть "b" выше - именно то, что люди Docker говорили о технологии. Он предназначен для упрощения задач разработки и развертывания. И исходя из моего опыта в качестве разработчика и сисопа, я должен согласиться.
WineSoaked

3
Это довольно абстрактный ответ. Нам нужны случаи, когда использовать / не использовать Docker. Вот в чем вопрос. Каждый может найти то, на что похож Docker, но лишь немногие могут объяснить в реальных сценариях.
Иван

1
Докер теперь переносится в мир окон, так как он больше не зависит от LXC: blogs.msdn.com/b/nzdev/archive/2015/06/02/… пожалуйста, поправьте меня, если я неправильно понял ответы здесь
bubakazouba

6
Мне трудно разобраться в части контейнеров «(например, контейнер Ubuntu на хосте Centos, но это все еще Linux)» . Насколько я понимаю, контейнеры разделяют ядро ​​хоста. Например, если у меня есть виртуальная машина с ядром Linux 4.6, у меня есть несколько гостевых виртуальных машин с ядрами Linux 2.4, 2.6, 3.2, 4.1 и 4.4. Если я выполню команды, специфичные для этого ядра, я получу поведение гостевого ядра (а не хоста). Но если мои гостевые виртуальные машины теперь являются контейнерами, будет ли выполненная команда определяться ядром хоста?
Джич

@bubakazouba да. ты прав. Теперь они используют runC
Rumesh Eranga Hapuarachchi

140

Большинство ответов здесь говорят о виртуальных машинах. Я собираюсь дать вам однострочный ответ на этот вопрос, который помог мне больше всего за последние пару лет использования Docker. Это так:

Docker - это просто модный способ запуска процесса, а не виртуальная машина.

Теперь позвольте мне объяснить немного больше о том, что это значит. Виртуальные машины - это их собственные звери. Мне хочется объяснить, что Docker , поможет вам понять это больше, чем объяснение, что такое виртуальная машина. Тем более, что здесь есть много прекрасных ответов, в которых точно сказано, что кто-то имеет в виду, когда говорит «виртуальная машина». Так...

Контейнер Docker - это просто процесс (и его дочерние элементы ), который отделен с помощью cgroups в ядре хост-системы от остальных процессов. На самом деле вы можете видеть процессы контейнера Docker, запустив их ps auxна хосте. Например, запуск apache2«в контейнере» это просто запуск apache2в качестве специального процесса на хосте. Он просто отделен от других процессов на машине. Важно отметить, что ваши контейнеры не существуют вне времени жизни вашего контейнерного процесса. Когда ваш процесс умирает, ваш контейнер умирает. Это потому, что Docker заменяет pid 1внутри вашего контейнера ваше приложение ( pid 1обычно это система init). Это последнее замечание pid 1очень важно.

Что касается файловой системы, используемой каждым из этих процессов контейнера, Docker использует, а затем образы с поддержкой UnionFS , которые вы загружаете, когда делаете a, . Тогда вы можете осмотреться. Все эти каталоги, которые выглядят как длинные хеши, на самом деле являются отдельными слоями. Каждый из них содержит файлы ( ) и метаданные (docker pull ubuntu . Каждое «изображение» - это просто серия слоев и связанных метаданных. Концепция наслоения здесь очень важна. Каждый слой - это просто изменение слоя под ним. Например, когда вы удаляете файл в своем Dockerfile при создании контейнера Docker, вы фактически просто создаете слой поверх последнего слоя, который говорит «этот файл был удален». Кстати, именно поэтому вы можете удалить большой файл из вашей файловой системы, но образ все равно занимает тот же объем дискового пространства. Файл все еще там, в слоях под текущим. Сами слои - это просто архивы файлов. Вы можете проверить это сdocker save --output /tmp/ubuntu.tar ubuntucd /tmp && tar xvf ubuntu.tarlayer.tarjson) с информацией об этом конкретном слое. Эти слои просто описывают изменения в файловой системе, которые сохраняются как слой «поверх» его первоначального состояния. При чтении «текущих» данных файловая система считывает данные так, как будто она просматривает только самые верхние слои изменений. Вот почему файл кажется удаленным, даже если он все еще существует в «предыдущих» слоях, потому что файловая система просматривает только самые верхние слои. Это позволяет совершенно разным контейнерам совместно использовать свои слои файловой системы, даже если некоторые существенные изменения могли произойти с файловой системой на верхних слоях в каждом контейнере. Это может сэкономить вам массу дискового пространства, когда ваши контейнеры совместно используют свои базовые слои изображений. Однако,

Работа в сети в Docker достигается с помощью сетевого моста (вызываемого docker0на хосте) и виртуальных интерфейсов для каждого контейнера на хосте. Это создает виртуальную подсеть docker0для ваших контейнеров, чтобы общаться "между" друг другом. Здесь есть много вариантов сетевого взаимодействия, включая создание пользовательских подсетей для ваших контейнеров и возможность «поделиться» сетевым стеком вашего хоста для прямого доступа вашего контейнера.

Докер движется очень быстро. Его документация - одна из лучших, которые я когда-либо видел. Как правило, оно хорошо написано, сжато и точно. Я рекомендую вам проверить доступную документацию для получения дополнительной информации и доверять документации всему, что вы читаете онлайн, включая переполнение стека. Если у вас есть конкретные вопросы, я настоятельно рекомендую присоединиться #dockerк Freenode IRC и задавать их там (вы даже можете использовать веб-чат Freenode для этого!).


12
«Docker - это просто модный способ запуска процесса, а не виртуальная машина». это отличное резюме, спасибо!
mkorman

Спасибо! В этом заслуга программиста с #dockerканала на Freenode IRC.
L0j1k

Это намного понятнее, чем другие ответы. Я думаю, это аналогия процесса, которая делает это для меня. Это просто снижает уровень абстракции.
Мате Мрше

Я бы добавил: «Docker - это просто модный способ запуска процесса изолированным, защищенным, инкапсулированным способом, а не виртуальной машиной». Хост-система имеет видимость (над процессами и ресурсами) подсистемы, но изолированная система не имеет видимости (над процессами и ресурсами) в хост-системе.
Сохаил Си

87

Docker инкапсулирует приложение со всеми его зависимостями.

Виртуализатор инкапсулирует ОС, которая может запускать любые приложения, которые он обычно может запускать на голой железной машине.


1
Я изучаю LXC, поправьте меня, если я ошибаюсь, но это может быть своего рода virtualenv? но, очевидно, шире, а не только в окружении Python за высказывания
NeoVe

2
Мне нравится этот ответ лучше всего. Это просто и идет прямо в точку. Теперь, когда у вас есть общее представление о том, ЧТО могут сделать LXC и виртуализаторы, подробности из других материалов будут иметь смысл.
Фил

2
@Phil Это произошло после того, как я сначала прочитал подробные ответы выше.
Джонни

Я предполагаю, что они хотят знать, как инкапсулировать. Это большая часть, которая показала бы разницу между ними, но вы не ответили.
Light.G

60

Они оба очень разные. Docker облегчен и использует LXC / libcontainer (который опирается на пространство имен ядра и cgroups) и не имеет эмуляции машины / оборудования, такой как гипервизор, KVM. Ксен, которые тяжелы.

Docker и LXC больше предназначены для песочницы, контейнеризации и изоляции ресурсов. Он использует API-интерфейс клонирования операционной системы хоста (в настоящее время только ядро ​​Linux), который обеспечивает пространство имен для IPC, NS (mount), сети, PID, UTS и т. Д.

А как насчет памяти, ввода-вывода, процессора и т. Д.? Это контролируется с помощью cgroups, где вы можете создавать группы с определенной спецификацией / ограничением ресурсов (ЦП, памяти и т. Д.) И размещать там свои процессы. Помимо LXC, Docker предоставляет серверную часть хранилища ( http://www.projectatomic.io/docs/filesystems/ ), например, объединяющую файловую систему, где вы можете добавлять слои и обмениваться слоями между различными пространствами имен монтирования.

Это мощная функция, при которой базовые образы обычно доступны только для чтения, и только когда контейнер изменяет что-либо в слое, он может что-то записать в раздел для чтения-записи (то есть, копировать при записи). Он также предоставляет множество других оболочек, таких как реестр и управление версиями изображений.

С обычным LXC вам нужно прийти с некоторыми rootfs или поделиться rootfs и, когда они будут общими, изменения отражаются в других контейнерах. Благодаря большому количеству этих дополнительных функций, Docker более популярен, чем LXC. LXC популярен во встраиваемых средах для обеспечения безопасности вокруг процессов, открытых для внешних объектов, таких как сеть и пользовательский интерфейс. Docker популярен в облачной многопользовательской среде, где ожидается стабильная производственная среда.

Обычная виртуальная машина (например, VirtualBox и VMware) использует гипервизор, а связанные технологии либо имеют специальное встроенное ПО, которое становится первым уровнем для первой ОС (хост-ОС, или гостевая ОС 0), либо программное обеспечение, которое запускается на хост-ОС для обеспечить аппаратную эмуляцию, такую ​​как процессор, USB / аксессуары, память, сеть и т. д., для гостевых ОС. Виртуальные машины по-прежнему (по состоянию на 2015 г.) популярны в мультитенантной среде с высоким уровнем безопасности.

Docker / LXC практически можно запустить на любом дешевом оборудовании (если у вас более новое ядро, можно использовать и менее 1 ГБ памяти), тогда как нормальным виртуальным машинам требуется как минимум 2 ГБ памяти и т. Д., Чтобы сделать что-то значимое с ней , Но поддержка Docker на хост-ОС недоступна в таких ОС, как Windows (по состоянию на ноябрь 2014 г.), где могут работать типы виртуальных машин на Windows, Linux и Mac.

Вот картинка из Docker / Rightscale: Вот картинка из правки


34

1. легкий

Это, вероятно, первое впечатление на многих изучающих докер.

Во-первых, образы докеров обычно меньше, чем образы виртуальных машин, поэтому их легко создавать, копировать и передавать.

Во-вторых, контейнеры Docker могут запускаться за несколько миллисекунд, а виртуальная машина запускается за секунды.

2. Многоуровневая файловая система

Это еще одна ключевая особенность Docker. Изображения имеют слои, и разные изображения могут совместно использовать слои, что делает его еще более компактным и ускоряет создание.

Если все контейнеры используют Ubuntu в качестве базовых образов, не каждое изображение имеет собственную файловую систему, но совместно использует одни и те же файлы подчеркивания Ubuntu и отличается только данными своих приложений.

3. Ядро общей ОС

Думайте о контейнерах как о процессах!

Все контейнеры, работающие на хосте, действительно представляют собой набор процессов с разными файловыми системами. Они используют одно и то же ядро ​​ОС, только инкапсулируют системную библиотеку и зависимости.

Это хорошо для большинства случаев (без поддержки дополнительного ядра ОС), но может быть проблемой, если между контейнерами необходима строгая изоляция.

Почему это важно?

Все это похоже на улучшение, а не революцию. Что ж, количественное накопление ведет к качественному преобразованию .

Подумайте о развертывании приложения. Если мы хотим развернуть новое программное обеспечение (сервис) или обновить его, лучше изменить файлы конфигурации и процессы, а не создавать новую виртуальную машину. Поскольку создание виртуальной машины с обновленным сервисом, ее тестирование (совместное использование между Dev & QA), развертывание в производство занимает часы, даже дни. Если что-то пойдет не так, вы должны начать все заново, тратя еще больше времени. Таким образом, используйте инструмент управления конфигурацией (puppet, salttack, chef и т. Д.) Для установки нового программного обеспечения, загрузка новых файлов предпочтительнее.

Когда дело доходит до докера, невозможно использовать вновь созданный контейнер докера для замены старого. Сопровождение намного проще! Создание нового образа, предоставление его в QA, тестирование, развертывание занимает всего несколько минут (если все автоматизировано), в худшем случае - часы. Это называется неизменной инфраструктурой : не поддерживайте (не обновляйте) программное обеспечение, вместо этого создайте новое.

Это меняет способ предоставления услуг. Мы хотим приложения, но должны поддерживать виртуальные машины (что является болью и имеет мало общего с нашими приложениями). Докер заставляет вас сосредоточиться на приложениях и сглаживает все.


27

Docker, в основном контейнеры, поддерживает виртуализацию ОС, т.е. ваше приложение чувствует, что оно имеет полный экземпляр ОС, тогда как виртуальная машина поддерживает аппаратную виртуализацию. . Вы чувствуете, что это физическая машина, на которой вы можете загрузить любую ОС.

В Docker работающие контейнеры совместно используют ядро ​​операционной системы, тогда как в виртуальных машинах они имеют свои собственные файлы ОС. Среда (ОС), в которой вы разрабатываете приложение, будет одинаковой при развертывании его в различных обслуживающих средах, таких как «тестирование» или «производство».

Например, если вы разрабатываете веб-сервер, работающий на порте 4000, при развертывании его в своей «тестовой» среде этот порт уже используется какой-либо другой программой, поэтому он перестает работать. В контейнерах есть слои; все изменения, которые вы внесли в ОС, будут сохранены в одном или нескольких слоях, и эти слои будут частью изображения, поэтому, где бы ни находилось изображение, также будут присутствовать зависимости.

В приведенном ниже примере хост-машина имеет три виртуальные машины. Чтобы обеспечить полную изоляцию приложений в виртуальных машинах, у каждого из них есть свои копии файлов ОС, библиотек и кода приложения, а также полный экземпляр ОС в памяти.Без контейнеров Тогда как на рисунке ниже показан тот же сценарий с контейнерами. Здесь контейнеры просто совместно используют операционную систему хоста, включая ядро ​​и библиотеки, поэтому им не нужно загружать ОС, загружать библиотеки или оплачивать стоимость частной памяти для этих файлов. Единственное добавочное пространство, которое они занимают, - это любая память и дисковое пространство, необходимые для запуска приложения в контейнере. Хотя среда приложения выглядит как выделенная ОС, приложение развертывается точно так же, как и на выделенном хосте. Контейнерное приложение запускается в считанные секунды, и на машине может поместиться гораздо больше экземпляров приложения, чем в случае с виртуальной машиной. введите описание изображения здесь

Источник: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/


Мне очень нравится первый абзац.
Light.G

23

Существуют три различные настройки, которые предоставляют стек для запуска приложения (это поможет нам понять, что такое контейнер и что делает его настолько мощным, чем другие решения):

1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers

1) Традиционный стек серверов состоит из физического сервера, на котором работает операционная система и ваше приложение.

Преимущества:

  • Использование сырьевых ресурсов

  • Изоляция

Недостатки:

  • Очень медленное время развертывания
  • Дорогой
  • Потраченные впустую ресурсы
  • Сложно масштабировать
  • Трудно мигрировать
  • Сложная конфигурация

2) стек виртуальных машин виртуальных машин состоит из физического сервера, на котором работает операционная система, и гипервизора, который управляет вашей виртуальной машиной, общими ресурсами и сетевым интерфейсом. Каждый Vm запускает гостевую операционную систему, приложение или набор приложений.

Преимущества:

  • Хорошее использование ресурсов
  • Легко масштабируется
  • Простое резервное копирование и миграция
  • Эффективность затрат
  • гибкость

Недостатки:

  • Распределение ресурсов проблематично
  • Поставщик блокировки
  • Сложная конфигурация

3) Настройка контейнера , ключевое отличие от другого стека заключается в том, что виртуализация на основе контейнеров использует ядро ​​операционной системы хоста для поиска нескольких изолированных гостевых экземпляров. Эти гостевые экземпляры называются контейнерами. Хост может быть физическим сервером или виртуальной машиной.

Преимущества:

  • Изоляция
  • облегченный
  • Ресурс эффективен
  • Легко мигрировать
  • Безопасность
  • Низкие накладные расходы
  • Зеркальное производство и среда разработки

Недостатки:

  • Та же архитектура
  • Ресурс тяжелых приложений
  • Проблемы с сетью и безопасностью.

Сравнивая настройку контейнера с его предшественниками, мы можем сделать вывод, что контейнеризация - самая быстрая, наиболее эффективная и наиболее безопасная установка, которую мы знаем на сегодняшний день. Контейнеры - это изолированные экземпляры, которые запускают ваше приложение. Docker каким-то образом раскручивает контейнер, слои получают оперативную память с драйверами хранилища по умолчанию (драйверы оверлеев), которые запускаются в течение нескольких секунд, и слоем копирования при записи, созданным поверх него после фиксации в контейнере, который обеспечивает выполнение контейнеры.В случае виртуальных машин это займет около минуты, чтобы загрузить все в среду виртуализации. Эти легкие экземпляры можно легко заменять, перестраивать и перемещать. Это позволяет нам отражать среду производства и разработки и является огромной помощью в процессах CI / CD. Преимущества, которые могут предоставить контейнеры, настолько убедительны, что они определенно здесь, чтобы остаться


Пожалуйста, расскажите, почему это должна быть «самая безопасная настройка» по сравнению с виртуальными машинами.
MKesper

@MKesper: при переходе от устаревшей среды к контейнерной среде у вас есть различные способы построения парадигмы безопасности, основанной на проактивном, а не реактивном подходе к предотвращению вторжений. Это позволяет защитить ваше приложение и среду выполнения на более детальном и детализированном уровне. Они также позволяют выявлять и устранять потенциальные угрозы безопасности до того, как они нарушат ваши рабочие процессы. И возможно объединить статический анализ с ML для автоматизации защиты во время выполнения и применения политик в вашей среде. Отсюда и строка «Самая безопасная настройка».
mohan08p

18

В связи с:-

«Почему развертывание программного обеспечения в образ докера проще, чем простое развертывание в согласованной производственной среде?»

Большая часть программного обеспечения развернута во многих средах, обычно как минимум три из следующих:

  1. Индивидуальные ПК разработчика
  2. Общая среда разработчика
  3. Индивидуальный тестер ПК
  4. Общая тестовая среда
  5. QA среда
  6. Среда UAT
  7. Тестирование нагрузки / производительности
  8. Живая постановка
  9. производство
  10. Архив

Также необходимо учитывать следующие факторы:

  • Разработчики и, в действительности, тестировщики будут иметь тонкие или очень разные конфигурации ПК, в зависимости от характера работы.
  • Разработчики часто могут разрабатывать на ПК вне контроля корпоративных или бизнес-стандартов (например, фрилансеры, которые разрабатывают на своих машинах (часто удаленно), или участники проектов с открытым исходным кодом, которые не «заняты» или «не заключили контракт» для настройки своих ПК определенным образом) путь)
  • Некоторые среды состоят из фиксированного количества нескольких машин в конфигурации с балансировкой нагрузки.
  • Во многих производственных средах облачные серверы динамически (или «упруго») создаются и уничтожаются в зависимости от уровня трафика.

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

Все это означает, что создание согласованных сред, во-первых, достаточно сложно только из-за большого объема (даже в сценарии «зеленого поля»), но поддерживать их согласованность практически невозможно, учитывая большое количество серверов, добавление новых серверов (динамически или вручную), автоматические обновления от поставщиков операционной системы, антивирусных программ, поставщиков браузеров и т. п., ручная установка программного обеспечения или изменения конфигурации, выполненные разработчиками или специалистами по серверам и т. д. Позвольте мне повторить, что это практически (без каламбура) невозможно поддерживать согласованность окружения (хорошо, для пуриста это можно сделать, но это требует огромного количества времени, усилий и дисциплины, именно поэтому в первую очередь были разработаны виртуальные машины и контейнеры (например, Docker)).

Поэтому задумайтесь над своим вопросом следующим образом: «Учитывая чрезвычайную сложность поддержания согласованности всех сред, проще ли развертывать программное обеспечение в образ докера, даже если принять во внимание кривую обучения?» , Я думаю, вы найдете, что ответ неизменно будет «да» - но есть только один способ выяснить, опубликовать этот новый вопрос в переполнении стека.


Итак, если я разверну свой образ докера с 15 различными блоками, которые имеют разные комбинации ОС / версии, все мои образы докера будут работать одинаково?
Теоман Шипахи

@Teomanshipahi Если все эти контейнеры могут использовать одно и то же ядро, предоставленное хостом, да, все они будут работать успешно.
Light.G

Если я использую Docker для Windows на моем локальном компьютере, могу ли я развернуть и запустить таким же образом в Linux / Mac?
Теоман Шипахи

Вещи, которые всегда кажутся неясными, заключаются в том, что все еще существуют зависимости от версии: 1) разработчик должен разрабатывать в той же среде, что и изображение; 2) Среда разработки и среда тестирования должны работать с одинаковыми (или совместимыми) версиями как ядра Linux, так и самого докера ... да?
Богатырь

18

Есть много ответов, которые более подробно объясняют различия, но вот мое очень краткое объяснение.

Одно важное отличие состоит в том, что виртуальные машины используют отдельное ядро ​​для запуска ОС . Вот почему он тяжелый и требует времени для загрузки, потребляя больше системных ресурсов.

В Docker контейнеры делят ядро с хостом; следовательно, он легкий и может быстро запускаться и останавливаться.

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

Docker использует файловую систему UNION . Docker использует технологию копирования при записи, чтобы уменьшить объем памяти, занимаемый контейнерами. Узнайте больше здесь


1
«В виртуализации ресурсы распределяются в начале настройки, и, следовательно, ресурсы используются не полностью, когда виртуальная машина простаивает во многих случаях». Hyper-V имеет понятие динамической памяти, где можно указать минимальное, максимальное и запуск ОЗУ.
Мариуш

15

С виртуальной машиной у нас есть сервер, у нас есть хост-операционная система на этом сервере, а затем у нас есть гипервизор. И затем, работая поверх этого гипервизора, мы имеем любое количество гостевых операционных систем с приложением и его зависимыми двоичными файлами, а также библиотеками на этом сервере. Это приносит целую гостевую операционную систему с этим. Это довольно тяжеловес. Также есть ограничение на то, сколько вы на самом деле можете поставить на каждую физическую машину.

Введите описание изображения здесь

Контейнеры Docker, с другой стороны, немного отличаются. У нас есть сервер. У нас есть операционная система хоста. Но вместо гипервизора у нас есть механизм Docker , в данном случае. В этом случае мы не будем брать с собой целую гостевую операционную систему. Мы представляем очень тонкий слой операционной системы , и контейнер может связываться с хост-ОС, чтобы получить доступ к функциональности ядра. И это позволяет нам иметь очень легкий контейнер.

Все, что у него есть, - это код приложения и все необходимые ему двоичные файлы и библиотеки. И эти двоичные файлы и библиотеки могут фактически использоваться в разных контейнерах, если вы хотите, чтобы они тоже были. И что это позволяет нам делать, это ряд вещей. У них намного быстрее время запуска . Вы не можете встать ни одной виртуальной машины в течение нескольких секунд, как это. И в равной степени, убирая их так быстро, чтобы мы могли очень быстро увеличивать и уменьшать их, и мы рассмотрим это позже.

Введите описание изображения здесь

Каждый контейнер думает, что он работает в своей собственной копии операционной системы. У него есть собственная файловая система, собственный реестр и т. Д., Что является своего рода ложью. Это на самом деле виртуализировано.



11

Я использовал Docker в производственных средах и в постановке очень много. Когда вы привыкнете к этому, вы найдете его очень мощным для построения мультиконтейнера и изолированных сред.

Docker был разработан на основе LXC (Linux Container) и отлично работает во многих дистрибутивах Linux, особенно в Ubuntu.

Контейнеры Docker являются изолированной средой. Это можно увидеть, когда вы вводите topкоманду в контейнере Docker, который был создан из образа Docker.

Кроме того, они очень легкие и гибкие благодаря конфигурации dockerFile.

Например, вы можете создать образ Docker, настроить DockerFile и сказать, что, например, когда он работает, wget 'this', apt-get 'that', запустить 'некоторый сценарий оболочки', установить переменные среды и так далее.

В микросервисных проектах и ​​архитектуре Docker является очень жизнеспособным активом. Docker, Docker Swarm, Kubernetes и Docker Compose позволяют добиться масштабируемости, отказоустойчивости и эластичности.

Еще одна важная проблема, касающаяся Docker, - это Docker Hub и его сообщество. Например, я реализовал экосистему для мониторинга кафки, используя Prometheus, Grafana, Prometheus-JMX-Exporter и Docker.

Для этого я скачал настроенные контейнеры Docker для zookeeper, kafka, Prometheus, Grafana и jmx-collector, затем смонтировал собственную конфигурацию для некоторых из них, используя файлы YAML, или для других, я изменил некоторые файлы и конфигурацию в контейнере Docker, и я Создайте целую систему для мониторинга Кафки с помощью многоконтейнерных докеров на одной машине с изоляцией, масштабируемостью и отказоустойчивостью, благодаря чему эту архитектуру можно легко перенести на несколько серверов.

Помимо сайта Docker Hub есть еще один сайт под названием quay.io, который вы можете использовать, чтобы иметь там свою собственную панель изображений Docker и извлекать / выдвигать к / с нее. Вы даже можете импортировать изображения Docker из Docker Hub в Quay, а затем запускать их из Quay на своем компьютере.

Примечание. Изучение Docker в первую очередь кажется сложным и сложным, но когда вы к нему привыкнете, вы не сможете работать без него.

Я помню первые дни работы с Docker, когда я ошибочно вводил команды или удалял свои контейнеры и все данные и конфигурации.


6

Вот как Docker представляет себя:

Docker - это компания, управляющая движением контейнеров, и единственный поставщик контейнерных платформ, который занимается всеми приложениями в гибридном облаке. Современные предприятия испытывают трудности с цифровым преобразованием, но ограничены существующими приложениями и инфраструктурой, рационализируя все более разнообразный портфель облаков, центров обработки данных и архитектур приложений. Docker обеспечивает подлинную независимость между приложениями и инфраструктурой, а также разработчиками и ИТ-специалистами, чтобы раскрыть их потенциал и создает модель для улучшения сотрудничества и инноваций.

Итак, Docker основан на контейнерах, то есть у вас есть образы и контейнеры, которые можно запустить на вашем текущем компьютере. Он не включает в себя операционную систему, такую ​​как виртуальные машины , но как пакет различных рабочих пакетов, таких как Java, Tomcat и т. Д.

Если вы понимаете контейнеры, вы понимаете, что такое Docker и чем он отличается от виртуальных машин ...

Итак, что такое контейнер?

Образ контейнера - это легкий, автономный исполняемый пакет программного обеспечения, который включает в себя все необходимое для его запуска: код, среду выполнения, системные инструменты, системные библиотеки, настройки. Контейнерное программное обеспечение, доступное как для Linux, так и для Windows, всегда будет работать одинаково, независимо от среды. Контейнеры изолируют программное обеспечение от его окружения, например, различия между средой разработки и промежуточными средами, и помогают уменьшить конфликты между группами, работающими с различным программным обеспечением в одной и той же инфраструктуре.

докер

Итак, как вы видите на изображении ниже, каждый контейнер имеет отдельный пакет и работает на одной машине с общей операционной системой этой машины ... Они безопасны и просты в отправке ...


4

Здесь есть много хороших технических ответов, в которых четко обсуждаются различия между виртуальными машинами и контейнерами, а также происхождение Docker.

Для меня принципиальное различие между виртуальными машинами и Docker заключается в том, как вы управляете продвижением своего приложения.

С помощью виртуальных машин вы продвигаете свое приложение и его зависимости от одной виртуальной машины до следующей DEV, от UAT до PRD.

  1. Часто эти виртуальные машины будут иметь различные патчи и библиотеки.
  2. Часто несколько приложений совместно используют виртуальную машину. Это требует управления конфигурацией и зависимостями для всех приложений.
  3. Отмена требует отмены изменений в ВМ. Или восстановить его, если это возможно.

Идея Docker заключается в том, что вы упаковываете свое приложение в собственный контейнер вместе с необходимыми библиотеками, а затем рекламируете весь контейнер как единое целое.

  1. За исключением ядра патчи и библиотеки идентичны.
  2. Как правило, в каждом контейнере есть только одно приложение, которое упрощает настройку.
  3. Отказ состоит из остановки и удаления контейнера.

Таким образом, на самом фундаментальном уровне с виртуальными машинами вы продвигаете приложение и его зависимости как дискретные компоненты, тогда как с помощью Docker вы продвигаете все в один удар.

И да, есть проблемы с контейнерами, включая управление ими, хотя такие инструменты, как Kubernetes или Docker Swarm, значительно упрощают задачу.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.