Wir erstellen einen Deployment-Plan in GKE ohne Plugins, SMS und Registrierung. Ein kurzer Blick unter Jenkins' Jackett.

Alles begann damit, dass der Teamleiter eines unserer Entwicklerteams mich bat, ihre neue Anwendung, die am Vortag containerisiert wurde, zur Testzwecken nach außen zu stellen. Ich habe das gemacht. Etwa 20 Minuten später kam die Bitte, die Anwendung zu aktualisieren, weil sie eine sehr wichtige Funktion hinzugefügt hatten. Ich habe aktualisiert. Nach ein paar Stunden … na ja, Sie ahnen, was als Nächstes geschah …

Ich muss gestehen, ich bin ziemlich faul (habe ich das nicht schon einmal erwähnt? nicht?), und, angesichts der Tatsache, dass die Teamleiter Zugang zu Jenkins haben, wo unser gesamtes CI/CD läuft, dachte ich: lass ihn selbst deployen, so viel er will! Ich erinnerte mich an den Witz: gib einem Menschen einen Fisch, und er wird einen Tag lang satt sein; nenne den Menschen Satt, und er wird sein ganzes Leben lang satt sein. Und ich ging los, um einen Job zu erstellen, der in der Lage ist, einen Container mit der Anwendung jeder erfolgreich gebauten Version in Kubernetes zu deployen und ihm beliebige Werte zu übergeben ENV (mein Opa, ein Philologe und ehemaliger Englischdozent, würde jetzt sicherlich mit dem Finger an die Schläfe tippen und mir sehr ausdrucksvoll zuschauen, während er diesen Satz liest).

Also, in diesem Artikel werde ich erzählen, wie ich gelernt habe:

1. Dynamisch Aufgaben in Jenkins aus der Aufgabe selbst oder aus anderen Aufgaben zu aktualisieren;
2. Sich mit der Cloud-Konsole (Cloud Shell) von einem Knoten mit installiertem Jenkins-Agent zu verbinden;
3. Eine Arbeitslast (Workload) in Google Kubernetes Engine zu deployen.

In der Tat, ich übertreibe ein wenig. Es wird vorausgesetzt, dass zumindest ein Teil der Infrastruktur in der Google-Cloud ist, und deshalb sind Sie ein Benutzer, und natürlich haben Sie ein GCP-Konto. Aber darum geht es in diesem Artikel nicht.

Dies ist mein weiteres Merkblatt. Solche Artikel schreibe ich nur aus einem Grund: vor mir stand eine Aufgabe, ich wusste von Anfang an nicht, wie ich sie lösen sollte, die Lösung ließ sich nicht in fertiger Form googeln, also habe ich sie in Teilen gegoogelt und schließlich die Aufgabe gelöst. Und damit ich in Zukunft, wenn ich vergesse, wie ich das gemacht habe, nicht alles wieder in Teilen googeln und zusammenstellen muss, schreibe ich mir solche Merkblätter.

Haftungsausschluss: 1. Der Artikel wurde "für mich selbst" geschrieben, und beansprucht nicht die Rolle von best practice. Ich würde mich freuen, Kommentare mit Vorschlägen wie "es wäre besser, es so zu machen" zu lesen.
2. Wenn man den praktischen Teil des Artikels als Salze betrachtet, dann ist dieser, wie all meine vorherigen Artikel, eine schwach salzige Lösung.

Dynamische Aktualisierung von Job-Einstellungen in Jenkins

Ich antizipiere Ihre Frage: was hat überhaupt die dynamische Aktualisierung eines Jobs damit zu tun? Ich habe den Wert des String-Parameters manuell eingegeben und losgelegt!

Ich antworte: Ich bin wirklich faul und mag es nicht, wenn sich Leute beschweren: Misha, das Deployment schlägt fehl, alles ist verloren! Man fängt an zu schauen, und da ist ein Tippfehler im Wert eines Parameters, der für den Job verwendet wird. Deshalb ziehe ich es vor, alles so fehlerfrei wie möglich zu machen. Wenn es eine Möglichkeit gibt, den Benutzer daran zu hindern, Daten direkt einzugeben und stattdessen eine Liste von Werten zur Auswahl anzubieten, then organisiere ich die Auswahl.

