Создание микросервисов

Сам Docker всех проблем за нас не решает. Его нужно представлять в качестве простой PaaS-платформы, работающей на одной машине. Если требуется инструментарий, помогающий управлять сервисами, разбросанными по нескольким Docker-экземплярам и нескольким машинам, нужно поискать другие программы, добавляющие такие возможности. К основным потребностям относится уровень диспетчеризации, позволяющий запрашивать контейнер, после чего он находит Docker-контейнер, который может запустить для вас. Оказать помощь в этой области могут принадлежащая Google недавно разработанная технология с открытым кодом Kubernetes и имеющиеся в CoreOS кластерные технологии. И похоже, что новички в этой области появляются чуть ли не каждый месяц. Еще одним интересным средством на основе Docker является Deis. Оно пытается предоставить поверх Docker PaaS-платформу, похожую на Heroku.

Ранее я уже говорил о PaaS-решениях. Я всегда вел борьбу с ними из-за того, что они довольно часто неправильно понимают уровень абстракции, а самостоятельно принимаемые решения существенно отстают от таких уже принятых решений, как Heroku. Docker получает намного больше прав, и резкий подъем интереса в этой области означает, как я предполагаю, что это средство через несколько лет станет намного более жизнеспособной платформой для всех разновидностей развертываний и всех разнообразных вариантов применения. Во многих отношениях Docker с соответствующим уровнем диспетчеризации располагается между решениями IaaS и PaaS, и для его описания уже использовался термин «контейнеры в качестве сервиса» (Containers as a Service (CaaS)).

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

Интерфейс развертывания

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

Проработав в этой области много лет, я убежден, что наиболее разумным способом запуска любого развертывания является единый вызов инструкции командной строки с указанием нужных параметров. Инструкция может вызываться из сценария, ее выполнение может инициироваться вашим CI-средством, или же она может набираться вручную. Для выполнения этой работы я создавал сценарии-оболочки в различных технологических стеках, от пакетных файлов Windows до bash, а также до Python Fabric-сценариев и т. д., но все инструкции командной строки использовали один и тот же основной формат.

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

Третье и последнее, о чем нам нужно знать, — это в какой среде следует развертывать микросервис. Как уже говорилось, топология наших микросервисов от среды к среде может быть разной, но здесь она должна быть скрыта от нас.

Итак, представим, что мы создали простой сценарий развертывания, получающий три параметра. Скажем, проводится локальное развертывание сервиса каталога в нашу локальную среду. Я могу набрать следующую инструкцию:

$ deploy artifact=catalog environment=local version=local

После того как будет проведена проверка, CI-сборка сервиса получает изменение и создает новый сборочный артефакт, присваивая сборке номер b456 в соответствии со стандартом, принятым в большинстве CI-средств. Это значение проводится по всему конвейеру. Когда запускается наша стадия тестирования, при выполнении CI-стадии может быть написано следующее:

$ deploy artifact=catalog environment=ci version=b456

Тем временем контролю качества потребовалось поместить последнюю версию сервиса каталога в интегрированную тестовую среду для выполнения исследовательского тестирования и оказания помощи в оформлении проспекта. Эта команда написала следующую инструкцию:

$ deploy artifact=catalog environment=integrated_qa version=latest