Cloud Foundry: сервисные брокеры 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/

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();

{
    "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».

$ cf add-service-broker \
--username demouser --password demopassword \
--url http://echo-service-broker.stacka.to echo-service