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


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

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

19   3035  

19 ответов:

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

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

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

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

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

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

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

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

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

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

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

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

интересные! Я полагаю, что меня все еще смущает понятие "snapshot[ting] the OS". Как это сделать без, ну, создания образа ОС?

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

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

enter image description here

Источник:https://www.docker.com/what-container#/package_software

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С. П. между тем Докер использует свою собственную реализацию "libcontainer" вместо команды lxc. Но LXC все еще можно использовать.

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

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

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

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

гипервизор

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

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

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

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

  • эмулятор
  • паравиртуализации
  • виртуализация на основе контейнеров

эмулятор

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

Emulation

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

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

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

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

Paravirtualization

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

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

Container-based virtualization

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

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

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

несколько инструментов управления доступны для контейнеров Linux, включая работы с lxc, LXD По, помощью systemd-nspawn, lmctfy, начальник, Linux и виртуальные серверы, серверы, настройки и т. д.

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

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

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

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

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

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

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

обновление:

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

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

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

Docker для Mac использует https://github.com/moby/hyperkit для эмуляции возможностей гипервизора и Гиперкита используется гипервизор.каркас в своем ядре. Гипервизор.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.

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

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

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

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

VM:

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

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

LXC s:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Docker и LXC предназначены больше для песочницы, контейнеризации и изоляции ресурсов. Он использует приложения для данной операционной системы (на данный момент только ядром Linux) по API клон, который предоставляет пространство имен для МПК, Н. С. (гора), сеть, ПИД, УЦ и т. д.

Что о память, I / O, CPU и т. д.? Это управляется с помощью cgroups, где вы можете создавать группы с определенным ресурсом (CPU, memory и т. д.) спецификация / ограничение и поместите туда свои процессы. В верхней части LXC Docker предоставляет серверную часть хранилища (http://www.projectatomic.io/docs/filesystems/) например, файловая система Union mount, в которой вы можете добавлять слои и совместно использовать слои между различными пространствами имен mount.

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

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

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

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

вот фото из docker / rightscale:Here is a pic from rightscale

1. Легкий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. индивидуальные ПК разработчика
  2. общая среда разработчика
  3. отдельный тестировщик ПК(с)
  4. общая тестовая среда
  5. QA окружающая среда
  6. UAT environment
  7. загрузка / тестирование производительности
  8. видео постановочное
  9. производства
  10. архиве

есть также следующие факторы:

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

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

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

Так что думайте о своем вопросе больше так "учитывая крайнюю трудность обеспечения согласованности всех сред, легче ли развертывать программное обеспечение в образе docker, даже если учитывать кривую обучения ?". Я думаю, что вы найдете ответ неизменно будет "да" - но есть только один способ узнать, опубликовать этот новый вопрос о переполнении стека.

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

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

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

плюсы:

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

  • изоляции

недостатки:

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

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

плюсы:

  • хорошее использование ресурсов
  • легко масштабировать
  • простота резервного копирования и миграции
  • экономичность
  • гибкость

недостатки:

  • ресурс выделение проблематично
  • поставщика
  • сложной конфигурации

3) The Настройка Контейнер, ключевое отличие от других стеков заключается в том, что виртуализация на основе контейнеров использует ядро ОС хоста для rum нескольких изолированных гостевых экземпляров. Эти гостевые экземпляры называются контейнерами. Хост может быть либо физическим сервером, либо ВИРТУАЛЬНАЯ ПАМЯТЬ.

плюсы:

  • изоляции
  • легкий
  • эффективный ресурс
  • легко мигрировать
  • безопасность
  • низкие накладные расходы
  • зеркальная среда производства и разработки

недостатки:

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

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

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

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

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

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

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

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

Enter image description here

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

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

Enter image description here

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

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

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

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

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

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

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

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

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

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

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

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

Это как настройки представляет:

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

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

Если вы понимаете контейнеры, вы получаете то, что докер и как он отличается от VMs...

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

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

Docker

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

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

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

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

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

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

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

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

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

Difference between how apps in VM use cpu vs containers

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