Der Plan ist folgender: Wir erstellen einen Job in Jenkins, bei dem vor dem Start eine Version aus einer Liste ausgewählt werden kann, sowie die Werte für die Parameter, die übergeben werden, zu definieren ENV, dann wird das Container-Image gebaut und in das Container Registry gepusht. Von dort wird das Container-Image im Kubernetes als Arbeitlast mit den im Job festgelegten Parametern gestartet.

Wir werden den Prozess der Erstellung und Konfiguration eines Jobs in Jenkins nicht betrachten, das wäre Off-Topic. Wir setzen voraus, dass der Job bereit ist. Für die Implementierung einer aktualisierbaren Versionsliste benötigen wir zwei Dinge: eine bereits vorhandene Ausgangsliste mit im Voraus gültigen Versionsnummern und eine Variable des Typs Wahlparameter im Job. In unserem Beispiel nennen wir die Variable BUILD_VERSION, darauf werden wir nicht näher eingehen. Aber bei der Ausgangsliste lassen Sie uns näher hinschauen.

Es gibt nicht so viele Optionen. Mir fallen spontan zwei ein:

• Die Remote Access API zu verwenden, die Jenkins seinen Benutzern anbietet;
• Den Inhalt eines entfernten Verzeichnisses des Repositories anzufordern (in unserem Fall ist das JFrog Artifactory, was nicht entscheidend ist).

Jenkins Remote Access API

Wie es sich gehört, bevorzuge ich es, umfangreiche Erklärungen zu vermeiden.
Ich erlaube mir nur, eine freiere Übersetzung eines Teils des ersten Absatzes der ersten Seite der API-Dokumentation anzubieten::

Jenkins bietet eine API für einen entfernten, maschinenverständlichen Zugang zu seiner Funktionalität. Der entfernte Zugang wird in einem REST-ähnlichen Stil angeboten. Das bedeutet, dass es keinen einheitlichen Einstiegspunkt für alle Funktionen gibt, sondern stattdessen eine URL der Form ".../api/", wobei "…" das Objekt bezeichnet, auf das die API-Funktionen angewendet werden.

Mit anderen Worten, wenn der Deployment-Job, über den wir gerade sprechen, unter der Adresse verfügbar ist http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, die API-Schnittstellen für diese Aufgabe sind unter folgender Adresse verfügbar http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

Als Nächstes haben wir die Wahl, in welchem Format wir die Ausgabe erhalten möchten. Lassen Sie uns auf XML achten, da das API nur in diesem Fall eine Filterung ermöglicht.

Lassen Sie uns einfach versuchen, eine Liste aller Ausführungen der Aufgabe zu erhalten. Uns interessiert nur der Name des Builds (displayName) und dessen Ergebnis (result):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

Hat es geklappt?

Jetzt filtern wir nur die Ausführungen heraus, die schließlich mit dem Ergebnis SUCCESSabschließen. Wir verwenden das Argument &exclude und übergeben ihm den Pfad zu dem Wert, der ungleich SUCCESSist. Ja, ja. Doppelte Negation ist eine Bestätigung. Wir schließen alles aus, was uns nicht interessiert:

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

Screenshot der erfolgreichen

Und nur zur Sicherheit stellen wir sicher, dass uns der Filter nicht getäuscht hat (Filter lügen ja nie!) und geben die Liste der "nicht-erfolgreichen" aus:

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

Screenshot der nicht-erfolgreichen

Liste der Versionen aus dem Ordner auf dem Remote-Server

Es gibt auch eine zweite Möglichkeit, die Liste der Versionen zu erhalten. Diese gefällt mir sogar besser als der Zugriff auf das Jenkins-API. Denn wenn die Anwendung erfolgreich gebaut wurde, bedeutet das, dass sie verpackt und in das entsprechende Verzeichnis im Repository gelegt wurde. Also, das Repository ist standardmäßig ein Speicherort für die Arbeitsversionen der Anwendungen. Lassen Sie uns einfach nachfragen, welche Versionen gelagert sind. Wir werden den Remote-Ordner curl'en, grep'en und awk'en. Wenn jemand an einem One-Liner interessiert ist, der ist im Spoiler.

Einzeiler-Befehl
Beachten Sie zwei Dinge: Ich übergebe im Header die Anmeldeinformationen für die Verbindung und ich benötige nicht alle Versionen aus dem Ordner, sondern filtere nur die, die innerhalb des letzten Monats erstellt wurden. Passen Sie den Befehl gemäß Ihrer Realität und Ihren Anforderungen an:

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+')

