Обычно, выступая в роли разработчиков, мы часто зацикливаемся на фазе разработки с его изысканиями, анализом, проверками и действиями по сборке.

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

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

Предоставление (рrovisioning) - также именуемое как создание набивки. Программное обеспечение нуждается в компьютерах и запущенных на них ресурсах. Гарантия того что доступно достаточно вычислительных ресурсов - а также их создание если это не так - это важная его часть. На самом деле нам требуются не просто машины или экземпляры; при развёртывании прикладных приложений в имеющемся облачном решении нам также могут потребоваться прочие физические или виртуальные инфраструктуры, такие как:

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

Управление выпусками. Большинство систем требуют регулярного сопровождения и продолжающейся разработки, которые подразумевают некую наступающую потребность развёртывания - или выпуска (release) - более новых версий. Обычно мы бы желали иметь возможность выполнять выпуски просто, с повтором в любое время, а также с минимальным или вовсе без оного воздействием на пользователей данной системы. Это может достигаться посредством автоматизации, хорошего инструментария и таких техник как сине- зелёные развёртывания или канареечные выпуски. Кроме того, когда дела идут не так как хотелось бы, сама возможность отката обратно к хорошо зарекомендовавшей себя версии имеющегося программного обеспечения может быть не доступна.

Мониторинг и оповещения. В мире мечты наше приложение, будучи развёрнутым единожды, как ожидается, будет исполняться вечно. На практике, однако, дела идут не так: серверы падают, программное обеспечение имеет ошибки, а наши предположения не всегда соответствуют истине. Вместо того чтобы прятать свои головы в песок, мы активно предпринимаем шаги для того чтобы знать состояние своего программного обеспечения и того насколько хорошо оно работает. Это обычно вовлекает отслеживание измерений жизнеспособности данной системы и получения оповещений когда дела начинают идти не так.

Работа. При повседневном исполнении промышленных систем существуют некоторые общие моменты, которые нам приходится выполнять: масштабирование для отработки растущих нагрузок, снижение масштаба для снижения затрат, проблемы диагностирования и отладки и в целом сохранение всего включённым. Умные команды операторов пытаются автоматизировать всё что только возможно для минимизации человеческих ошибок и высвобождения своего времени с тем, чтобы они могли быть активными вместо того чтобы постоянно тушить пожары.

Принятие Docker меняет наше представление о многих из этих областей.

Возьмём в качестве примера управление настройкой. Несмотря на чрезвычайную популярность таких инструментов как Chef, Puppet или Ansible, их роль в мире с контейнерами рассматривается как снижающаяся. При использовании Docker каждая часть программного обеспечения имеет свои зависимости, встроенные в её образ, изолируя их от аналогичной в другом контейнере. Это впечатляющим образом упрощает имеющиеся проблемы. Поскольку зависимости уровня приложения управляются самим этим приложением, в его Dockerfile, настройка экземпляров вашей инфраструктуры в основном просто некий вариант гарантии того что Docker установлен.

Как мы вскорости обнаружим, Docker также имеет и прочие последствия, в особенности относительно того как мы выпускаем своё программное обеспечение и работаем с ним.

Docker изменил имеющийся ландшафт Ops двумя ключевыми способами. Прежде всего, его встроенный механизм доставки - возможность запихивать (push) образы в некий Реестр Docker и вытаскивать (pull) их обратно по мере необходимости - решает множество вопросов: как я получаю сво программное обеспечение на соответствующей целевой машине? Во- вторых, контейнеры позволяют нам гигантским образом не сопоставимое программное обеспечение в сущности одним и тем же способом; мы можем применять один и тот же механизм для запуска, останова и перезапуска контейнеров, вне зависимости от того что им приходится исполнять.

Такая стандартизация, как в терминологии механизма доставки, так и того как управлять программным обеспечением, придаёт новый облик тому способу, которым мы думаем об операциях. Сам фокус смещается на то как мы настраиваем, запускаем и обновляем множество контейнеров, которые составляют некое приложение во взаимодействии (in concert), некий процесс именуемый как оркестрация (контейнеров).

Новое племя инструментов возникло в помощь оркестрации нашего прикладного приложения контейнеров; они именуются (что не достаточно креативно) оркестраторами.

