Из ГОСТ Р 70860–2023 Информационные технологии. Облачные вычисления. Общие технологии и методы

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

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

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

За обеспечение возможности хранения и получения доступа к образам контейнеров отвечает реестр контейнеров. Реестры контейнеров могут предоставляться как общедоступные облачные сервисы или как частные облачные сервисы. Примером общедоступного облачного сервиса для предоставления реестра контейнеров является Docker Hub, доступный по адресу: hub.docker.com. Реестры контейнеров имеют сервисные интерфейсы, которые обеспечивают по крайней мере возможность выполнения операций push и pull. Операция push закачивает один или несколько образов в реестр, а операция pull скачивает один или несколько образов из реестра.

Репозиторий представляет собой набор связанных образов контейнеров. Примером набора связанных образов контейнеров является набор образов контейнеров для библиотек конкретной ОС, где каждый образ предназначен для определенной версии этой ОС.

Например, репозиторий контейнеров может содержать набор из четырех образов контейнеров с именами some_os_libs:16.01, some_os_libs:16.02, some_os_libs:16.03, some_os_libs:latest. В этом случае в репозитории имеются четыре записи для разных версий ОС, каждая из которых имеет метку номера версии. Версия с меткой «latest» (последняя) указывает на тот же образ контейнера, что и версия с меткой «16.03».

Это объясняется тем, что, если другим образам контейнеров необходимо всегда использовать последнюю версию образа контейнера ОС в качестве родительского элемента, они могут использовать метку «latest» при получении образа, что приведет к автоматическому обновлению, когда новые образы контейнеров более поздних версий ОС будут загружены в реестр контейнеров. Другой областью применения меток, используемых в репозиториях образов, является создание образов для конкретных целевых сред. В качестве альтернативного метода можно использовать образы fat-мэнифестов [из 7.3.3 Репозитории и реестры образов контейнеров ГОСТ Р 70860—2023]

Согласно 7.2.2, контейнерная служба и связанные с ним инструменты позволяют управлять жизненным циклом только одного контейнера. Однако развертывание типичных приложений для облачных вычислений, как правило, включает в себя развертывание и работу множества контейнеров, часто на нескольких хост-системах. Приложение может содержать несколько экземпляров определенного контейнера, работающих параллельно, как для обеспечения резервирования на случай отказа одного экземпляра, так и для обеспечения достаточной масштабируемости, чтобы справиться с нагрузкой, создаваемой входящими запросами. Приложение также может содержать множество различных компонентов, каждый из которых работает в собственном экземпляре контейнера(ов) благодаря использованию архитектуры микросервисов или разделению функциональных возможностей на нескольких уровнях; пример — веб-приложение, использующее базу данных. CMS осуществляет оркестрацию и управление заданными наборами контейнеров.

CMS может абстрагировать базовую инфраструктуру, рассматривая набор контейнеров как единую цель развертывания и в то же время обеспечивая соблюдение политик развертывания, таких как разделение параллельных экземпляров контейнеров для целей резервирования и перехода на другой ресурс при сбое [из 7.4.1 Общие положения ГОСТ Р 70860—2023]

Общие функциональные возможности CMS включают:

а) оркестрацию

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

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

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

б) планирование

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

в) мониторинг и проверку состояния

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

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

г) автоматическое масштабирование

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

д) управление ресурсами

Ресурс в CMS — это логическая конструкция, которую может создавать инструмент оркестрации и управлять ею. В качестве примера можно привести развертывание сервиса или приложения;

е) виртуальную сеть

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

ж) обнаружение сервисов

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

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

и) обновление и модернизацию

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

к) декларативную конфигурацию

Обычно CMS предоставляют команде специалистов DevOps средства для декларативной настройки конфигурации оркестрации приложения с использованием заданной схемы, написанной на таких языках программирования как YAML (yaml.org/) и JSON (www.ecma-international.org/publications-and-standards/standards/ecma-404/). Декларативная конфигурация обычно также содержит информацию о репозиториях контейнеров, сетевой конфигурации, средствах хранения и функциях обеспечения безопасности, которые поддерживает приложение. Декларативная конфигурация необходима для того, чтобы CMS могли автоматизировать процесс управления приложением и его компонентами. По сути, декларативная конфигурация указывает CMS нужную конфигурацию. CMS, в свою очередь, стремится создавать и поддерживать эту конфигурацию. Для этого она принимает решения в отношении действий, необходимых для достижения поставленной задачи, используя знания о целевых системах и внутренних стратегиях развертывания [из 7.4.2 Общие функциональные возможности CMS ГОСТ Р 70860—2023]

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

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

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

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

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

