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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

введите описание изображения здесь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

гипервизор

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

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

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

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

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

эмуляция

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

эмуляция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VM :

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

В этом контексте VM вызывается как Гость, а среда, в которой он работает, называется хостом.

LXC s:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот снимок с dockerы / правкале: Вот фото от прав

1. Легкий вес

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

First, docker images are usually smaller than VM images, makes it easy to build, copy, share.

Second, Docker containers can start in several milliseconds, while VM starts in seconds.

2. Layered File System

This is another key feature of Docker. Images have layers, and different images can share layers, make it even more space-saving and faster to build.

If all containers use Ubuntu as their base images, not every image has its own file system, but share the same underline ubuntu files, and only differs in their own application data.

3. Shared OS Kernel

Think of containers as processes!

All containers running on a host is indeed a bunch of processes with different file systems. They share the same OS kernel, only encapsulates system library and dependencies.

This is good for most cases(no extra OS kernel maintains) but can be a problem if strict isolations are necessary between containers.

Why it matters?

All these seem like improvements, not revolution. Well, quantitative accumulation leads to qualitative transformation .

Think about application deployment. If we want to deploy a new software(service) or upgrade one, it is better to change the config files and processes instead of creating a new VM. Because Creating a VM with updated service, testing it(share between Dev & QA), deploying to production takes hours, even days. If anything goes wrong, you got to start again, wasting even more time. So, use configuration management tool(puppet, saltstack, chef etc.) to install new software, download new files is preferred.

When it comes to docker, it’s impossible to use a newly created docker container to replace the old one. Maintainance is much easier!Building a new image, share it with QA, testing it, deploying it only takes minutes(if everything is automated), hours in the worst case. This is called immutable infrastructure : do not maintain(upgrade) software, create a new one instead.

It transforms how services are delivered. We want applications, but have to maintain VMs(which is a pain and has little to do with our applications). Docker makes you focus on applications and smooths everything.

Docker, basically containers, supports OS virtualization ie your application feels that it has a complete instance of an OS whereas VM supports hardware virtualization . You feel like it is a physical machine in which you can boot any OS.

In Docker, the containers running share the host OS kernel, whereas in VMs they have their own OS files. The environment (the OS) in which you develop an application would be same when you deploy it to various serving environments, such as “testing” or “production”.

For example, if you develop a web server that runs on port 4000, when you deploy it to your “testing” environment, that port is already used by some other program, so it stops working. In containers there are layers; all the changes you have made to the OS would be saved in one or more layers and those layers would be part of image, so wherever the image goes the dependencies would be present as well.

In the example shown below, the host machine has three VMs. In order to provide the applications in the VMs complete isolation, they each have their own copies of OS files, libraries and application code, along with a full in-memory instance of an OS. Without Containers Whereas the figure below shows the same scenario with containers. Here, containers simply share the host operating system, including the kernel and libraries, so they don’t need to boot an OS, load libraries or pay a private memory cost for those files. The only incremental space they take is any memory and disk space necessary for the application to run in the container. While the application’s environment feels like a dedicated OS, the application deploys just like it would onto a dedicated host. The containerized application starts in seconds and many more instances of the application can fit onto the machine than in the VM case. введите описание изображения здесь

Source: https://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/

In relation to:-

“Why is deploying software to a docker image easier than simply deploying to a consistent production environment ?”

Most software is deployed to many environments, typically a minimum of three of the following:

  1. Individual developer PC(s)
  2. Shared developer environment
  3. Individual tester PC(s)
  4. Shared test environment
  5. QA environment
  6. UAT environment
  7. Load / performance testing
  8. Live staging
  9. производство
  10. Архив

There are also the following factors to consider:

  • Developers, and indeed testers, will all have either subtlely or vastly different PC configurations, by the very nature of the job
  • Developers can often develop on PCs beyond the control of corporate or business standardisation rules (eg freelancers who develop on their own machines (often remotely) or contributors to open source projects who are not ’employed’ or ‘contracted’ to configure their PCs a certain way)
  • Some environments will consist of a fixed number of multiple machines in a load balanced configuration
  • Many production environments will have cloud-based servers dynamically (or ‘elastically’) created and destroyed depending on traffic levels

As you can see the extrapolated total number of servers for an organisation is rarely in single figures, is very often in triple figures and can easily be significantly higher still.