Итак, что же оркестраторы нам предоставляют? Прежде всего, они дают некую среду и платформу в которых мы можем исполнять приложения в контейнерах и управлять ими. Он делают это создавая некий уровень абстракции поверх самих (физических или виртуальных) серверов, требующихся для исполнения данного программного обеспечения. При развёртывании приложений более удобно представлять себе нашу группу "вычислительных" серверов как некий единый логический элемент: кластер. Это позволяет нам произносить вещи наподобие, "Давайте развернём это приложеие в кластере", не заботясь о том как это будет развёрнуто или в точности в каком именно экземпляре - мы можем (как правило) позволить своему уровню оркестрации обработать эти подробности для нас.

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

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

Так как оркестраторы понимают желательное состояние, они способны быть интеллектуальными и намного более устойчивыми к сбоям. Если некий код в одном из наших контейнеров разрушается по какой- то причине, сам оркестратор способен автоматически повторить его запуск/ Если некий узел целиком отказывает в нашем кластере, то есть, все имеющиеся в нём контейнеры пропали, опять же, сам оркестратор может восстановить и запустить новые заменяющие контейнеры в остающихся узлах.

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

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

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

В настоящее время существуют два конкурирующих уровня оркестрации, которые могут применяться с Docker: Swarm и Kubernetes. Оба имеют много схожего, но также и существенные различия.

Swarm (или режим Swarm - роя) - сделанное самостоятельно Docker решение - было встроено в механизм Docker начиная с версии 1.12, следовательно вы его уже установили. Хотя и потребуется некоторое время для его подготовки к промышленному применению, Swarm в настоящее время представляет собой некий зрелый, способный, без лишних церемоний оркестратор. Хотя он и упускает одно или два желательных свойств (таких как автоматическое масштабирование), он является продуманной частью программного обеспечения и помещает гигантскую мощность вам в руки. Вы получите опыт Swarm из первых рук в последующих главах. {Прим. пер.: к сожалению, здесь наши интересы расходятся. Нас зачаровало данное описание практики работы с Docker. Тем не менее, наше видение дальнейшего внедрения получаемых приложений Docker связано с применением Kubernetes, для которого мы пока не встречали руководство по практике работы с контейнерами подобного уровня. Если же вы, читатели, полагаете что данный перевод следует продолжить, обращайтесь к нам.}

Другим крупным игроком выступает Kubernetes, который является неким инструментарием с открытым исходным кодом, созданным Google, но теперь находящимся под попечительством CNCF, (Cloud Native Computing Foundation). Kubernetes не только поддерживает автоматическое масштабирование, но также предоставляет и дополнительный контроль над тем как проектируется ваше приложение. Тем не менее, этот богатый набор свойств и выразительных возможностей имеет некую цену: он значительно более сложен чем Swarm, требует больше усилий для изучения, а его файлы настроек гораздо более обширные. Кроме того, установка Kubernetes вручную может быть сама по себе более продолжительной и сложной задачей. {Прим. пер.: см. наш перевод 2 издания Полного руководства Kubernetes Джиджи Сэйфана.}

Kubernetes и Swarm имеют аналогичную архитектуру на верхнем уровне. Оба различают исполнительные узлы на которых запускаются контейнеры и узлы диспетчеры, которые управляют исполнителями и выполняют в них оркестрацию. Одним заметным отличием является то, что узлы диспетчеры могут запускать контейнеры рабочей нагрузки дополнительно к своей роли управления и оркестрацией кластера, в то время как узлы диспетчеров Kubernetes не могут делать этого. Также следует отметить, что Kubernetes в настоящее время применяет обидную терминологию хозяин/ подчинённый (master/ slave) для обозначения узлов диспетчеров и исполнителей, хотя я надеюсь, что это вскоре будет изменено.

При изучении выбора между Swarm или Kubernetes, ключевым является получение основ их концептуальных моделей. Хотя и имеются схожести, каждый из них требует привыкания. К примеру, Swarm имеет понятие стека, который представляет само приложение как группу лежащих в основе служб. С другой стороны Kubernetes делает дальнейшее разбиение на некое Развёртывание (Deployment), составляемое из Наборов реплик (ReplicaSets), который в свою очередь состоят из Подов.

