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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

гипервизор

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

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

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

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

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

эмулятор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

обновление:

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

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

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

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

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

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty. Теперь мы даже можем проверить версию ядра этой виртуальной машины:

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

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

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

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

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

VM:

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

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

для lxcs:

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

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

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

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

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

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

отказ от VMs на данный момент не практичен. Так как ВМ и LXCs иметь собственное индивидуальное существование и важность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вот фотография из docker / rightscale:

1. Легкий

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

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

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

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

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

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

3. Общее ядро ОС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

плюсы:

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

• изоляции

недостатки:

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

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

плюсы:

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

недостатки:

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

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

плюсы:

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

недостатки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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