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

Шрифт
Интервал

$ 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 <образ>