Вот итоговое представление на очень верхнем уровне этих двух решений:

Таблица 1-1. Права доступа

	Swarm	Kubernetes
Открытый исходный код	Да	Да
Разработан	Docker	Google
Отслеживается	Docker	CNCF
Установка	Простая	Сложная
Кривая изучения	Лёгкая	Трудная
Набор свойств	Меньший	Больший
Встроенное автоматическое маштабирование?	Нет	Да
Поддержка сообщества	Хорошая	Исключительная

Хотя Swarm всё ещё имеет своё место, Kubernetes выглядит как получивший большую тягу, а также долю внимания, и быстро становится де факто стандартом оркестрации. На самом деле, в знак признательности, Docker добавил встроенную поддержку Kubernetes сразу после установки. На самом деле вопрос противопоставления Swarm и Kubernetes не стоит вовсе: не лишним будет потратить время на ознакомление с обоими доступными вам вариантами.

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

Один окончательный момент: Swarm и Kubernetes являются двумя главными оркестраторами, некоторые поставщики услуг хостинга имеют и свой собственный уровень оркестрации специфичный для их платформы - отметим Amazon ECS (Amazon Elastic Container Service).

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

Первым базовым предложением являются платформы - именуемые как IaaS (Infrastructure as a Service). Они предоставляют вам строительные блоки нижнего уровня для создания той среды, в которой будут исполняться ваши приложения. Как вы могли бы ожидать, это предоставляет вам наибольшую гибкость и персонализацию в терминах подгонки вашей среды под ваши нужды. Однако, вам придётся проделывать всю работу по предоставлению ваших экземпляров, их настройке и установке вашего уровня оркестрации.

Последние - именуемые как платформы CaaS (Containers as a Service) - самая близкая к Heroku вещь в мире контейнеров. Они позволяют вам сосредоточиться на своём приложении и мало заботиться о той инфраструктуре, на которой оно исполняется. Для большинства это наиболее популярный вариант для начала. С его помощью быстро получается нечто запущенное и исполняемое, а вы самой платформой разгружены от множества обязанностей, в том числе многих вопросов относительно безопасности. Однако всё это получается за счёт меньших гибкости и персонализации - вы ограничены теми возможностями, которые выставляются вам самой платформой.

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

Далее мы рассмотрим некоторые варианты инструментов обеспечения инфраструктуры IaaS, если это тот путь, которым вы намерены двигаться, прежде чем кратко ознакомимся с крупными игроками в пространстве CaaS.

Если вы намерены идти путём IaaS, в теории вам может подойти любой поставщик облачных решений; они просто предоставляют ту сырую инфраструктуру, в которой вы можете запускать поверх свои собственные контейнеры Docker.

Вот некоторые крупнейшие игроки, о которых вы скорее всего уже слышали:

Тем не менее, вам придётся обеспечить свою инфраструктуру, а в частности, те экземпляры, в которых будут установлены Docker и ваш уровень оркестрации. Существует ряд инструментов, которые помогут вам в этом начинании.

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

Машина Docker применяет соответствующий шаблон адаптера, предоставляя различные драйверы, способные создавать экземпляры в широком диапазоне платформ. Вскорости мы воспользуемся этим для создания локальных экземпляров VirtualBox с последующим созданием инфраструктуры на основе облачного решения.

Порой вам требуется предоставлять больше нежели просто экземпляры. Возможно у вас имеются безопасные контейнеры, которые следует усилить, либо могут иметься специфические сетевые требования, которые вовлекают само создание сетевых устройств (межсетевых экранов, шлюзов NAT и тому подобного) с некой особой организацией. В таком случае Машины Docker самой по себе может оказаться недостаточно;вам придётся в помощь себе дополнительные инструменты.

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

Кроме того, все эти инструменты предшествовали Docker - в особенности Puppet (2005) и Chef (2009) - поэтому они не были рождены в том мировоззрении, которое включало в себя контейнеры. Тем не менее, они всё ещё могут применяться для раскрутки некого кластера с Docker и для вашего уровня оркестрации, но в зависимости от ваших потребностей это может оказаться излишним.