В бессерверных вычислениях часто используют модели оплаты за объем работы, выполненный облачным сервисом, а не за выделенные ресурсы (например, ВМ или контейнер). Поэтому оплата может производиться из расчета за один вызов API или, например, за один HTTP-запрос. Такую модель оплаты можно рассматривать как самый экстремальный вариант оплаты по факту потребления.

Среди преимуществ бессерверных вычислений для потребителя облачной службы могут быть следующие:

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

[из 8.1 Общие положения ГОСТ Р 70860—2023]

Распространенной формой бессерверных вычислений является форма «функции как услуга» (FaaS). FaaS представляет собой форму бессерверных вычислений, в которой функциональные возможности, используемые потребителем облачной службы, заключаются в выполнении кода приложения потребителя в виде одной или нескольких функций, каждая из которых запускается по выбранному потребителем событию. FaaS также является разновидностью формы «вычисления как услуга» (CompaaS) согласно определению по ГОСТ ISO/IEC 17788.

FaaS может выполнять код клиентского приложения, написанный на одном или нескольких языках программирования. Все облачные сервисы FaaS поддерживают приложения, написанные на одном или нескольких языках программирования, включая, помимо прочего, С#, Go, Java™, JavaScript, РНР, Python, Ruby, Swift. FaaS поддерживает функциональные возможности платформы как услуги в отношении предоставления программного стека среды выполнения, необходимого для выполнения кода приложения. Таким образом, потребителю облачной службы не нужно развертывать и поддерживать программный стек среды выполнения. Как правило, FaaS не требует написания кода приложения потребителя облачной службы для использования какой-либо конкретной среды разработки приложений. Кроме того, FaaS организует работу приложения и программного стека среды выполнения по требованию для обслуживания любых событий, которые запускают приложение.

Цель FaaS — сделать инфраструктуру невидимой для разработчиков приложений и сервисов. При использовании FaaS базовые серверы, ВМ и (или) контейнеры невидимы для пользователя сервиса. Разработчик не только не имеет к ним доступа, но и не может получить его, поскольку они автоматически управляются поставщиком облачной службы как часть облачного сервиса.

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

Автоматизированное управление, обеспечиваемое FaaS, является основной отличительной особенностью, т. к. высокая масштабируемость обеспечивается в автоматическом режиме. Если частота возникновения событий для данной FaaS растет, то объем ресурсов, выделяемых соответствующей облачной службе для обработки этих событий, автоматически увеличивается, а когда частота возникновения событий снижается, они удаляются [из 8.2.1 Обзор ГОСТ Р 70860—2023]

Использование FaaS подразумевает написание одной или нескольких функций, где каждая функция — это часть программного кода, предназначенная для выполнения одной конкретной задачи. Именно из-за этой особенности программирования бессерверной среды выполнения эти облачные сервисы получили такое название — «функция как услуга» (FaaS). По сути, это серьезное изменение способа разработки приложений и сервисов, включая добавление отдельных принципов архитектуры микросервисов (см. раздел 9). Существуют определенные принципы, которые действуют в отношении функций и способа их выполнения.

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

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

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

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

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

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

Поскольку за один раз можно развернуть только одну функцию, бессерверный подход обеспечивает значительную гибкость в этом плане. Приложения могут создаваться по одной функции за раз, каждая из которых развертывается и масштабируется отдельно. Это также позволяет ускорить разработку и развертывание (нет необходимости ждать сборки приложения или сервиса, содержащего несколько функциональных возможностей). Каждая функциональная возможность может быть создана, протестирована и развернута отдельно [из 8.2.2 Функции FaaS ГОСТ Р 70860—2023]

Бессерверный фреймворк представляет собой инструмент, призванный оказать помощь при создании и развертывании функций для облачных сервисов FaaS. В частности, он поддерживает развертывание функций в рамках разных предложений FaaS различных поставщиков облачных служб.

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

Для решения проблемы разработки функций для развертывания на любом из множества предложений FaaS поставщиков облачных служб были разработаны бессерверные фреймворки, которые позволяют разрабатывать функции, ориентированные на различные FaaS по требованию, учитывая различия между ними (особенно в отношении процессов загрузки и развертывания) [из 8.2.3 Бессерверные фреймворки ГОСТ Р 70860—2023]