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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

гипервизор

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

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

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

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

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

эмуляция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обновить:

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

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

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

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

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

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

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

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

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

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

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

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

ВМ :

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

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

LXC s:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. легкий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

Недостатки:

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

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

В связи с:-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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