VM или Docker?

Как понять, что вам нужен Docker, а не VM? Давайте попытаемся разобраться в основных отличиях изоляции виртуальных машин (VM) и Docker-контейнеров, могут ли они быть взаимозаменяемы и как мы можем их использовать.


Так в чём же отличие Docker-контейнеров от VM?
Виртуальная машина (VM) — это виртуальный компьютер со всеми виртуальными устройствами и виртуальным жёстким диском, на который и устанавливается новая независимая ОС (гостевая ОС) вместе с виртуальными драйверами устройств, управлением памятью и другими компонентами. Т. е. мы получаем абстракцию физического оборудования, позволяющую запускать на одном компьютере множество виртуальных компьютеров. Виртуальное оборудование отображается в свойствах системы, а установленные приложения взаимодействуют с ним как с настоящим. При этом сама виртуальная машина полностью изолирована от реального компьютера, хотя и может иметь доступ к его диску и периферийным устройствам.
Установленная VM может по-разному занимать место на диске компьютера:


  • фиксированное место на жёстком диске, что позволяет осуществлять более быстрый доступ к виртуальному жёсткому диску и позволяет избежать фрагментации файла;
  • динамическое выделение памяти. При установке дополнительных приложений память будет динамически выделяться под них, пока не достигнет максимального объема, отведенного ей.

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


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


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


Docker наиболее распространенная технология использования контейнеров в работе приложения. Он стал стандартом в этой области, строясь на основе cgroups и пространстве имён, которые обеспечивает ядро Linux. Нативной ОС для Docker является Linux, поэтому запуск Docker-контейнеров на Windows будет происходить внутри виртуальной машины с ОС Linux.


Из чего создаётся контейнер?


Образ — основной элемент, из которого создаются контейнеры. Образ создаётся из Dockerfile, добавленного в проект и представляет собой набор файловых систем (слоёв) наслоённых друг на друга и сгруппированных вместе, доступных только для чтения; максимальное число слоёв равно 127.


В основе каждого образа находится базовый образ, который указывается командой FROM — входная точка при формировании образа Dockerfile. Каждый слой является readonly-слоем и представлен одной командой, модифицирующей файловую систему, записанной в Dockerfile. Данный подход позволяют разным файлам и директориям из разных файловых слоёв прозрачно накладываться, создавая каскадно-объединённую файловую систему. Слои содержат метаданные, позволяющие сохранять сопутствующую информацию о каждом слое во время выполнения и сборки. Каждый слой содержит ссылку на следующий слой, если слой не имеет ссылки, значит это самый верхний слой в образе.
Начиная с версии Docker EE 17.06.02-ee5 и в Docker Engine — Community используется Overlay2 или Overlay, в более ранних версиях используется AuFS (Advanced multi layered Union file system).


Контейнер — как это работает?


Контейнер — это абстракция на уровне приложения, объединяющая код и зависимости. Контейнеры всегда создаются из образов, добавляя доступный для записи верхний слой и инициализирует различные параметры. Т. к. контейнер имеет свой собственный слой для записи и все изменения сохраняются в этом слое, несколько контейнеров могут совместно использовать доступ к одному и тому же образу. Каждый контейнер можно настроить через файл в проекте docker-compose.yml, задавая различные параметры, такие как имя контейнера, порты, идентификаторы, зависимости между другими контейнерами. Если в настройках не задавать имя контейнера, то Docker каждый раз будет создавать новый контейнер, присваивая ему имя случайным образом.


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


Как работает каскадно-объединённая файловая система?


Каскадно-объединённая файловая система (ФС) реализует механизм копирования при записи (Copy-On-Write, COW). Рабочей единицей является слой, каждый слой следует рассматривать как отдельную полноценную файловую систему с иерархией директорий от самого корня. Данный подход использует объединенное монтирование файловых систем, позволяя, прозрачно для пользователя, объединять файлы и каталоги различных файловых систем (называемых ветвями) в единую связанную файловую систему. Содержимое каталогов с одинаковыми путями будет отображаться вместе в одном объединенном каталоге (в едином пространстве имён) полученной файловой системы.


Объединение слоёв происходит по следующим принципам:


  • один из слоёв становится слоем верхнего уровня, второй и последующие – слоями нижнего уровня;
  • пользователю объекты слоёв доступны «сверху вниз», т.е. если запрошенный объект есть в «верхнем» слое, возвращается он, независимо от наличия объекта с таким именем в «нижнем» слое; иначе возвращается объект «нижнего» слоя; если запрошенного объекта нет ни там, ни там, возвращается ошибка «Нет такого файла или каталога»;
  • рабочим слоем является «верхний», то есть все действия пользователя по изменению данных отражаются только на слое верхнего уровня, не влияя на содержимое слоёв нижних уровней.

Вывод


При необходимости виртуализации системы с гарантированно выделенными ресурсами и виртуальным аппаратным обеспечение, стоит выбрать VM. Что даёт использование VM:


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

