[Эта статья была первоначально написана Джейми Патоном.]
Мы рады, что с открытым исходным кодом в реализации Cloud Foundry Service Broker в Node.js .
Это было интересное путешествие, наблюдая, как различные компоненты Cloud Foundry развиваются с момента его первого выпуска в 2011 году. Службы данных — это лишь один из основных компонентов, которые должны быть обновлены во второй версии проекта Cloud Foundry.
Почему Node.js?
Здесь, в ActiveState, мы думаем, что наличие широкого выбора услуг передачи данных позволяет усовершенствовать ваши инновации и оптимизировать ваши приложения, а добавление новых в Cloud Foundry должно быть простым процессом.
Нам также нравится использовать Node.js и пользоваться преимуществами энергичного роста сообщества, поддерживающего его. С более чем 160 новыми модулями, добавляемыми в NPM каждый день, стало доступно много хорошего кода, полезного для написания REST-серверов.
По своей сути Node.js предоставляет все необходимое для начала работы, включая:
- REST-сервер, использующий Restify, который поддерживает API служб v2
- EventEmitter API для подписки на события предоставления / привязки
- Встроенный пользовательский журнал
- Модуль npm может быть использован через ‘require’ или как отдельный брокер, использующий CLI.
- Обеспечивает сохранение записей службы через хранилище данных LevelDB
Старые сервисы CFv1
Архитектура сервиса v1 в целом работала хорошо, но разделение сервиса на два отдельных компонента означало, что любой из них был потенциальной единственной точкой отказа. С помощью сервисов v2 вы можете настроить столько брокеров, сколько вам нужно, и все они могут взаимодействовать с одной и той же службой данных для горизонтального масштабирования.
Написание сервисов v1 было немного неловким делом, так как вы обычно ограничивались реализацией Ruby, которая включала сборку поверх двух больших хранилищ Ruby. Если облачный контроллер был обновлен, его необходимо обновить для обеспечения совместимости. Вам также пришлось разместить сервисные процессы в месте, которое может быть достигнуто как с помощью шины сообщений NATS, так и API-интерфейса Cloud Controller. Обычно это ограничивает доступ к той же сети, что и сам кластер Cloud Foundry.
Шлюзы CFv1 были разработаны для объявления любого количества сервисов облачному контроллеру, работающему в его домене. В его обязанности входил запуск асинхронного REST-сервера, который запрашивал двунаправленную связь с облачным контроллером для рекламы каталога услуг. Он также будет поддерживать синхронизацию с сервисными узлами по локальной шине сообщений NATS, что означает, что шлюз и узел тесно связаны.
Узлы CFv1 были главным образом ответственны за управление определенными планами обслуживания. Это был основной оркестратор между реальной службой данных и шлюзом, и он должен был поддерживать правильный набор услуг, определяемый шлюзом. Большая часть основного набора служб CFv1 хранила определенные положения службы в локальной базе данных SQLite для обеспечения согласованности.
Подробную информацию о внедрении устаревших сервисов v1 можно найти здесь .
Новые сервисы CFv2
API сервисов v2 привел к нескольким долгожданным изменениям, таким как более подробные атрибуты плана для более детального API биллинга, аутентификация всех запросов с помощью базовой аутентификации HTTP (ранее это было с использованием общих токенов) и более заметное изменение в управлении внешними сервисами. с установкой Cloud Foundry. Все каталогизированные сервисы и планы теперь должны иметь уникальный идентификационный номер, а их устаревшие версии v1 «версия» и «поставщик» устарели в v2.
Внутри API сервисов v2 был введен немного другой режим, в котором вы будете реализовывать сервис. Понятия шлюза и узла как двух отдельных объектов больше не существуют. Теперь есть только «брокер», который отвечает за:
- Реализация REST-сервера для взаимодействия с Cloud Controller
- Аутентификация запросов с использованием базовой аутентификации HTTP
- Предоставление интерфейса к самой службе данных для всех событий предоставления / отмены предоставления и привязки / отмены привязки
- Ведение каталога всех доступных услуг и связанных с ними планов обслуживания
- Ведение единой записи экземпляров и привязок предоставленных сервисов для обеспечения их устойчивости между перезапусками брокера.
Сервис МаркетПлейс
Другим долгожданным изменением стало введение централизованной системы «MarketPlace», которая позволяет администратору CF устанавливать службы и делать их доступными для каждой организации. Чтобы позволить рынку и дальше поддерживать внешние услуги, брокерам теперь требуется только однонаправленная связь. Это, в свою очередь, означает, что вам больше не нужно предоставлять HTTP-порт Cloud Controller через общедоступную или ненадежную сеть посреднику служб.
Регистрация v2 Сервисов
В отличие от сервисов v1, для сервисов v2 вам необходимо зарегистрировать брокера с помощью отдельного вызова API сервиса. Например, используя клиент cf:
$ cf create-service-broker <broker name> <user> <password> http://test-broker.stackato.com/
Внедрение брокера
Мы сохранили минимальный уровень, чтобы обеспечить большую гибкость при реализации ваших собственных брокеров. Основная идея заключается в том, что вы просто предоставляете ему файл конфигурации JSON, в котором подробно описываются сервисы и связанные планы, а затем просто прослушиваете события, когда контроллер облака их инициирует. :
broker.js:
var Broker = require('cf-services-connector-nodejs'); var Config = require('./config/increment-service'); // JSON configuration file var inc = 0; var broker = new Broker(Config); broker.start(); broker.on('provision', function (req, next) { inc++; var reply = { dashboard_url: req.params.service_id }; next(reply); }); broker.on('unprovision', function (req, next) { next(); }); broker.on('bind', function (req, next) { var reply = {}; reply.credentials = { host: '192.xxx.xxx.xxx', port: (1000 + inc) }; next(reply); }); broker.on('unbind', function (req, next) { next(); }); // broker.stop();
Пока все просто. Обратите внимание, что ваш собственный брокер должен подписаться на все события, указанные выше.
Конфигурация брокера
С нашей реализацией Node.js сервисного брокера вся конфигурация для брокера инкапсулирована в файл конфигурации JSON.
Вот файл конфигурации, который использует вышеупомянутый брокер.
Приращение-services.json:
{ "apiVersion": "2.1.0", "authUser": "<changeme>", "authPassword": "<changeme>", "defaultVersion": "1.0", "name": "Increment Service", "port": 5006, "services": [{ "id": "47c6bff8-c653-4812-89f8-ee9a9b6c3d55", "bindable": true, "name": "Increment Service", "version": "1.0", "description": "Increment Service - increment", "metadata": { "providerDisplayName": "Increment Service Ltd.", "tags": [ "increment", "demo" ] }, "plans": [{ "name": "default", "id": "6b6fdd28-eb91-4eb7-9936-bf82ec1ec2d5", "description": "This is the first plan", "public": true, "free": true }, { "name": "secondary", "id": "a3d1fb32-ba06-4122-9013-d42ef84d8b75", "description": "This is the secondary plan", "public": true, "free": false }] }], "database": { "enabled": true, "allowOrphanedBindings": false, "databaseFile": "./leveldb", "encryptionKey": "!!changeme!!" } }
Надеюсь, приведенный выше конфиг достаточно понятен. Самое главное, не забудьте изменить «authUser», «authPassword» и, если вы используете встроенную базу данных, «encryptionKey».
Если для параметра allowOrphanedBindings задано значение true, посредник выдаст ошибку 500, если попытается удалить экземпляр службы, имеющий привязки. При удалении экземпляра службы может потребоваться автоматическое удаление всех привязок, поэтому по умолчанию для этого параметра установлено значение false.
Документация Cloud Foundry для v2 Services описывает другие атрибуты конфигурации, которые вы можете использовать. Например, вы можете добавить URL-адрес документации, URL-адрес службы поддержки и платежную информацию.
Добавление брокера в ваш кластер
Реализация брокера Node.js включает в себя пример службы брокера, которая называется echo-service .
Если бы мы развернули это приложение в изолированной программной среде Stackato , мы могли бы добавить эту службу брокера эха в качестве доступной службы в нашем кластере, используя следующую команду.
$ cf add-service-broker \ --username demouser --password demopassword \ --url http://echo-service-broker.stacka.to echo-service
Открытый исходный код
Мы рады, что у нас есть сервис-брокер с открытым исходным кодом, чтобы помочь вам начать писать свои собственные сервисы. Как видно из приведенного выше примера, теперь это очень просто реализовать.
Мы надеемся, что это позволит вам без труда приступить к написанию служб данных для Stackato 3 и Cloud Foundry v2. Если у вас возникли какие-либо проблемы или вы хотите оставить отзыв, пожалуйста, откройте проблему Github или присоединитесь к каналу #stackato на irc.freenode.net.
— См. Больше на:
http://www.activestate.com/blog/2014/04/cloud-foundry-nodejs-service-brokers-open-sourced#sthash.p4rXEhjl.dpuf