Job-Konfiguration und Konfigurationsdatei des Jobs in Jenkins

Wir haben uns mit der Quelle der Versionsliste befasst. Lassen Sie uns jetzt die erhaltene Liste in die Aufgabe einfügen. Für mich war die naheliegende Lösung, einen Schritt in der Build-Aufgabe hinzuzufügen. Ein Schritt, der im Falle eines Erfolgs ausgeführt wird.

Öffnen Sie die Einstellungen der Build-Aufgabe und scrollen Sie nach unten. Klicken Sie auf die Schaltflächen: Add build step -> Conditional step (single). In den Einstellungen des Schrittes wählen wir die Bedingung aus Aktueller Build-Status, setzen den Wert SUCCESS, die auszuführende Aktion im Erfolgsfall Führen Sie den Shell-Befehl aus.

Und jetzt kommt das Interessanteste. Die Jenkins-Job-Konfigurationen werden in Dateien gespeichert. Im XML-Format. Unter dem Pfad http://pfad-zum-job/config.xml Dementsprechend kann die Konfigurationsdatei heruntergeladen, nach Bedarf bearbeitet und wieder an ihren Ursprungsort zurückgelegt werden.

Denken Sie daran, dass wir oben vereinbart haben, dass wir für die Liste der Versionen einen Parameter erstellen. BUILD_VERSION?

Lassen Sie uns die Konfigurationsdatei herunterladen und einen Blick hineinwerfen. Nur um sicherzustellen, dass der Parameter vorhanden ist und tatsächlich die richtige Form hat.

Screenshot unter dem Spoiler.

Ihr angegebener Ausschnitt der config.xml sollte genauso aussehen. Mit der Ausnahme, dass der Inhalt des Elements choices bisher fehlt.

Sind Sie sich sicher? Gut, dann schreiben wir das Skript, das im Falle eines erfolgreichen Builds ausgeführt wird.
Das Skript wird die Liste der Versionen abrufen, die Konfigurationsdatei herunterladen, die Liste der Versionen an der gewünschten Stelle in die Datei schreiben und sie dann wieder zurücklegen. Ja. Alles korrekt. Die Liste der Versionen in die XML-Datei an die Stelle schreiben, an der bereits eine Liste der Versionen vorhanden ist (wird in Zukunft nach dem ersten Start des Skripts sein). Ich weiß, in der Welt leben noch leidenschaftliche Liebhaber von regulären Ausdrücken. Ich zähle mich nicht dazu. Bitte installieren Sie xmlstarlet auf dem Computer, auf dem die Konfiguration bearbeitet wird. Ich denke, das ist nicht so ein großer Preis, um das Bearbeiten von XML mit sed zu vermeiden.

Unter dem Spoiler finden Sie den Code, der die oben beschriebene Reihenfolge vollständig umsetzt.

Wir schreiben die Liste der Versionen aus dem Ordner auf dem Remote-Server in die Konfiguration.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Wenn Ihnen die Version, die die Versionen aus Jenkins abruft, besser gefallen hat und Sie ebenso faul sind wie ich, finden Sie unter dem Spoiler dasselbe Code-Snippet, jedoch die Liste aus Jenkins:

Wir schreiben die Liste der Versionen aus Jenkins in die Konfiguration.
Beachten Sie, dass der Name meines Builds aus einer fortlaufenden Nummer und der Versionsnummer, die durch einen Doppelpunkt getrennt sind, besteht. Dementsprechend schneidet awk den unerwünschten Teil ab. Passen Sie diese Zeile nach Ihren Bedürfnissen an.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Wenn Sie den Code getestet haben, der auf den obigen Beispielen basiert, sollte im Deployment-Job bereits eine Dropdown-Liste mit den Versionen erscheinen. So ähnlich wie im Screenshot unter dem Spoiler.

Korrekt ausgefüllte Liste der Versionen.

Wenn alles funktioniert hat, kopieren Sie das Skript in Führen Sie den Shell-Befehl aus und speichern Sie die Änderungen.

Verbindung zur Cloud Shell

Unsere Sammler befinden sich in Containern. Als Mittel zur Bereitstellung von Anwendungen und Konfigurationsmanager verwenden wir Ansible. Wenn es also um den Bau von Containern geht, fallen mir drei Optionen ein: Docker in Docker installieren, Docker auf einer Maschine mit Ansible installieren oder Container in der Cloud-Konsole bauen. Über die Plugins für Jenkins haben wir in diesem Beitrag beschlossen, still zu sein. Erinnern Sie sich?

