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

# - name: some-name

# image: some-image

# Здесь указываем имя контейнера-посла

- name: nginx

image: nginx

Глава 3. Паттерн Ambassador 63

volumeMounts:

- name: config-volume

mountPath: /etc/nginx

volumes:

- name: config-volume

configMap:

name: experiment-config

Чтобы воспользоваться контейнером-послом в полной мере, в группу можно добавить еще один или несколько контейнеров. 4 Адаптеры

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

Разработка реальных приложений — тренировка по построению гетерогенных, гибридных систем. Одни части вашего прило-жения могут быть написаны вашей командой с нуля, другие Глава 4. Адаптеры 65

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

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

Далее в главе мы рассмотрим несколько приложений паттерна Adapter.

66Часть I. Одноузловые паттерны проектирования

Мониторинг

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

Существует множество стандартизированных интерфейсов мониторинга — syslog , мониторинг событий Windows (ETW), JMX для Java-приложений и многие другие протоколы и ин-терфейсы. Однако все они различаются как протоколами, так и способами коммуникации (push или pull). К сожалению, приложения, входящие в вашу распределенную систему, могут включать в себя как части из самописного кода, так и готовые open-source-компоненты. В результате вы сталкиваетесь с широким разнообразием интерфейсов мониторинга, которые необходимо интегрировать в одну по-нятную систему.

К счастью, разработчики большинства решений, касающихся мониторинга, осознают, что эти решения должны быть ши-роко применимы, и поэтому реализуют механизм надстроек, позволяющий адаптировать формат мониторинга к некоторо-му общему интерфейсу. Как развертывать приложения гиб-ким и устойчивым образом, имея такой набор инструментов? У паттерна Adapter есть ответ на данный вопрос. Примени-тельно к мониторингу мы видим, что контейнер приложения — это просто приложение, за которым мы хотим наблюдать. Контейнер-адаптер содержит инструменты, преобразующие интерфейс мониторинга, предоставляемого контейнером прило-жения, в интерфейс, ожидаемый системой мониторинга общего назначения.

Глава 4. Адаптеры 67

Разбиение системы таким образом позволяет создавать более понятные и легко сопровождаемые системы. Развертывание новых версий приложения не требует развертывания новой вер-сии адаптера для мониторинга. К тому же контейнер-монитор может быть повторно использован совместно с разными контей-нерами приложений. Кроме того, его может даже предоставить независимая команда, занимающаяся поддержкой подсистемы мониторинга. Наконец, развертывание адаптера для мониторин-га в виде отдельного контейнера гарантирует, что каждый кон-тейнер получит свой выделенный набор ресурсов: процессор, память и т. п. Благодаря этому неправильно функционирующий контейнер не вызовет проблем с пользовательскими сервисами. Практикум. Мониторинг с помощью Prometheus

В качестве примера рассмотрим мониторинг состояния контей-неров с помощью Prometheus ( https://prometheus.io/ ). Prometheus — это агрегатор данных мониторинга, который собирает показатели организует в упорядоченную по времени базу данных. Кроме базы данных, Prometheus предоставляет средства визуализации и язык запросов для анализа собранных показателей. Чтобы обе-

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

Однако многие приложения, такие как хранилище «ключ — зна-чение» Redis, предоставляют показатели в формате, не совме-стимом с Prometheus. Следовательно, паттерн Adapter весьма полезен для адаптирования существующих сервисов вроде Redis к интерфейсу сбора показателей Prometheus. 68Часть I. Одноузловые паттерны проектирования

Рассмотрим спецификацию простой группы контейнеров для сервиса Redis:

apiVersion: v1

kind: Pod

metadata:

name: adapter-example

namespace: default

spec:

containers:

- image: redis

name: redis

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