This all means that creating consistent environments in the first place is hard enough just because of sheer volume (even in a green field scenario), but keeping them consistent is all but impossible given the high number of servers, addition of new servers (dynamically or manually), automatic updates from o/s vendors, anti-virus vendors, browser vendors and the like, manual software installs or configuration changes performed by developers or server technicians, etc. Let me repeat that – it’s virtually (no pun intended) impossible to keep environments consistent (okay, for the purist, it can be done, but it involves a huge amount of time, effort and discipline, which is precisely why VMs and containers (eg Docker) were devised in the first place).

So think of your question more like this “Given the extreme difficulty of keeping all environments consistent, is it easier to deploying software to a docker image, even when taking the learning curve into account ?” , I think you’ll find the answer will invariably be “yes” – but there’s only one way to find out, post this new question on Stack Overflow.

There are three different setups that providing a stack to run an application on (This will help us to recognize what a container is and what makes it so much powerful than other solutions):

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

1) Traditional server stack consist of a physical server that runs an operating system and your application.

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

  • Utilization of raw resources

  • изоляция

Недостатки:

  • Very slow deployment time
  • Expensive
  • Wasted resources
  • Difficult to scale
  • Difficult to migrate
  • Complex configuration

2) The VM stack consist of a physical server which runs an operating system and a hypervisor that manages your virtual machine, shared resources, and networking interface. Each Vm runs a Guest Operating System, an application or set of applications.

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

  • Good use of resources
  • Easy to scale
  • Easy to backup and migrate
  • Cost efficiency
  • Flexibility

Недостатки:

  • Resource allocation is problematic
  • Vendor lockin
  • Complex configuration

3) The Container Setup , the key difference with other stack is container-based virtualization uses the kernel of the host OS to rum multiple isolated guest instances. These guest instances are called as containers. The host can be either a physical server or VM.

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

  • изоляция
  • облегченный
  • Resource effective
  • Easy to migrate
  • Безопасность
  • Low overhead
  • Mirror production and development environment

Недостатки:

  • Same Architecture
  • Resource heavy apps
  • Networking and security issues.

By comparing the container setup with its predecessors, we can conclude that containerization is the fastest, most resource effective, and most secure setup we know to date. Containers are isolated instances that run your application. Docker spin up the container in a way, layers get run time memory with default storage drivers(Overlay drivers) those run within seconds and copy-on-write layer created on top of it once we commit into the container, that powers the execution of containers. In case of VM’s that will take around a minute to load everything into the virtualize environment. These lightweight instances can be replaced, rebuild, and moved around easily. This allows us to mirror the production and development environment and is tremendous help in CI/CD processes. The advantages containers can provide are so compelling that they’re definitely here to stay.

There are many answers which explain more detailed on the differences, but here is my very brief explanation.

One important difference is that VMs use a separate kernel to run the OS . That’s the reason it is heavy and takes time to boot, consuming more system resources.

In Docker, the containers share the kernel with the host; hence it is lightweight and can start and stop quickly.

In Virtualization, the resources are allocated in the beginning of set up and hence the resources are not fully utilized when the virtual machine is idle during many of the times. In Docker, the containers are not allocated with fixed amount of hardware resources and is free to use the resources depending on the requirements and hence it is highly scalable.

Docker uses UNION File system .. Docker uses a copy-on-write technology to reduce the memory space consumed by containers. Подробнее здесь

With a virtual machine , we have a server, we have a host operating system on that server, and then we have a hypervisor. And then running on top of that hypervisor, we have any number of guest operating systems with an application and its dependent binaries, and libraries on that server. It brings a whole guest operating system with it. It’s quite heavyweight. Also there’s a limit to how much you can actually put on each physical machine.

Введите описание изображения здесь

Docker containers on the other hand, are slightly different. We have the server. We have the host operating system. But instead a hypervisor , we have the Docker engine , in this case. In this case, we’re not bringing a whole guest operating system with us. We’re bringing a very thin layer of the operating system , and the container can talk down into the host OS in order to get to the kernel functionality there. And that allows us to have a very lightweight container.

All it has in there is the application code and any binaries and libraries that it requires. And those binaries and libraries can actually be shared across different containers if you want them to be as well. And what this enables us to do, is a number of things. They have much faster startup time . You can’t stand up a single VM in a few seconds like that. And equally, taking them down as quickly.. so we can scale up and down very quickly and we’ll look at that later on.

Введите описание изображения здесь

Every container thinks that it’s running on its own copy of the operating system. It’s got its own file system, own registry, etc. which is a kind of a lie. It’s actually being virtualized.

