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

avatar
zslayton
16 апреля 2013 в 21:19
820345
21
4082

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

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

Источник
HDave
13 апреля 2016 в 17:39
13

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

devesh-ahuja
5 апреля 2017 в 06:51
1

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

aaa90210
25 мая 2017 в 05:19
31

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

lifeisfoo
7 июля 2017 в 08:50
0

Вы можете найти некоторые интересные факты о реализации и изоляции контейнеров на сайте doger.io.

Davide Castronovo
21 июля 2018 в 09:18
6

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

Shapeshifter
8 мая 2019 в 18:43
20

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

Ed Randall
6 сентября 2019 в 07:57
6

В этой статье Docker-on-Windows сравнивается с Docker-on-Linux, и даются некоторые полезные сведения: collabnix.com/…

reyqueson
6 марта 2020 в 19:06
0

Эластичность и автоматизация

Andy Ray
29 декабря 2020 в 18:17
2

Меня также смутило, почему в образах Docker указано «FROM Ubuntu», если они не работают под управлением ОС. Я записал то, что узнал: blog.andrewray.me/towards-a-strong-mental-model-of-docker

Ответы (21)

avatar
Ken Cochrane
16 апреля 2013 в 22:35
3736

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, они могут выполняться на одном компьютере одновременно и должны завершаться намного быстрее. Попробуйте сделать это с полной виртуальной машиной.

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

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

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

avatar
peterh
26 ноября 2020 в 15:53
-2

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

Факт - это то, что документация Docker понимает под «контейнерами», это паравиртуализация (иногда «виртуализация на уровне ОС») в реальности, в отличие от аппаратной виртуализации, которая является докером. нет.

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

Причина, по которой он стал настолько популярным, заключается в том, что они «дали огонь обычным людям», то есть сделали возможным простое использование типично серверных (= Linux) сред / программных продуктов на Рабочие станции Win10. Это тоже повод для нас терпеть их маленькие «нюансы». Но это не значит, что мы тоже должны этому верить.

Ситуация становится еще более туманной из-за того, что докер на хостах Windows использовал встроенный Linux в HyperV, и его контейнеры работали в нем. Таким образом, докер в Windows использует комбинированное решение для аппаратного обеспечения и паравиртуализации.

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

Spike0xff
3 марта 2021 в 08:02
1

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

peterh
3 марта 2021 в 10:22
0

@ Spike0xff Какие именно утверждения требуют доказательств? Я могу вставить их в пост, но не уверен. Например, любому, кто знает, как работает докер и что такое паравиртуализация, имхо трудно отрицать, что докер является движком паравиртуализации. Сегодня я бы добавил, что этот докер хорош в конфигурируемости и вещах DevOps (например, у вас может быть Dockerfile или compose.yml в вашем дереве git).

avatar
Sulaiman Al-farisi
16 ноября 2020 в 00:50
0

На мой взгляд, это зависит, это видно из потребностей вашего приложения, почему вы решили развернуть приложение в Docker, потому что Docker разбивает приложение на мелкие части в соответствии с его функцией, это становится эффективным, потому что когда одно приложение / функция является ошибка не влияет на другие приложения, в отличие от использования полной vm, он будет медленнее и сложнее по конфигурации, но в некотором смысле безопаснее, чем docker

avatar
TastyCode
16 июля 2018 в 02:56
16

Difference between how apps in VM use cpu vs containers

Источник: Kubernetes в действии.

avatar
TJA
25 мая 2018 в 11:58
7

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

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

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

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

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

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

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

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

avatar
Alireza
23 мая 2018 в 13:32
8

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

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

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

Если вы разбираетесь в контейнерах, вы понимаете, что такое Docker и чем он отличается от VM s ...

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

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

Docker

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

avatar
Nedzad G
21 мая 2018 в 08:22
22

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

Enter image description here

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

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

Enter image description here

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

avatar
cizixs
10 августа 2017 в 04:25
45

1. Легкий

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

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

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

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

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

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

3. Общее ядро ​​ОС

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

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

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

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

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

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

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

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

avatar
Touraj Ebrahimi
22 мая 2017 в 15:45
15

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

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

Контейнеры Docker - это изолированные среды. Вы можете увидеть это, выполнив команду top в контейнере Docker, который был создан из образа Docker.

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

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

