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

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

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

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

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

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

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

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

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

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

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

$ docker run --pid=container:${APP_ID} \

- p 8080:8080 \

brendanburns/topz:db0fa58

/server -addr 0.0.0.0:8080

Это запустит контейнер-прицеп topz в том же самом простран-стве идентификаторов процессов контейнера приложений. Заметьте, что вам, возможно, придется поменять порт, исполь-зуемый прицепом, если ваш контейнер с приложением так-же принимает входящие запросы на порт 8080. При запущен-ном контейнере-прицепе вы можете обратиться к адресу http:// localhost:8080/topz , чтобы получить полный срез информации о процессах, работающих внутри контейнера приложения и ис-пользуемых ими ресурсах.

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