Я продолжаю перечитывать документацию Docker, чтобы попытаться понять разницу между Docker и полноценной виртуальной машиной. Как ему удается обеспечить полную файловую систему, изолированную сетевую среду и т. Д., Не будучи таким тяжелым?
Почему развертывание программного обеспечения в образе Docker (если это правильный термин) проще, чем просто развертывание в согласованной производственной среде?
Первоначально 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 обычно строится на основе готовых образов из реестра, вам редко приходится делать «снимок» всю ОС себе.
Хорошие ответы. Чтобы получить изображение контейнера и виртуальной машины, взгляните на приведенный ниже.
Было бы полезно понять, как виртуализация и контейнеры работают на низком уровне. Это многое прояснит.
Примечание: я немного упрощаю описание ниже. См. Ссылки для получения дополнительной информации.
Как виртуализация работает на низком уровне?
В этом случае диспетчер виртуальных машин берет на себя кольцо ЦП 0 (или корневой режим в новых ЦП) и перехватывает все привилегированные вызовы, сделанные гостевой ОС, чтобы создать иллюзию, что гостевая ОС имеет собственное оборудование. Забавный факт: до 1998 года считалось невозможным добиться этого на архитектуре x86, потому что не было возможности осуществить такой перехват. Ребята из VMware были первыми, у которого возникла идея переписать исполняемые байты в памяти для привилегированных вызовов гостевой ОС, чтобы добиться этого.
В итоге виртуализация позволяет запускать две совершенно разные ОС на одном оборудовании. Каждая гостевая ОС проходит через все процессы начальной загрузки, загрузки ядра и т. Д. Вы можете иметь очень строгую безопасность. Например, гостевая ОС не может получить полный доступ к ОС хоста или другим гостям и все испортить.
Как контейнеры работают на низком уровне?
Примерно 2006 люди, включая некоторых сотрудников компании Google реализовал новую функцию уровня ядра под названием namespaces (однако идея задолго до существовала во FreeBSD). Одна из функций ОС - разрешить совместное использование глобальных ресурсов, таких как сеть и диски, между процессами. Что, если бы эти глобальные ресурсы были заключены в пространства имен, чтобы они были видны только тем процессам, которые выполняются в том же пространстве имен? Скажем, вы можете получить кусок диска и поместить его в пространство имен X, а затем процессы, запущенные в пространстве имен Y, не смогут его увидеть или получить к нему доступ. Точно так же процессы в пространстве имен X не могут получить доступ к чему-либо в памяти, выделенной пространству имен Y. Конечно, процессы в X не могут видеть или взаимодействовать с процессами в пространстве имен Y. Это обеспечивает своего рода виртуализацию и изоляцию для глобальных ресурсов. Вот как работает Docker: каждый контейнер работает в своем собственном пространстве имен, но использует в точности то же ядро, что и все другие контейнеры. Изоляция происходит потому, что ядру известно пространство имен, которое было назначено процессу, и во время вызовов API оно гарантирует, что процесс может получить доступ к ресурсам только в своем собственном пространстве имен.
Ограничения контейнеров по сравнению с виртуальными машинами теперь должны быть очевидны: вы не можете запускать совершенно разные ОС в контейнерах, как в виртуальных машинах. Однако вы можете запускать разные дистрибутивы Linux, потому что они используют одно и то же ядро. Уровень изоляции не такой сильный, как у виртуальной машины. Фактически, в ранних реализациях гостевой контейнер мог взять на себя управление хостом. Также вы можете видеть, что когда вы загружаете новый контейнер, вся новая копия ОС не запускается, как это происходит на виртуальной машине. Все контейнеры используют одно и то же ядро . Вот почему контейнеры легкие. Также, в отличие от виртуальной машины, вам не нужно заранее выделять значительный кусок памяти для контейнеров, потому что мы не запускаем новую копию ОС. Это позволяет запускать тысячи контейнеров в одной ОС при их изолировании, что было бы невозможно, если бы мы запускали отдельные копии ОС на их собственных виртуальных машинах.
Мне нравится ответ Кена Кокрейна.
Но я хочу добавить дополнительную точку зрения, не освещенную здесь подробно. На мой взгляд, Docker отличается и во всем процессе. В отличие от виртуальных машин, Docker не только обеспечивает оптимальное совместное использование ресурсов оборудования, но и предоставляет «систему» для упаковки приложений (желательно, но не обязательно, как набор микросервисов).
Для меня это вписывается в разрыв между инструментами, ориентированными на разработчиков, такими как rpm, пакетами Debian, Maven, npm + Git с одной стороны и инструменты управления, такие как Puppet, VMware, Xen, что угодно ...
Почему развертывание программного обеспечения в образе докера (если это правильный термин) проще, чем просто развертывание в согласованной производственной среде?
Ваш вопрос предполагает наличие согласованной производственной среды. Но как сохранить согласованность? Рассмотрим некоторое количество (> 10) серверов и приложений, этапов в конвейере.
Чтобы синхронизировать это, вы начнете использовать что-то вроде Puppet, Chef или своего собственные сценарии инициализации, неопубликованные правила и / или много документации ... Теоретически серверы могут работать неограниченно долго, при этом они должны быть полностью согласованными и обновленными. Практика не позволяет полностью управлять конфигурацией сервера, поэтому существует значительный простор для дрейфа конфигурации и неожиданных изменений в работающих серверах.
Таким образом, существует известный шаблон, позволяющий избежать этого, так называемый неизменяемый сервер . Но неизменный серверный шаблон не понравился. В основном из-за ограничений виртуальных машин, которые использовались до Docker. Работа с большими изображениями размером в несколько гигабайт, перемещение этих больших изображений, просто для изменения некоторых полей в приложении, было очень трудоемким. Понятно ...
С экосистемой Docker вам никогда не придется перемещать гигабайты при «небольших изменениях» (спасибо aufs и Registry), и вам не нужно беспокоиться о потере производительности из-за упаковки приложений в контейнер Docker во время выполнения. Вам не нужно беспокоиться о версиях этого изображения.
И, наконец, вы даже часто сможете воспроизводить сложные производственные среды даже на своем ноутбуке с Linux (не звоните мне, если в вашем случае это не сработает;))
И, конечно, вы можете запускать контейнеры Docker в виртуальных машинах (это хорошая идея). Уменьшите выделение ресурсов сервера на уровне виртуальных машин. Всем вышеперечисленным может управлять Docker.
P.S. Между тем Docker использует собственную реализацию libcontainer вместо LXC. Но LXC по-прежнему можно использовать.
Docker - это не методология виртуализации. Он полагается на другие инструменты, которые фактически реализуют виртуализацию на основе контейнеров или виртуализацию на уровне операционной системы. Для этого 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 (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 изначально.
В большинстве ответов здесь говорится о виртуальных машинах. Я собираюсь дать вам однострочный ответ на этот вопрос, который больше всего помог мне за последние пару лет использования Docker. Вот это:
Докер - это просто модный способ запустить процесс, а не виртуальную машину.
Теперь позвольте мне подробнее объяснить, что это значит. Виртуальные машины сами по себе зверь. Я чувствую, что объяснение того, что такое Docker, поможет вам понять это больше, чем объяснение того, что такое виртуальная машина. Тем более, что здесь есть много хороших ответов, которые точно рассказывают, что имеют в виду, когда говорят «виртуальная машина». Так...
Контейнер Docker - это просто процесс (и его дочерние элементы), который отделен с помощью cgroups внутри ядра хост-системы от остальной части процессы. Фактически вы можете увидеть процессы контейнера 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!).
#docker на Freenode IRC.
- person L0j1k; 10.12.2017
В этом посте мы проведем некоторые различия между виртуальными машинами и LXC. Давайте сначала определим их.
ВМ:
Виртуальная машина имитирует физическую вычислительную среду, но запросы на ЦП, память, жесткий диск, сетевые и другие аппаратные ресурсы управляются уровнем виртуализации, который транслирует эти запросы на базовое физическое оборудование.
В этом контексте виртуальная машина называется гостевой, а среда, в которой она работает, называется хостом.
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 имеют собственное индивидуальное существование и важность.
Docker инкапсулирует приложение со всеми его зависимостями.
Виртуализатор инкапсулирует ОС, которая может запускать любые приложения, которые он обычно может запускать на голой машине.
Они оба очень разные. Docker легкий и использует LXC / libcontainer (который полагается на пространство имен ядра и контрольные группы) и не имеет эмуляции машины / оборудования, такой как гипервизор, KVM. Xen какие тяжелые.
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: 
Вероятно, это первое впечатление у многих изучающих докеры.
Во-первых, образы докеров обычно меньше, чем образы виртуальных машин, что упрощает сборку, копирование и совместное использование.
Во-вторых, контейнеры Docker могут запускаться за несколько миллисекунд, а виртуальная машина запускается за секунды.
Это еще одна ключевая особенность Docker. У изображений есть слои, а разные изображения могут использовать общие слои, что делает их еще более компактными и более быстрыми для создания.
Если все контейнеры используют Ubuntu в качестве базовых образов, не каждый образ имеет свою собственную файловую систему, но использует одни и те же файлы ubuntu с подчеркиванием и отличается только данными собственного приложения.
Думайте о контейнерах как о процессах!
Все контейнеры, работающие на хосте, действительно представляют собой набор процессов с разными файловыми системами. Они используют одно и то же ядро ОС, только инкапсулируют системную библиотеку и зависимости.
Это хорошо для большинства случаев (без дополнительной поддержки ядра ОС), но может стать проблемой, если между контейнерами необходима строгая изоляция.
Все это похоже на улучшения, а не на революцию. Итак, количественное накопление ведет к качественному преобразованию.
Подумайте о развертывании приложения. Если мы хотим развернуть новое программное обеспечение (службу) или обновить его, лучше изменить файлы конфигурации и процессы, а не создавать новую виртуальную машину. Потому что создание виртуальной машины с обновленным сервисом, ее тестирование (совместное использование между разработчиками и QA), развертывание в производственной среде занимает часы, а то и дни. Если что-то пойдет не так, придется начинать заново, тратя еще больше времени. Итак, используйте инструмент управления конфигурацией (марионетка, солончак, повар и т. Д.) Для установки нового программного обеспечения, предпочтительно загружать новые файлы.
Когда дело доходит до докера, невозможно использовать только что созданный контейнер докера для замены старого. Сопровождение намного проще! Создайте новый образ, поделитесь им с QA, протестируйте его, разверните всего за минуты (если все автоматизировано), в худшем случае - часы. Это называется неизменной инфраструктурой: не поддерживайте (обновляйте) программное обеспечение, вместо этого создайте новое.
Он меняет способ предоставления услуг. Нам нужны приложения, но мы должны поддерживать виртуальные машины (что является проблемой и имеет мало общего с нашими приложениями). Docker заставляет вас сосредоточиться на приложениях и все сглаживает.
Docker, в основном контейнеры, поддерживает виртуализацию ОС, т. Е. Ваше приложение считает, что оно имеет полный экземпляр ОС, тогда как виртуальная машина поддерживает виртуализацию оборудования. Вы чувствуете, что это физическая машина, с которой вы можете загрузить любую ОС.
В 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) Стек виртуальных машин состоит из физического сервера, на котором работает операционная система, и гипервизора, который управляет вашей виртуальной машиной, общими ресурсами и сетевым интерфейсом. Каждая виртуальная машина запускает гостевую операционную систему, приложение или набор приложений.
Преимущества:
Недостатки:
3) Настройка контейнера, ключевое отличие от другого стека заключается в том, что виртуализация на основе контейнеров использует ядро ОС хоста для работы с несколькими изолированными гостевыми экземплярами. Эти гостевые экземпляры называются контейнерами. Хостом может быть физический сервер или виртуальная машина.
Преимущества:
Недостатки:
Сравнивая настройку контейнера с его предшественниками, мы можем сделать вывод, что контейнеризация - это самая быстрая, наиболее ресурсоэффективная и самая безопасная настройка, которую мы знаем на сегодняшний день. Контейнеры - это изолированные экземпляры, запускающие ваше приложение. Docker каким-то образом раскручивает контейнер, слои получают оперативную память с драйверами хранилища по умолчанию (оверлейные драйверы), которые запускаются в течение нескольких секунд, и слой копирования при записи создается поверх него, когда мы фиксируем в контейнере, что обеспечивает выполнение контейнеров. В случае виртуальных машин загрузка всего в виртуальную среду займет около минуты. Эти легкие экземпляры можно легко заменять, перестраивать и перемещать. Это позволяет нам отразить среду производства и разработки и очень помогает в процессах CI / CD. Преимущества, которые могут дать контейнеры, настолько убедительны, что они определенно никуда не денутся.
В связи с:-
«Почему развернуть программное обеспечение в образе докера проще, чем просто развернуть в согласованной производственной среде?»
Большая часть программного обеспечения развертывается во многих средах, обычно как минимум в трех из следующих:
Также следует учитывать следующие факторы:
Как видите, экстраполированное общее количество серверов для организации редко выражается однозначными числами, очень часто - трехзначными и может быть значительно выше.
Все это означает, что создание согласованных сред в первую очередь достаточно сложно из-за большого объема (даже в сценарии с зеленым полем), но сохранить их согласованными практически невозможно, учитывая большое количество серверов, добавление новых серверов (динамически или вручную), автоматические обновления от поставщиков операционных систем, поставщиков антивирусных программ, поставщиков браузеров и т. д., ручная установка программного обеспечения или изменения конфигурации, выполняемые разработчиками или техническими специалистами по серверам и т. д. практически (без каламбура) невозможно поддерживать согласованность сред (хорошо, для пуриста это можно сделать, но это требует огромного количества времени, усилий и дисциплины, именно поэтому виртуальные машины и контейнеры (например, Docker) были разработаны в первое место).
Так что подумайте о своем вопросе как о следующем: «Учитывая чрезвычайную сложность обеспечения единообразия всех сред, проще ли развернуть программное обеспечение в образе докера, даже если принять во внимание кривую обучения?». Я думаю, вы обнаружите, что ответом неизменно будет «да», но есть только один способ узнать это - опубликовать этот новый вопрос в Stack Overflow.
Есть много ответов, которые более подробно объясняют различия, но вот мое очень краткое объяснение.
Одно важное отличие состоит в том, что виртуальные машины используют отдельное ядро для работы ОС. По этой причине он тяжелый и требует времени для загрузки, потребляя больше системных ресурсов.
В Docker контейнеры совместно используют ядро с хостом; следовательно, он легкий и может быстро запускаться и останавливаться.
В виртуализации ресурсы распределяются в начале установки, и, следовательно, ресурсы не используются полностью, когда виртуальная машина много раз простаивает. В Docker контейнерам не выделяется фиксированное количество аппаратных ресурсов, и они могут свободно использовать ресурсы в зависимости от требований и, следовательно, обладают высокой масштабируемостью.
Docker использует UNION File system. Docker использует технологию копирования при записи, чтобы уменьшить объем памяти, занимаемой контейнерами. Подробнее здесь
С виртуальной машиной у нас есть сервер, у нас есть операционная система хоста на этом сервере, а затем у нас есть гипервизор. А затем, работая поверх этого гипервизора, у нас есть любое количество гостевых операционных систем с приложением и зависимыми от него двоичными файлами и библиотеками на этом сервере. Он приносит с собой целую гостевую операционную систему. Достаточно тяжеловесный. Также существует ограничение на количество, которое вы можете поместить на каждую физическую машину.
С другой стороны, контейнеры Docker немного отличаются. У нас есть сервер. У нас есть основная операционная система. Но вместо гипервизора в данном случае используется механизм Docker. В этом случае мы не берем с собой гостевую операционную систему целиком. Мы добавляем очень тонкий слой операционной системы, и контейнер может разговаривать с ОС хоста, чтобы получить доступ к функциям ядра там. И это позволяет нам иметь очень легкий контейнер.
Все, что у него есть, - это код приложения и любые требуемые двоичные файлы и библиотеки. И эти двоичные файлы и библиотеки могут использоваться в разных контейнерах, если вы хотите, чтобы они тоже были. И это позволяет нам делать несколько вещей. У них гораздо более быстрое время запуска. Вы не можете вывести одну виртуальную машину за несколько секунд. И в равной степени, устраняя их так же быстро ... чтобы мы могли очень быстро увеличивать и уменьшать масштаб, и мы рассмотрим это позже.
Каждый контейнер думает, что он работает на собственной копии операционной системы. У него своя файловая система, собственный реестр и т. Д., Что является своего рода ложью. Он фактически виртуализируется.
Источник: Kubernetes в действии.
Я очень много использовал 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, когда я вводил неправильные команды или по ошибке удалял свои контейнеры и все данные и конфигурации.
Вот как представляется Docker:
Docker - это компания, управляющая движением контейнеров, и единственный поставщик контейнерных платформ, который обращается к каждому приложению в гибридном облаке. Сегодняшние предприятия вынуждены проводить цифровую трансформацию, но они ограничены существующими приложениями и инфраструктурой, при этом рационализируя все более разнообразный портфель облаков, центров обработки данных и архитектур приложений. Docker обеспечивает истинную независимость между приложениями и инфраструктурой, разработчиками и ИТ-специалистами, чтобы раскрыть их потенциал и создать модель для лучшего сотрудничества и инноваций.
Итак, Docker основан на контейнерах, что означает, что у вас есть образы и контейнеры, которые можно запускать на вашем текущем компьютере. Он не включает операционную систему, такую как виртуальные машины, а представляет собой набор различных рабочих пакетов, таких как Java, Tomcat и т. Д.
Если вы разбираетесь в контейнерах, вы понимаете, что такое Docker и чем он отличается от ВМ ...
Образ контейнера - это легкий автономный исполняемый пакет программного обеспечения, который включает в себя все необходимое для его запуска: код, среду выполнения, системные инструменты, системные библиотеки, настройки. Контейнерное программное обеспечение, доступное как для приложений Linux, так и для Windows, всегда будет работать одинаково, независимо от среды. Контейнеры изолируют программное обеспечение от его окружения, например различий между средой разработки и промежуточной средой, и помогают уменьшить конфликты между командами, использующими разное программное обеспечение в одной и той же инфраструктуре.
Итак, как вы видите на изображении ниже, каждый контейнер имеет отдельный пакет и работает на одной машине с общей операционной системой этой машины ... Они безопасны и просты в доставке ...
Здесь есть много хороших технических ответов, в которых четко обсуждаются различия между виртуальными машинами и контейнерами, а также происхождение Docker.
Для меня фундаментальное различие между виртуальными машинами и Docker заключается в том, как вы управляете продвижением своего приложения.
С виртуальными машинами вы продвигаете свое приложение и его зависимости от одной виртуальной машины к следующей DEV, UAT и PRD.
Идея Docker состоит в том, что вы объединяете свое приложение в отдельный контейнер вместе с необходимыми ему библиотеками, а затем продвигаете весь контейнер как единое целое.
Таким образом, на самом фундаментальном уровне с виртуальными машинами вы продвигаете приложение и его зависимости как отдельные компоненты, тогда как с Docker вы продвигаете все одним движением.
И да, есть проблемы с контейнерами, включая управление ими, хотя такие инструменты, как Kubernetes или Docker Swarm, значительно упрощают задачу.
На мой взгляд, это зависит, это видно из потребностей вашего приложения, почему вы решили развернуть приложение в Docker, потому что Docker разбивает приложение на мелкие части в соответствии с его функцией, это становится эффективным, потому что, когда одно приложение / функция является ошибкой, оно имеет не влияет на другие приложения, в отличие от использования полной виртуальной машины, он будет медленнее и сложнее по настройке, но в некотором смысле безопаснее, чем докер
Документация докеров (и самообъяснение) проводит различие между виртуальными машинами и контейнерами. У них есть тенденция интерпретировать и использовать вещи несколько необычными способами. Они могут это сделать, потому что это их дело, что они пишут в своей документации, и потому что терминология виртуализации еще не совсем точна.
Факт - это то, что документация Docker понимает в отношении контейнеров, это паравиртуализация (иногда виртуализация на уровне ОС) в реальность, в отличие от аппаратной виртуализации, которой не является докер.
Docker - это низкокачественное решение для паравиртуализации. Различие между контейнером и виртуальной машиной придумано разработчиками докеров, чтобы объяснить серьезные недостатки их продукта.
Причина, по которой он стал настолько популярным, заключается в том, что они подарили огонь обычным людям, т.е. это сделало возможным простое использование типичных серверных (= Linux) сред / программных продуктов на рабочих станциях Win10. Это тоже повод для нас терпеть их маленькие нюансы. Но это не значит, что мы тоже должны этому верить.
Ситуация становится еще более туманной из-за того, что докеры на хостах Windows использовали встроенный Linux в HyperV, и его контейнеры работали в нем. Таким образом, докер в Windows использует комбинированное решение для аппаратного обеспечения и паравиртуализации.
Короче говоря, контейнеры Docker - это некачественные (пара) виртуальные машины с огромным преимуществом и множеством недостатков.