Ich habe beschlossen: Nun, da Container "out of the box" in der Cloud-Konsole gebaut werden können, warum sich die Mühe machen? Halten wir es einfach, richtig? Ich möchte Jenkins-Container in der Cloud-Konsole bauen und sie dann von dort in Kubernetes schießen. Zumal die Kanäle innerhalb der Google-Infrastruktur sehr leistungsfähig sind, was sich positiv auf die Bereitstellungsgeschwindigkeit auswirken wird.

Für den Zugriff auf die Cloud-Konsole sind zwei Dinge erforderlich: gcloud und Zugriffsrechte auf Google Cloud API für die VM-Instanz, von der aus diese Verbindung hergestellt wird.

Für diejenigen, die sich überhaupt nicht aus der Google-Cloud verbinden möchten:
Google erlaubt die Deaktivierung der interaktiven Authentifizierung in seinen Diensten. Dadurch kann man sich von der Kaffeemaschine aus verbinden, falls sie mit *nix-Systemen läuft und selbst eine Konsole hat.

Wenn Bedarf besteht, dieses Thema detaillierter in diesem Beitrag zu behandeln, schreiben Sie in die Kommentare. Wenn genügend Stimmen zusammenkommen, schreibe ich ein Update zu diesem Thema.

Der einfachste Weg, Berechtigungen zu erteilen, ist über die Web-Oberfläche.

1. Halten Sie die VM-Instanz an, von der aus in Zukunft die Verbindung zur Cloud-Konsole hergestellt wird.
2. Öffnen Sie die Instanzdetails und klicken Sie auf Ändern.
3. Wählen Sie ganz unten auf der Seite den Geltungsbereich des Zugriffs der Instanz. Vollzugriff auf alle Cloud-APIs.

   Screenshot
   

4. Speichern Sie die Änderungen und starten Sie die Instanz neu.

Nach dem Starten der VM verbinden Sie sich über SSH mit ihr und stellen Sie sicher, dass die Verbindung ohne Fehler erfolgt. Verwenden Sie den Befehl:

gcloud alpha cloud-shell ssh

Eine erfolgreiche Verbindung sieht etwa so aus.

Bereitstellung in GKE

Da wir bestrebt sind, vollständig auf IaC (Infrastructure as Code) umzusteigen, werden unsere Dockerfiles im Git gespeichert. Das ist die eine Seite. Die Bereitstellung in Kubernetes wird durch eine YAML-Datei beschrieben, die nur für diese Aufgabe verwendet wird, die selbst auch als Code betrachtet werden kann. Das ist die andere Seite. Im Allgemeinen beabsichtige ich Folgendes:

1. Wir nehmen die Werte der Variablen. BUILD_VERSION und optional die Variablenwerte, die übergeben werden sollen durch ENV.
2. Wir laden das Dockerfile aus Git herunter.
3. Wir generieren die YAML für das Deployment.
4. Wir laden beide Dateien per SCP in die Cloud-Konsole hoch.
5. Dort bauen wir den Container und pushen ihn in das Container-Registry.
6. Wir wenden die Deployment-Datei an, um die Last in Kubernetes zu deployen.

Lass uns konkreter werden. Angenommen, wir müssen Werte für zwei Parameter übergeben: ENVsprechen, nehmen wir an, dass wir zwei Parameterwerte übergeben müssen: PARAM1 und PARAM2. Wir fügen ihre Definition für das Deployment hinzu, Typ — String Parameter.

Screenshot

Die YAML werden wir einfach durch Umleitung generieren echo in eine Datei. Es wird natürlich vorausgesetzt, dass in deinem Dockerfile enthalten ist PARAM1 und PARAM2das Name der Last der Name der Last wirdawesomeapp , und der gebaute Container mit der angegebenen Version liegt in über den Pfad verbunden ist. Container registrygcr.io/awesomeapp/awesomeapp-

Listing der Befehle

Wir bereinigen das Home-Verzeichnis in der Cloud-Konsole von der alten Docker-Datei:

Wir legen das frisch heruntergeladene Dockerfile in das Home-Verzeichnis der Cloud-Konsole mit SCP ab:

Wir bauen, taggen und pushen den Container in das Container-Registry:

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"