Например, в AWS, когда я запускаю новый экземпляр EC2, он загружает новую виртуальную машину, а затем заполняет ее образом контейнера. Это причина того, что запуск новых инстансов EC2 занимает 60-90 секунд.
Из любопытства, каковы недостатки того, что AWS запускает хост-машину как есть, и когда пользователь хочет «развернуть экземпляр EC2», AWS просто запускает контейнер с ограниченными разрешениями и предоставляет пользователю доступ только к этот контейнер?
Плюс в том, что вычислительный экземпляр будет раскручиваться очень быстро. Я все еще изучаю облачные технологии, поэтому мне просто интересно, каковы недостатки.
Возможно, сложнее выделить ресурсы ЦП без использования виртуальных машин? И в результате пользователи будут драться друг с другом за доступный процессор? Или, может быть, есть какие-то проблемы с безопасностью? Хотел бы узнать об этом.
Контейнеры обычно запускают только одно приложение и являются неизменяемыми, т. Е. Изменения не сохраняются при перезапусках. У контейнеров также нет собственного ядра.
С другой стороны, виртуальные машины запускают всю операционную систему, включая ядро, сценарии инициализации, системные демоны и т. Д. И хранилище обычно сохраняется после перезапуска.
Виртуальные машины и контейнеры служат разным целям - погуглите что-то вроде «Виртуальные машины против контейнеров», в Интернете много всего.
Если ты хочешь бежать Контейнер как услуга в AWS не беспокоясь о базовых виртуальных машинах, посмотрите на AWS Fargate - это именно то, что вам нужно.
Надеюсь, это поможет :)
Ваш вопрос в некоторой степени заключается в том, чтобы взглянуть на вещи назад: EC2 - это не универсальное хостинговое решение, которое использует виртуальные машины; это сервис для размещения виртуальных машин. Таким образом, есть несколько способов интерпретировать ваш вопрос.
Ответ на это можно вывести из графика: бета-версия EC2 была запущена в 2006 году, а полная версия - в 2008 году; Docker не был публично выпущен до 2013 года, а Kubernetes - в 2015 году.
Контейнерная технология разрабатывалась во время запуска EC2 - у BSD уже были «тюрьмы», а у Linux были некоторые формы изоляция пространства имен - но это была не та зрелая экосистема, с которой мы знакомы сегодня. С другой стороны, виртуальные частные серверы были устоявшейся концепцией - VMWare явно продавала ESX для услуг хостинга в 2002 году., то Xen гипервизор последовал в 2003 году, и Линод был запущен в том же году. Нововведением EC2 стала система запуска виртуальных серверов. по запросу, по требованию используя эту установленную технологию.
Хотя контейнеры в некотором смысле можно рассматривать как «облегченную виртуальную машину», это не полное описание, и они не являются взаимозаменяемыми. Виртуальная машина создана для того, чтобы дать пользователю иллюзию доступа к физическому серверу с полным контролем над всей системой; ресурсы, такие как сеть, представлены как виртуальное оборудование, с которым пользователь может напрямую взаимодействовать, если пожелает. Контейнеры представляют собой более ограниченную абстракцию, и приложение, как правило, гораздо более тесно связано с конфигурацией самого контейнера, например, перенаправляет только определенные сетевые порты.
За прошедшие годы Amazon добавила множество сервисов, но очень консервативно относится к отказу от старых, на которые полагаются клиенты. Таким образом, они предлагают множество услуг, основанных на контейнерах, а не на виртуальных машинах, таких как ECS (Elastic Container Service, запущен в 2014 г.), Фаргейт (запущен в 2017 г.), и EKS (Elastic Kubernetes Service, запущен в 2018 г.); но они вряд ли откажутся от EC2, если пользователи все еще будут его использовать.
Учитывая, что доступен облачный хостинг на основе контейнеров, почему люди по-прежнему предпочитают использовать сервисы на основе виртуальных машин, такие как EC2?
Я думаю, есть несколько причин; несколько, которые приходят на ум:
Таким образом, хотя популярность контейнеров продолжает расти, они еще не полностью заменили виртуальные серверы и, вероятно, никогда не будут. Таким образом, EC2 и аналогичные услуги облачного хостинга на базе виртуальных машин никуда не денутся.
Безопасность - определенно причина. Контейнеры используют одно и то же ядро между ними и хостом. Так что они не считаются изолированными на 100%.
Тем не менее, облачные провайдеры также предоставляют контейнеры. AWS тоже это делает. Я предполагаю, что контейнеры дешевле виртуальных машин, но я не проверял.
По сути, вы спрашиваете более общую тему: виртуальные машины против контейнеров; независимо от платформы применяются одни и те же плюсы и минусы.
Существует несколько различных подходов к контейнерам, и текущий принятый ответ, похоже, учитывает только контейнеры в стиле OCI (похожие на докеры). Есть много других типов контейнеров, таких как тюрьмы LXC и BSD, которые используют разные подходы.
Например, LXC может легко содержать несколько приложений и по умолчанию является изменяемым. Он также имеет сценарии инициализации и системные демоны (systemd и т. Д.).
Возможно, сложнее выделить ресурсы ЦП без использования виртуальных машин? И в результате пользователи будут драться друг с другом за доступный процессор?
Распределение ресурсов ЦП, ОЗУ и дискового пространства также легко выполняется с помощью контейнеров.
Плюс в том, что вычислительный экземпляр будет раскручиваться очень быстро.
Подготовка контейнеров не является мгновенной задачей (но может быть быстрее, чем "60-90 секунд"), поскольку вам все равно нужно получить образ, извлечь его и запустить.
Или, возможно, есть некоторые проблемы с безопасностью?
Безопасность является основным источником беспокойства для всех упомянутых мной контейнерных решений, поскольку все они используют одно ядро. Несмотря на то, что существует множество мер безопасности, иногда все же обнаруживаются уязвимости. Если бы у вас был общий сервер с вашими друзьями, и у вас у всех были контейнеры в них, вы, вероятно, были бы в большей степени в безопасности, но в масштабе крупных провайдеров, таких как Amazon (где множество предприятий используют их услуги), это может быть значительным забота о безопасности.
Если вы проверите Веб-сайт AWS Fargate например, в нем говорится, что многие ресурсы для их контейнеров не являются общими, и с этой точки зрения он намного ближе к виртуальной машине, чем к традиционному автономному контейнеру:
Отдельные задачи ECS или модули EKS выполняются в своей собственной выделенной среде выполнения ядра и не разделяют ресурсы ЦП, памяти, хранилища или сетевых ресурсов с другими задачами и модулями. Это обеспечивает изоляцию рабочей нагрузки и повышенную безопасность для каждой задачи или модуля.
И последнее, что я хотел бы отметить, - это совместимость. Поскольку ваш доступ к ядру (а также, возможно, к вашим системным вызовам) ограничен, вы не можете выполнять определенные задачи, такие как загрузка модулей dkms или выполнение конфигураций sysctl. Не все приложения будут работать в этом режиме, но это скорее исключение, чем норма.
Существует множество допустимых вариантов использования контейнеров (как OCI-подобных, так и LXC-подобных), и это определенно не «одно решение для всех». Отсутствие необходимости запускать все ядро и выполнять другие типы виртуализации (графика, аудио, сеть и т. Д.) Приводит к гораздо меньшим накладным расходам, но также необходимо учитывать недостатки использования контейнеров, некоторые из которых я упоминается в моем ответе.