Я продолжаю перечитывать документацию Docker, чтобы попытаться понять разницу между Docker и полной виртуальной машиной. Как ему удается обеспечить полную файловую систему, изолированную сетевую среду и т.д., Не будучи таким тяжелым?
Почему развертывание программного обеспечения в образ Docker (если это правильный термин) проще, чем простое развертывание в согласованной производственной среде?
Изначально Docker использовал контейнеры LinuX (LXC), но позже переключился на runC (ранее известный как libcontainer), который работает в той же операционной системе, что и его хост. Это позволяет ему совместно использовать много ресурсов операционной системы хоста. Кроме того, он использует многоуровневую файловую систему (AuFS) и управляет сетью.
AuFS - это многоуровневая файловая система, поэтому вы можете иметь часть только для чтения и часть записи, которые объединяются вместе. Можно иметь общие части операционной системы только для чтения (и совместно использовать их для всех ваших контейнеров), а затем дать каждому контейнеру собственное монтирование для записи.
Итак, допустим, у вас есть образ контейнера 1 ГБ; если вы хотите использовать полную виртуальную машину, вам потребуется 1 ГБ, умноженное на количество требуемых виртуальных машин. С 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 обычно строится поверх готовых образов из реестра, вам редко приходится "снимать" всю ОС самостоятельно.
Хорошие ответы. Просто чтобы получить представление изображения контейнера против виртуальной машины, взгляните на изображение ниже.
Возможно, было бы полезно понять, как виртуализация и контейнеры работают на низком уровне. Это прояснит многое.
Примечание. Я немного упрощаю описание ниже. См. Ссылки для получения дополнительной информации.
Как виртуализация работает на низком уровне?
В этом случае диспетчер VM берет процессорное кольцо 0 (или "корневой режим" в новых процессорах) и перехватывает все привилегированные вызовы, сделанные гостевой ОС, чтобы создать иллюзию, что гостевая ОС имеет свое собственное оборудование. Забавный факт: до 1998 года считалось невозможным достичь этого в архитектуре x86, потому что не было никакого способа сделать такой перехват. Люди на VMWare были первыми, у которых была идея переписать исполняемые байты в памяти для привилегированных вызовов гостевой ОС, чтобы достичь этого.
Чистый эффект заключается в том, что виртуализация позволяет вам запускать две совершенно разные ОС на одном и том же оборудовании. Каждая гостевая ОС проходит весь процесс загрузки, загрузки ядра и т.д. У вас может быть очень жесткая безопасность, например, гостевая ОС не может получить полный доступ к ОС хоста или другим гостям и беспорядок.
Как контейнеры работают на низком уровне?
Вокруг 2006, люди, в том числе некоторые из сотрудников Google, внедрили новую функцию уровня ядра, называемую пространствами имен (однако идея long до существует во FreeBSD). Одна из функций ОС - разрешить совместное использование глобальных ресурсов, таких как сеть и диск, для процессов. Что делать, если эти глобальные ресурсы были обернуты в пространствах имен, чтобы они были видны только тем процессам, которые выполняются в одном пространстве имен? Скажем, вы можете получить кусок диска и поместить его в пространство имен X, а затем процессы, запущенные в пространстве имен Y, не могут увидеть или получить к нему доступ. Аналогично, процессы в пространстве имен X не могут получить доступ к чему-либо в памяти, которая распределена для пространства имен Y. Конечно, процессы в X не могут видеть или говорить с процессами в пространстве имен Y. Это обеспечивает вид виртуализации и изоляции для глобальных ресурсов. Вот как работает докер: каждый контейнер работает в своем собственном пространстве имен, но использует точно такое же ядро, как и все другие контейнеры. Изоляция происходит из-за того, что ядро знает пространство имен, которое было назначено процессу, и во время вызовов API он гарантирует, что процесс сможет обращаться к ресурсам только в своем собственном пространстве имен.
Ограничения контейнеров против VM теперь должны быть очевидны: вы не можете запускать совершенно другую ОС в контейнерах, например, в виртуальных машинах. Однако вы можете запускать разные дистрибутивы Linux, потому что они используют одно и то же ядро. Уровень изоляции не такой сильный, как у VM. Фактически, для "гостевого" контейнера был способ захвата узла в ранних реализациях. Также вы можете видеть, что при загрузке нового контейнера вся новая копия ОС запускается не так, как в VM. Все контейнеры используют одно и то же ядро . Вот почему контейнеры легкие. Кроме того, в отличие от виртуальной машины, вам не нужно заранее выделять значительную часть памяти в контейнеры, потому что у нас нет новой копии ОС. Это позволяет запускать тысячи контейнеров на одной ОС, в то время как изолировать их, что может быть невозможно, если мы запускаем отдельную копию ОС в своей собственной виртуальной машине.
Мне нравится ответ Кена Кокрейна.
Но я хочу добавить дополнительную точку зрения, подробно не освещенную здесь. На мой взгляд, 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 все еще можно использовать.
Докер не методология виртуализации. Он опирается на другие инструменты, которые фактически реализуют виртуализацию на основе контейнеров или виртуализацию на уровне операционной системы. Для этого 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. Контейнер добавляет свой идентификатор для каждого процесса и добавляет новые проверки контроля доступа к каждому системному вызову. Доступ к нему осуществляется с помощью системного вызова clone(), который позволяет создавать отдельные экземпляры ранее глобальных пространств имен.
Пространства имен можно использовать по-разному, но наиболее распространенный подход заключается в создании изолированного контейнера, который не имеет видимости или доступа к объектам вне контейнера. Процессы, выполняющиеся внутри контейнера, по-видимому, выполняются в обычной системе 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.
Через этот пост мы собираемся провести некоторые строки различий между виртуальными машинами и LXC. Пусть сначала определите их.
VM
Виртуальная машина эмулирует физическую вычислительную среду, но запросы на процессор, память, жесткий диск, сетевой и другие аппаратные ресурсы управляются уровнем виртуализации, который переводит эти запросы на физическое оборудование.
В этом контексте виртуальная машина вызывается как Гость, а среда, в которой она выполняется, называется хостом.
LXC s:
Контейнеры Linux (LXC) - это операционные системные возможности, позволяющие запускать несколько изолированных контейнеров Linux на одном управляющем хосте (хост LXC). Контейнеры Linux служат легкой альтернативой виртуальным машинам, поскольку они не требуют гипервизоров, а именно. Virtualbox, KVM, Xen и т.д.
Теперь, если вы не были напитаны Аланом (Зак Галифьянакис - из серии "Похмелье" ) и были в Вегасе в прошлом году, вы будете очень осведомлены о огромном волнении интереса к технологиям Linux-контейнеров, и если я буду конкретный проект с одним контейнером, создавший шум в мире за последние несколько месяцев, - Docker, приводящий к некоторым мнимым мнениям о том, что облачные вычислительные среды должны отказаться от виртуальных машин (виртуальных машин) и заменить их контейнерами из-за их более низких накладных расходов и потенциально лучшей производительности.
Но большой вопрос: возможно ли это?, будет ли это разумно?
а. LXCs привязаны к экземпляру Linux. Это может быть разные вкусы Linux (например, контейнер Ubuntu на хосте CentOS, но его все еще Linux.) Точно так же контейнеры на базе Windows теперь привязаны к экземпляру Windows, если мы посмотрим на виртуальные машины, у которых есть довольно широкий охват и с помощью гипервизоры вы не ограничены операционными системами Linux или Windows.
б. LXC имеют низкие накладные расходы и имеют лучшую производительность по сравнению с виртуальными машинами. Инструменты: Docker, которые построены на плечах технологии LXC, предоставили разработчикам платформу для запуска своих приложений и в то же время предоставили возможность людям с помощью инструмента, который позволит им развернуть один и тот же контейнер на производственных серверах или центрах обработки данных. Он пытается сделать опыт между разработчиком, работающим с приложением, загрузкой и тестированием приложения, а лицо, занимающееся операциями, развертывает это приложение без сбоев, потому что именно здесь все трение лежит и цель DevOps заключается в том, чтобы сломать эти силосы.
Таким образом, лучший подход - поставщики облачной инфраструктуры должны защищать соответствующее использование виртуальных машин и LXC, поскольку каждый из них подходит для обработки конкретных рабочих нагрузок и сценариев.
Отказ от виртуальных машин сейчас не является практическим. Таким образом, обе виртуальные машины и LXC имеют свое собственное индивидуальное существование и важность.
В большинстве ответов здесь говорится о виртуальных машинах. Я дам вам ответ на один вопрос на этот вопрос, который помог мне больше всего за последние пару лет использовать Docker. Это:
Docker - просто причудливый способ запуска процесса, а не виртуальная машина.
Теперь позвольте мне объяснить немного больше о том, что это значит. Виртуальные машины - их собственный зверь. Я чувствую, что объясняю, что Docker поможет вам понять это больше, чем объяснить, что такое виртуальная машина. Тем более, что здесь есть много прекрасных ответов, в которых вам точно сказано, что означает кто-то, когда говорят "виртуальная машина". Так что...
Контейнер Docker - это всего лишь процесс (и его дочерние элементы), который разделяется с помощью cgroups внутри ядра хост-системы от остальных процессов. Фактически вы можете увидеть свои процессы контейнера Docker, запустив ps aux на хосте. Например, запуск apache2 "в контейнере" только начинается apache2 как особый процесс на хосте. Он просто был отделен от других процессов на машине. Важно отметить, что ваши контейнеры не существуют за пределами вашего контейнерного процесса. Когда ваш процесс умирает, ваш контейнер умирает. Это потому, что Docker заменяет pid 1 внутри вашего контейнера вашим приложением (pid 1 обычно является системой init). Этот последний вопрос о 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 webchat для этого!).
Docker инкапсулирует приложение со всеми его зависимостями.
Виртуализатор инкапсулирует ОС, которая может запускать любые приложения, которые он обычно может запускать на голой железной машине.
Оба они очень разные. Докер является легким и использует LXC/libcontainer (который полагается на пространство имен ядер и группы) и не имеет эмуляции машинного/аппаратного обеспечения, такого как гипервизор, KVM. Xen, которые тяжелы.
Docker и LXC больше предназначены для изолирования песочницы, контейнеризации и выделения ресурсов. Он использует API-интерфейс хост-OS (в настоящее время только для ядра Linux), который предоставляет пространство имен для IPC, NS (mount), сети, PID, UTS и т.д.
Как насчет памяти, ввода-вывода, процессора и т.д.? Это контролируется с помощью групп, где вы можете создавать группы с определенным ресурсом (ЦП, память и т.д.) Спецификацией/ограничением и размещать там свои процессы. В дополнение к LXC, Docker предоставляет бэкэнд памяти (http://www.projectatomic.io/docs/filesystems/), например, файловая система объединения монтирования, в которой вы можете добавлять слои и обмениваться слоями между различными монтируемыми Пространства имен.
Это мощная функция, в которой базовые изображения обычно читаются только, и только когда контейнер модифицирует что-то на этом слое, он будет писать что-то для чтения-записи раздела (копия a.k.a. при записи). Он также предоставляет множество других оберток, таких как реестр и управление версиями изображений.
С обычным LXC вам нужно приходить с некоторыми rootfs или совместно использовать rootfs и при совместном использовании, а изменения отражаются на других контейнерах. Благодаря множеству этих дополнительных функций Docker более популярен, чем LXC. LXC популярен во встроенных средах для реализации безопасности вокруг процессов, открытых для внешних объектов, таких как сеть и пользовательский интерфейс. Docker популярен в облачной среде с несколькими арендаторами, где ожидается согласованная производственная среда.
Обычная виртуальная машина (например, VirtualBox и VMware) использует гипервизор, а соответствующие технологии либо имеют выделенную прошивку, которая становится первым уровнем для первой ОС (хост-ОС или гостевой ОС 0), либо программным обеспечением, которое работает на ОС хоста для обеспечения эмуляции оборудования, такого как процессор, USB/аксессуары, память, сеть и т.д., гостевой ОС. Виртуальные машины по-прежнему (по состоянию на 2015 год) популярны в среде многопользовательской защиты с высокой степенью защиты.
Docker/LXC может быть запущен на любом дешевом оборудовании (менее 1 ГБ памяти также в порядке, если у вас есть более новое ядро) по сравнению с обычными виртуальными машинами требуется как минимум 2 ГБ памяти и т.д., чтобы сделайте с ним что-нибудь значимое. Но поддержка Docker на ОС хоста недоступна в ОС, такой как Windows (по состоянию на ноябрь 2014 г.), где, как могут типы виртуальных машин могут запускаться на окнах, Linux и Mac.
Вот снимок с docker/rightscale: 
Это, вероятно, первое впечатление для многих учеников докеров.
Во-первых, изображения докеров обычно меньше изображений VM, упрощают сбор, копирование, совместное использование.
Во-вторых, контейнеры Docker могут запускаться через несколько миллисекунд, а VM запускается через несколько секунд.
Это еще одна ключевая особенность Docker. Изображения имеют слои, а разные изображения могут совместно использовать слои, сделать их еще более компактными и быстрее создавать.
Если все контейнеры используют Ubuntu в качестве их базовых изображений, не каждое изображение имеет свою собственную файловую систему, но использует одни и те же основные файлы Ubuntu и только отличается от своих собственных данных приложения.
Подумайте о контейнерах как о процессах!
Все контейнеры, запущенные на узле, действительно представляют собой множество процессов с разными файловыми системами. Они используют одно и то же ядро ОС, только инкапсулируют системную библиотеку и зависимости.
Это хорошо для большинства случаев (без дополнительного ядра ОС), но может быть проблемой, если между контейнерами необходимы строгие изоляторы.
Все это похоже на улучшения, а не на революцию. Ну, количественное накопление приводит к качественной трансформации.
Подумайте о развертывании приложений. Если мы хотим развернуть новое программное обеспечение (услугу) или обновить его, лучше изменить конфигурационные файлы и процессы вместо создания новой виртуальной машины. Поскольку создание виртуальной машины с обновленной услугой, ее тестирование (доля между Dev и QA), развертывание на производство занимает часы, даже дни. Если что-то пойдет не так, вам нужно начать снова, тратя еще больше времени. Таким образом, используйте инструмент управления конфигурацией (кукольный, соляной стол, шеф-повар и т.д.) Для установки нового программного обеспечения, загрузка новых файлов является предпочтительной.
Когда дело доходит до докера, невозможно использовать вновь созданный контейнер докеров, чтобы заменить старый. Поддержание нового образа, совместное использование его с QA, его тестирование, его развертывание занимает всего несколько минут (если все автоматизировано), часы в худшем случае. Это называется неизменяемой инфраструктурой: не поддерживайте (обновлять) программное обеспечение, создавайте вместо него новый.
Он преобразует доставку сервисов. Нам нужны приложения, но они должны поддерживать виртуальные машины (что является болью и мало чем связано с нашими приложениями). Docker позволяет сосредоточиться на приложениях и сглаживать все.
Docker, в основном контейнеры, поддерживает виртуализацию ОС, то есть ваше приложение считает, что оно имеет полный экземпляр ОС, в то время как VM поддерживает аппаратную виртуализацию. Вы чувствуете, что это физическая машина, на которой вы можете загружать любую ОС.
В Docker контейнеры работают совместно с ядром хост-системы, тогда как в виртуальных машинах они имеют свои собственные файлы ОС. Окружение (ОС), в котором вы разрабатываете приложение, будет таким же, когда вы развертываете его в различных средах обслуживания, таких как "тестирование" или "производство".
Например, если вы разрабатываете веб-сервер, который работает на порту 4000, когда вы развертываете его в своей "тестовой" среде, этот порт уже используется какой-либо другой программой, поэтому он перестает работать. В контейнерах есть слои; все изменения, внесенные вами в ОС, будут сохранены в одном или нескольких слоях, и эти слои будут частью изображения, поэтому везде, где изображение будет отображаться, будут присутствовать также.
В приведенном ниже примере хост-машина имеет три виртуальных машины. Чтобы обеспечить приложения в полной изоляции виртуальных машин, у каждого из них есть свои собственные копии файлов ОС, библиотек и кода приложения, а также полный экземпляр операционной системы в памяти. 
В то время как на приведенном ниже рисунке показан один и тот же сценарий с контейнерами. Здесь контейнеры просто обмениваются операционной системой хоста, включая ядро и библиотеки, поэтому им не нужно загружать ОС, загружать библиотеки или оплачивать частную память для этих файлов. Единственное добавочное пространство, которое они берут, это любое пространство памяти и диска, необходимое для запуска приложения в контейнере. В то время как среда приложений выглядит как выделенная ОС, приложение развертывается так же, как и на выделенный хост. Контейнеризованное приложение запускается через несколько секунд, и многие другие экземпляры приложения могут помещаться на машину, чем в случае виртуальной машины.
Источник: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/
Существуют три разные настройки, которые предоставляют стек для запуска приложения (это поможет нам узнать, что такое контейнер и что делает его настолько мощным, как другие решения):
1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers
1) Традиционный сервер состоит из физического сервера, на котором выполняется операционная система и ваше приложение.
Преимущества:
Использование исходных ресурсов
Выделение
Недостатки:
2) стек VM состоит из физического сервера, на котором запущена операционная система и гипервизор, который управляет вашей виртуальной машиной, совместно используемыми ресурсами и сетевым интерфейсом. Каждый Vm запускает гостевую операционную систему, приложение или набор приложений.
Преимущества:
Недостатки:
3) Настройка контейнера, ключевым отличием от другого стека является виртуализация на основе контейнеров, использующая ядро ОС хоста для ромов нескольких изолированных гостевых экземпляров. Эти экземпляры гостей называются контейнерами. Хост может быть либо физическим сервером, либо виртуальной машиной.
<сильные > Преимущества:
Недостатки:
Сравнивая настройку контейнера с его предшественниками, мы можем заключить, что контейнеризация - это самая быстрая, наиболее эффективная с точки зрения ресурсов и наиболее безопасная настройка, которую мы знаем до настоящего времени. Контейнеры - это изолированные экземпляры, которые запускают ваше приложение. Docker разворачивает контейнер в некотором роде, слои получают память времени выполнения с драйверами хранилища по умолчанию (драйверы Overlay), которые запускаются в течение нескольких секунд, и слой с копированием на запись, созданный поверх него, как только мы вставляем в контейнер, выполнение контейнеров. В случае виртуальной машины, которая займет около минуты, чтобы загрузить все в среду виртуализации. Эти легкие экземпляры можно заменить, перестроить и легко перемещать. Это позволяет нам отражать среду производства и разработки и оказывает огромную помощь в процессах CI/CD. Преимущества, которые могут предоставить контейнеры, настолько убедительны, что они определенно здесь, чтобы остаться.
В отношении: -
"Почему развертывание программного обеспечения для изображения докеров проще, чем просто развертывание в последовательную производственную среду?"
Большинство программ развертывается во многих средах, как правило, не менее трех из следующих:
Также необходимо учитывать следующие факторы:
Как вы можете видеть, экстраполированное общее количество серверов для организации редко бывает в виде одиночных цифр, очень часто бывает в тройных числах и может быть значительно ниже.
Все это означает, что создание непротиворечивых сред в первую очередь достаточно сложно только из-за огромного объема (даже в сценарии с зеленым полем), но поддержание их согласованности практически невозможно при большом количестве серверов, добавление новых серверов (динамически или вручную), автоматические обновления от поставщиков o/s, поставщиков антивирусов, поставщиков браузеров и т.п., установки программного обеспечения вручную или изменения конфигурации, выполняемые разработчиками или техниками серверов и т.д. Позвольте мне повторить что - фактически (без каламбура) невозможно поддерживать согласованность среды (хорошо, для пуриста это можно сделать, но это связано с огромным количеством времени, усилий и дисциплины, именно поэтому виртуальные машины и контейнеры (например, Docker) были разработаны в первую очередь).
Итак, подумайте над своим вопросом, как это: "Учитывая чрезвычайную сложность сохранения совместимости всех сред, проще ли развертывать программное обеспечение на изображении докеров, даже учитывая учет кривой обучения?". Я думаю, что вы найдете ответ, который всегда будет "да", но есть только один способ узнать, опубликовать этот новый вопрос в "Переполнение стека".
Есть много ответов, которые объясняют более подробно различия, но вот мое очень краткое объяснение.
Важным отличием является то, что виртуальные машины используют отдельное ядро для запуска ОС. Это причина, по которой она тяжелая и требует времени для загрузки, потребляя больше системных ресурсов.
В Docker контейнеры совместно используют ядро с хостом; следовательно, он легкий и может быстро и быстро запускаться.
В виртуализации ресурсы выделяются в начале настройки, и, следовательно, ресурсы не используются полностью, когда виртуальная машина неактивна в течение многих времен. В Docker контейнеры не выделяются фиксированным количеством аппаратных ресурсов и могут свободно использовать ресурсы в зависимости от требований и, следовательно, очень масштабируемы.
Docker использует UNION файловую систему. Docker использует технологию копирования на запись для сокращения объема памяти, потребляемой контейнерами. Подробнее здесь
С виртуальной машиной у нас есть сервер, у нас есть хост-операционная система на этом сервере, а затем у нас есть гипервизор. И затем, работая поверх этого гипервизора, у нас есть любое количество гостевых операционных систем с приложением и его зависимыми двоичными файлами, а также библиотеками на этом сервере. Это приносит целую гостевую операционную систему с этим. Это довольно тяжеловес. Также есть ограничение на то, сколько вы на самом деле можете поставить на каждую физическую машину.
Контейнеры Docker, с другой стороны, немного отличаются. У нас есть сервер. У нас есть операционная система хоста. Но вместо гипервизора у нас есть механизм Docker, в данном случае. В этом случае мы не будем брать с собой целую гостевую операционную систему. Мы представляем очень тонкий слой операционной системы, и контейнер может связываться с хост-ОС, чтобы получить доступ к функциональности ядра. И это позволяет нам иметь очень легкий контейнер.
Все, что у него есть, - это код приложения и все необходимые ему двоичные файлы и библиотеки. И эти двоичные файлы и библиотеки могут фактически использоваться в разных контейнерах, если вы хотите, чтобы они тоже были. И что это позволяет нам делать, это ряд вещей. У них намного быстрее время запуска. Вы не можете встать ни одной виртуальной машины в течение нескольких секунд, как это. И в равной степени, убирая их так быстро, чтобы мы могли очень быстро увеличивать и уменьшать их, и мы рассмотрим это позже.
Каждый контейнер считает, что он работает на своей собственной копии операционной системы. У него есть собственная файловая система, собственный реестр и т.д., Что является своего рода ложью. Это на самом деле виртуализировано.
Я использовал 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 и Dokcer.
Для этого я скачал настроенные контейнеры Docker для zookeeper, kafka, Prometheus, Grafana и jmx-collector, затем смонтировал свою собственную конфигурацию для некоторых из них, используя файлы yml, или для других, я изменил некоторые файлы и конфигурацию в контейнере Docker и собрал целое Система мониторинга кафки с использованием многоконтейнерных докеров на одной машине с изоляцией, масштабируемостью и отказоустойчивостью, благодаря которой эту архитектуру можно легко перенести на несколько серверов.
Помимо сайта Docker Hub есть еще один сайт под названием quay.io, который вы можете использовать, чтобы иметь там свою собственную панель изображений Docker и извлекать/выдвигать к ней/из нее. Вы даже можете импортировать образы Docker из Docker Hub в Quay, а затем запускать их из Quay на своем компьютере.
Примечание. Изучение Docker в первую очередь кажется сложным и трудным делом, но когда вы к нему привыкнете, вы не сможете работать без него.
Я помню первые дни работы с Docker, когда я ошибочно вводил команды или удалял свои контейнеры и все данные и конфигурации.
Источник: Kubernetes в действии.
Вот как Docker представляет себя:
Docker - это компания, управляющая движением контейнеров, и единственный поставщик контейнерных платформ, который занимается всеми приложениями в гибридном облаке. Сегодняшние предприятия испытывают давление с целью преобразования в цифровом виде, но они ограничены существующими приложениями и инфраструктурой, рационализируя все более разнообразный портфель облаков, центров обработки данных и архитектур приложений. Docker обеспечивает подлинную независимость между приложениями и инфраструктурой, а также разработчиками и ИТ-специалистами, чтобы раскрыть их потенциал и создает модель для улучшения сотрудничества и инноваций.
Итак, Docker основан на контейнерах, то есть у вас есть образы и контейнеры, которые можно запустить на вашем текущем компьютере. Это не включает в себя операционную систему, такую как VM, но как пакет различных рабочих пакетов, таких как Java, Tomcat и т.д.
Если вы понимаете контейнеры, вы получаете, что такое Docker и чем он отличается от виртуальных машин...
Образ контейнера - это легкий, автономный исполняемый пакет программного обеспечения, который включает в себя все необходимое для его запуска: код, среду выполнения, системные инструменты, системные библиотеки, настройки. Контейнерное программное обеспечение, доступное как для Linux, так и для Windows, всегда будет работать одинаково, независимо от среды. Контейнеры изолируют программное обеспечение от его окружения, например, различия между средой разработки и промежуточными средами, и помогают уменьшить конфликты между группами, работающими с различным программным обеспечением в одной и той же инфраструктуре.
Итак, как вы видите на изображении ниже, каждый контейнер имеет отдельный пакет и работает на одной машине с той же операционной системой машины... Они безопасны и просты в отправке...
Здесь есть много хороших технических ответов, в которых четко обсуждаются различия между виртуальными машинами и контейнерами, а также происхождение Docker.
Для меня принципиальная разница между виртуальными машинами и Docker заключается в том, как вы управляете продвижением своего приложения.
С помощью виртуальных машин вы продвигаете свое приложение и его зависимости от одной виртуальной машины до следующей DEV, от UAT до PRD.
Идея Docker заключается в том, что вы упаковываете свое приложение в собственный контейнер вместе с необходимыми библиотеками, а затем рекламируете весь контейнер как единое целое.
Таким образом, на самом фундаментальном уровне с виртуальными машинами вы продвигаете приложение и его зависимости как дискретные компоненты, тогда как с помощью Docker вы продвигаете все в один удар.
И да, есть проблемы с контейнерами, включая управление ими, хотя такие инструменты, как Kubernetes или Docker Swarm, значительно упрощают задачу.
Простой ответ на ваш вопрос: -
Вы хотели знать, разница между виртуальной машиной и докером
Основная концепция: Docker - это виртуализация на основе контейнеров, с помощью которой мы можем создавать контейнеры и развертывать наши приложения в контейнерах. Поэтому основной момент, который следует помнить здесь, - Docker использует одно и то же ядро ОС для запуска "n" количества контейнеров на этом сервере. тогда как если вы используете виртуализацию, вы можете создать "n" количество виртуальных машин (на основе емкости вашего хоста) и установить ОС для этой виртуальной машины, а затем запустить/развернуть приложение на этой виртуальной машине.
Размер и емкость: Если вы создаете виртуальную машину и устанавливаете Linux на этой виртуальной машине, ее базовая настройка, вероятно, будет потреблять около 8-16 мегабайт вашей машины (сам образ Linux составляет от 4 до 6 Гбит) Если вы устанавливаете Docker на своих хостах, вы сможете развернуть контейнер Linux за очень короткое время, и это практически займет 200-500 Мб места вашего хоста.
Время Создание виртуальной машины, установка изображений и готовность виртуальной машины будут выполняться по крайней мере через 1 час (по моему опыту), тогда как Docker может сделать ваш контейнер linux готовым в течение 5-10 минут; гораздо меньше, чем это (учитывая, что у вас хорошая скорость сети)