В проектах и ​​архитектуре микросервисов 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. контейнер, и я создаю целую систему для мониторинга kafka с использованием многоконтейнерных докеров на одной машине с изоляцией, масштабируемостью и отказоустойчивостью, благодаря чему эту архитектуру можно легко перенести на несколько серверов.

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

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

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

avatar
Jayabalan Bala
11 апреля 2017 в 03:20
23

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

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

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

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

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

Mariusz
11 января 2018 в 15:32
1

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

avatar
mohan08p
12 февраля 2017 в 16:47
30

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

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

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

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

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

  • Изоляция

Недостатки:

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

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

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

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

Недостатки:

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

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

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

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

Недостатки:

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

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

MKesper
11 января 2018 в 09:18
0

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

mohan08p
15 февраля 2018 в 04:21
0

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

avatar
Ali Kahoot
9 января 2017 в 13:22
35

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

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

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

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

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

avatar
Greg Trevellick
15 октября 2016 в 11:25
26

В отношении: -

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

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

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

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

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

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

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

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

Teoman shipahi
10 января 2018 в 19:52
0

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

Light.G
28 сентября 2018 в 05:49
0

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

Teoman shipahi
28 сентября 2018 в 12:42
0

Если я использую докер для Windows на своем локальном компьютере, могу ли я развернуть и запустить таким же образом в linux / mac?

Bogatyr
22 октября 2019 в 19:56
0

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

avatar
L0j1k
4 апреля 2016 в 02:35
170

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

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

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

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

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

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

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

avatar
Ashish Bista
2 апреля 2016 в 00:55
298

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

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

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

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

Гипервизор

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

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

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

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

  • Эмуляция
  • Паравиртуализация
  • Виртуализация на основе контейнеров

Эмуляция

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

Emulation

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

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

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

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

Paravirtualization

Виртуализация на основе контейнеров

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

Container-based virtualization

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

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

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

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

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

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

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

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

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

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

Управление ресурсами в контейнерах осуществляется через контрольные группы. 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 изначально.

andreee
13 сентября 2021 в 14:32
0

+1, очень лаконичный ответ. Но следует отметить / добавить, что с WSL2 и Windows, работающими на «истинном» ядре Linux, Hyper-V больше не требуется, и контейнеры могут работать изначально. Это оказывает заметное влияние, в частности, на производительность.

avatar
Shital Shah
13 января 2016 в 01:49
665

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

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

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

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

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

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

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

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

Jeach
9 июня 2016 в 21:23
39

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

user276648
26 сентября 2016 в 02:08
18

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

David C.
13 июля 2017 в 16:18
6

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

avatar
manu97
14 октября 2015 в 18:02
655

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

enter image description here

Источник

Betamos
5 декабря 2015 в 01:33
25

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

reza
10 июня 2016 в 11:50
16

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

manu97
10 июня 2016 в 17:32
0

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

kyb
15 мая 2017 в 13:22
6

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

Paweł Prażak
14 июня 2017 в 16:54
17

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

lyle
21 июля 2017 в 01:57
2

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

Franck Dernoncourt
10 июня 2018 в 19:49
0

Связанный мета-вопрос о SU, требующий удалить все ответы только с изображениями: Ответы только на видео / изображения

avatar
resultsway
3 ноября 2014 в 17:44
68

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

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

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

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

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

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

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

Вот картинка из docker / rightscale: Here is a pic from rightscale

avatar
aholbreich
19 сентября 2014 в 16:21
354

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

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

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

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

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

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

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

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

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

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

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

blitzen9872
20 апреля 2017 в 22:12
1

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

roo2
24 августа 2017 в 01:21
3

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

yosefrow
25 декабря 2017 в 10:08
3

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

aholbreich
14 февраля 2019 в 14:37
0

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

avatar
Giovanni De Gasperis
27 августа 2014 в 18:25
109

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

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

NeoVe
3 сентября 2015 в 18:35
1

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

Phil
26 октября 2015 в 16:58
2

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

johnny
29 октября 2015 в 20:27
2

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

Light.G
28 сентября 2018 в 05:43
0

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

avatar
Pankaj Arora
26 августа 2014 в 07:46
158

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

VM :

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

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

LXC s:

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

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

Но большой вопрос в том, возможно ли это? будет ли это разумно?

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

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

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

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

WineSoaked
1 октября 2014 в 05:30
4

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

Ivan Voroshilin
15 октября 2014 в 08:43
3

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

bubakazouba
16 ноября 2015 в 05:50
1

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

Jeach
9 июня 2016 в 21:06
6

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