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

участок работ, за который они несли бы ответственность. Не-редко отдельные компоненты (при условии, что они правильно выделены) оказываются повторно применяемыми модулями, которыми могут воспользоваться разные команды. Рассмотрим, к примеру, задачу синхронизации локальной фай-ловой системы с удаленным 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. Одноузловые паттерны проектирования