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




чем отличается системная виртуальная машина от процессорной (13)

1. Легкий вес

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

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

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

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

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

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

3. Совместное ядро ​​ОС

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

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

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

Почему это имеет значение?

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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


Первоначально 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.

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

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

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

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

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

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

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


Через этот пост мы собираемся провести некоторые различия между виртуальными машинами и 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 есть свое индивидуальное существование и важность.


В связи с:-

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

  • изоляция

Недостатки:

  • Очень медленное время развертывания
  • Дорого
  • Отходы ресурсов
  • Трудно масштабировать
  • Трудно мигрировать
  • Комплексная конфигурация

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

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

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

Недостатки:

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

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

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

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

Недостатки:

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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





virtualization