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

Исполнение  контейнера-прицепа  совместно  с  основным  кон-тейнером планируется посредством атомарной  группы контей-неров ,  такой  как  под  (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.

Рис. 2.2. HTTPS-прицеп

Динамическая конфигурация с помощью паттерна Sidecar Простое  проксирование  трафика  в  уже  существующее  прило-жение не единственный случай применимости паттерна Sidecar. Глава 2. Паттерн Sidecar 37

Другой  расхожий  пример  —  синхронизация  конфигурации.  Многие приложения используют конфигурационные файлы для  настройки  параметров.  Они  могут  быть  простыми  текстовыми  файлами либо иметь более жесткую структуру, как у форматов  XML,  JSON  или  YAML.  Многие  приложения  написаны  с  уче-том  того,  что  такой  файл  в  системе существует  и  что они  смо-гут считать из него свою конфигурацию. Однако в изначально  облачной  среде  полезнее  использовать  API  для  обновления  конфигурации. Это позволяет динамически разворачивать кон-фигурацию посредством API, а не заходить вручную на каждый  сервер  и  редактировать  конфигурационные  файлы  импера-тивными  командами.  Желание  задействовать  такой  API  про-диктовано  как  легкостью  использования,  так  и  возможностью  автоматизации,  например  отката,  что  делает  конфигурацию  и реконфигурацию сервера безопаснее и проще. По аналогии с примером про HTTPS новые приложения можно  писать  так,  чтобы  их  конфигурация  была  динамической  и  ее  можно  было  получать  с  помощью  облачных  API-запросов.  Адаптация же существующего приложения и его обновление  могут  оказаться  более  сложной  задачей.  К  счастью,  паттерн  Sidecar можно также использовать для расширения функцио-нальности  приложения  новыми  возможностями,  не  изменяя  при этом самого приложения. В реализации паттерна Sidecar,  приведенной на рис. 2.3, также показано два контейнера — кон-тейнер,  предоставляющий  услуги  приложения,  и  контейнер  с  менеджером  конфигурации.  Два  контейнера  объединены  в  под,  в  котором  они  совместно  используют  каталог.  В  этом  совместно используемом каталоге и находится конфигураци-онный файл.