Выпущенный в 2015, годом позже Docker, Terraform HashiCorp относительный новичок на рассматриваемой сцене. Вместо того чтобы выступать в роли полноценной системы настройки, он рассматривает себя в качестве некого оркестратора инфраструктуры с более скромной целью предоставления и обновления вашей инфраструктуры неким безопасным, контролируемым образом.

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

Теперь, когда мы сделали краткий обзор своих вариантов при выборе сборки поверх IaaS, давайте переключим своё внимание на пространство CaaS (Container as a Service).

Как мы уже обсуждали, предложения CaaS позволяют вам достичь желаемого запуска гораздо быстрее. Они предоставляют некую службу управления, которая выступает отправным пунктом возможностей платформы по исполнению приложений Docker.

В этой области Kubernetes король. Это доминирующая служба оркестрации, предоставляемая поставщиками. Это означает, что раз у вас имеется поднятым и исполняемым ваш кластер рабочей нагрузки Kubernetes, вы взаимодействуете с ним через команду kubectl для развёртывания, обновления и масштабирования своего приложения. Аналогично вы настраиваете манифесты, которые описывают те службы, которые вы желаете исполнять и то как они должны подключаться чтобы предоставлять формат Kubernetes.

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

Необычным в этом списке выступает Amazon ECS (Amazon Elastic Container Service) выпендривающийся собственным уровнем оркестрации контейнеров Amazon вместо Kubernetes.

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

Сама служба может управляться через Консоль диспетчера AWS, или через ECS CLI, которые обе позволяют вам предоставлять необходимую инфраструктуру. Дополнительно к этому также может применяться CloudFormation - частный язык предоставления инфраструктурой Amazon.

В ECS вы описываете свои контейнеры приложений с помощью файлов настройки, именуемых определениями задач в формате JSON. Это предоставляет совместимость с файлами Compose - с некоторыми предостережениями - что может позволять вам обходить естественный формат определения задач.

Несмотря на совместимость с Compose нет необходимости разбираться в потребностях понимания концептуальной модели ECS, которая содержит в ECS головокружительные прелести кластеров, служб, задач, ALB (Application Load Balancers) и ELB (Elastic Load Balancers), VPC и много иного.

GKE (Google Kubernetes Engine) предоставляет реальную модель CaaS, которая позволяет вам забыть обо всём лежащем в основе оборудовании. Он предоставляет полностью управляемый кластер, а это означает что они после запуска следят за работой инфраструктуры и гарантируют сохранение работоспособности кластеров.

Создание некого базового кластера осуществляется при помощи короткой ясной команды- например:

​ 	​$ ​​gcloud​​ ​​container​​ ​​clusters​​ ​​create​​ ​​guestbook​​ ​​--num-nodes=3​
		

Что сообщает, "Создай новый кластер именуемый guestbook из трёх узлов" и, как вы и ожидали, GKE обработает само создание данной инфраструктуры для вас. Существует множество прочих доступных конфигураций кластеров, таких как кластеры со множеством регионов.

GKE выглядит наиболее зрелым, дружественным пользователю предложением в данном пространстве - что не является сюрпризом, поскольку Kubernetes был создан Google.

Ключевым недостатком Amazon EKS (Amazon Elastic Container Service for Kubernetes) на момент написания является его ограниченная доступность - в настоящее время только в областях в Северной Вирджинии, США (us-east-1), Орегоне, США (us-east-2) и Огайо, США (us-east-3). Тем не менее,несомненно это со временем улучшится.

В отличие от GKE здесь просачиваются базовые основы AWS. К примеру, так как для EKS требуется возможность создания в ваше распоряжение Amazon EC2 (Amazon Elastic Compute Cloud), вам придётся создать некую роль службы IAM (AWS Identify & Access Management) с верными полномочиями для начала работы с EKS.

Это становится очевидно в самой команде создания кластера:

​ 	​$ ​​aws​​ ​​eks​​ ​​create-cluster​
​ 	  --name prod \
​ 	  --role-arn \
​ 	    arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleFor... \
​ 	  --resources-vpc-config \
​ 	    subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18
		