I have used Docker in production environments and staging very much. When you get used to it you will find it very powerful for building a multi container and isolated environments.

Docker has been developed based on LXC (Linux Container) and works perfectly in many Linux distributions, especially Ubuntu.

Docker containers are isolated environments. You can see it when you issue the top command in a Docker container that has been created from a Docker image.

Besides that, they are very light-weight and flexible thanks to the dockerFile configuration.

For example, you can create a Docker image and configure a DockerFile and tell that for example when it is running then wget ‘this’, apt-get ‘that’, run ‘some shell script’, setting environment variables and so on.

In micro-services projects and architecture Docker is a very viable asset. You can achieve scalability, resiliency and elasticity with Docker, Docker swarm, Kubernetes and Docker Compose.

Another important issue regarding Docker is Docker Hub and its community. For example, I implemented an ecosystem for monitoring kafka using Prometheus, Grafana, Prometheus-JMX-Exporter, and Dokcer.

For doing that I downloaded configured Docker containers for zookeeper, kafka, Prometheus, Grafana and jmx-collector then mounted my own configuration for some of them using yml files or for others I changed some files and configuration in the Docker container and I build a whole system for monitoring kafka using multi-container Dockers on a single machine with isolation and scalability and resiliency that this architecture can be easily moved into multiple servers.

Besides the Docker Hub site there is another site called quay.io that you can use to have your own Docker images dashboard there and pull/push to/from it. You can even import Docker images from Docker Hub to quay then running them from quay on your own machine.

Note: Learning Docker in the first place seems complex and hard, but when you get used to it then you can not work without it.

I remember the first days of working with Docker when I issued the wrong commands or removing my containers and all of data and configurations mistakenly.

This is how Docker introduces itself:

Docker is the company driving the container movement and the only container platform provider to address every application across the hybrid cloud. Today’s businesses are under pressure to digitally transform but are constrained by existing applications and infrastructure while rationalizing an increasingly diverse portfolio of clouds, datacenters and application architectures. Docker enables true independence between applications and infrastructure and developers and IT ops to unlock their potential and creates a model for better collaboration and innovation.

So Docker is container based, meaning you have images and containers which can be run on your current machine. It’s not including the operating system like VM s, but like a pack of different working packs like Java, Tomcat, etc.

If you understand containers, you get what Docker is and how it’s different from VM s…

So, what’s a container?

A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings. Available for both Linux and Windows based apps, containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings, for example differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.

Docker

So as you see in the image below, each container has a separate pack and running on a single machine share that machine’s operating system… They are secure and easy to ship…

There are a lot of nice technical answers here that clearly discuss the differences between VMs and containers as well as the origins of Docker.

For me the fundamental difference between VMs and Docker is how you manage the promotion of your application.

With VMs you promote your application and its dependencies from one VM to the next DEV to UAT to PRD.

  1. Often these VM’s will have different patches and libraries.
  2. It is not uncommon for multiple applications to share a VM. This requires managing configuration and dependencies for all the applications.
  3. Backout requires undoing changes in the VM. Or restoring it if possible.

With Docker the idea is that you bundle up your application inside its own container along with the libraries it needs and then promote the whole container as a single unit.

  1. Except for the kernel the patches and libraries are identical.
  2. As a general rule there is only one application per container which simplifies configuration.
  3. Backout consists of stopping and deleting the container.

So at the most fundamental level with VMs you promote the application and its dependencies as discrete components whereas with Docker you promote everything in one hit.

And yes there are issues with containers including managing them although tools like Kubernetes or Docker Swarm greatly simplify the task.

Difference between how apps in VM use cpu vs containers

Source: Kubernetes in Action.

I think this should be the basis of understanding all other answers and extra information linked.

Honestly, we cannot compare docker to VM. From all answers before me, many of them have already shown such a point. But they still failed to say it out specifically.

To compare one thing to another, they must have the similar position or functionality, in their field at least.

Below I come up with a rough pair list which includes all concept/software I know. I will appreciate it if someone could make it up for all of us. Благодаря!

Docker — VMWare
libcontainer/runc — hypervisor
Docker image — VM OS image
Docker container — VM/virtual machine

Hope this would help all of you. From my opinion, Docker is a tool(based on libcontainer/runc) that could somehow carry kernel instructions to multiple containers. VMWare is a tool (based on hypervisor) that could somehow carry hardware instructions to multiple virtual machine instances.

Вот и все.

Давайте будем гением компьютера.