что это такое, почему он отличный (нет) и когда его использовать.

1656599773 chto eto takoe pochemu on otlichnyj net i kogda ego

Когда Amazon анонсировал Fargate в конце 2017 года на AWS re:Invent (вместе с EKS), это действительно попало под радар. Ни один из блогов или инфлюэнсеров, за которыми я следил в то время, на самом деле не говорил об этом, кроме как:

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

Как разработчика, это поразило меня. Давайте посмотрим почему.

Бум производительности

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

Все они тоже решали серьезные вопросы. Вот моя разбивка революций и проблем, которые они решили:

  • Появление облачных сервисов (IaaS)
    Стоимость и масштабируемость инфраструктуры
  • Сообщество с открытым кодом, конференции, семинары, технические блоги, переполнение стека и т.д.
    Ограниченный доступ к знаниям
  • Системы версий, инструменты совместной работы, средства непрерывной интеграции
    Параллельная инженерия Системы несоответствия и интеграции ад
  • Контейнерная архитектура
    Трудности с созданием приложений в непостоянных средах
  • Бессерверные вычислительные услуги (PaaS)
    Администрирование серверов и систем

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

Прекрасно, но подождите — где Фаргейт во всем этом?

Ваш корабль – это проблема

1*o5kiw7FwodkMegfRDNfktg
Рекомендуется спасательный жилет

Смотрите когда Docker принес контейнеры массам, он быстро стал новым стандартом в разработке и был широко принят.

Вскоре после этого и после успеха в Kubernetes, AWS запустила собственную (более базовую) службу управления контейнерами: Amazon Elastic Container Service (ECS). В нем было введено понятие задач.

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

Поскольку я рано принял ECS, мне это очень понравилось, и некоторое время он отлично работал. Но в конце концов придется управлять ими дополнительные слои (Задачи и контейнеры) вместо экземпляров EC2 становились все сложнее.

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

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

Потому что ваши задачи будут развернуты случайным образом (по умолчанию) на одном и том же типе Экземпляры EC2 с доступными ресурсамивы сталкиваетесь со следующими проблемами:

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

Желательным обходом для решения этих проблем было:

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

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

Кто-то должен был придумать лучшую идею.

Пусть плывут

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

Как мы можем запускать контейнеры, не беспокоясь о серверах и кластерах?

И именно об этом AWS Fargate. Он полностью отвлекает базовую инфраструктуру, и вы видите каждый из ваших контейнеров как единственную машину.

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

1*aLMrzsEK-E9EGIjxXvQ48Q
контейнеры на Fargate (художественный рендеринг)

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

Контейнеры в качестве услуги (CaaS)

Я на самом деле в это верю Контейнеры как услуга (CaaS) – это настоящий PaaS чего разработчики ждали годами. Это позволяет разработчикам разворачивать свои контейнеры непосредственно в облаке, не беспокоясь обо всем, что между ними.

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

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

Fargate (или CaaS) принесет вам лучшее из обоих миров.

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

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

Бессерверное развертывание позволяет сосредоточиться на написании великолепного кода. Нет предоставления, простое масштабирование.

Границы

CaaS против PaaS

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

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

Стоимость

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

Будем надеяться, что они будут работать дальше снижение стоимости. Как бы продукт ни был хорошим, его трудно оправдать почти в 4 раза дороже эквивалентного экземпляра EC2 по требованию (например, для t2.medium).

1*_GhNwtmR-m63DOx6b9GXDg
Сравнение цен Fargate и EC2 в долларах США

Нужно ли переключать все задачи ECS на Fargate?

Еще нет. Как указано выше, в некоторых случаях вы собираетесь более чем втрое увеличить свои расходы. Пока они не снизят стоимость, возможно вам лучше использовать стандартные инстанции EC2.

Однако Fargate может быть более полезен для вас в следующих случаях:

  • Если у вас возникли проблемы с эффективным автоматическим масштабированием ваших задач ECS и часто в конечном счете остается много неиспользованных ЦБ или память. С Фаргейтом, ты платите только за ресурсы, которые вы определили в своих задачах.
  • Для ваших задач, которые будут выполняться по желанию или по графику и не требуется специальный экземпляр EC2. С Фаргейтом, ты платите только при выполнении вашего задания.
  • Для ваших задач, которые имеют пиковое использование памяти и/или ЦБ. Просто потому, что это сэкономит вам время и заботы, связанные с настройкой и управлением такими делами.

Бонус

Для тех, кто предпочитает Kubernetes закончено ECSFargate в скором времени сможет запустить Elastic Container Service для Kubernetes.

Добавить комментарий

Ваш адрес email не будет опубликован.