){kind=small}
Versenden von GitLab CI Pipeline-Benachrichtigungen mit Nexmo Messages
Lesedauer: 6 Minuten
Ich betreibe meinen eigenen Blog, Der polyglotte Entwicklerder als Teil einer kontinuierlichen Integrations- und Bereitstellungspipeline veröffentlicht wird. Im Wesentlichen geschieht die folgende Abfolge von Ereignissen jedes Mal, wenn eine git push ausgeführt wird:
Die statische Website wird auf GitLab übertragen.
Der Build-Prozess der Pipeline beginnt
Der Bereitstellungsprozess der Pipeline beginnt
Die statische Website ist veröffentlicht und steht zur Nutzung bereit
In mehr Fällen, als ich zugeben möchte, schlägt der Prozess fehl, weil entweder mein Build oder die Bereitstellung fehlgeschlagen ist. Das Problem ist, dass ich oft nicht weiß, dass diese Fehler passieren, was manchmal eine Menge Rückverfolgung verursacht.
Wir werden sehen, wie wir den CI/CD-Prozess durch SMS-Benachrichtigungen von Nexmo im Falle eines Fehlers verbessern können.
Falls Sie mit GitLab nicht vertraut sind, können Sie deren CI-Dienste nutzen, indem Sie eine .gitlab-ci.yml Datei in das Stammverzeichnis Ihres Git-Projekts einfügen. Diese Datei könnte etwa so aussehen:
image: "node:alpine"
stages:
- build
- deploy
build:
stage: build
script:
- npm install
- npx gulp build
artifacts:
paths:
- dist
deploy:
stage: deploy
script:
- npm install
- npx gulp deployDie obige Konfiguration ist fiktiv, aber sie folgt einer korrekt formatierten .gitlab-ci.yml Datei. In dem obigen Szenario gibt es eine build Stage, die die build gulp-Aufgabe ausführt und eine deploy Stufe, die die deploy gulp-Aufgabe ausführt.
Was passiert, wenn eine der beiden Stufen ausfällt?
Mit GitLab CI können Sie festlegen, wann bestimmte Phasen ausgeführt werden, d. h. Sie können eine Phase so gestalten, dass sie im Falle eines Fehlers ausgeführt wird. Mit diesem Gedanken im Hinterkopf, könnten wir unsere .gitlab-ci.yml etwa wie folgt aussehen lassen:
image: "node:alpine"
stages:
- build
- deploy
- failure
build:
stage: build
script:
- npm install
- npx gulp build
artifacts:
paths:
- dist
deploy:
stage: deploy
script:
- npm install
- npx gulp deploy
failure:
stage: failure
script:
- echo "failure"
when: on_failureDie wichtige Information ist die when Eigenschaft, die auf der failure Bühne.
Da wir nun wissen, wie wir eine GitLab CI-Konfiguration erstellen können, stellt sich die Frage, wie wir diese zu unserem Vorteil nutzen können, um uns zu benachrichtigen, wenn in der Pipeline ein Fehler auftritt.
Hier sind Nexmo und der SMS-Dienst von großem Nutzen.
Wenn unsere Pipeline ausfällt, können wir den SMS-Service von Nexmo nutzen, um uns eine Textnachricht zu schicken, die Pipeline-Informationen, Commit-Informationen oder wirklich alles, was für uns oder das für das Projekt verantwortliche Team wertvoll sein könnte, enthalten kann.
Um dieses Tutorial durchzuführen, benötigen Sie ein Vonage API-Konto. Wenn Sie noch keines haben, können Sie sich noch heute anmelden und mit einem kostenlosen Guthaben beginnen. Sobald Sie ein Konto haben, finden Sie Ihren API-Schlüssel und Ihr API-Geheimnis oben auf dem Vonage-API-Dashboard.
Um die Nexmo SMS API zu nutzen, benötigen Sie einen Account. Innerhalb der Einstellungen Ihres Accounts notieren Sie sich den API-Schlüssel und das API-Geheimnis.
Settings
Die API-Informationen werden für den automatischen Versand von SMS-Nachrichten benötigt.
Wenn wir das wirklich wollten, und das sollten wir nicht, könnten wir eine cURL-Anweisung erstellen und alle unsere API- und Telefonnummern-Informationen fest codieren und direkt in die GitLab CI-Konfiguration einfügen. Das könnte man, sollte man aber nicht. Stattdessen sollten wir Pipeline-Umgebungsvariablen in GitLab erstellen.
Im Menü CI / CD -> Einstellungen Ihres GitLab-Projekts, erweitern Sie die Registerkarte Variablen Abschnitt.
Gitlab env variables
Hier fügen Sie Ihre sensiblen Informationen ein, damit sie nicht für jeden, der an Ihrem Projekt arbeitet, sichtbar sind. Fügen Sie den API-Schlüssel und die geheimen API-Informationen sowie die Zieltelefonnummer für die SMS hinzu. Um sie vor der Ausgabe des Pipeline-Protokolls zu schützen, stellen Sie sicher, dass diese Variablen Maskiertsind, damit sie nicht angezeigt werden.
Schauen wir uns nun die Datei .gitlab-ci.yml Datei. Damit sie leichter zu verstehen ist, kürzen wir sie ein wenig und lassen sie wie folgt aussehen:
image: "alpine:latest"
stages:
- build
- notify
build:
stage: build
script:
- exit 1
notify:
stage: notify
script:
- apk add curl
- curl -X "POST" "https://rest.nexmo.com/sms/json" -d "from=15404161937" -d "text=${CI_PROJECT_NAME} ${CI_COMMIT_SHORT_SHA} Failed!" -d "to=${to}" -d "api_key=${api_key}" -d "api_secret=${api_secret}"
when: on_failureBeachten Sie, dass es nur zwei Phasen gibt, von denen eine nur im Falle eines Fehlers stattfindet. In der build erzwingen wir einen Fehler zu Beispielzwecken. Dieser Fehler löst die notify Phase aus, in der die cURL-Anwendung heruntergeladen wird und eine HTTP-Anfrage an die Nexmo SMS API gestellt wird.
In der cURL-Anfrage werden bestimmte Variablen verwendet. Die ${CI_PROJECT_NAME} und ${CI_COMMIT_SHORT_SHA} Variablen sind von GitLab vordefiniertvordefiniert, aber die ${to}, ${api_key}, und ${api_secret} sind die Variablen, die wir mit unseren Nexmo-Informationen definiert hatten.
Wenn Sie Ihr Git-Projekt pushen, sollte es im Falle eines Fehlers eine SMS senden, die sowohl das fehlgeschlagene Projekt als auch den fehlgeschlagenen Commit enthält.
Die Nexmo SMS API ist großartig, aber was, wenn Sie andere Plattformen als nur SMS erreichen wollen? Hier kommt die Nexmo Messages API ins Spiel, die SMS-, Facebook Messenger-, Viber- und WhatsApp-Unterstützung bietet.
Die Einrichtung ist etwas aufwendiger, aber dafür erhalten Sie viel mehr Funktionen.
Um loszulegen, benötigen Sie eine Art von Backend-Service. Da Nexmo Node.js unterstützt, ist es sinnvoll, Node.js und JavaScript zu verwenden, um zu vermeiden, dass Sie Ihre eigenen HTTP-Anfragen erstellen müssen.
Erstellen Sie ein neues Projektverzeichnis, das außerhalb Ihres GitLab-Projekts gehostet werden soll. Führen Sie in diesem Verzeichnis die folgenden Schritte aus:
npm init -y
npm install nexmo@beta express --save
touch main.jsDie obigen Befehle erstellen eine neue package.json Datei, eine main.js Datei für die gesamte Anwendungslogik und installieren jede der Abhängigkeiten.
Der Sinn dieses Backends ist es, Webhooks zu steuern, die der Nexmo-Dienst verwenden wird. Wenn man mit der Nexmo Messages API arbeitet, wird ein Status Webhook und ein eingehender Webhook werden als Teil des Nachrichtenflusses benötigt.
Öffnen Sie die main.js und fügen Sie Folgendes ein:
const Express = require("express");
const Nexmo = require('nexmo');
const server = Express();
server.use(Express.json());
server.use(Express.urlencoded({ extended: false }));
const nexmo = new Nexmo({
apiKey: "NEXMO_API_KEY",
apiSecret: "NEXMO_API_SECRET",
applicationId: "NEXMO_APPLICATION_ID",
privateKey: "NEXMO_PATH_TO_PRIVATE_KEY"
});
server.post("/status", (request, response, next) => {
console.log(request.body);
response.send(request.body);
});
server.post("/inbound", (request, response, next) => {
console.log(request.body);
response.send(request.body);
});
server.listen("3000", () => {
console.log("Listening at :3000...");
});
Ignorieren Sie vorerst die Token. Wir werden uns gleich darum kümmern, wie wir sie bekommen.
Der obige Code erstellt einen einfachen Node.js-Server mit zwei API-Endpunkten, die die erforderlichen Webhooks darstellen. In unserem Szenario werden wir nur die Anfragen ausdrucken, die in die Webhooks fließen, und sie an den Anfragenden zurückschicken.
Eine Anfrage, die in den Status Webhook eingehende Anfrage könnte wie folgt aussehen:
{
message_uuid: 'UUID_STRING',
to: { number: 'RECIPIENT_PHONE_NUMBER', type: 'sms' },
from: { number: 'SENDER_PHONE_NUMBER', type: 'sms' },
timestamp: '2019-09-09T23:18:25.308Z',
usage: { price: '0.0062', currency: 'EUR' },
status: 'delivered'
}Da wir keine Nachrichten von Nutzern erhalten, wird die eingehende Webhook für uns nicht sehr relevant, auch wenn er erforderlich ist.
Kommen wir also zurück zu den Token-Informationen:
const nexmo = new Nexmo({
apiKey: "NEXMO_API_KEY",
apiSecret: "NEXMO_API_SECRET",
applicationId: "NEXMO_APPLICATION_ID",
privateKey: "NEXMO_PATH_TO_PRIVATE_KEY"
});Ab jetzt sollten Sie bereits über die apiKey und apiSecret Werte aus dem vorherigen Beispiel, in dem die SMS API direkt mit cURL im Falle einer fehlgeschlagenen Bereitstellung verwendet wurde. Was wir nicht haben, sind die applicationId und die privateKey was eigentlich eine Datei ist.
Klicken Sie im Nexmo Dashboard auf Nachrichten und Versand und fahren Sie mit der Erstellung einer neuen Anwendung fort.
Create messages application
Geben Sie der Anwendung einen Namen und geben Sie die URL zu jedem der Webhooks an, die Sie gerade erstellt haben. Wenn Sie noch lokal testen, sollten Sie ngrok verwenden, um sich in localhost zu tunneln, so dass Sie weiter testen können, ohne Ihre Anwendung zu implementieren. Erzeugen Sie ein neues privates und öffentliches Schlüsselpaar und verschieben Sie den heruntergeladenen privaten Schlüssel in Ihr Node.js-Projektverzeichnis.
Wenn Sie die von Ihnen erstellten Applications im Nexmo Dashboard anzeigen, sollten Sie Zugriff auf die Application ID der soeben erstellten Applikation haben. Geben Sie sowohl die Application id als auch den Pfad zum privaten Schlüssel in der nexmo Variable, die in unserem Node.js-Projekt existiert.
Theoretisch haben Sie, solange Sie die Webhook-Anwendung bedienen, zwei Möglichkeiten, Nachrichten von GitLab aus zu versenden:
Sie können einen weiteren Endpunkt erstellen, der das JavaScript SDK zum Senden verwendet.
Sie können cURL verwenden, aber auch ein JWT erzeugen.
Die einfachere der beiden Optionen besteht darin, der Webhook-Anwendung einfach einen weiteren Endpunkt hinzuzufügen, den GitLab im Falle eines Fehlers ausführen kann, da das JavaScript-SDK die JWT-Generierung automatisch übernimmt.
Fügen Sie innerhalb des Node.js-Projekts Folgendes ein:
server.post("/notify", (request, response, next) => {
nexmo.channel.send(
{ type: "sms", number: request.body.recipient },
{ type: "sms", number: request.body.sender },
{
content: {
type: "text",
text: request.body.message
}
},
(error, data) => {
if(error) {
return response.status(500).send(error);
}
response.send(data);
},
{ useBasicAuth: true },
);
});
Im obigen Szenario werden die Empfänger- und Absenderinformationen sowie die Nachrichteninformationen mit der Anfrage gesendet. Dann sendet die Anwendung die Nachricht und die Webhooks werden dabei verwendet.
Wenn wir unsere GitLab CI-Konfiguration aktualisieren würden, könnte sie wie folgt aussehen:
image: "alpine:latest"
stages:
- build
- notify
build:
stage: build
script:
- exit 1
notify:
stage: notify
script:
- apk add curl
- curl -X "POST" "http://HOST/notify" -H 'content-type: application/json' -d '{ "sender": "15404161937", "recipient": "${to}", "message": "${CI_PROJECT_NAME} ${CI_COMMIT_SHORT_SHA} Failed!" }'
when: on_failureIn der obigen Konfiguration wird die Node.js-Anwendung verwendet, und es wird eine JSON-Nutzlast gesendet. Die Informationen in der Nutzlast sind die Daten, die zuvor als Pipeline-Variablen für das GitLab-Projekt hinzugefügt wurden.
Denken Sie daran, dass Sie mit der Messages API über SMS hinausgehende Messaging-Techniken verwenden können, auch wenn SMS die Grundlage dieses Beispiels war.
Sie haben gerade gesehen, wie Sie mit Nexmo und GitLab SMS-Benachrichtigungen in Ihre kontinuierliche Integrations- und Bereitstellungspipeline einbinden können. Wir haben in diesem Tutorial zwar kein besonders aufwändiges Projekt erstellt, aber die verwendeten Concepts lassen sich leicht auf ein komplexeres Projekt übertragen. Der Punkt hier ist, dass Sie Ihre Nexmo-Informationen nehmen, Umgebungsvariablen für Ihre Pipeline erstellen und eine Fehlerphase einrichten können, um Ihr Team per SMS zu benachrichtigen.