Определить, когда использовать ВМ, контейнер или ВмМ, может быть довольно непросто. Это связано с тем, что каждый тип экземпляра обладает собственным конкретным предназначением. Выбор той или иной технологии зависит от типа рабочих нагрузок, которые контролирует ИТ-администратор. Если ему нужно развернуть традиционные монолитные приложения, то в этом случае идеально подходят ВМ — это полный и независимый сервер для запуска сложных унаследованных программ, например СУБД. Контейнеры лучше подходят в тех случаях, когда рабочим нагрузкам требуется масштабируемость и мобильность. К ним также прибегают для обслуживания процессов, которые могут обходиться без высокого уровня безопасности, поскольку контейнеры не могут работать в изолированных средах. Поддержка традиционных монолитных приложений с обеспечением должного уровня масштабируемости и мобильности — это тот случай, когда администратору не обойтись без ВмМ. Они обладают преимуществами контейнерной архитектуры, сохраняя при этом безопасность и изоляцию, как раз те преимущества, которыми обладают полноценные ВМ.
Проблемы с управлением ВмМ
ВмМ преодолевают разрыв между контейнерами и полноценными ВМ, предлагая администраторам преимущества обоих. Но, тем не менее, они и сами не лишены недостатков. Они позволяют создавать множество экземпляров виртуальных машин одновременно и на протяжении длительного времени, но по мере накопления ВмМ администраторы рискуют превысить как лимит гипервизора на ВМ, так и доступные лицензии на ПО. Другая проблема: широкомасштабное использование ВмМ может привести к конфликту ресурсов. Существует ошибочное предположение, что в связи с тем, что ее размер небольшой, то и ресурсов она потребляет немного. Нужно понимать, что размер ВмМ не обязательно связан с тем объемом ресурсов, которые она использует. Чаще всего конфликт ресурсов вызывает именно огромная масса ВмМ на одном хосте. Создавая их за короткий промежуток времени в большом количестве, администраторы рискуют перегрузить хост.
AWS Firecracker — средство для управления ВмМ
Как уже говорилось, ВмМ не лишены недостатков, однако рынок предлагает несколько платформ, которые помогут устранить проблемы с управлением. Одним из примеров является AWS Firecracker — технология виртуализации с открытым кодом, которая позволяет администраторам создавать ВмМ для контейнерных приложений. AWS задействует Firecracker для поддержки собственных облачных сервисов, таких как Lambda и Fargate, однако в ноябре 2018 г. компания открыла к нему доступ сторонним администраторам для применения в локальных средах. Firecracker сочетает изоляцию и безопасность уровня ВМ с мобильностью контейнеров и хорошо подходит для кратковременных или событийных рабочих нагрузок, таких как бессерверные вычисления, или других задач, где требуется несколько уровней изоляции и защиты. Основой Firecracker является модуль KVM, встроенный в Linux, что позволяет ему запускать ВмМ в невиртуализированных средах.
Как применять AWS Firecracker
Отдав предпочтение ВмМ в качестве предпочтительных инструментов для обслуживания рабочих нагрузок, администраторы сразу же могут приступать к их созданию при помощи AWS Firecracker. Он предоставляет администраторам минималистичный дизайн, который снижает требования к памяти и лучше защищает от вредоносных атак. Вначале следует загрузить двоичные файлы Firecracker, затем распаковать сжатый файл ядра Linux, который может служить гостевой ОС. Помимо этого требуется корневая файловая система, например, подойдет образ файловой системы ext4. Следующий шаг — открытие двух оболочек командной строки: одна предназначается для запуска Firecracker, другая — для записи в его API. Обе оболочки должны работать в одном каталоге с двоичными файлами Firecracker. После выполнения этих шагов администраторам потребуется запустить гостевую машину. Чтобы сделать это, ядро гостевой ОС и гостевую корневую файловую систему нужно установить во второй оболочке. Затем администраторы могут вернуться к первой оболочке, выполнив вход на гостевую машину.