где, вновь, просачиваются такие понятия AWS как роли IAM, идентификаторы подсети и группы безопасности. Общеизвестно, что большпя часть из этого будет предварительно наполнена если вы создаёте свой кластер из Консоли AWS; однако, эти настройки могут быть пугающими и слегка отталкивающими для непосвящённых. Тем не менее, мы получаем кластер с высокой доступностью, распределённый по различным Зонам доступности (AZ, Availability Zones).

EKS имеет тенденцию работать с ценами дороже прочих предложений, в частности, за счёт того, что Zmazon взимает плату 0.20$/час за свой уровень управления кластером.

AKS (Azure Kubernetes Service) является солидным конкурентом, но скорее всего на втором месте по отношению к GKE с точки зрения возможностей и простоты в применении.

Вот для сравнения команда по созданию кластера:

​ 	az aks create \
​ 	    --name myAKSCluster \
​ 	    --resource-group myResourceGroup \
​ 	    --node-count 1 \
​ 	    --generate-ssh-keys \
​ 	    --service-principal <appId> \
​ 	    --client-secret <password>
		

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

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

Amazon выделяется из прочих в этой группе. ECS имеет собственный частный уровень оркестрации, а EKS требует больше работы вручную для получения вашего кластера поднятым и запущенным. Оба выставляют присущие только AWS особенности внутреннего строения, предоставляя вам больше гибкости за счёт простоты в применении, которую вы обычно ожидаете от управляемой службы.

Основными причинами для того чтобы следовать за платформами Amazon являются:

Если у вас не имеется такого багажа и вы просто желаете зайти и быстро всё запустить, я бы рекомендовал в качестве отправной точки Google Kubernetes Engine. Он кажется наиболее зрелым предложением и Kubernetes начинал свою жизнь в Google.

Относительно названия безсерверных вычислений было высказано множество мнений ^{[1, 2, 3]}, но оставляя это в стороне, существует растущая потребность для ещё более абстрактных служб.

Получая популярность за счёт таких служб как Amazon AWS Lambda, Безсерверные вычисления стали синонимом для FaaS (Functions as a Service). Вы предоставляете для исполнения некий код при возникновении некого события и сама платформа заботится о том как и где его исполнять. Хотя тот код, который вы поставляете обычно за сценой включается в контейнеры, это некие подробности реализации, о которых вам не стоит беспокоиться. Преимуществом данной модели является то, что вы полностью устраняете потребность в инфраструктуре предоставления, а масштабирование выполняется автоматически на основе загруженности.

Тем не менее, основной тёмной стороной является то, что вы ограничены имеющимися языками и инструментами, поддерживаемыми такими платформами FAAS. Если вместо поддержки файлов сырого кода вы предоставите свои собственные образы Docker, вы получите все преимущества Docker, но с меньшим числом ограничений времени исполнения. Вместо того чтобы быть ограниченным самой платформой, вы обладаете полным контролем относительно того какие языки программирования и инструменты использует ваш код.

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

AWS Fargate является новой платформой Amazon, которая раскручивает безсерверные вычисления в своих службах ECS и EKS. И ECS, и EKS, по умолчанию, требуют неких этапов работы вручную по созданию необходимых экземпляров EC2, которые будут исполнять сами контейнеры. Fargate представляет собой замещающий вычислительный механизм для ECS и EKS, который удаляет необходимость в том чтобы задумываться об экземплярах сервера и управлять ими.

Как это работает на практике? Вы определяете свои контейнеры, а также настройки относящиеся к тому как эти контейнеры должны управляться во время исполнения. На основе установленных вами параметров значений ЦПУ и оперативной памяти Fargate будет автоматически масштабировать ваши контейнеры верх или вниз на основе загруженности; вам нет нужды заботиться о том где или как они запускаются.

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

Хотя Fargate удаляет много тяжести из самой оркестрации исполнения контейнеров в промышленном применении, как и в случае с AWS EKS, вам всё ещё придётся иметь некое взаимодействие с лежащими в основе службами AWS для настройки своей сетевой среды и определения политик безопасности.

