How is Docker different from a virtual machine?

docker containers virtual-machine virtualization

668472 просмотра

19 ответа

I keep rereading the Docker documentation to try to understand the difference between Docker and a full VM. How does it manage to provide a full filesystem, isolated networking environment, etc. without being as heavy?

Why is deploying software to a Docker image (if that's the right term) easier than simply deploying to a consistent production environment?

Автор: zslayton Источник Размещён: 13.07.2019 03:08

Ответы (19)


3186 плюса

Решение

Docker originally used LinuX Containers (LXC), but later switched to runC (formerly known as libcontainer), which runs in the same operating system as its host. This allows it to share a lot of the host operating system resources. Also, it uses a layered filesystem (AuFS) and manages networking.

AuFS is a layered file system, so you can have a read only part and a write part which are merged together. One could have the common parts of the operating system as read only (and shared amongst all of your containers) and then give each container its own mount for writing.

So, let's say you have a 1 GB container image; if you wanted to use a full VM, you would need to have 1 GB times x number of VMs you want. With Docker and AuFS you can share the bulk of the 1 GB between all the containers and if you have 1000 containers you still might only have a little over 1 GB of space for the containers OS (assuming they are all running the same OS image).

A full virtualized system gets its own set of resources allocated to it, and does minimal sharing. You get more isolation, but it is much heavier (requires more resources). With Docker you get less isolation, but the containers are lightweight (require fewer resources). So you could easily run thousands of containers on a host, and it won't even blink. Try doing that with Xen, and unless you have a really big host, I don't think it is possible.

A full virtualized system usually takes minutes to start, whereas Docker/LXC/runC containers take seconds, and often even less than a second.

There are pros and cons for each type of virtualized system. If you want full isolation with guaranteed resources, a full VM is the way to go. If you just want to isolate processes from each other and want to run a ton of them on a reasonably sized host, then Docker/LXC/runC seems to be the way to go.

For more information, check out this set of blog posts which do a good job of explaining how LXC works.

Why is deploying software to a docker image (if that's the right term) easier than simply deploying to a consistent production environment?

Deploying a consistent production environment is easier said than done. Even if you use tools like Chef and Puppet, there are always OS updates and other things that change between hosts and environments.

Docker gives you the ability to snapshot the OS into a shared image, and makes it easy to deploy on other Docker hosts. Locally, dev, qa, prod, etc.: all the same image. Sure you can do this with other tools, but not nearly as easily or fast.

This is great for testing; let's say you have thousands of tests that need to connect to a database, and each test needs a pristine copy of the database and will make changes to the data. The classic approach to this is to reset the database after every test either with custom code or with tools like Flyway - this can be very time-consuming and means that tests must be run serially. However, with Docker you could create an image of your database and run up one instance per test, and then run all the tests in parallel since you know they will all be running against the same snapshot of the database. Since the tests are running in parallel and in Docker containers they could run all on the same box at the same time and should finish much faster. Try doing that with a full VM.

From comments...

Interesting! I suppose I'm still confused by the notion of "snapshot[ting] the OS". How does one do that without, well, making an image of the OS?

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

Автор: Ken Cochrane Размещён: 16.04.2013 10:35

478 плюса

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

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

Источник

Автор: manu97 Размещён: 14.10.2015 06:02

416 плюса

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

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

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

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

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

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

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

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

Автор: Shital Shah Размещён: 13.01.2016 01:49

315 плюса

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

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

Автор: aholbreich Размещён: 19.09.2014 04:21

196 плюса

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

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

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

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

гипервизор

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

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

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

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

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

эмуляция

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

эмуляция

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

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

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

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

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

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

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

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

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

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

Подсистема Linux 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.

Автор: Ashish Bista Размещён: 02.04.2016 12:55

139 плюса

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

ВМ :

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

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

LXC s:

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

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

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

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

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

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

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

Автор: Pankaj Arora Размещён: 26.08.2014 07:46

118 плюса

Большинство ответов здесь говорят о виртуальных машинах. Я собираюсь дать вам однострочный ответ на этот вопрос, который помог мне больше всего за последние пару лет использования 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 ubuntuа потом cd /tmp && tar xvf ubuntu.tar. Тогда вы можете осмотреться. Все эти каталоги, которые выглядят как длинные хеши, на самом деле являются отдельными слоями. Каждый из них содержит файлы ( layer.tar) и метаданные (json) с информацией об этом конкретном слое. Эти слои просто описывают изменения в файловой системе, которые сохраняются как слой «поверх» его первоначального состояния. При чтении «текущих» данных файловая система считывает данные так, как будто она просматривает только самые верхние слои изменений. Вот почему файл кажется удаленным, хотя он все еще существует в «предыдущих» слоях, поскольку файловая система просматривает только самые верхние слои. Это позволяет совершенно разным контейнерам совместно использовать свои уровни файловой системы, даже если некоторые существенные изменения могли произойти с файловой системой на верхних слоях в каждом контейнере. Это может сэкономить вам массу дискового пространства, когда ваши контейнеры совместно используют свои базовые слои изображений. Тем не мение,

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

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

Автор: L0j1k Размещён: 04.04.2016 02:35

80 плюса

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

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

Автор: Giovanni De Gasperis Размещён: 27.08.2014 06:25

57 плюса

Они оба очень разные. 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: Вот картинка из правки

Автор: resultsway Размещён: 03.11.2014 05:44

31 плюса

1. легкий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: cizixs Размещён: 10.08.2017 04:25

24 плюса

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

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

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

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

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

Автор: Ali Kahoot Размещён: 09.01.2017 01:22

20 плюса

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

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

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

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

  • Утилизация сырьевых ресурсов

  • изоляция

Недостатки:

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

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

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

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

Недостатки:

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

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

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

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

Недостатки:

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

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

Автор: mohan08p Размещён: 12.02.2017 04:47

17 плюса

В связи с:-

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

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

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

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

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

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

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

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

Автор: Greg Trevellick Размещён: 15.10.2016 11:25

17 плюса

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

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

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

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

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

Автор: Jayabalan Bala Размещён: 11.04.2017 03:20

14 плюса

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

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

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

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

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

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

Автор: Nedzad G Размещён: 21.05.2018 08:22

9 плюса

Я использовал 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 и Dokcer.

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

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

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

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

Автор: Touraj Ebrahimi Размещён: 22.05.2017 03:45

9 плюса

Разница между тем, как приложения в ВМ используют процессор против контейнеров

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

Автор: TastyCode Размещён: 16.07.2018 02:56

6 плюса

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

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

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

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

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

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

докер

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

Автор: Alireza Размещён: 23.05.2018 01:32

4 плюса

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

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

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

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

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

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

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

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

Автор: TJA Размещён: 25.05.2018 11:58
Вопросы из категории :
32x32