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

$ 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. Одноузловые паттерны проектирования

Создание простейшего PaaS-сервиса на основе паттерна Sidecar Паттерн Sidecar может использоваться не только для адапти-рования и мониторинга. Его также можно задействовать для реализации всей логики приложения с применением упро-щенного модульного подхода. Представьте себе, к примеру, простой PaaS-сервис, построенный вокруг рабочего процесса в Git-репозитории. Когда вы развернете этот сервис, вы смо-жете разворачивать код на рабочие серверы путем загрузки его в Git-репозиторий. Рассмотрим, как c помощью паттерна Sidecar можно простейшим образом реализовать такой PaaS. Как было сказано ранее, в паттерне Sidecar два контейнера — основной контейнер приложения и контейнер-прицеп. В про-стом PaaS-приложении основной контейнер представляет собой Node.js-сервер, реализующий веб-сервис. Node.js-сервер на-строен таким образом, что автоматически перезапускается при обновлении файлов. Это реализовано с помощью инструмента nodemon ( https://nodemon.io/ ).

Контейнер-прицеп использует общую с основным контейнером приложения файловую систему и выполняет простой цикл, синхронизирующий ее с Git-репозиторием: #!/bin/bash

while true; do

git pull

sleep 10

done

Безусловно, этот скрипт мог быть гораздо сложнее. Он намерен-но упрощен, чтобы его было проще читать. Node.js-приложение и прицеп с Git-синхронизатором, реализу-ющие наш простейший PaaS-сервис, развертываются и исполня-Глава 2. Паттерн Sidecar 43

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

Рис. 2.4. Простейший PaaS-сервис на базе паттерна SidecarРазработка модульных и повторно используемых реализаций паттерна Sidecar

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

сценариев развертывания. Обеспечивая модульность и воз-можность повторного использования, реализации этого пат-терна позволяют значительно ускорить разработку вашего приложения.

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

‰ ‰ параметризация контейнеров;

‰ ‰ создание программного интерфейса контейнеров;‰ ‰ документирование работы контейнера.Параметризованные контейнеры Параметризация контейнеров — важнейший показатель дости-жения модульности и повторного использования контейнеров, независимо от того, реализуют они паттерн Sidecar или нет. Что я понимаю под параметризацией? Представьте, будто кон-тейнер — это функция в программе. Сколько у нее параметров? Каждый параметр представляет собой входные данные, которые помогают подстроить обобщенный контейнер под конкретную ситуацию. Рассмотрим, к примеру, контейнер-прицеп с SSL, который мы развернули ранее. Чтобы быть полезным в общем случае, он должен иметь по меньшей мере два параметра: имя сертификата, обеспечивающего функциональность SSL, и порт унаследованного сервера приложений, запущенного на ло-кальной машине. Без этих параметров трудно сказать, что он будет полезен для широкого спектра приложений. Похожие параметры есть во всех контейнерах-прицепах, рассмотренных в данной главе.

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

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

менных среды. Пример передачи параметра контейнеру: docker run -e=PORT=<���порт> -d <���образ>

Передача значений в контейнер — только половина успеха. Другая половина — собственно использование значений пере-менных внутри контейнера. Обычно это реализуется в рамках сценариев оболочки. Такой сценарий подгружает переменные среды, переданные контейнеру-прицепу, и на их основе либо корректирует конфигурационные файлы, либо параметризует базовое приложение.

К примеру, можно передать путь к сертификату и порт прило-жения в виде переменных среды следующим образом: docker run -e=PROXY_PORT=8080 \

-e=CERTIFICATE_PATH=/путь/к/сертификату.crt ... Сценарий в контейнере воспользуется значениями этих перемен-ных для формирования конфигурационного файла nginx.conf , который укажет серверу, где искать файл сертификата и куда переадресовывать запросы.

Определение API всех контейнеров Если учитывать, что вы параметризуете свои контейнеры, будет очевидно, что каждый из них определяет некую «функцию», кото-рая вызывается при запуске контейнера. Эта функция является ча-стью API, определяемого вашим контейнером, но у него есть и дру-гие составляющие, включая вызовы к внешним по отношению 46Часть I. Одноузловые паттерны проектирования

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