Почему контейнеры «убьют» виртуальные машины?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

Традиционно у вас есть 3 основных варианта: 

  • собственный железный сервер

  • хостинг виртуальной машины 

  • облачные сервисы наподобие Amazon EC2 

- Если вам нужна высокая производительность, вы точно знаете, сколько вычислительных ресурсов вам нужно (проект уже “устоялся”), а главное, в штате есть человек по администрированию инфраструктуры, логично выбрать аренду или покупку железного сервера. 

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

- Если у вашего сервиса невысокая нагрузка и у вас есть свободное время на небольшое администрирование, логично выбрать виртуальную машину. Особенно если есть желание «разделить» инфраструктуру с другими пользователями и не платить за то, чем не пользуетесь. 

Но что если: 

  • проект не такой большой, чтобы платить серьезные деньги за облако по типу Amazon, 

  • вы не хотите тратить человеческий ресурс на администрирование инфраструктуры 

  • и хотите большую масштабируемость, чем у железного сервера? 

Вот как раз в этом случае и пригодятся контейнеры.

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

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

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

Один Docker-контейнер, конечно, хорошо, но что делать, если их много? И тут на помощь приходит Kubernetes, который умеет их оркестрировать. Kubernetes управляет «расписанием» (определяет, когда запускать тот или иной сервис) и распределяет нагрузку на серверы, чтобы вычислительные ресурсы расходовались оптимально. Это похоже на морской танкер, везущий контейнеры, где каждому выделено определенное место. Нагрузка между контейнерами на танкере распределяется так, чтобы физическая инфраструктура использовалась оптимальным образом и танкер не “перевернулся”. Программист, как заказчик перевозки, просто загружает контейнеры, а Kubernetes, как капитан танкера, делает все остальное.

Чем же контейнеры лучше виртуальных машин? 

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

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

Преимущества контейнеров в сравнении с виртуальными машинами: 

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

- Надежность. Если контейнер, содержащий функцию вашего проекта «упадет», Kubernetes его просто автоматически перезапустит. А если вы используете дублирование, то и вовсе не заметите отказа в работе ваших приложений. С виртуальной машиной вам придется перезапускать весь сервис, а не отдельный модуль.

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

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

За счет простоты в использовании и меньшим требованиям к аппаратным ресурсам, контейнеры вытесняют виртуальные машины для большой части задач. Так, согласно исследованию компании DataDog доля компаний (среди их клиентов), использующих Docker-контейнеры, уже превысила 25%.

Динамика проникновения Docker
Динамика проникновения Docker

Однако есть нюанс контейнерной архитектуры: если с одним docker-контейнером все просто, то Kubernetes уже нужно настраивать и администрировать.

Возникает вопрос, как упростить эту задачу.

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

Либо, если вы хотите кардинально упростить себе жизнь, можно воспользоваться облаками, заточенными под контейнеры. К таким относится американский сервис Heroku и сервис, который развивает наша команда, – Amvera. В этих сервисах можно просто выбрать нужное количество контейнеров/инстансов и развернуть сервисы через push кода в выделенный GIT-репозиторий. После чего облако само развернет решение и подключит балансировщик нагрузки к контейнерам. 

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

Вы просто отправляете PUSH в GIT-репозиторий - а Amvera сама развертывает ваши обновления и настраивает конфигурации серверов. 

Начать пользоваться ресурсами Amvera можно бесплатно. Мы запускаемся и проводим закрытое бесплатное бета-тестирование. Оно нужно нам для получения обратной связи по продукту. Будем рады, если вы примете в нем участие! 

Для участия в бесплатном бета-тесте вам необходимо зарегистрироваться в личном кабинете Amvera. После регистрации будет автоматически начислена 1 т.р. на использование сервиса. Если у вас высоконагруженный проект, напишите нам, и мы в рамках бета-теста выделим дополнительные бесплатные вычислительные мощности. Обещаем, что после завершения бета-теста (январь 2023 г.), сервис будет не дороже простой виртуальной машины, если вы захотите продолжить его использование. 

Ссылка на бесплатные вычислительные мощности для вашего проекта: https://amvera.ru/betatest

Источник: https://habr.com/ru/company/amvera/blog/696304/


Интересные статьи

Интересные статьи

Поскольку глобальные объёмы данных теперь измеряются в зеттабайтах и ​​быстро растут, вопрос о миграции в облако в 2022 году звучит не «зачем?», а «когда и как?», и отказ от переноса критически важн...
По данным Pyrus, системы для создания единой корпоративной среды, отслеживающей активность сотрудников, почти половина работников не выполняет задачи к дедлайнам. Это в больших компаниях, а в секторе ...
Говоря о разработке сайтов с использованием CMS 1C Bitrix вопрос покрытия тестами поднимается редко. Главная причина в том, что большинство проектов обходится штатным функционалом, который предоставля...
Короткая предыстория 6 мая 1937 года самый большой дирижабль в мире, «Гинденбург», сгорел при посадке на американской авиабазе Лейкхерст. Трагедия была ужасной, в ней погибло 36 ч...
Приветствую вас (лично вас, а не всех кто это читает)! Сегодня мы: Создадим приложение (навык) Алисы с использованием нового (октябрь 2019) сервиса Yandex Cloud Functions. Настроим н...