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

...

# Главный сервер принимает запросы на порт 8080 EXPOSE 8080

...

Если вы используете переменные среды для параметризации контейнера, то, чтобы установить их значения по умолчанию, можно указать директиву ENV с комментарием: ...

# Параметр PROXY_PORT обозначает порт, на который необходимо # перенаправлять запросы

ENV PROXY_PORT 8000

...

C помощью директивы LABEL к образу можно добавить метадан-ные — e-mail разработчика, адрес веб-страницы, версию образа и т. д.

...

LABEL "org.label-schema.vendor"="name@company.com" LABEL "org.label.url"="http://images.company.com/my-cool-image" LABEL "org.label-schema.version"="1.0.3"

Глава 2. Паттерн Sidecar 49

Имена меток метаданных позаимствованы из проекта Label Schema ( http://label-schema.org/rc1 ). Цель проекта — сформировать набор общеизвестных меток.

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

бительных терминов появляется возможность задействовать инструменты, разработанные сообществом, не меняя образа контейнера. Безусловно, можно добавлять и любые другие метки, уместные в контексте вашего образа. Резюме

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

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

3 Паттерн AmbassadorВ предыдущей главе мы рассмотрели паттерн Sidecar, в рамках которого контейнер-прицеп функционально дополняет суще-ствующий контейнер приложения. В этой главе мы познакомимся с паттерном Ambassador («посол»). Контейнер-посол выступает посредником во взаимодействии контейнера приложения с внеш-ним миром. Как и в случае с остальными одноузловыми паттерна-ми проектирования, два контейнера составляют симбиотический союз и исполняются совместно на одном компьютере. Схема данного паттерна изображена на рис. 3.1.

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

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

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

В оставшейся части данной главы мы рассмотрим несколько практических примеров реализации паттерна Ambassador. Использование паттерна Ambassador для шардирования сервиса В какой-то момент данных на уровне хранилища (storage layer) становится так много, что они перестают помещаться на одной машине. В таких ситуациях необходимо шардировать уровень хранилища.

Шардинг (шардирование) — разделение уровня хранилища на несколько независимых частей (шардов), каждая из которых размещается на отдельной машине. В данной главе рассматри-вается одноузловой паттерн проектирования, предназначенный для адаптирования существующих сервисов, чтобы те могли взаимодействовать с другими, шардированными сервисами, находящимися где-то в Интернете. Здесь не рассматривается, откуда появляются шардированные сервисы. О шардировании многоузловом паттерне проектирования шардированных сервисов мы подробно поговорим в главе 6. 52Часть I. Одноузловые паттерны проектирования

Схема шардированного сервиса представлена на рис. 3.2.