Вступ до Amazon Fargate: що це таке, чому він чудовий (і ні), і коли ним користуватися.

Коли Amazon оголосив Fargate наприкінці 2017 року на AWS re: Invent (разом з EKS), він справді потрапив під радари. Жоден з блогів чи впливових агентів, за якими я тоді стежив, насправді не говорив про це, окрім чогось у тому плані:

О так, і є нова річ, яка дозволить користувачам ECS запускати контейнери безпосередньо в хмарі.

Як розробник, це справді вразило мене. Подивимось чому.

Бум продуктивності

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

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

  • Поява хмарних служб (IaaS)

    Вартість інфраструктури та масштабованість

  • Спільнота з відкритим кодом, конференції, семінари, технічні блоги, переповнення стеку тощо

    Обмежений доступ до знань

  • Системи версій, інструменти співпраці, інструменти безперервної інтеграції

    Паралельна розбіжність системних розбіжностей та пекло інтеграції

  • Контейнерна архітектура

    Складність у побудові додатків у несумісних середовищах

  • Безсерверні обчислювальні послуги (PaaS)

    Адміністрування серверів та систем

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

Чудово , але зачекайте - де Фаргейт у всьому цьому?

Проблема у вашому кораблі

Побачте, коли Докер приніс контейнери в маси, це швидко стало новим стандартом у розробці і було широко прийнято.

Незабаром і після успіху Kubernetes AWS запустила власну (більш базову) службу управління контейнерами: Amazon Elastic Container Service (ECS). Він ввів поняття Завдання.

Завданням може бути будь-який екземпляр контейнерів, що працюють разом. Від веб-програми, яка запускає веб-сервер, кілька мікросервісів, базу даних та зворотний проксі-сервер, до списку пакетів сценаріїв оболонки, які періодично запускатимуться.

Будучи раннім впровадником ECS, мені це дуже сподобалось, і якийсь час він чудово працював. Але врешті-решт, керувати цими додатковими рівнями (Завданнями та контейнерами) замість лише екземплярів EC2 ставало дедалі складнішим.

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

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

Оскільки ваші завдання будуть розгорнуті випадковим чином (за замовчуванням) на однотипних екземплярах EC2 із доступними ресурсами , ви стикаєтесь із такими проблемами:

  • Один кластер дотримується однакових правил автоматичного масштабування та автоматично надає однакові екземпляри EC2.
  • Деякі контейнери потребуватимуть абсолютно різних ресурсів, але все одно доведеться працювати разом.
  • Деякі контейнери не обов'язково дотримуються однакових правил для автоматичного масштабування.
  • Іноді декілька контейнерів в одному і тому ж завданні потребують власного балансувача навантаження, і наявність декількох балансирів навантаження для одного завдання неможливе.

Найкращим способом вирішення цих проблем було:

  • вручну розгорнути деякі з ваших примірників з різними ресурсами залежно від потреби
  • приєднати ці екземпляри до вашого кластера
  • запустити один контейнер за завданням
  • зв’яжіть свої екземпляри EC2 вручну разом
  • написати складні обмеження розміщення стратегії на ECS, щоб переконатися, що правильне завдання було на правильній машині, яка мала відповідний ресурс, залежно від того, що вона зробила

Це дуже багато роботи, це досить нудно і важко підтримувати. І це начебто перемагає мету роботи з контейнерами.

Хтось повинен був придумати кращу ідею.

Нехай плавають

Як виявляється, у команди AWS були ті самі проблеми. Вони думали над цим протягом останнього року і працювали над вирішенням наведеної нижче проблеми:

Як ми могли запускати контейнери, не турбуючись про сервери та кластери?

І саме про це йдеться у AWS Fargate . Він повністю абстрагує базову інфраструктуру, і ви бачите кожен ваш контейнер як єдину машину.

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

Це все одно, що ваші контейнери стають кораблями з власним вітрилом, кермом та екіпажем і можуть самостійно плисти до місця призначення.

Контейнери як послуга (CaaS)

Я насправді вважаю, що Containers as a Service (CaaS) - це справжній PaaS, на який розробники чекали роками. Це дозволяє розробникам розгортати свої контейнери безпосередньо в хмарі, не турбуючись про все, що між ними.

Звичайно, існує вже безліч технологій, які дозволяють безперешкодно запускати ваш код у хмарі, не турбуючись про масштаби або адміністрування сервера (наприклад, дивовижний Heroku , Lambda або навіть по-своєму механізм додатків Google) . Але всі мають обмеження.

  • Ви повинні вибрати між втратою трохи гнучкості
  • Ви повинні дотримуватися підтримуваних мов
  • Ви не можете використовувати підтримувані мови, оскільки для вашого проекту потрібна власна низькорівнева бібліотека, яка доступна лише в дуже конкретних системах
  • У вашому проекті використовується передова технологія, яка не буде доступна широким мас у найближчі кілька років
  • Деякі з цих платформ дуже (дуже) дорогі, особливо при масштабуванні

Fargate (або CaaS) приносить вам найкраще з обох світів.

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

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

Безсерверне розгортання дозволяє зосередитися на написанні чудового коду. Без резервування, легке масштабування.

Межі

CaaS проти PaaS

Це правда, що ви відмовляєтесь від деяких цікавих аспектів справжнього PaaS. Так, вам все одно доведеться вручну оновлювати зображення вашого контейнера, а іноді вам доведеться писати власні зображення Docker. Спочатку це може бути боротьбою, якщо ви не знаєте основ системного адміністрування .

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

Вартість

Погодьмось, хмарні послуги (IaaS) дорожчі, ніж наявність власної інфраструктури (якщо ви зможете масштабувати її за запитом). З тієї ж причини відсутність необхідності надавати, керувати та масштабувати ваші сервери має вартість. Це може бути ще не найкращим рішенням для деяких найпростіших випадків використання.

Будемо сподіватися, що вони будуть працювати над зниженням вартості. Наскільки хороший продукт, важко виправдати майже в 4 рази ціну еквівалента екземпляра EC2 на вимогу (наприклад, для t2.medium).

Чи слід перемикати всі мої завдання ECS на Fargate?

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

Однак Fargate може бути для вас більш корисним у наступних випадках використання:

  • Якщо у вас є проблеми з автоматичним масштабуванням ваших завдань ECS ефективно, і часто в результаті виходить багато невикористаного процесора або пам'яті . За допомогою Fargate ви платите лише за ресурси, які ви визначили у своїх завданнях .
  • Для ваших завдань, які будуть виконуватися на вимогу або за розкладом і не потребують виділеного екземпляра EC2. За допомогою Fargate ви платите лише тоді, коли виконується ваше завдання.
  • Для ваших завдань, які мають максимальне використання пам'яті та / або процесора . Просто тому, що це заощадить ваш час та клопоти з налаштуванням та керуванням такими справами.

Бонус

Для тих, хто віддає перевагу Kubernetes перед ECS , Fargate незабаром зможе запустити службу еластичних контейнерів для Kubernetes.