Распределенные системы. Паттерны проектирования - страница 16
Такой пример, конечно же, очевиден, но нарушить интерфейс контейнера можно гораздо менее явным образом. Допустим, параметр UPDATE_FREQUENCY изначально принимал число секунд.
Со временем, с учетом обратной связи от пользователей, раз-работчик решил, что длительные интервалы (минуты, часы) не-удобно указывать в секундах. Он модифицировал параметр так, Глава 2. Паттерн Sidecar 47
чтобы тот принимал строки (10 минут, 5 секунд и т. п.). Посколь-ку старые значения параметров не смогут быть обработаны но-вым контейнером, такое изменение API окажется критическим. Представьте, что разработчик предусмотрел этот вариант, но сделал так, чтобы значения без единиц измерения интерпрети-ровались как число миллисекунд. Такое изменение, хотя и не приводит к ошибкам, является недопустимым, поскольку при-водит к более частым проверкам конфигурации и, как следствие, большей нагрузке на сервер.
Надеюсь, вы осознали, что для обеспечения настоящей модуль-ности необходимо внимательно относиться к предоставляемому вашим контейнером программному интерфейсу. Критические изменения могут быть вызваны менее очевидными, нежели смена имени параметра, причинами.
Документирование контейнеров На данный момент вы уже умеете параметризовать свои контей-неры, чтобы они были модульными и их можно было повторно использовать. Вы уже знаете, насколько важно поддерживать стабильный программный интерфейс вашего контейнера, чтобы обеспечить его бесперебойную работу у конечных пользовате-лей. Но есть еще один шаг к построению модульных, повторно используемых контейнеров — предоставить пользователям ин-формацию, как их применять в принципе.
Как и в случае с программными библиотеками, ключ к созданию полезной вещи — объяснение, как ею пользоваться. Мало поль-зы в создании гибкого, надежного, модульного контейнера, если никто не может понять, как с ним работать. К сожалению, на сегодняшний день доступно не так много формальных инстру-ментов, позволяющих документировать образы контейнеров, но есть несколько полезных приемов, упрощающих работу. 48 Часть I. Одноузловые паттерны проектирования
У каждого контейнера есть конфигурационный файл Dockerfile , на основе которого строится образ контейнера. Именно в нем в первую очередь стоит искать документацию к контейнеру. Некоторые части Dockerfile документируют работу контей-нера сами по себе. Одним из примеров может служить дирек-тива EXPOSE , в которой перечислены сетевые порты, открытые в контейнере. Указывать ее не обязательно, но это считается хорошим тоном. Неплохо также снабдить ее комментарием, поясняющим, какой конкретно сервис прослушивает данный порт. Например:
...
# Главный сервер принимает запросы на порт 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 можно использовать для модерни-зации унаследованных приложений, если внесение изменений в них обойдется слишком дорого. Кроме того, этот паттерн можно применять для создания модульных контейнеров-ути-лит, задающих стандартную реализацию часто используемых функциональных возможностей. Контейнеры-утилиты можно задействовать во множестве приложений, повышая согласо-ванность среды и снижая расходы на разработку последующих приложений.