стандарт формирования дистрибутива контейнеризированного приложения
Что такое контейнеризация? Знакомство с технологией
Технология контейнеризации — это ещё одна форма виртуализации ОС, предлагающая изоляцию приложений в пользовательских пространствах (контейнерах). Все контейнеры используют одну и ту же операционную систему. Благодаря технологии контейнеризации можно запускать приложение с нужными библиотеками в типовом контейнере, который соединяется с хостом или другой внешней компонентой при помощи простого интерфейса.
Все компоненты, необходимые для работы приложения (код, среда запуска, системные инструменты, библиотеки и настройки), упаковываются в один образ и могут быть использованы повторно в рамках текущей задачи или для любых других. Контейнер независим от ресурсов и архитектуры хоста. Он создаёт изолированную среду для приложения, не используя CPU, RAM или хранилище хостовой ОС. Все процессы идут внутри. 
Виртуальная машина и контейнер: в чём разница
Виртуальные машины (ВМ) и контейнеры отличаются друг от друга. Это два разных подхода к созданию независимых изолированных вычислительных сред на физическом сервере. В чём особенность каждого варианта?
Для чего нужны контейнеры
Это удобное решение для тестирования и разработки. Когда разработчик запускает свой или чей-то код в тестовой среде, могут возникать ошибки из-за изменения среды приложения. Топология сети, политики безопасности, вычислительные ресурсы также могут влиять на работу приложения. Контейнер самодостаточен и легко пересоздаётся, если нужно откатить изменения или провести ещё одно тестирование.
Что представляет собой контейнеризация с точки зрения используемых технологий? Для создания контейнеров используются е технологии, как Linux XC, OpenVZ, Linux VServer, BSD Jails и Solaris. Первая популярная технология контейнеризации в Linux — это OpenVZ, превратившаяся позднее в более совершенный коммерческий продукт Virtuozzo.
Плюсы контейнеризации
Недостатки технологии
Несмотря на то, что контейнеров может быть много, они, как правило, короткоживущие. Docker-контейнеры, например, часто называют одноразовыми. Можно использовать его, получить результат, а затем удалить и запустить точно такой же.
Если вас интересуют вопросы контейнеризации или вы хотите использовать облачный инструмент оркестрации контейнеров Kubernetes, обратитесь к менеджерам Cloud4Y по телефону 8 (499) 877-12-35. Вы можете связаться с нами любым другим способом.
7 принципов проектирования приложений, основанных на контейнерах
В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.
Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.
Как правило, с облачными (cloud native) приложениями можно предвидеть отказы, а их функционирование и масштабирование возможно даже тогда, когда нижележащая инфраструктура испытывает проблемы. Чтобы это стало возможным, платформы, предназначенные для запуска таких приложений, накладывают определённые обязательства и ограничения на запускаемые в них приложения. Если кратко, то приложение недостаточно просто поместить в контейнер и запустить — возможность его эффективной оркестровки в платформах вроде Kubernetes требует дополнительных усилий. Каковы же они?
Подход Red Hat к приложениям cloud native
Предлагаемые здесь идеи созданы под вдохновением различных других работ (например,
The Twelve-Factor App), затрагивающих многие области: от управления исходным кодом до моделей масштабируемости приложений. Однако область применения рассматриваемых здесь принципов ограничена проектированием контейнеризированных приложений, основанных на микросервисах, для cloud native-платформ вроде Kubernetes.
В описании всех принципов в качестве основного примитива используется образ контейнера, а в качестве целевого окружения для его запуска — платформа оркестровки контейнеров. Следование этим принципам призвано гарантировать, что (подготовленные в соответствии с ними) контейнеры получат полноценную поддержку в большинстве движков оркестровки, т.е. будут обслуживаться планировщиком, масштабироваться и мониториться автоматизированно. Принципы перечислены в случайном (а не приоритетном) порядке.
1. Single Concern Principle (SCP)
Во многих смыслах SCP аналогичен принципу единственной ответственности (Single Responsibility Principle, SRP) в SOLID, говорящему о том, что каждый класс должен иметь одну ответственность. Стоящая за SRP мотивация — должна быть лишь одна причина, которая может привести к изменению класса.
Слово «concern» (переводится как «озабоченность», «беспокойство», «интерес», «задача») подчёркивает, что озабоченность — более высокий уровень абстракции, чем ответственность, который лучше описывает спектр задач контейнера (по сравнению с классом). Если главной мотивацией для SRP является единственная причина для изменения, то для SCP — возможность повторного использования образа контейнера и его заменяемость. Если вы создаёте контейнер, отвечающий за одну задачу, и он полностью её решает, вырастает вероятность повторного использования этого образа в других обстоятельствах.
В общем, принцип SCP гласит, что каждый контейнер должен решать единственную проблему и делать это хорошо (на ум сразу приходит классика из философии UNIX — DOTADIW, «Do one thing and do it well» — прим. перев.). Если же микросервису необходимо отвечать за множество проблем, можно использовать такие паттерны, как sidecar- и init-контейнеры, для объединения множества контейнеров в единую развёртываемую площадку (под), где каждый контейнер будет по-прежнему заниматься единственной задачей.
2. High Observability Principle (HOP)
Контейнеры — унифицированный способ упаковывать и запускать приложения, превращающий их в «чёрный ящик». Однако любой контейнер должен предоставлять программные интерфейсы приложения (API) для окружения, в котором он исполняется, делая возможным мониторинг состояния и поведения контейнера. Это необходимое условие для возможности автоматизации обновлений контейнера и сопровождения его жизненного цикла.
С практической точки зрения, контейнеризированное приложение должно предоставлять хотя бы (как минимум!) API для различных проверок его состояния: liveness (работоспособность) и readiness (готовность к обслуживанию запросов). Ещё лучше, если предлагаются и другие способы отслеживать состояние приложения — в частности, логирование важных событий в STDERR и STDOUT для их последующей агрегации утилитами вроде Fluentd и Logstash, интеграции с инструментами для сборки метрик: OpenTracing, Prometheus и др.
Вывод таков: обращайтесь со своим приложением как с чёрным ящиком, но реализуйте все необходимые API, помогающие платформе следить за приложением и управлять им настолько хорошо, насколько это возможно.
3. Life-cycle Conformance Principle (LCP)
Если HOP говорит о предоставлении API, из которых сможет «читать» платформа, то LCP — это обратная сторона: у вашего приложения должна быть возможность узнавать о событиях из платформы. И даже более того: не только узнавать о них, но и реагировать на них — отсюда происходит и название этого принципа («conformance» переводится как «соответствовать», «согласоваться», «подчиняться правилам»).
У управляющей платформы может быть множество событий, которые помогут в управлении жизненным циклом контейнера, но некоторые из них важнее других. Например, для корректного завершения работы процесса приложению необходимо получить сообщение с соответствующим сигналом (SIGTERM) во избежание срочного прекращения работы через SIGKILL. Бывают и другие значимые события — например, PostStart и PreStop, которые необходимы для «прогрева» приложения в начале его работы или, наоборот, освобождения ресурсов при завершении.
4. Image Immutability Principle (IIP)
В контейнеризированных приложениях закладывается неизменность (immutability): их собирают один раз, после чего они запускаются без изменений в разных окружениях. Это подразумевает использование внешних инструментов для хранения используемых в их работе данных, а также создание/применение различных конфигураций для разных окружений. Любое изменение в контейнеризированном приложении должно приводить к сборке нового образа контейнера, которые будет использоваться во всех окружениях. Этот же принцип, известный как immutable infrastructure, используется для управления серверной инфраструктурой.
5. Process Disposability Principle (PDP)
Одна из главных причин перехода на контейнеризированные приложения — контейнеры должны быть настолько недолговечными, насколько это возможно, и готовыми к замене другим контейнером в любой момент времени. Причин заменить контейнер может быть много: проверка состояния, обратное масштабирование (scale down) приложения, миграция на другой хост, нехватка ресурсов…
Поэтому контейнеризированным приложениям необходимо поддерживать своё состояние распределённым и избыточным. Кроме того, приложение должно быстро стартовать и останавливаться и даже быть готовым к внезапному (и полному) аппаратному сбою. Другая полезная практика в реализации этого принципа — создание маленьких контейнеров, т.к. контейнеры автоматически запускаются на разных хостах, и их меньший размер ускорит время запуска (поскольку предварительно их нужно физически скопировать на хостовую систему).
6. Self-Containment Principle (S-CP)
Контейнер должен содержать всё необходимое на момент сборки, полагаясь лишь на наличие ядра Linux (все дополнительные библиотеки «появляются» в момент сборки). Помимо библиотек это означает также необходимость содержать исполняемые среды языков программирования, платформу приложений (если используется) и любые другие зависимости для запуска контейнеризированного приложения. Единственное исключение здесь составляют конфигурации, которые будут разными в разных окружениях и должны предоставляться во время запуска (пример — ConfigMap в Kubernetes).
Некоторые приложения состоят из множества контейнеризированных компонентов. Например, контейнеризированное веб-приложение может требовать контейнера с базой данных. Этот принцип не предлагает объединять контейнеры: просто у контейнера с базой данных должно быть всё необходимое для её работы, а контейнера с веб-приложением — для работы веб-приложения (веб-сервер и т.д.).
7. Runtime Confinement Principle (RCP)
Принцип S-CP рассматривает контейнеры с перспективы времени сборки и результирующего бинарника с его содержимым, однако контейнер — это не одномерный чёрный ящик, лежащий на диске. Другие «измерения» контейнера появляются при его запуске — это «измерения» потребления памяти, процессора и других ресурсов.
Любой контейнер должен объявлять свои требования к ресурсам и передавать эту информацию платформе, поскольку его запросы на CPU, память, сеть, диск влияют на то, как платформа выполняет планирование, автомасштабирование, управление ресурсами, обеспечивает общий уровень SLA для контейнера. Кроме того, важно, чтобы приложение умещалось в выделенные ей ресурсы. В случае нехватки ресурсов платформа с меньшей вероятностью будет останавливать или мигрировать такие контейнеры.
Другие рекомендации
В дополнение к этим принципам предлагаются менее фундаментальные, но всё же тоже зачастую полезные практики, относящиеся к контейнерам:
P.S. от переводчика
Про некоторые из этих принципов — в частности, про Image Immutability Principle (IIP), который мы назвали как «One image to rule them all», и Self-Containment Principle (S-CP) — рассказывалось в нашем докладе «Лучшие практики CI/CD с Kubernetes и GitLab» (по ссылке — текстовая выжимка и полное видео).
Стандарт формирования дистрибутива контейнеризированного приложения
ГОСТ Р ИСО/МЭК 90003-2014
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
РАЗРАБОТКА ПРОГРАММНЫХ ПРОДУКТОВ
Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов
Software engineering. Guidelines for the application of ISO 9001:2008 to computer software
Дата введения 2016-01-01
Предисловие
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Всероссийский научно-исследовательский институт сертификации» (ОАО «ВНИИС») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 076 «Системы менеджмента»
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов, приведенных в библиографии, соответствующие им национальные и межгосударственные стандарты, сведения о которых приведены в дополнительном приложении ДА
6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.
Введение
Настоящий стандарт является руководящим указанием для организаций по применению ИСО 9001:2008 к процессам, связанным с заказом, поставкой, разработкой, эксплуатацией и сопровождением программных продуктов.
Настоящий стандарт определяет вопросы, которые нужно рассматривать, и его применимость не зависит от технологий, моделей жизненного цикла, процессов в области разработки, последовательности действий и организационной структуры, которые используются организацией. Предлагаемые руководящие указания и определенные к рассмотрению вопросы предполагают обстоятельный и многосторонний, но не исчерпывающий охват изучаемого предмета. В случае когда область деятельности организации охватывает области, отличные от разработки программных продуктов, взаимосвязь между элементами системы менеджмента качества организации, имеющими отношение к программным продуктам, и остальными аспектами необходимо четко документировать в рамках системы менеджмента качества в как итоговую совокупность.
Разделы 4, 5 и 6 и составные части раздела 8 ИСО 9001:2008 применимы преимущественно на «глобальном» уровне в организации, хотя они могут иметь желательный результат и на «проектном/программном уровне». Каждый проект или разработка продукции может учитывать или ориентироваться на соответствующие элементы системы менеджмента качества организации для обеспечения соответствия требованиям, относящимся к реализуемому проекту/выпускаемой продукции.
Организации, внедрившие системы менеджмента качества для разработки, осуществления эксплуатации или сопровождения программных продуктов на основе положений настоящего стандарта, могут принимать решение об использовании процессов из ИСО/МЭК 12207 в целях обеспечения или дополнения модели процессного подхода ИСО 9001:2008. Соответствующие параграфы ИСО/МЭК 12207:2008 указаны в каждом разделе настоящего стандарта, однако они не заключают в себе требования в дополнение к тем требованиям, что имеются в ИСО 9001:2008. Дальнейшее руководство с указаниями по применению ИСО/МЭК 12207 содержится в ИСО/МЭК 24748-3. Что касается дополнительного руководства ИСО/МЭК JTC 1/SC7 вырабатывает регулярные сообщения применительно к международным стандартам для разработки программных продуктов. В случаях когда эти сообщения (ссылки) относятся непосредственно к какому-либо пункту или подпункту ИСО 9001:2008, они помещаются после руководящих указаний для данного пункта или подпункта. В случае когда они применяются повсеместно в положениях пункта или подпункта, эти ссылки помещают в конце заключительной части пункта или подпункта.
В тех местах настоящего стандарта, где текст был приведен из ИСО 9001:2008, данный текст в целях облегчения его идентификации заключен в рамку.
1 Область применения
1.1 Общие положения
Настоящий стандарт устанавливает требования к системе менеджмента качества в тех случаях, когда организация:
a) нуждается в демонстрации своей способности всегда поставлять продукцию, отвечающую требованиям потребителей и соответствующим обязательным требованиям;
b) ставит своей целью повышение удовлетворенности потребителей посредством эффективного применения системы менеджмента качества, включая процессы постоянного ее улучшения, и обеспечение соответствия требованиям потребителей и соответствующим обязательным требованиям.
1 В настоящем стандарте термин «продукция» применим только:
a) к предназначаемой для потребителя или затребованной им продукции;
b) к любым заданным результатам процессов жизненного цикла.
2 Законодательные и другие обязательные требования могут быть выражены как правовые требования.
[ИСО 9001:2008 Системы менеджмента качества. Требования] [2]
Настоящий стандарт предлагает для организаций руководящие указания по применению ИСО 9001:2008 к процессам, связанным с заказом, поставкой, разработкой, осуществлением эксплуатации и сопровождением программных продуктов и к связанным с этими процессами сервисным обслуживанием. Он не добавляет или каким-либо иным другим образом не изменяет требования ИСО 9001:2008.
В приложении А (справочном) представлена таблица с дополнительными указаниями по внедрению ИСО 9001:2008, имеющимися в международных стандартах, разработанных ИСО/МЭК JTC 1/SC7 и ИСО/ТК 176.
Руководящие указания, представленные в настоящем стандарте, не предназначены для применения в качестве оценочных критериев при проведении мероприятий, связанных с регистрацией/сертификацией систем менеджмента качества.
1.2 Применение
Требования настоящего стандарта являются общими и предназначены для применения всеми организациями независимо от их вида, размера и поставляемой продукции.
Если какое-либо требование(я) настоящего стандарта нельзя применить вследствие специфики организации и ее продукции, допускается его исключение.
При допущенных исключениях заявления о соответствии настоящему стандарту приемлемы, если эти исключения подпадают под требования раздела 7 и не влияют на способность или ответственность организации обеспечивать продукцией, соответствующей требованиям потребителей и соответствующим обязательным требованиям.
Настоящий стандарт применим к программным продуктам, которые:
— являются элементом коммерческого контракта, заключенного с другой организацией;
— представляют собой продукцию, предназначенную для продажи на потребительском рынке;
— используются для обеспечения реализации процессов организации;
— встроены в техническую продукцию/оборудование, и
— относятся к программным услугам.
Некоторые организации могут осуществлять все вышеуказанные действия; другие могут специализироваться в одной области. В любой ситуации рекомендуется, чтобы система менеджмента качества организации охватывала все аспекты (связанные с программными и непрограммными средствами) деятельности организации.
2 Нормативные ссылки
ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь.
3 Термины и определения
В настоящем стандарте применены термины и определения, данные в ИСО 9000.
В тексте настоящего стандарта термин «продукция» может означать также «услуга».
В настоящем стандарте применены термины и определения, данные в ИСО 9000:2005 [1], и некоторые термины (включенные в настоящий стандарт для удобства пользования), данные в ИСО/МЭК 12207:2008 [7].
Однако в тех случаях, когда возникают противоречия в терминах и определениях, следует применять термины и определения, установленные в ИСО 9000:2005 [1].
3.1 деятельность (activity): Совокупность взаимосвязанных задач по реализации процесса.
[ИСО/МЭК 12207:2008, 4.3]
3.2 базовая линия (baseline): Официально принятая версия элемента конфигурации, независимая от среды, формально обозначенная и зафиксированная в конкретный момент времени жизненного цикла элемента конфигурации.
[ИСО/МЭК 12207:2008, 4.6]
3.3 элемент конфигурации (configuration item): Объект внутри конфигурации, который удовлетворяет функции конечного использования и может быть однозначно определен в данной эталонной точке.
[ИСО/МЭК 12207:2008, 4.7]
3.4 COTS (COTS Commercial-Off-The-Shelf) (предназначенный для продажи готовый продукт): Программный продукт, имеющийся в продаже, который может быть использован без выполнения действий, связанных с разработкой.
3.5 разработка (implementation): Процесс жизненного цикла программного продукта, состоящий из действий по изучению требований, проектированию, программированию, интеграции, тестированию, инсталляции и обеспечению приемки программных продуктов.
3.6 модель жизненного цикла (life cycle model): Структура, состоящая из процессов, работ и задач, относящихся к жизненному циклу программного продукта, который может быть разделен на этапы, и которая используется для лучшего взаимопонимания.
[ИСО/МЭК 12207:2008, 4.17]
3.7 измерять (measure): Проводить измерение.
[ИСО/МЭК 15939:2007, 2.16]
3.8 мера измерения (measure): Переменная, которой присваивается значение, полученное в результате проведения измерения.
[ИСО/МЭК 15939:2007, 2.15]
3.9 измерение (measurement): Совокупность операций, предназначенных для определения числового значения переменной, выраженной в заданных единицах измерения.
[ИСО/МЭК 15939:2007, 2.17]
3.10 процесс (process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая входы в выходы.
3.11 регрессивное тестирование (regression testing): Тестирование, требуемое для определения того, что изменение в отношении какого-либо компонента системы не сказалось негативным образом на функциональных возможностях, надежности или характеристиках и не привело к появлению дополнительных дефектов.
3.12 выпуск (release): Конкретная версия элемента конфигурации, которая доступна для реализации конкретной цели.
[ИСО/МЭК 12207:2008, 4.35]
3.13 тиражирование (replication): Копирование программного продукта с одного носителя на другой.
3.14 программный элемент (software item): Идентифицируемый компонент программного продукта.
3.15 программный продукт (software product): Набор машинных программ, процедур и возможно связанных с ними документации и данных.
1 Программный продукт может предназначаться для доставки в качестве неотъемлемой части другого продукта или быть использован в ходе разработки.
2 Отличается от определения ИСО 9000.
3 В настоящем стандарте термины «software» и «software product» являются синонимами.
Контейнеризация приложений: что это такое и когда стоит использовать
По меткому выражению специалистов из IBM, контейнеризация «позволяет писать приложения один раз и запускать их где угодно».
Разработчики могут создавать и развертывать приложения быстрее и безопаснее, чем при традиционном подходе к написанию кода — когда он разрабатывается в определенной вычислительной среде, а его перенос в новое место, например из тестовой среды в продуктивную, часто приводит к ошибкам выполнения кода.
В статье, написанной совместно с экспертами из компании Git in Sky, расскажем о том, как контейнерные технологии устраняют эту проблему.
Что такое контейнер и чем эта технология удобна для разработчиков приложений
Контейнер приложения — экземпляр исполняемого программного обеспечения (ПО), который объединяет двоичный код приложения вместе со всеми связанными файлами конфигурации, библиотеками, зависимостями и средой выполнения.
Смысл и главное преимущество технологии в том, что контейнер абстрагирует приложение от операционной системы хоста, то есть остается автономным, благодаря чему становится легко переносимым — способным работать на любой платформе.
Контейнеры — небольшие, быстрые и портативные, потому что могут не включать в себя гостевую операционную систему (ОС), а используют функции и ресурсы основной ОС. Контейнеры используют не только для изоляции различных программных процессов, но и для контроля ресурсов, за которые эти процессы могут конкурировать. Это, например, объем памяти или ресурсы процессора.
Уже существующие приложения можно переупаковать в контейнеры, например, посредством технологии Docker, и они будут эффективнее использовать вычислительные ресурсы. Этот процесс называется контейнеризацией. Потребность в ней может возникнуть, когда надо быстро и без повторной сборки приложения переместить его из одной вычислительной среды в другую, где развернуть легко и согласованно.
Еще одно применение технологии — использовать контейнер, содержащий экземпляр другого дистрибутива ОС, что позволяет запускать одновременно несколько контейнеров с приложениями, требующими разных дистрибутивов. Такие контейнеры называют системными и применяют их для традиционных приложений: все конфигурации, инструменты (различное вспомогательное ПО) и монолитная архитектура приложения находятся в одном контейнере.
Чтобы лучше понять, чем хороши контейнеры, стоит сравнить их с виртуальными машинами.
В чем разница между контейнерами и виртуальными машинами
На каждой виртуальной машине (ВМ) отдельная гостевая операционная система работает поверх операционной системы хоста с виртуализированным доступом к базовому оборудованию.
Виртуальные машины с разными ОС могут работать на одном физическом сервере: ВМ UNIX может работать вместе с ВМ Linux и так далее. Микроядро и система виртуализации, которые создают и запускают виртуальные машины, называются гипервизорами или мониторами ВМ. Это то, что находится между оборудованием и ВМ и необходимо для виртуализации сервера, а также для изоляции операционных систем друг от друга.
Контейнеры устанавливаются поверх физического сервера и его ОС, например Linux или Windows. Каждый контейнер отделяет свое содержимое от операционной системы. Контейнеры «легкие» — весят всего мегабайты и запускаются за секунды, ведь они берут лишь небольшую часть памяти при совместном использовании ОС.
Виртуальные машины могут запускать любое ядро операционной системы независимо от основной операционной системы, контейнер должен быть совместим с ядром ОС сервера.
Как и ВМ, контейнеры позволяют упаковывать приложение вместе с библиотеками и другими зависимостями, обеспечивая изолированные среды для запуска программных сервисов. Они отделяют приложения друг от друга. Это означает, что не придется беспокоиться о конфликтующих зависимостях или конфликте ресурсов, ведь можно установить лимиты ресурсов для каждого контейнера. Важно отметить, что это дополнительный уровень безопасности, поскольку приложения не работают в операционной системе сервера.
Преимущества контейнеризации приложений
Контейнерная технология дает ряд преимуществ по сравнению с обычной виртуализацией серверов.
Безопасность контейнеров
При запуске контейнеров надо учитывать, что есть некоторый риск запустить их с неполной изоляцией, тогда какой-то вредоносный код из сети может получить доступ к памяти сервера.
Здесь нужно использовать решения, повышающие безопасность контейнеров:
Как управляют контейнерами: системы оркестрации
Оркестрация позволяет автоматизировать развертывание, управление и масштабирование контейнерных приложений. Для этого используют такие инструменты, как Kubernetes — стандарт современной оркестрации контейнеров с открытым исходным кодом. Он совместим с несколькими средами выполнения контейнеров, включая Docker.
Технология возникла потому, что контейнерные приложения могут быть сложными и при их производстве может потребоваться от сотен до тысяч отдельных контейнеров, которыми трудно управлять. С помощью Kubernetes легко оркестрировать множество контейнеров на протяжении всего их жизненного цикла, включая: подготовку, резервирование, мониторинг здоровья, распределение ресурсов, масштабирование, балансировку нагрузки и перемещение между серверами.
Если использовать Kubernetes как сервис от провайдера, то можно снять со специалистов компании нагрузку по его администрированию и обновлению, не думать о резервном копировании. Облачный сервис позволяет ускорить доставку приложений, подключать автомасштабирование в один клик, мониторить доступность запущенных сервисов в одном месте, использовать отказоустойчивые балансировщики нагрузки и многое другое.