Б Бёрнс - Распределенные системы. Паттерны проектирования

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

Кроме изоляции ресурсов, существует множество причин раз-делять одноузловое приложение на несколько контейнеров. Рас-смотрим масштабирование команды. Есть достаточно оснований верить тому, что идеальное количество человек в команде — от шести до восьми. Чтобы так структурировать команды и при этом создавать системы значительного размера, членам каждой команды необходимо давать небольшой, четко ограниченный 32Часть I. Одноузловые паттерны проектирования

участок работ, за который они несли бы ответственность. Не-редко отдельные компоненты (при условии, что они правильно выделены) оказываются повторно применяемыми модулями, которыми могут воспользоваться разные команды. Рассмотрим, к примеру, задачу синхронизации локальной фай-ловой системы с удаленным Git-репозиторием исходных тек-стов. Если вы сделаете такой инструмент синхронизации от-дельным контейнером, то сможете использовать его из PHP, HTML, JavaScript, Python и других веб-ориентированных язы-ков и сред. Если же выделить каждую среду в отдельный кон-тейнер, где, скажем, интерпретатор Python и Git-синхронизатор будут неразрывно связаны, то повторное использование такого модуля и, как следствие, существование соответствующей не-большой команды разработчиков, ответственной за этот мо-дуль, станут невозможными.

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

Надеюсь, приведенные примеры натолкнули вас на мысль о де-композиции своих приложений на несколько контейнеров, даже если они работают в рамках одного узла. В последующих главах Часть I. Одноузловые паттерны проектирования 33

будут описаны паттерны, которые помогут вам сориентиро-ваться в построении модульных групп контейнеров. В отличие от многоузловых распределенных паттернов эти паттерны под-разумевают тесную связь между всеми контейнерами. В частно-сти, они предполагают, что исполнение контейнеров в паттерне может быть надежно распланировано в рамках одной машины. Они также подразумевают, что все контейнеры в рамках пат-терна могут при необходимости совместно использовать тома или части файловых систем, а также иные ключевые ресурсы, например сетевые пространства имен и общую память. Такая тесно связанная группа в Kubernetes 1 называется подом (pod) , но сама идея в общем случае применима к разным оркестрато-рам контейнеров, хотя некоторые из них могут поддерживать ее более естественным образом, нежели другие. 2 Паттерн SidecarSidecar — это одноузловой паттерн, состоящий из двух контей-неров. Первый из них — контейнер приложения . Он содержит основную логику программы. Без этого контейнера приложения бы не существовало. Вдобавок к контейнеру приложения пред-усмотрен еще «прицепной» (sidecar) контейнер . Роль прицепа — дополнить и улучшить контейнер приложения, часто таким образом, чтобы приложение не знало о его существовании. В простейшей форме контейнер-прицеп можно использовать, чтобы добавить функциональности контейнеру, который было бы сложно улучшить иным способом.

Исполнение контейнера-прицепа совместно с основным кон-тейнером планируется посредством атомарной группы контей-неров , такой как под (pod) в Kubernetes. Контейнер-прицеп и контейнер приложения совместно используют не только процессорные, но и другие ресурсы — части файловой системы, имя хоста, сетевые (и другие) пространства имен. Обобщенная схема паттерна Sidecar приведена на рис. 2.1.

Рис. 2.1. Обобщенный паттерн Sidecar

Пример реализации паттерна Sidecar. Добавление возможности HT TPS-соединения к унаследованному сервису

Рассмотрим, к примеру, унаследованный веб-сервис. Много лет назад, когда он создавался, безопасность внутренней сети не имела такого высокого приоритета для компании, как сейчас, а значит, запросы пользователей обслуживались по незашифро-ванному протоколу HTTP, а не HTTPS. В связи с последними инцидентами в системе безопасности руководство компании обязало разработчиков использовать протокол HTTPS на всех сайтах компании. Солью на раны команды разработчиков, ко-торой поручено модернизировать этот сервис, стало то, что его исходные тексты собирались на старой версии сборочной системы, которая уже не функционирует. Контейнеризовать HTTP-приложение достаточно просто — двоичный исполня-емый файл может работать в старом дистрибутиве Linux поверх более современного ядра, функционирующего на оркестраци-онном сервере, принадлежащем команде. Но добавить HTTPS к этому приложению — задача куда более сложная. Команде нужно принять решение — или воскресить старую сбо-рочную систему, или портировать исходный код приложения на новую. Один из разработчиков предлагает использовать паттерн Sidecar для менее радикального разрешения этой ситуации. 36Часть I. Одноузловые паттерны проектирования

Применение паттерна Sidecar в данной ситуации самоочевидно. Унаследованный веб-сервис настроен на обслуживание запро-сов исключительно с локального компьютера (127.0.0.1), а это значит, что к нему могут получить доступ только те сервисы, которые используют общий с ним сетевой адаптер (то есть за-пущены на одном компьютере). Обычно это непрактично, по-скольку означает, что к такому сервису никто не сможет полу-чить доступ. При использовании паттерна Sidecar к контейнеру с приложением добавляется контейнер-прицеп с веб-сервером nginx. Nginx-контейнер находится в том же пространстве имен, что и унаследованное веб-приложение, поэтому ему доступен сервис, работающий на localhost. В то же время nginx позволяет обслуживать HTTPS-трафик, приходящий с внешнего адреса группы контейнеров, и проксировать его унаследованному веб-приложению (рис. 2.2). Поскольку незашифрованный трафик проходит только через локальный петлевой интерфейс внутри группы контейнеров, уровень безопасности данных теперь удов-летворяет службу сетевой безопасности компании. Таким обра-зом, команда модернизировала унаследованное приложение, не задаваясь проблемой его пересборки с целью поддержки HTTPS.