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

Унаследованное приложение при запуске предсказуемо загружа-ет конфигурацию из файла в файловой системе. Менеджер кон-фигурации  при  запуске  считывает  данные  конфигурационного  38 Часть I. Одноузловые паттерны проектирования

Рис. 2.3. Пример использования паттерна Sidecar для динамического управления конфигурацией

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

Механизм  такого  уведомления  различается  от  приложения  к  приложению.  Одни  приложения  следят  за  изменением  кон-фигурационного файла,  другие  ожидают  сигнала  SIGHUP.  Глава 2. Паттерн Sidecar 39

В  крайнем  случае  менеджер  конфигурации  может  завершить  приложение,  отправив  ему  сигнал  SIGKILL.  После  остановки  приложения оркестратор перезапустит контейнер унаследован-ного приложения, и в этот момент оно загрузит новую конфигу-рацию. Как и в случае с добавлением HTTPS в существующее  приложение,  этот  пример  иллюстрирует,  как  паттерн  Sidecar  может помочь адаптировать существующие приложения к тре-бованиям облачной среды.

Модульные контейнеры приложений Простительно  думать,  что  единственная  причина  существова-ния  паттерна  Sidecar  —  необходимость  адаптации  устаревших  приложений  без  изменения  их  исходных  текстов.  И  хотя  это  популярный  вариант  использования данного  паттерна,  суще-ствует  множество  других  причин  проектировать  приложения  с  его  помощью.  Одно  из  основных  преимуществ  применения  паттерна  Sidecar  —  модульность  и  повторное  использование  контейнеров-прицепов.  Для  развертывания  любого  «боевого»  приложения, от которого ожидается высокий уровень надежно-сти, требуется функционал, касающийся отладки и управления  приложением,  например  считывание  ресурсов,  потребляемых  приложениями  внутри  контейнера,  по  аналогии  с  утилитой  командной строки top.

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

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

приведет  к  расхождениям  между  языками  и  отсутствию  под-держки этой функциональности в новых языках. Функциональность topz можно развернуть в виде контейнера-прицепа, работающего в том же пространстве идентификаторов  процессов,  что  и  контейнер  приложения.  Topz-контейнер  осу-ществляет интроспекцию всех запущенных процессов и предо-ставляет  единообразный  пользовательский  интерфейс.  Кроме  того,  можно  задействовать  оркестратор  для  автоматического  развертывания такого контейнера вместе со всеми приложения-ми, чтобы для каждого приложения, работающего в вашей ин-фраструктуре, был доступен одинаковый набор инструментов. Любой технический выбор подразумевает некоторый компро-мисс между применением модульных контейнерных паттернов  и  внесением  собственного  кода  в  приложение.  Библиотечно-ориентированный  подход  всегда  будет  несколько  менее  адап-тирован  под  особенности  вашего  приложения.  Подобная  реа-лизация может оказаться менее эффективной в плане размера  или  производительности;  API  могут  потребовать  некоторой  адаптации  для  использования  в  вашей  среде.  Я  бы  сравнил  такой  компромисс  с  компромиссом  между  покупкой  готовой  одежды и заказом ее у модельера. Заказная одежда вам подой-дет лучше, но на ее производство понадобится больше времени  и она будет стоить вам дороже. Как и с вещами, когда дело ка-сается программирования, многим из нас имеет смысл покупать  решения  общего  назначения.  Если  ваше  приложение  требует  максимальной производительности, то, конечно же, всегда мож-но прибегнуть к самодельному решению.

Практикум. Развертывание контейнера topz Чтобы  увидеть  контейнер-прицеп в  действии,  сначала  необ-ходимо  создать  еще  один  контейнер,  который  послужит  кон-Глава 2. Паттерн Sidecar 41

тейнером  приложения.  Возьмите  существующее  приложение  и разверните его с помощью Docker:

$ docker run -d <образ-приложения>

<хеш-сумма-контейнера>

После  запуска  данного  образа  вы  получите  идентификатор  конкретного контейнера. Он  будет  выглядеть  как-то  так:  cccf82b85000 .  Если  идентификатор  контейнера  вам  неизве-стен, вы всегда можете его просмотреть с помощью команды  docker  ps , которая покажет все запущенные в данный момент  контейнеры.

Допустим,  вы  поместили  это  значение  в  переменную  среды  APP_ID .  Теперь  можете  запустить  контейнер  topz  в  том  же  пространстве  идентификаторов  процессов  с  помощью  такой  команды: