Blog

Wie man einen Amazon RDS Service Broker für Cloud Foundry schreibt

Mark van Holsteijn

Mark van Holsteijn

Aktualisiert Oktober 22, 2025
9 Minuten

Cloud Foundry ist eine wunderbare On-Premise-PaaS, die die Erstellung und Bereitstellung sehr einfach macht und gleichzeitig Skalierbarkeit und hohe Verfügbarkeit für Ihre zustandslosen Anwendungen bietet. Aber Cloud Foundry ist eigentlich ein Application Platform Service und bietet keine hohe Verfügbarkeit und Skalierbarkeit für Ihre Daten. Zum Glück gibt es Amazon RDS, das dies als Service hervorragend bietet. In diesem Blog zeige ich Ihnen, wie einfach es ist, einen Cloud Foundry Service Broker für Amazon RDS zu erstellen, zu installieren und zu verwenden. Der Broker wurde in Node.JS unter Verwendung des Restify-Frameworks entwickelt und kann wie eine normale Cloud Foundry-Anwendung bereitgestellt werden. Schließlich verweise ich Sie auf einen Skeleton Service Broker, den Sie als Grundlage für Ihren eigenen verwenden können.

Cloud Foundry Service Broker Domäne

Bevor ich mich in die Details der Implementierung stürze, möchte ich Sie in den Cloud Foundry-Jargon einführen. Wenn Sie mit der Fachsprache vertraut sind, überspringen Sie einfach den Abschnitt 'AWS RDS Service Broker Operationen'. Dienst - eine externe Ressource, die von einer Anwendung genutzt werden kann. Dabei kann es sich um eine Datenbank, ein Nachrichtensystem oder eine externe Anwendung handeln. Häufig angebotene Dienste sind mysql, postgres, redis und memcached. Serviceplan - ein Plan legt die Qualität des Dienstes fest und regelt die Menge an Arbeitsspeicher, Festplattenplatz, Knoten usw., die mit dem Dienst bereitgestellt werden. Servicekatalog - ein Dokument, das alle Services und Servicepläne eines Servicebrokers enthält. Service Broker - ein Programm, das in der Lage ist, Dienste zu erstellen und Anwendungen die notwendigen Informationen zur Verfügung zu stellen, um sich mit dem Dienst zu verbinden. Ein Service Broker kann nun die folgenden Operationen durchführen: Beschreiben Sie die Dienstleistungen - Zeigen Sie mir alle Dienstleistungen, die dieser Makler anbieten kann. Dienst erstellen - Erstellen einer Instanz eines Dienstes, der einem bestimmten Plan entspricht. Wenn der Dienst eine Datenbank ist, hängt es vom Broker ab, was dies bedeutet: Er kann einen ganzen Datenbankserver oder nur eine neue Datenbankinstanz oder sogar nur ein Datenbankschema erstellen. Cloud Foundry nennt dies 'Bereitstellung einer Service-Instanz'. Binden eines Dienstes - Bereitstellung der erforderlichen Informationen für eine bestimmte Anwendung, um eine Verbindung zu einem vorhandenen Dienst herzustellen. Wenn es sich bei dem Dienst um eine Datenbank handelt, werden der Hostname, der Portname, der Datenbankname, der Benutzername und das Passwort angegeben. Je nach Servicebroker kann der Broker sogar spezifische Anmeldeinformationen für jede Bindungsanfrage/Anwendung erstellen. Der Cloud Controller speichert die zurückgegebenen Anmeldeinformationen in einem JSON-Dokument, das als UNIX-Umgebungsvariable (VCAP_SERVICES) gespeichert wird. Bindung aufheben - je nach Service-Broker machen Sie das rückgängig, was Sie bei der Bindung getan haben. Dienst zerstören - Ganz einfach, Sie löschen einfach, was erstellt wurde. Cloud Foundry nennt dies "Deprovisionierung einer Service-Instanz". Im nächsten Abschnitt werde ich diese Vorgänge auf Amazon AWS RDS-Services abbilden.

AWS RDS Service Broker Vorgänge

Jeder Service Broker muss eine REST-API der Cloud Foundry-Spezifikation implementieren. Um den Amazon AWS RDS Service Broker zu erstellen, musste ich vier von fünf Methoden implementieren:

  • Dienste beschreiben - gibt verfügbare Dienste und Servicepläne zurück
  • Dienst erstellen - Rufen Sie die Operation createDBInstance auf und speichern Sie die generierten Anmeldeinformationen als Tags mit der Instanz.
  • bind service - rufen Sie die Operation describeDBInstances auf und geben Sie die gespeicherten Anmeldeinformationen zurück.
  • Löschdienst - rufen Sie einfach die Operation deleteDBInstance auf.

Ich habe diese REST-Aufrufe mit dem Restify-Framework und der Amazon AWS RDS API für Javascript implementiert: [javascript] // Katalog holen server.get('/v2/katalog', function(request, response, next) { response.send(config.catalog); next(); }); // Dienst erstellen server.put('/v2/service_instances/:id', function(request, response, next) { response.send(501, { 'description' : 'create/provision service not implemented' }); next(); }); // Dienst löschen server.del('/v2/service_instances/:id', function(req, response, next) { response.send(501, { 'description' : 'delete/unprovision service not implemented' }); next(); }); // Dienst binden server.put('/v2/service_instances/:instance_id/service_bindings/:id', function(req, response, next) { response.send(501, { 'description' : 'bind service not implemented' }); next(); }); // Bindung des Dienstes aufheben server.del('/v2/service_instances/:instance_id/service_bindings/:id', function(req, response, next) { response.send(501, { 'description' : 'unbind service not implemented' }); next(); }); [/javascript] Für die tatsächliche Implementierung der einzelnen Operationen auf AWS RDS möchte ich Sie auf den Quellcode von aws-rds-service-broker.js auf github.com verweisen.

Design-Entscheidungen

Das sieht doch gar nicht so schwierig aus, oder? Hier sind einige meiner Designentscheidungen:

Wo speichere ich die Berechtigungsnachweise?

Ich speichere die Anmeldeinformationen als Tags auf der Instanz. Ich wollte einen Service Broker erstellen, der völlig zustandslos ist, damit ich ihn in Cloud Foundry selbst einsetzen kann. Ich wollte nicht von einer kompletten Datenbank für ein paar Informationen abhängig sein. Die Tags schienen für diesen Zweck geeignet zu sein.

Warum gibt bind bei jeder Verbindung die gleichen Anmeldedaten zurück?

Ich wollte, dass der Bindungsdienst so einfach wie möglich ist. Ich wollte keine neuen Benutzerkonten und Passwörter erstellen, denn dann hätte ich noch mehr Status zu verwalten. Außerdem stellte ich fest, dass, wenn ich zwei Anwendungen an denselben MySQL-Dienst binde, sie die Daten des jeweils anderen sehen können. Wozu also noch Benutzer für Bindungen anlegen? Und schließlich war der Bindungsdienst so einfach, dass der Entbindungsdienst noch einfacher war, weil es nichts rückgängig zu machen gab.

Wie lassen sich verschiedene Servicepläne umsetzen?

Die createDBInstance-Operation der AWS RDS-API-Operation nimmt ein JSON-Objekt als Eingabeparameter entgegen, das im Grunde das Äquivalent eines Plans ist. Ich musste nur für jeden Plan einen entsprechenden JSON-Datensatz in die Konfigurationsdatei einfügen. Siehe die Beschreibung des Parameters params der Operation createDBInstance.

Wie erstelle ich einen AWS RDS-Service innerhalb von 60 Sekunden?

Nun, ich weiß es nicht. Die Service Broker-API besagt, dass Sie einen Dienst innerhalb des Timeouts des Cloud Controllers erstellen müssen (das sind 60 Sekunden), aber RDS braucht ein bisschen mehr Zeit. Die Erstellungsanforderung wird also innerhalb von Sekunden ausgelöst, aber bis Sie eine Anwendung daran binden können, kann es ein paar Minuten dauern. Daran kann ich nichts ändern.

Warum sollten Sie die Anmeldeinformationen für den Service Broker in Umgebungsvariablen speichern?

Ich möchte, dass der Service Broker bei der Bereitstellung konfiguriert wird. Wenn die Anmeldeinformationen in der Konfigurationsdatei stehen, müssen Sie die Dateien der Anwendung bei jeder Bereitstellung ändern.

Installation

In dieser Anleitung gehe ich davon aus, dass Sie Zugang zu einem AWS-Konto haben und über eine Installation von Cloud Foundry verfügen. Ich habe Stackato verwendet, eine Cloud Foundy-Implementierung von ActiveState. Diese Anleitung setzt voraus, dass Sie das auch tun!

  1. Erstellen Sie einen AWS IAM-Benutzer Erstellen Sie zunächst einen AWS IAM-Benutzer (cf-aws-service-broker) mit mindestens den folgenden Berechtigungen
  2. Zuweisung von Berechtigungen für die Ausführung von AWS RDS-Vorgängen Der neu erstellte IAM-Benutzer benötigt die Berechtigungen zum Erstellen von RDS-Datenbanken. Ich habe die folgenden Berechtigungen verwendet: [javascript] { "Version": "2012-10-17", "Erklärung": [ { "Wirkung": "Erlauben", "Aktion": [ "rds:AddTagsToResource", "rds:CreateDBInstance", "rds:DeleteDBInstance", "rds:DescribeDBInstances", "rds:ListTagsForResource" ], "Ressource": [ "*" ] }, { "Wirkung": "Erlauben", "Aktion": [ "iam:GetUser" ], "Ressource": [ "*" ] } ] } [/javascript]
  3. Generieren Sie den AWS-Zugangsschlüssel und das Geheimnis für den Benutzer 'cf-aws-service-broker'.
  4. Erstellen Sie ein Datenbank-Subnetz Erstellen Sie ein Datenbank-Subnetz 'stackato-db-subnet-group' in der AWS-Region, in der Sie die Datenbanken erstellen möchten.
  5. Überprüfen Sie den Service-Broker [bash] gitclone https://github.com/mvanholsteijn/aws-rds-service-broker cd aws-rds-service-broker [/bash]
  6. Fügen Sie alle Ihre Parameter als Umgebungsvariablen in die manifest.yml ein [javascript] Anwendungen: - Name: aws-rds-service-broker mem: 256M disk: 1024M instances: 1 env: AWS_ACCESS_KEY_ID: <fillin> AWS_SECRET_ACCESS_KEY: <fillin> AWS_REGION: <der db-Subnetzgruppe, z.B. eu-west-1> AWS_DB_SUBNET_GROUP: stackato-db-subnet-group SERVICE_BROKER_USERNAME: <fillin> SERVICE_BROKER_PASSWORD: <fillin> stackato: ignoriert: - .git - bin - node_modules [/javascript]
  7. Stellen Sie den Service Broker bereit [bash] stackato target <your-service-broker> --skip-ssl-validation stackato login push [/bash]
  8. Installieren Sie den Service-Broker Dieses Skript ist eine schlaue Implementierung, die den Service-Broker in Cloud Foundry erstellt und alle Pläne öffentlich zugänglich macht. In Stackato verwenden wir die curl-Befehle, um dies zu erreichen. Dieses Skript setzt voraus, dass Sie jq installiert haben, den wunderbaren JSON-Kommandozeilenprozessor von Stephen Dolan. [bash] bin/install-service-broker.sh [/bash]

Jetzt können Sie den Service Broker nutzen!

Verwendung des Service Brokers

Jetzt sind wir bereit, den Service Broker zu verwenden.

  1. Verteilen Sie eine Beispielanwendung [bash] $[/bash]git clone https://github.com/mvanholsteijn/paas-monitor $stackato push -n
  2. Erstellen Sie einen Dienst für die mysql-Dienste [bash] $ stackato create-service 1. filesystem 1.0, by core 2. mysql 3. mysql 5.5, by core 4. postgres 5. postgresql 9.1, by core 6. redis 2.8, by core 7. user-provided Welche Art soll bereitgestellt werden:? 2 1. 10gb: 10Gb HA MySQL-Datenbank. 2. default: Kleine 5Gb Nicht-HA-MySQL-Datenbank Bitte wählen Sie den Dienstplan aus, der in Kraft treten soll:? 2 Neuen Dienst erstellen [mysql-844b1] ... OK [/bash]
  3. Binden Sie den Dienst an die Anwendung [bash] stackato bind-service mysql-844b1 paas-monitor Binden von mysql-844b1 an paas-monitor ... Fehler 10001: Dienstmaklerfehler: Kein Endpunkt auf der Instanz 'cfdb-3529e5764' gesetzt. Die Instanz befindet sich im Zustand 'Erstellen'. Bitte versuchen Sie es ein paar Minuten später erneut (500) [/bash] wiederholen, bis die Datenbank tatsächlich erstellt wurde (3-10 Minuten auf AWS) [bash] stackato bind-service mysql-844b1 paas-monitor Bindet mysql-844d1 an paas-monitor ... Stoppt Anwendung [paas-monitor] ... OK Anwendung [paas-monitor] starten ... OK https://paas-monitor.<your-api-endpoint>/ deployed [/bash]
  4. Überprüfen Sie die Umgebung der Anwendung [bash] curl -s https://paas-monitor.<your-api-endpoint> /environment| jq .DATABASE_URL "mysql://root:e1zfMf7OXeq3@cfdb-3529e5764.c1ktcm2kjsfu.eu-central-1.rds.amazonaws.com:3306/mydb" [/bash] Wie Sie sehen können, wurden die Anmeldeinformationen für die neu erstellte Datenbank in die Umgebung der Anwendung eingefügt.

Erstellen Sie Ihren eigenen Service Broker

Wenn Sie Ihren eigenen Service Broker in Node.JS erstellen möchten, ist der Skeleton Service Broker ein guter Ausgangspunkt. Er enthält eine Reihe von Dienstprogrammen zum Testen Ihres Brokers im Verzeichnis bin.

  • catalog.sh - ruft den Katalogvorgang auf
  • provision.sh - ruft den Erstellungsvorgang auf
  • unprovision.sh - Aufruf des Löschvorgangs
  • bind.sh - ruft die Bindungsoperation für eine bestimmte Instanz auf
  • unbind.sh - ruft die Operation unbind für eine bestimmte Instanz und Bindungs-ID auf.
  • list.sh - ruft die Operation list all service instances auf
  • getenv.sh - liefert die Umgebungsvariablen einer CF-Anwendung als quellfähige Ausgabe
  • install-service-broker.sh - installiert die Anwendung und macht alle Pläne öffentlich.
  • docurl.sh - ruft die Operation stackato CURL auf.

getenv.sh, install-service-broker.sh und provision.sh erfordern die Installation von jq.

Fazit

Wie Sie sehen können, ist es ganz einfach, Ihren eigenen Cloud Foundry Service Broker zu erstellen!


Tags:

Verfasst von

Mark van Holsteijn

Mark van Holsteijn is a senior software systems architect at Xebia Cloud-native solutions. He is passionate about removing waste in the software delivery process and keeping things clear and simple.

Contact

Let’s discuss how we can support your journey.