Ценообразование Fargate основывается на использовании виртуальных ЦПУ и памяти, а в настоящее время это составляет от двух- до шести- кратного превышения чем исполнение экземпляра EC2. Данный зазор ещё существеннее если вы рассматриваете вариант того что некий экземпляр EC2 способен запускать множество контейнеров. Следовательно, хотя это и интересная служба для её отслеживания, её стоимость должна пойти вниз прежде чем она получит настоящий импульс.

ACI (Microsoft Azure Container Instances) является намного более ограниченным видом Безсерверной обработки для контейнеров. Они не могут применяться для запуска станартных приложений в контейнерах, как и те приложения Rails, которые мы собирали на протяжении данной книги. Вместо этого они предназначены для приложений, которые изначально создавались в виде безсерверных; это подходит для дискретных задач (таких как обработка данных) или движимых событиями приложений.

Как и в случае Fargate, ценообразование основывается на использовании виртуальных ЦПУ и памяти, причём обе службы стоят примерно одинаково.

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

Вот те компромиссы, из которых вам предстоит делать выбор:

Сопоставление разового платежа и долговременной стоимости. Стоимость элемента обычно растёт с их количеством, подлежащим управлению; IaaS обычно дешевле чем CaaS, которые в свою очередь дешевле Безсерверного обслуживания. Тем не менее, чем меньше управления, тем больше требуется разовых инженерных усилий. Зачастую именно более крупные, более устоявшиеся компании идут путём IaaS; у них достаточно богатые потребности в карманных запасах и больше уверенности в том, что они будут представлены достаточно продолжительно чтобы извлечь выгоду из многолетней экономии средств. Для компаний меньшего размера, а в особенности стартапов, такие первоначальные затраты трудно обосновать, если только они не дают ключевых конкурентных преимуществ.

Сосредоточенность и производительность разработчика. Аналогично стоимости, можете ли вы себе позволить потратить время и усилия на создание своей платформы поверх IaaS вместо того чтобы просто работать быстрее с некоторой управляемой службой? Общая мудрость состоит в том, что вам следует сосредоточиться на том, что делает ваш продукт уникальным - в большинстве случаев это не будет вашей промышленной средой.

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

Управляемость и гибкость. При CaaS у вас ограничен контроль за изменением фундаментальных свойств или возможностей вашей системы, в то время как IaaS снабжает вас неограниченным управлением для построения той системы, которую вы пожелаете. Рассмотрите насколько много управления требуется вам и в пределах каких размеров. Некоторые отрасли имеют очень специфические требования безопасности или аудита, которые могут неизбежно приводить к сделанному на заказ решению. Однако Kubernetes даёт вам гигантские возможности для проектирования вашего программного обеспечения, поэтому это может предоставлять столько гибкости, сколько вам необходимо.

Региональная доступность. Если вы базируетесь в Сиднее и доставляете программное обеспечение для пользователей в Сан- Пауло, во избежание задержек вам скорее всего требуется размещать хостинг ближе к конечным пользователям. Некоторые из управляемых служб CaaS имеют ограниченную региональную доступность, что может перечёркивать ряд предложений.

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

Привязка к производителю/ платформе. Применение определённого инструмента или службы одновременно привязывает вас к нему и освобождает от чего- то ещё. принятие Kubernetes обязательно будет означать размышления рамках его концептуальной модели, определения файлов настройки конкретным образом, а в более общем плане, построения вокруг него рабочего потока вашей команды: налицо все виды привязки. С другой стороны, управление приложениями при помощи Kubernetes на одном хосте будет очень походить, если просто не совпадать, с аналогичным где- либо ещё, тем самым это снижает привязанность к платформе хостинга. Аналогично, построение поверх IaaS даёт некую свободу, но связывает вас с поставщиком услуг хостинга. Выбирайте свою отраву с умом.

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

В частности:

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

{Прим. пер.: к сожалению, здесь наши интересы расходятся. Нас зачаровало данное описание практики работы с Docker. Тем не менее, наше видение дальнейшего внедрения получаемых приложений Docker связано с применением Kubernetes, для которого мы пока не встречали руководство по практике работы с контейнерами подобного уровня. Если же вы, читатели, полагаете что данный перевод следует продолжить, обращайтесь к нам.}