Если вы хотите изолировать работающие приложения как отдельные процессы, вам подойдёт Docker. Что даёт использование Docker:


  • обеспечивает виртуализацию на уровне ОС;
  • контейнеры разделяют ядро системы, работая как отдельный процесс основной ОС;
  • потребление системных ресурсов, таких как расход памяти и нагрузка на CPU, могут ограничиваться отдельно для каждого контейнера с использованием cgroups;
  • ФС для контейнеров создаётся с использованием механизма COW, что позволяет ускорить разворачивание приложения, снижает расход памяти и экономит место на диске;
  • изменённая файловая система одного контейнера, может использоваться в качестве основы для формирования новых базовых образов других контейнеров.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 81

    +1

    С докером я бы сравнивал не VM, а LXC/LXD, оно как то ближе чем VM.

      +1

      Ближе по каким метриками? По популярности ближе? :)

        +1
        Контейнер ближе к контейнеру чем к виртуалке, всё правильно.
        А популярность не показатель. Лохер очень популярен но это же не повод его в прод тащить.
          +1

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

            +1

            И? LXC используется и как докер, для отдельных приложений, так и для развертывания оперативных систем и приложений уже в них…

              0

              Как популярны эти виды использования? Сколько процентов админов или разработчиков вспомнят об этой опции, когда им поставят задачу как-то упорядочить и стандартизировать развёртывание, например, сложных многокомпонентных систем как локально у разработчиков и тестировщиков, так и на удаленных окружениях?

                0

                Проблема отсутствия широты кругозора разработчиков и админов вне технологий. Остаётся только форсить knowledge sharing.

                  +1
                  Сколько процентов админов или разработчиков вспомнят об этой опции

                  Вспомнят те, кто интересуется. Если не читать новостей, не стремится узнавать «что нового» — вряд ли сможешь построить максимально подходящую для конкретной ситуации инфраструктуру.
                    0

                    Ну вот я вроде интересуюсь и даже вспомню "есть ещё rkt и что-то на L, что каноникал двигает или двигала", если спросят что есть на рынке. Но если спросят, что выбрать для нового проекта или куда существующий мигрировать, то я по них не упомяну. И даже не потому что нет опыта с ними (k8s год назад мог упомянуть, Chef сейчас могу упомянуть), а потому что не на слуху оно в широких массах, выглядит как инструмент для весьма специфических задач или как игрушка для "красноглазиков" (в хорошем смысле слова).

          +2

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

          +12
          Статья называется «VM или Docker?», но основное внимание уделено уже деталям Docker. По заголовку ожидал другое от статьи. Статья не даёт ответа на вопрос из заголовка.

          Но за старания спасибо.
            0
            Спасибо большое за комментарий, учту в следующих статьях. Надеюсь, было интересно.
            +3
            Предлагаю ещё осветить следующий вопрос.
            VM гарантирует программную независимость. Это значит, что я могу развернут виртуальную машину на любом железе и на любой ОС и внутри неё будет всё работать как надо. Причем больше ничего не нужно — нужно просто запустить VM и настроить интерфейс с ней (общие папки, порты настроить).
            А что гарантирует докер? Вот есть у меня контейнер веб-сервера. И две ОС — дебиан и windows 10. Почему и за счёт чего гарантируется работа контейнера? Что происходить после разворачивания образа?
              –9
              VM гарантирует программную независимость.… запустить VM и настроить интерфейс с ней (общие папки, порты настроить).


              То же самое гарантирует и докер (и с папками портами — все тоже), но только гораздо дешевле.

              Считайте, что докер просто легкая VM с Linux на борту. Все что можно сделать с VM вы можете сделать и с докером.
                +4
                Считайте, что докер просто легкая VM с Linux на борту

                Не стоит так считать, пусть даже для упрощенных объяснений — не стоит всё равно. Особенно если речь про запуск разных операционок — просто так контейнер с линуксом в винде не запустить, сначала придется запустить виртуалку с ядром линукса, которое уже сможет внутри создать все условия для запуска контейнеров.
                –1
                А что гарантирует докер?

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


                Вот есть у меня контейнер веб-сервера. И две ОС — дебиан и windows 10.

                Во-первых, linux-контейнер на windows хосте будет прозрачно завёрнут в Hyper-V VM с Moby Linux.


                Почему и за счёт чего гарантируется работа контейнера?

                • Всё окружение побайтово то же, что на dev-машине — в этом суть образов.
                • Сисколлы, доступные изнутри, стабильны что в linux, что в win-контейнерах.
                  0

                  Ядро же не войдёт в окружение. Если требуется специфичная версия ядра приложению…

                  0

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

                  +5

                  А я вот не понимаю зачем нужен докер. Сейчас большинство хостеров и так используют kvm для виртуализации и разделения ресурсов, так зачем внутри такой vm которая предоставляется клиенту нужна еще одна абстракция для разделения ресурсов? Почему нельзя взять код сервера и необходимые зависимости (обычно это ядро линукса + код бэка, то есть никакого ненужного и предустановленного софта в виде различных linux дистрибутивов, даже busybox и ssh-сервер с таким подходом будет не нужен) и запаковать его в виде образа vm (обычно это iso-файл) и загрузить через апи хостера как kvm-образ и запустить как обычный сервер. Таким образом получаем все те же плюсы что у докера, но главное — мы избавляемся от лишнего программного слоя и получаем меньшую воронку для уязвимостей поскольку на сервере не будет ничего лишнего (не будет даже открытого ssh-порта так как деплой будет происходить снаружи)

                    –1
                    А я вот не понимаю зачем нужен докер.

                    Способ простого развёртывания софта с минимальным оверхедом.


                    Почему нельзя взять код сервера и необходимые зависимости (обычно это ядро линукса + код бэка, то есть никакого ненужного и предустановленного софта в виде различных linux дистрибутивов, даже busybox и ssh-сервер с таким подходом будет ненужен) и запаковать его в виде образа vm (обычно это iso-файл) и загрузить через апи хостера как kvm-образ и запустить как обычный сервер.

                    В kvm уже layers завезли? У нас миграцияи сборка всех образов на следующий релиз .net core свелась к изменению переменной в .env — дальше CI пересобрал все образы из compose, просто вызвав docker-compose build и запушил их все с новым тегом тоже в одну строку, который подставил нужную версию в FROM mcr.microsoft.com/dotnet/core/sdk:{TARGET_FRAMEWORK}. Размер образов свёлся к одному базовому слою и по нескольку мегабайт на каждый сервис. Я не очень представляю объём работы, который нужно сделать, чтобы протестировать и собрать такие же образы на kvm, но есть подозрение, что это несколько сложнее, а про дедупликацию можно и не думать.

                      +3

                      А чем же миграция через сборку нового iso-образа вместе запуском нужного кода в качестве init-а (pid 1) будет отличаться от сборки такого же docker-контейнера где будет минимум ненужного софта (FROM scratch + статически собранные бинарники, либо только самое необходимое)? Как по мне отличий практически нет — iso-образы наверняка точно также можно собирать инкрементально, деплой и миграцию также можно автоматизировать.

                        +2
                        Я бы с удовольствием прочитал статью о том, как выполнять «фишки» докера, на KVM. С докером все понятно, есть довольно простой язык описания контейнеров и неплохая документация. Но ничего подобного для KVM я не встречал (ну не сильно и искал). Если с помощью KVM можно без проблем собрать образ виртуалки, поместить в нее приложение и запустить, было бы неплохо узнать об этом подробнее. Не увидел в комментариях упоминания о использовании ресурсов, виртуалка вроде как потребляет больше ресурсов чем контейнер, и для одного единственного приложения (микросервиса) это такое себе решение. Другой вопрос если иметь для KVM такой-же репозиторий образов который есть у docker. В общем с нетерпением жду статью с таким сравнением.
                          0

                          Ресурсы — как правило не проблема. Понятно, что для статического сайтика, завернутого в докер, оверхед от ещё одной копии ОСи будет больше, но это разговоры из серии "вам шашечки или ехать" — может вообще не стоило пытаться самому разворачивать хостинг тогда, а взять готовое SaaS решение? Нужно инструмент выбирать под задачу, а не наоборот.


                          Касательно уплотнения ресурсов. Ну, да, докер поможет. Но обратная сторона — а как же стабильность? Не боитесь огрести от того, что ядро общее и некоторые ресурсы ядра не изолируются? В случае если говорим про кубернетИс, то давайте говорить про него, а не про докер. Тем более, что рантаймы в к8с меняются. И, да, он умеет управлять виртуалками тоже (!!!!)


                          По сборке для квм — смотрите в сторону hashicorp packer. Можно собирать готовые образа вм под облачные платформы и все основные гипервизоры.

                            0
                            Ну вот сценарий. У нас есть браузерная игра, игроки по всему миру. У игры есть getaway, балансировщик, штук 15 микросервисов, шардированная база данных (не важно сколько), ну и сервер очередей, пусть RabbitMQ. Надо при всплеске активности игроков в другой части земного шара, поднять кластер локационно ближе к ним. Оркестратор поверх докера позволит это сделать довольно быстро, особенно если уже есть подготовленные машины под контейнеры. При этом поднять столько нод, сколько нужно, глушить и поднимать их в зависимости от загрузки. Сколько времени по сравнению с контейнером потребуется одной виртуальной машине на запуск, сколько данных нужно перекинуть в нужный ЦОД для развертывания? Как только в одной части земли наступает ночь, в другой начинается день, и мы кидаем ресурсы в эту часть земли тратя деньги в тех ЦОД в которых нужно. Если этот сервер заточен под docker у него есть локальный репозиторий контейнеров, нам нужно только подтянуть наше приложение.
                              0

                              Это нечестно. У вас предаллоцированные ресурсы. Если вы упретесь в количество нод и все равно придется провижионить новые, то это будет от дней (баре метал) до минут (облако) и все равно спайк вы пропустите. В этом отношении — докер поможет, но за счёт того, что у вас есть резерв в кластере прямо сейчас. Читай — недоутилизированные ресурсы, за которые вы платите. И, да, в принципе, с тем же успехом можно и без докера — больше вопрос выбора оркестратора, который сможет запускать приложение в виде дополнительных реплик.


                              И, повторюсь опять, если требуется поднимать сами ноды (ВМ) — то из готовых образов со всем необходимым они даже подниматься будут быстрее, чем с докером, т.к. ему ещё имиджи надо стянуть с софтом… Но это больше вопрос первого, "холодного" старта

                                0
                                Как вариант, это балансировать нагрузку внутри KVM глуша и поднимая контейнеры. Допустим если мы размещаем на VM не кластер приложения, а отдельный пулл нод (есть не нагруженные сервисы например регистрация, а есть обработчики событий). Мы можем более тонко распределять нагрузку по нашим ограниченным ресурсам (не представляю правда когда это может понадобиться, но если случится «датапокалипсис» и всем не хватит железа… :D). При этом мы не трогаем конфигурацию наших виртуалок и всегда и везде используем один единственный стартовый снапшот для запуска.Тогда удастся выиграть пару минут для запуска дополнительных ресурсов. Идея в том, чтобы пережить непредусмотренный пик нагрузки.
                        +1

                        Про дедупликацию для виртуалок что-то было в недавней статье про CoW файловые системы

                        +2

                        Пожалую попробую прояснить подробней — суть не в том чтобы юзать kvm вместо докера — тут суть в том чтобы избавиться от лишнего программного слоя. Сейчас когда заказываем машинку у хостера (vps или различные облачные решения) то вместо целой физической машинки получаем лишь запущенный образ виртуальной машины с другими такими же соседями.
                        И дальше поверх этой запущенной машины мы добавляем еще один программный слой в виде докера для еще одной изоляции. И появляется вопрос — почему нельзя точно также как с докером собрать весь код, зависимости и окружение вместе в виде некого контейнера но только без докера? То есть это будет не контейнер (который будет запускаться внутри виртуальной машины которую нам предоставил хостер) это будет уже сразу готовый iso-образ операционной системы который будет запущен хостером на той виртуальной машине которую мы арендуем.
                        Уже сейчас многие хостеры предоставляют возможность загрузить кастомные iso-образы — и если можно собрать весь код и деплоить сразу в виде iso-образа то тогда докер становится просто ненужной абстракцией и лишним программным слоем

                          –3
                          • А если у вас 40 контейнеров, то вы будете 40 VPS заказывать? А если их автоматом нужно запускать/останавливать?
                          • Как уже отметили выше, как жить без слоев? Каждый релиз закачивать гигабайтные ISO?
                          • Так же не понятно как обеспечивать взаимодействие контейнеров: как создавать виртуальные сети, маппить порты, задавать переменные окружения?
                          • Следующая проблема — единный API. Предположим, что хостер предоставил вам API для загрузки образов. Что делать, если вам надо переехать к другому хостеру, у которого совершенно другое API? Переписывать все? И что делать разработчикам, чтобы развернуть образ локально? Настраивать и запускать все ручками?

                          Этот список проблем, которые решает докер, можно продолжать еще долго.

                            0

                            Слои — не панацея. Даже правильное их расположение не решает проблему, когда по факту нужно "ромбической наследование" слоев. А оно, между прочим оказывается нужно достаточно часто. И я даже не знаю — благо ли это, что его нет в докере или нет. Т.к. наследование ромбиком это всегда путь отстрелить себе ногу (например, в обоих родительских образах есть одинаковые каталоги-файлы по имени, но разные по содержимому). Лучше бы diff докачивался не послойно, а пофайлово. Ей-Богу.


                            Так же не понятно как обеспечивать взаимодействие контейнеров: как создавать виртуальные сети, маппить порты, задавать переменные окружения?

                            Переоцениваете важность и нужность виртсетей. Зачастую лучше вообще избегать докер-сетей. Сложно. Вносят penalty при сетевом взаимодействии. И пр

                              0

                              Разумеется, это не панацея. Но это лучше, чем монолит. Или, упомянутые выше, ISO для VPS не являются монолитом?


                              Переоцениваете важность и нужность виртсетей. Зачастую лучше вообще избегать докер-сетей. Сложно. Вносят penalty при сетевом взаимодействии.

                              Не всегда же требуется максимально возможная производительность от сетевой подсистемы, тем более в случае когда проект размещается на VPS. И потом, основной вопрос был: как конфигурировать эти ISO?


                              PS Не совсем понятно к чему относились минусы. Разве на эти вопросы есть ответы у данного абстрактного хостера? Или они не имеют никакой значимости?


                              Хорошо, давайте возьмем конкретного хостера: Amazon Web Services. У них есть все это с незапамятных времен, когда докера еще и в помине не было. И образы в виде "ISO", и обширный API, и всякие Cloud Formation для автоматизации деплоя, и много прочего. Заменяет ли он все плюсы докера и решает ли все выше обозначенные проблемы?

                                +1
                                Но это лучше, чем монолит

                                Хороший маленький монолит лучше, чем плохая распределённая сеть из микросервисов. Не так ли ?


                                Или, упомянутые выше, ISO для VPS не являются монолитом?

                                Вы прицепились к двум вещам. Причем неверным. Не iso — это сказал коллега. И это только один из способов. Те же AMI у Амазона более подобны "золотым образам" жёсткого диска. И по AMIшкам я ответил — можно их готовить HashiCorp Packer. Не нравится? Ну, давайте попробуем подобрать другой тулинг.


                                Во-вторых, VPS вызывает неверные (или Вы специально в это русло утаскивает?) ассоциации с маленькими провайдерами типа ТаймВеб, Beget, hetzner отчасти и пр. — которые дают отдельные ВМ, вместо того, чтобы предоставлять инфру. Как бы есть небольшая разница между непонятной vps у непонятного провайдера и EC2/Compute Engine в облаке с нормальным API?


                                Заменяет ли он все плюсы докера и решает ли все выше обозначенные проблемы?

                                Если говорить за разработчика — он хочет Хероку. Вы ведь наверняка его видели? Как локальный вариант — есть dokku. Но это абстракция более высокого уровня, чем докер...

                                  0
                                  Хороший маленький монолит лучше, чем плохая распределённая сеть из микросервисов. Не так ли ?

                                  Я рассуждал именно в разрезе микросервисов. Иначе нужно было бы ставить вопрос не VPS vs Docker, а именно Монолит vs Микросервисы.


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


                                  И по AMIшкам я ответил — можно их готовить HashiCorp Packer. Не нравится? Ну, давайте попробуем подобрать другой тулинг.

                                  Т.е. вы имеете ввиду, что можно взять нейкий тулкит и при помощи него делать более менее схожие многослойные (ромбические?) образы для того же AWS EC2? Видимо, я не сразу понял о чем речь.


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


                                  Во-вторых, VPS вызывает неверные (или Вы специально в это русло утаскивает?) ассоциации с маленькими провайдерами типа ТаймВеб, Beget, hetzner

                                  Да, именно такое впечатление у меня и осталось от комментария bgnx.


                                  Как бы есть небольшая разница между непонятной vps у непонятного провайдера и EC2/Compute Engine в облаке с нормальным API?

                                  Именно так. Хорошо, если вопрос стоит как "Почему не использовать AWS/Azure/Google Cloud вместо Docker", то это немного меняет дело. Но у меня, как разработчика, все еще остаются некоторые вопросы:


                                  • Например как запустить AMI контейнер у себя локально? Когда я работал с EC2, то не находил подобной возможности. Можно ли это сделать сейчас?
                                  • Все та же проблема с взаимодействием контейнеров, в случае если я все же пишу микросервисы, а не монолит.
                                  • Еще одна проблема в том, что AMI поднимаются безумно медленно. Это будет особенно мешать, если надо обновлять контейнеры часто.
                                  • И опять же, что делать, если амазон завтра скажет, например, что больше не работает с Россией и нужно срочно переносить все другому хостеру. Как же тут быть? В случае с докером такой проблемы нету.

                                  Если говорить за разработчика — он хочет Хероку. Вы ведь наверняка его видели? Как локальный вариант — есть dokku. Но это абстракция более высокого уровня, чем докер...

                                  Тут именно проблема в абстракции более высокого уровня. Например, мои текущие задачи никак не вписываются в возможности Heroku

                            +1
                            Уже сейчас многие хостеры предоставляют возможность загрузить кастомные iso-образы — и если можно собрать весь код и деплоить сразу в виде iso-образа то тогда докер становится просто ненужной абстракцией и лишним программным слоем

                            Я в GCP видел возможность деплоить контейнер как VM (ЕМНИП там просто прозрасно для пользователя ContainerOS стартует).


                            Почему же люди бегут с VM в докер?


                            Я думаю, что основная причина: дешевизна. Докер (lxc/containerd) дешевле. На одну физическую машину можно упаковать больше контейнеров, проще разделять процессорное время/память.


                            В целом, популярные оркестраторы (k8s) умеют управлять полезной нагрузкой независимо от того, это VM или контейнер. Для тех пользователей, которым надо запускать нагрузку "ближе к железу" это решает все проблемы управления.

                              +1
                              И появляется вопрос — почему нельзя

                              А почему нельзя? Можно, так и делали до появления контейнеров. Хотите — продолжайте так делать и дальше.
                              +1
                              1. Развёртывание докер контейнеров уже стандартизировано готовыми системами оркестрации. Нет нужды писать что-то своё.
                              2. Эти системы оркестрации умеют из коробки делать всё необходимое для обеспечения связи между контейнерами, а также, для автоматического перезапуска, распределения нагрузки, ограничения доступа и т.д.
                              3. Контейнер докера легковесный. Существующие образы содержат только самое необходимое для работы одного приложения. Докер — не полноценная виртуалка. Скорее, это эмулятор операционной системы.
                              4. Как уже отмечалось в комментах, сборка контейнера, зачастую, стандартизирована под изменение одного файла конфигурации. Этот файл определяет поведение контейнера на разных машинах.
                              5. Докер — мультиплатформенный. Даже дизайнер, имея самые общие представления о работе контейнеров, может поставить себе докер и запустить проект.
                                +1
                                Контейнер докера легковесный. Существующие образы содержат только самое необходимое для работы одного приложения. Докер — не полноценная виртуалка. Скорее, это эмулятор операционной системы.

                                К сожалению, это полуправда. Дело в том, что большинство образов на докерхаб содержат избыточные компоненты. Вот глядишь и понимаешь, что чтобы это заработало — надо все переписать на golang'е, компилировать в статический бинарь и именно его уже класть в FROM: scratch
                                Тогда заживём. А пока мусора в образах больше, чем полезной нагрузки...


                                Докер — мультиплатформенный. Даже дизайнер, имея самые общие представления о работе контейнеров, может поставить себе докер и запустить проект.

                                К сожалению, если он не сидит под линуксом, то его может очень быстро настигнуть разочаровании в докере. В маке и под виндой докер работает через выделенную вм, а это означает сразу более низкую производительность. В первую очередь — по дисковым операциям. Отчасти проблему решает docker-sync
                                А ещё сетевое взаимодействие становится сложнее.

                                  0
                                  А пока мусора в образах больше, чем полезной нагрузки

                                  Довольно часто, но в разработке можно и с мусором пожить, а на прод собрать что надо.

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

                                  Ну, если разработчик умеет только счетами пользоваться — его тоже постигнет разочарование=) Пора бы уже Linux как стандарт воспринимать и знать как таблицу умножения.
                                    –2
                                    Довольно часто, но в разработке можно и с мусором пожить, а на прод собрать что надо.

                                    Можно, но набегут сторонники того, что в тесте и в проде должны быть идентичные образы (в разработке — по ВОЗМОЖНОСТИ — тоже)


                                    Пора бы уже Linux как стандарт воспринимать и знать как таблицу умножения.

                                    Бородатые админы и разработчики под Виндовс… даже не знаю… плачут или смеются....

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

                                    под Вин Докер уже научился использовать Windows Containers, естественно «там где оно есть». Майкрософт за тему с Докером серьезно взялись.
                                      0

                                      К сожалению, тут у меня пробел, но насколько мне известно — windows containers позволяют запускать только Вин-приложения, но не линукс-контейнеры… Так что универсальностью тут и не пахнет.

                                        +1

                                        Да, Linux контейнеры под Windows все еще используют Hyper-V, но могут работать в двух разных режимах:


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

                                        Вот тут есть более подробная информация об этом: https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers

                                      0
                                      Дело в том, что большинство образов на докерхаб содержат избыточные компоненты. Вот глядишь и понимаешь, что чтобы это заработало — надо все переписать на golang'е, компилировать в статический бинарь и именно его уже класть в FROM: scratch

                                      Всё же не путайте мусор, который остаётся от, скажем так, не экономной сборки образа (билд депенденси и артефакты, например) и рантайм для приложения на конкретном стэке. Я даже не уверен, что для Go FROM: scratch должно быть по умолчанию, а не только для специфических случаев

                                        0

                                        Мысль свою разверните. И, да, я не путаю. Потому что у Вас в стандартном докере бежит стандартная… Дистрибьюция линукса. Со стандартным пакетным менеджером. И делая apt install Вы туда тащите кучу всего. Даже не разбираясь нужно оно или нет. Причем. Что интересно. Чем более "жирный" образ — тем меньше желания залезать ему под капот (а получить образ на 3-4 ГиБ с pytorch, cuda etc — легко, хотя это и экстремальный случай)

                                          0

                                          Я знаю о наличии как FROM scratch, так и образов типа alpine, но предпочитаю FROM ubuntu:bionic-20191029 на сегодняшний день. Может всё, что там в 25 мб есть, приложению и не нужно, но подавляющая часть всего этого нужна разработчикам и эксплуатанционщикам для эффективной работы с образом. Прежде всего bash и apt :) Ну, исхожу из того, что никто не делает образы на базе полноценных установок ubuntu, а используют всё же оптимизированные для докер образы


                                          Я больше о практике, принятой в некоторых официальных образов, типа сделать apt install build-essentials и ко, а после сборки из исходников ничего в образе не чистить.

                                    +1

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


                                    Ну и субъективно тулинг докера, его экосистема (включая k8s, хотя Докер для него не обязателен) удобнее с точки зрения пользователей (читай — разработчиков, девопосов и админов) и в гораздо большей части FOSS.

                                      0

                                      Все правильно. В Амазон так и можно деплоиться.

                                        0
                                        А я вот не понимаю зачем нужен докер.

                                        Скажу не конкретно про докер, а в целом про контейнеры. Во-первых — меньше объем (не надо собирать в образ ядро линукса, systemd и прочее, переносится между серверами только приложение и необходимые именно ему библиотеки и конфиги), во-вторых — быстрый старт (контейнер стартует практически мгновенно, виртуалка так быстро не стартует. Единственный гипервизор, который кто-то использует в проде, рассчитанный на быстрый старт — firecracker от Amazon, и он всё равно медленнее контейнера стартует). В-третих — инфраструктура по сборке и деплою. Для виртуалок за все годы существования технологии таких удобных инструментов так и не сделали.
                                          0

                                          Насчёт systemd. Его в докер не кладут, а лучше бы клали. Потому что многие не могут декомпозировать софт по разным причинам и сделать контейнер на исполняемый файл. Результат — все равно тащат всякие tini, supervisord в контейнер. И на самом деле это достаточно частая практика.
                                          Даже systemd пинками можно в докер засунуть — это позволяет соблюсти унификацию с дистрибьюциями вне докера, — но при этом это сценарий, который требует много допдействий

                                            0
                                            Результат — все равно тащат всякие tini, supervisord в контейнер. И на самом деле это достаточно частая практика.

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

                                            Просто немного странная терминология, но точно не перепутаны, потому что в FROM не упомянут контейнер.

                                              +1
                                              FROM — обязательная инструкция для описания Dockerfile
                                              CMD — необязательная

                                              Фактически контейнер запускает команда docker run, но FROM является отправной точкой при чтении dockerfile и создании контейнера.
                                                0

                                                Поддержу. Но скорее запуск контейнера триггерит не CMD. А именно вторая инструкция после FROM :-) но это детали реализации. Давайте в них не углубляться. Просто если коллега изначально правильно написал БЫ про ENTRYPOINT + CMD....

                                                  +2
                                                  А именно вторая инструкция после FROM

                                                  Даже если будет одна инструкция FROM — контейнер будет запущен.
                                                    0

                                                    При запуске контейнера докерфайл вообще не читается, а запускается то, что было указано в CMD/ENTRYPOINT исходного или родительского Докерфайла, если они вообще использовались при сборке образа. Различные RUN команды, вообще в контейнере не запускаются, если вы их имели ввиду под второй строчкой.

                                                      0

                                                      Наша дискуссия было про другое, если я уловил мысль — про создание временных контейнеров при docker build. Потом этот временный контейнер commit'ится и получается промежуточный образ.

                                                        0

                                                        Я думаю, автор поста о временных контейнерах при docker build в посте вообще не упоминал, кроме как "FROM — входная точка при формировании образа;"

                                                    0

                                                    При run FROM не читается, более того вообще Докерфайл не читается, ещё более того, Докерфайла в принципе может не быть.

                                                0

                                                VM и Docker решают разные задачи. VM позволяет держать усебя запущенный экземпляр сервера. Docker предоставляет возможность упаковать приложение вместе со средой исполнения. По сути, Docker контейнер — это экзешник: запустил его, и у тебя поднялся сайт. VM запустил, и у тебя поднялась гостевая операционная система внутри виртуальной машины.
                                                Ничто не мешает запустить Docker внутри VM. По сути, на некоторых VPS это и происходит. Сам VPS с конфигурацией можно копировать в виде VM и развернуть похожую конфигурацию локально.
                                                Docker выгодно отличается от сервера, запущенного в VM тем, что имеет минимальный даунтайм при запуске, поскольку приложение запускается моментально и поставляется в одном пакете со средой исаолнения. А вот деплой на сервере представляет собой многошаговый процесс: поменять конфиги, выполнить команды, перезапустить сервер. С другой стороны, приложение, запущенное в контейнере, будет потреблять больше ресурсов.
                                                VM лучше подходит для доставки приложения участникам разработки, поскольку требует только запустить виртуалку. В случае с Vagrant, сетевое соединение настроится автоматически. Ничего настраивать руками не придётся. Docker потребует от пользователя минимальные навыки администрирования системы оркестрации.

                                                  +1

                                                  Хорошо работает доставка VM с установленным и настроенный докером, если требуется что-то сложное. :) Сами же говорите, что они не взаимоисключающие.

                                                    0
                                                    Как-правило, доставка образа VM обходится дороже. Дешевле загнать конфигурацию в тот же Ansible и поставлять скрипты отдельно от образа.
                                                      0

                                                      Хм, а как же packer, terraform и вроде как тенденция к переходу на "иммутабельную" инфраструктуру по возможности? Деплой виртуалок из готовых образов ведь быстрее и надёжнее, чем каждый раз раскатывать конфиг ансиблом на чистой системе, плюс повторяемость..

                                                        –1

                                                        Иммутабельная инфраструктура — это очень правильная идея. Но и к нее есть… Темные стороны


                                                        1. Этот подход нам совершенно не говорит что делать с данными. Круто, когда все стейтлесс. Взял и передеплоил. Но как только нам нужно хранить данные (т.е. чуть более часто, чем всегда) — приходится думать. То ли брать внешнее хранилище (s3? Rds? Managed database?) со всеми его плюсами и недостатками, то ли разрабатывать свое хранилище… И тут начинается.
                                                        2. IaC на старте очень дорог. Он усложняет процессы, не давая взамен чего-то… Ощутимого. Он хорош, когда реально проект уже зрелый и требует большой инфры. Тогда IaC прекрасен. Тут спору нет.
                                                          +2

                                                          Да, стейтфул — это боль. Еще бОльшая боль — когда у вас bare metal который тоже как-то надо менеджить. В целом именно поэтому AWS и ему подобные успешно предлагают сервисы типа RDS — "мы вам настроим и будем поддерживать stateful сервис, а вы нам просто денежку платите".


                                                          Насчет дороговизны IaC на старте — не совсем согласен. Как только у вас появляется хотя бы два окружения (прод и стейджинг), то еще вопрос, что дороже — описать это как IaC, или руками поддерживать одинаковость этих окружений, и периодически при дебаге втыкаться в то, что окружения все-таки разные.

                                                            +1

                                                            Ну, попробуйте сделать универсальное IaC для нескольких облаков, а потом поддерживать его в актуальном состоянии. Это правда больно. Если же живёте в рамках какой-то одной среды… Тогда попроще.
                                                            И ещё. IaC предполагает, что через месяц, полгода, год ты сможешь все развернуть все в том же виде. Это достижимо, но опять очень много нюансов — за это время могут поменяться API облаков, версии тулинга, да и артефакты вот тех старый версий нужно вытащить из хранилища, т.к. пересобрав их сейчас получишь уже другие версии, которые не факт, что заработают. Для справедливости скажу, что вот такая задача далеко не всегда нужна, т.к. многие SaaS продукты бегут на единственной, текущей версии. И, очевидно, что IaC требует так же, как и код программы, ежедневных практик и подгонки под реальность. Т.е. если его рассматривать именно как способ автоматизации работы и облегчения работы админа/опса/девопса, то все ок


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

                                                              0
                                                              Ну, попробуйте сделать универсальное IaC для нескольких облаков, а потом поддерживать его в актуальном состоянии. Это правда больно.

                                                              Охотно верю (сам с таким в проде не сталкивался — используем только AWS). Но подозреваю, что руками это всё поддерживать не менее больно.

                                                          –3
                                                          А что, много хостеров предоставляют возможность развернуться со своего образа? Сейчас для проекта от среднего масштаба и выше выбирается Docker. Образ VM для раскладывания идеально подошёл бы для небольших проектов и средних проектов, поскольку их можно свести в относительный монолит — без обилия мелких микросервисов. Но большинство хостеров, предоставляющих небольшие VDS или облака под эти цели, не предоставляют возможность разложиться со своего образа. А ещё же нужен репозиторий для образа.
                                                            +1
                                                            Но большинство хостеров, предоставляющих небольшие VDS или облака под эти цели, не предоставляют возможность разложиться со своего образа. А ещё же нужен репозиторий для образа.

                                                            Это немного не так работает. Большинство облачных провайдеров предоставляют возможность создания снапшотов с виртуалок, и разворачивания новых виртуалок из этих самых снапшотов. Именно это и эксплуатируется пакером — он поднимает виртуалку прямо у вашего облачного провайдера из одного из базовых образов, предоставляемых провайдером, раскатывает туда нужный софт и сохраняет снапшот. Дальше с помощью любого инструмента управления облаком (хоть собственные скрипты, напрямую дергающие REST API, хоть терраформ) из этих снапшотов поднимается нужно количество виртуалок. Загрузка своих образов не нужна. А роль репозитория играет ваш аккаунт у облачного провайдера.

                                                              +1

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

                                                            +2

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

                                                        +2
                                                        Почему упомянута UnionFS, разве в Докере не OverlayFS (а ранее AuFS)?

                                                        >Данная ФС реализует механизм копирования при записи (Copy-On-Write, COW)

                                                        Разве там есть COW? Или имеется ввиду выделение отдельного read-write слоя для «жизни контейнера»?

                                                        > т.к. в отличие от VM, виртуализируют ОС, а не аппаратное обеспечение.
                                                        мне кажется, формулировка некорректная. Виртуализации там нет. ОСь никто не «виртуализирует», разве что окружение. Ядро и его ресурсы все-равно общие.

                                                        >Dockerfile может содержать такие команды как:

                                                        описание очень поверхностное. Извините, но вот например это «CMD — запускает создание нового контейнера на основе образа» очень странная формулировка. Директива CMD к «созданию контейнера» отношения не имеет. Про EXPOSE — тоже не совсем корректно, и не указано зачем на самом деле он нужен.

                                                        P.S. и, как мне кажется, не освещено главное отличие контейнеров от ВМ — первые выполняются на одном общем ядре ОС, вторые — имеют свои отдельные ядра ОС. Да, это банальщина, я понимаю. Но тут как бы тема статьи такая — про банальные вещи.
                                                          –1
                                                          Добрый день.

                                                          Да, в статье действительно допущена неточность. Docker действительно использует AuFS, построенной на базе UnionFs.
                                                          Docker реализует механизм COW: если файл или каталог уже существуют на нижнем слое в образе, и другому слою (включая слой для записи) требуется доступ для чтения к нему, он просто использует существующий файл. Если другой слой должен изменить файл при создании образа или запуске контейнера, файл копируется в этот слой и изменяется. Это минимизирует ввод-вывод и размер каждого из последующих слоев.
                                                          EXPOSE эта инструкция указывает какой набор портов прослушивает контейнер во время выполнения, вы можете указать будут ли прослушиваться порты по UDP или TCP, по умолчанию установлен TCP.
                                                            0

                                                            Aufs уже в новых дистрибутивах не используют. Там overlay2. По сути для пользователя то же самое

                                                              0
                                                              Да, но там есть некоторые ограничения:
                                                              aufs рекомендуется использовать, если у вас Docker 18.06 или старше, когда используется Ubuntu 14.04 (kernel 3.13), которые не поддерживают overlay2.
                                                                +1

                                                                Вы сами-то такие старые сервера видели? Если да, то пора бы их уже обновлять.
                                                                Касательно centos — там вообще по умолчанию до последнего времени был devicemapper и ничего… как-то жили..


                                                                если у вас Docker 18.06 или старше

                                                                старше — в смысле новее версия или более ранняя? Я бы рекомендовал выражать свои мысли точнее ) Ну, и в 18.06, по-моему, overlay уже нормально работал.

                                                              +1
                                                              EXPOSE эта инструкция указывает какой набор портов прослушивает контейнер во время выполнения

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

                                                              Единственное на что эта директива влияет, это на запуск контейнера через docker run с ключом -P. Тогда Докер автоматом прокинет указанные в EXPOSE порты на 0.0.0.0

                                                              Я почему акцентирую на этом внимание — изначально, изучая Докер, назначение и суть EXPOSE я понял «только с третьей попытки». Ибо в документации и разных статьях оно было описано невнятно.
                                                            0
                                                            Почему то большинство комментов тут с точки зрения использования у хостинг-провайдеров. Все же в курсе что виртуалки можно использовать не только так? :) Для VPS докер действительно не вариант.

                                                            Щас напишу одной строчкой зачем нужен докер: завернуть приложение вместе с его окружением в одну сущность (образ) с минимумом лишнего хлама. Тут писали что дескать на докерхабе большинство образов неоправданно велики потому что внутри много ненужного. Так это разве проблема докера как технологии? Или может это кривыми руками образы собирали? Качайте только официальные образы, там обычно все норм
                                                              0
                                                              Качайте только официальные образы, там обычно все норм

                                                              У официальных образов другие проблемы есть. Например, достаточно ограниченный набор "ручек" для настройки, спорные дефолты. Поэтому набирают силу и клиентскую массу альтернативные образы — например, от bitnami, которые позволяют согласно 12-factor передавать все или хотя бы бОльшую часть ключей через переменные окружения.


                                                              завернуть приложение вместе с его окружением в одну сущность (образ) с минимумом лишнего хлама.

                                                              К сожалению, разрабы думают про это обратное — для них докер удобный способ замести весь мусор (в случае языков вроде python, js@node.js, ruby и пр.) в контейнер и больше об этом не думать. Не мешает? Ну, и ладно.


                                                              Т.е. если речь про тестирование/разработку — к докеру по сути-то вопросов особо и не возникает. ) Удобно. Быстро. Как правило — не вызывает особой головной боли. Но не нужно из него делать… универсальное решение всех проблем.

                                                              +1
                                                              Для сочетания этих слоёв в один образ Docker использует Advanced multi layered Union file system (AuFS построена на базе UnionFS)

                                                              Я бы тут еще один момент уточнил — докер довольно умный и AuFS использовать не будет если у него контейнеры на файловой системе поддерживающей CoW и тома. Например на btrfs docker во всю использует снимки и CoW самой btrfs.

                                                              Only users with full accounts can post comments. Log in, please.