_Der Autor hat das Programm Tech Education Fund ausgewählt, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten. _
Einführung
Ein automatisierter Bereitstellungsprozess ist eine Voraussetzung für eine skalierbare und ausfallsichere Anwendung, und GitOps oder Git-based DevOps hat sich schnell entwickelt Eine beliebte Methode zum Organisieren von CI / CD mit einem Git-Repository als "einzige Quelle der Wahrheit". Tools wie CircleCI werden in Ihr GitHub-Repository integriert und ermöglichen es Ihnen, Ihren Code bei jedem Zugriff automatisch zu testen und bereitzustellen Wenn Sie eine Änderung an Ihrem Repository vornehmen. Wenn diese Art von CI / CD mit der Flexibilität der Kubernetes-Infrastruktur kombiniert wird, können Sie eine Anwendung erstellen, die sich bei sich ändernden Anforderungen problemlos skalieren lässt.
In diesem Artikel verwenden Sie CircleCI, um eine Beispielanwendung in einem DigitalOcean Kubernetes (DOKS) -Cluster bereitzustellen. Nachdem Sie dieses Tutorial gelesen haben, können Sie dieselben Techniken anwenden, um andere CI / CD-Tools bereitzustellen, die als Docker-Images erstellt werden können.
Voraussetzungen
Um diesem Tutorial folgen zu können, benötigen Sie:
-
Ein DigitalOcean account, das Sie unter Sign up einrichten können für ein DigitalOcean-Konto.
-
Docker auf Ihrer Workstation installiert und Kenntnisse zum Erstellen, Entfernen und Ausführen von Docker-Images. Sie können Docker unter Ubuntu 18.04 installieren, indem Sie dem Tutorial unter How To Install and folgen Verwenden Sie Docker unter Ubuntu 18.04.
-
Kenntnisse über die Funktionsweise von Kubernetes und das Erstellen von Bereitstellungen und Diensten. Es wird dringend empfohlen, den Artikel Introduction to Kubernetes zu lesen.
-
Das Befehlszeilenprogramm https://kubernetes.io/docs/tasks/tools/install-kubectl/ [
+ kubectl +], das auf dem Computer installiert ist, von dem aus Sie Ihren Cluster steuern. -
Ein Konto unter Docker Hub zum Speichern Ihres Beispielanwendungsimages.
-
Ein GitHub Konto und Kenntnisse der Git-Grundlagen. Sie können der Tutorial-Reihe Introduction to Git: Installation, Usage and Branches und https: // folgen. www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github[Wie erstelle ich eine Pull-Anfrage auf GitHub?
Für dieses Tutorial verwenden Sie Kubernetes Version + 1.13.5 + und + kubectl + Version + 1.10.7 +.
Schritt 1 - Erstellen Sie Ihren DigitalOcean Kubernetes Cluster
In diesem ersten Schritt erstellen Sie den DigitalOcean Kubernetes (DOKS) -Cluster, aus dem Sie Ihre Beispielanwendung bereitstellen. Die von Ihrem lokalen Computer ausgeführten "+ kubectl +" - Befehle ändern oder rufen Informationen direkt vom Kubernetes-Cluster ab.
Rufen Sie in Ihrem DigitalOcean-Konto die Seite Kubernetes auf.
Klicken Sie auf * Einen Kubernetes-Cluster erstellen * oder klicken Sie auf die grüne Schaltfläche * Erstellen * oben rechts auf der Seite und wählen Sie * Cluster * aus dem Dropdown-Menü aus.
image: https://assets.digitalocean.com/articles/cart_64920/Create_DOKS.gif [Erstellen eines Kubernetes-Clusters auf DigitalOcean]
Auf der nächsten Seite legen Sie die Details Ihres Clusters fest. Ein * Wählen Sie eine Kubernetes-Version * Wählen Sie die Version * 1.13.5-do.0 *. Wenn dieser nicht verfügbar ist, wählen Sie einen höheren.
Wählen Sie für * Wählen Sie eine Datencenter-Region * die Region aus, die Ihnen am nächsten liegt. In diesem Tutorial wird * San Francisco - 2 * verwendet.
Sie haben dann die Möglichkeit, Ihre * Knotenpools * zu erstellen. Unter Kubernetes ist ein Knoten eine Worker-Maschine, die die zum Ausführen von Pods erforderlichen Dienste enthält. Bei DigitalOcean ist jeder Knoten ein Droplet. Ihr Knotenpool besteht aus einem einzelnen * Standardknoten *. Wählen Sie die Konfiguration * 2GB / 1vCPU * und ändern Sie die Anzahl der Knoten in * 1 Knoten *.
Sie können zusätzliche Tags hinzufügen, wenn Sie möchten. Dies kann hilfreich sein, wenn Sie die DigitalOcean-API verwenden oder nur Ihre Knotenpools besser organisieren möchten.
Wenn Sie * Wählen Sie einen Namen * für dieses Tutorial, verwenden Sie + kubernetes-deployment-tutorial. Dies erleichtert das Durchlesen der nächsten Abschnitte. Klicken Sie abschließend auf die grüne Schaltfläche * Create Cluster * (Cluster erstellen), um Ihren Cluster zu erstellen.
Nach der Clustererstellung befindet sich auf der Benutzeroberfläche eine Schaltfläche zum Herunterladen einer Konfigurationsdatei mit dem Namen * Download Config File *. Dies ist die Datei, mit der Sie die "+ kubectl " - Befehle authentifizieren, die Sie für Ihren Cluster ausführen werden. Laden Sie es auf Ihre ` kubectl +` Maschine herunter.
Die Standardmethode für die Verwendung dieser Datei besteht darin, bei allen Befehlen, die Sie mit "+ kubectl " ausführen, immer das Flag " - kubeconfig " und den Pfad dazu zu übergeben. Wenn Sie beispielsweise die Konfigurationsdatei auf " Desktop " heruntergeladen haben, würden Sie den Befehl " kubectl get pods +" wie folgt ausführen:
kubectl --kubeconfig ~/Desktop/kubernetes-deployment-tutorial-kubeconfig.yaml get podsDies würde die folgende Ausgabe ergeben:
OutputNo resources found.Dies bedeutet, dass Sie auf Ihren Cluster zugegriffen haben. Die Meldung "+ Keine Ressourcen gefunden. +" Ist korrekt, da sich keine Pods in Ihrem Cluster befinden.
Wenn Sie keine anderen Kubernetes-Cluster verwalten, können Sie die Datei "kubeconfig" in einen Ordner in Ihrem Ausgangsverzeichnis mit dem Namen "+ .kube +" kopieren. Erstellen Sie dieses Verzeichnis, falls es nicht existiert:
mkdir -p ~/.kubeKopieren Sie dann die Konfigurationsdatei in das neu erstellte Verzeichnis "+ .kube " und benennen Sie es in " config +" um:
cp ~/.kube/configDie Konfigurationsdatei sollte nun den Pfad "+ ~ / .kube / config " haben. Dies ist die Datei, die " kubectl " standardmäßig liest, wenn ein Befehl ausgeführt wird. Es ist also nicht mehr erforderlich, " - kubeconfig +" zu übergeben. Führen Sie Folgendes aus:
kubectl get podsSie erhalten folgende Ausgabe:
OutputNo resources found.Greifen Sie jetzt mit den folgenden Schritten auf den Cluster zu:
kubectl get nodesSie erhalten die Liste der Knoten in Ihrem Cluster. Die Ausgabe wird ungefähr so aussehen:
OutputNAME STATUS ROLES AGE VERSION
kubernetes-deployment-tutorial-1-7pto Ready <none> 1h v1.13.5In diesem Lernprogramm verwenden Sie den Namensraum "+ default " für alle " kubectl " -Befehle und Manifestdateien, die die Arbeitslast und die Betriebsparameter der Arbeit in Kubernetes definieren. _Namespaces_ sind wie virtuelle Cluster in Ihrem einzelnen physischen Cluster. Sie können in einen beliebigen anderen Namespace wechseln. Vergewissern Sie sich nur, dass Sie es immer mit dem ` - Namespace ` Flag an ` kubectl +` übergeben und / oder im Metadatenfeld des Kubernetes-Manifests angeben. Sie sind eine großartige Möglichkeit, die Bereitstellungen Ihres Teams und ihrer Betriebsumgebungen zu organisieren. Weitere Informationen hierzu finden Sie unter official Kubernetes overview on Namespaces.
Wenn Sie diesen Schritt abgeschlossen haben, können Sie jetzt "+ kubectl +" für Ihren Cluster ausführen. Im nächsten Schritt erstellen Sie das lokale Git-Repository, mit dem Sie Ihre Beispielanwendung speichern möchten.
Schritt 2 - Das lokale Git-Repository erstellen
Sie strukturieren jetzt Ihre Beispielbereitstellung in einem lokalen Git-Repository. Sie werden auch einige Kubernetes-Manifeste erstellen, die global für alle Bereitstellungen sind, die Sie auf Ihrem Cluster ausführen werden.
Erstellen Sie zunächst lokal ein neues Git-Repository, das Sie später an GitHub senden. Erstellen Sie einen leeren Ordner mit dem Namen "+ do-sample-app" in Ihrem Ausgangsverzeichnis und "+ cd" darin:
mkdir ~/do-sample-app
cd ~/do-sample-appErstellen Sie nun mit dem folgenden Befehl ein neues Git-Repository in diesem Ordner:
git init .Erstellen Sie in diesem Repository einen leeren Ordner mit dem Namen "+ kube +":
mkdir ~/do-sample-app/kube/Dies ist der Ort, an dem Sie die Kubernetes-Ressourcenmanifeste speichern, die sich auf die Beispielanwendung beziehen, die Sie in Ihrem Cluster bereitstellen.
Erstellen Sie nun einen weiteren Ordner mit dem Namen "+ kube-general +", diesmal jedoch außerhalb des soeben erstellten Git-Repositorys. Machen Sie es in Ihrem Home-Verzeichnis:
mkdir ~/kube-general/Dieser Ordner befindet sich außerhalb Ihres Git-Repositorys, da er zum Speichern von Manifesten verwendet wird, die nicht für eine einzelne Bereitstellung in Ihrem Cluster spezifisch sind, sondern für mehrere. Auf diese Weise können Sie diese allgemeinen Manifeste für verschiedene Bereitstellungen wiederverwenden.
Nachdem Sie Ihre Ordner erstellt und das Git-Repository Ihrer Beispielanwendung eingerichtet haben, ist es an der Zeit, die Authentifizierung und Autorisierung Ihres DOKS-Clusters zu veranlassen.
Schritt 3 - Erstellen eines Dienstkontos
Es wird im Allgemeinen nicht empfohlen, den Standardbenutzer * admin * für die Authentifizierung von anderen Services in Ihrem Kubernetes-Cluster zu verwenden. Wenn Ihre Schlüssel beim externen Anbieter kompromittiert werden, wird der gesamte Cluster kompromittiert.
Stattdessen verwenden Sie eine einzelne Service Account mit einer bestimmten Rolle, die Teil des https: / ist. /kubernetes.io/docs/reference/access-authn-authz/rbac/[RBAC Kubernetes authorisation model].
Dieses Berechtigungsmodell basiert auf Roles und Resources. Zunächst erstellen Sie ein Service-Konto, bei dem es sich im Grunde um einen Benutzer in Ihrem Cluster handelt. Anschließend erstellen Sie eine Rolle, in der Sie angeben, auf welche Ressourcen in Ihrem Cluster zugegriffen werden kann. Zuletzt erstellen Sie eine Rollenbindung, mit der die Verbindung zwischen der Rolle und dem zuvor erstellten Dienstkonto hergestellt wird und dem Dienstkonto Zugriff auf alle Ressourcen gewährt wird, auf die die Rolle Zugriff hat.
Die erste Kubernetes-Ressource, die Sie erstellen werden, ist das Dienstkonto für Ihren CI / CD-Benutzer, das in diesem Lernprogramm den Namen "+ cicd +" trägt.
Erstellen Sie die Datei "+ cicd-service-account.yml " im Ordner " ~ / kube-general +" und öffnen Sie sie mit Ihrem bevorzugten Texteditor:
nano ~/kube-general/cicd-service-account.ymlSchreiben Sie den folgenden Inhalt darauf:
~ / kube-general / cicd-service-account.yml
apiVersion: v1
kind: ServiceAccount
metadata:
name: cicd
namespace: defaultDies ist eine YAML-Datei. Alle Kubernetes-Ressourcen werden mit einem dargestellt. In diesem Fall ist diese Ressource von Kubernetes API-Version "+ v1 " (intern " kubectl " erstellt Ressourcen durch Aufrufen von Kubernetes HTTP-APIs) und ist ein " ServiceAccount +".
Das Feld "+ Metadaten " wird verwendet, um weitere Informationen zu dieser Ressource hinzuzufügen. In diesem Fall geben Sie diesem " ServiceAccount" den Namen "+ cicd " und erstellen ihn im " default +" - Namespace.
Sie können dieses Dienstkonto jetzt in Ihrem Cluster erstellen, indem Sie "+ kubectl apply +" wie folgt ausführen:
kubectl apply -f ~/kube-general/Sie erhalten eine Ausgabe ähnlich der folgenden:
Outputserviceaccount/cicd createdVersuchen Sie, sich mit Ihrem Dienstkonto bei Ihrem Cluster anzumelden, um sicherzustellen, dass Ihr Dienstkonto funktioniert. Dazu müssen Sie zuerst das entsprechende Zugriffstoken abrufen und in einer Umgebungsvariablen speichern. Jedes Dienstkonto verfügt über ein Zugriffstoken, das Kubernetes als Secret speichert.
Sie können dieses Geheimnis mit dem folgenden Befehl abrufen:
TOKEN=$(kubectl get secret $(kubectl get secret | grep cicd-token | awk '{print $1}') -o jsonpath='{.data.token}' | base64 --decode)Einige Erklärungen zur Funktionsweise dieses Befehls:
$(kubectl get secret | grep cicd-token | awk '{print $1}')Dies wird verwendet, um den Namen des Geheimnisses abzurufen, das mit unserem "+ cicd " - Dienstkonto zusammenhängt. ` kubectl get secret ` gibt die Liste der Geheimnisse im Standard-Namespace zurück. Dann suchen Sie mit ` grep ` nach den Zeilen, die sich auf Ihr ` cicd ` Service-Konto beziehen. Dann geben Sie den Namen zurück, da dies das erste in der einzelnen Zeile ist, die vom ` grep +` zurückgegeben wird.
kubectl get secret -o jsonpath='{.data.token}' | base64 --decodeDadurch wird nur das Geheimnis für Ihr Dienstkontotoken abgerufen. Sie greifen dann mit + jsonpath + auf das Token-Feld zu und übergeben das Ergebnis an + base64 --decode +. Dies ist erforderlich, da das Token als Base64-Zeichenfolge gespeichert wird. Das Token selbst ist ein JSON Web Token.
Sie können nun versuchen, Ihre Pods mit dem Dienstkonto "+ cicd " abzurufen. Führen Sie den folgenden Befehl aus und ersetzen Sie "+" durch die Server-URL, die nach "+ server" angegeben ist: + "in" + ~ kube / config + ". Dieser Befehl gibt einen bestimmten Fehler aus, den Sie später in diesem Lernprogramm kennenlernen werden:
kubectl --insecure-skip-tls-verify --kubeconfig="/dev/null" --server= --token=$TOKEN get pods+ - insecure-skip-tls-verify + überspringt den Schritt des Überprüfens des Zertifikats des Servers, da Sie nur testen und dies nicht überprüfen müssen. + - kubeconfig =" / dev / null "+ soll sicherstellen, dass + kubectl + Ihre Konfigurationsdatei und Anmeldeinformationen nicht liest, sondern stattdessen das bereitgestellte Token verwendet.
Die Ausgabe sollte ungefähr so aussehen:
OutputError from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:cicd" cannot list resource "pods" in API group "" in the namespace "default"Dies ist ein Fehler, aber es zeigt uns, dass das Token funktioniert hat. Der Fehler, den Sie erhalten haben, besteht darin, dass Ihr Dienstkonto nicht über die erforderliche Berechtigung zum Auflisten der Ressource "+ Geheimnisse +" verfügt, Sie jedoch auf den Server selbst zugreifen konnten. Wenn Ihr Token nicht funktioniert hätte, wäre der Fehler der folgende gewesen:
Outputerror: You must be logged in to the server (Unauthorized)Nachdem die Authentifizierung erfolgreich war, besteht der nächste Schritt darin, den Autorisierungsfehler für das Dienstkonto zu beheben. Dazu erstellen Sie eine Rolle mit den erforderlichen Berechtigungen und binden sie an Ihr Dienstkonto.
Schritt 4 - Erstellen der Rolle und der Rollenbindung
Kubernetes hat zwei Möglichkeiten, Rollen zu definieren: Verwenden einer "+ Role " - oder einer " ClusterRole +" -Ressource. Der Unterschied zwischen ersteren und letzteren besteht darin, dass der erste für einen einzelnen Namespace gilt, während der andere für den gesamten Cluster gilt.
Da Sie in diesem Lernprogramm einen einzelnen Namespace verwenden, verwenden Sie ein "+ Role +".
Erstellen Sie die Datei "+ ~ / kube-general / cicd-role.yml +" und öffnen Sie sie mit Ihrem bevorzugten Texteditor:
nano ~/kube-general/cicd-role.ymlDie Grundidee ist, Zugriff zu gewähren, um alles zu tun, was mit den meisten Kubernetes-Ressourcen im Namensraum "+ default " zusammenhängt. Ihre ` Rolle +` würde so aussehen:
~ / kube-general / cicd-role.yml
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cicd
namespace: default
rules:
- apiGroups: ["", "apps", "batch", "extensions"]
resources: ["deployments", "services", "replicasets", "pods", "jobs", "cronjobs"]
verbs: ["*"]Diese YAML hat einige Ähnlichkeiten mit der zuvor erstellten, aber hier sagen Sie, dass diese Ressource eine "+ Rolle " ist und von der Kubernetes-API " rbac.authorization.k8s.io / v1 " stammt. Sie benennen Ihre Rolle " cicd " und erstellen sie in demselben Namespace, in dem Sie auch Ihr " ServiceAccount " erstellt haben, das " Standardkonto +".
Dann haben Sie das Feld "+ rules +", eine Liste der Ressourcen, auf die diese Rolle Zugriff hat. In Kubernetes werden Ressourcen basierend auf der API-Gruppe definiert, zu der sie gehören, der Art der Ressource selbst und den Aktionen, die Sie dann ausführen können. Dies wird durch ein Verb dargestellt. Diese Verben ähneln den HTTP-Verben.
In unserem Fall sagen Sie, dass Ihre "+ Rolle " auf den folgenden Ressourcen alles " * " ausführen darf: " Bereitstellungen", "+ Dienste", "+ Replikatsätze", "+ Pods ", " + jobs + `und` + cronjobs + `. Dies gilt auch für Ressourcen, die zu den folgenden API-Gruppen gehören: "" "" (leere Zeichenfolge), " apps ", " batch " und " extensions ". Die leere Zeichenfolge steht für die Root-API-Gruppe. Wenn Sie beim Erstellen einer Ressource " apiVersion: v1 +" verwenden, bedeutet dies, dass diese Ressource Teil dieser API-Gruppe ist.
Ein "+ Rolle " allein macht nichts; Sie müssen auch eine https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding [` RoleBinding `] erstellen, die eine ` Role ` an etwas bindet In diesem Fall ein " ServiceAccount +".
Erstellen Sie die Datei "+ ~ / kube-general / cicd-role-binding.yml +" und öffnen Sie sie:
nano ~/kube-general/cicd-role-binding.ymlFügen Sie der Datei die folgenden Zeilen hinzu:
~ / kube-general / cicd-role-binding.yml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cicd
namespace: default
subjects:
- kind: ServiceAccount
name: cicd
namespace: default
roleRef:
kind: Role
name: cicd
apiGroup: rbac.authorization.k8s.ioIhr + RoleBinding + enthält einige bestimmte Felder, die in diesem Lernprogramm noch nicht behandelt wurden. + roleRef + ist die + Rolle +, die Sie an etwas binden möchten; In diesem Fall ist es die Rolle "+ cicd ", die Sie zuvor erstellt haben. " subject " ist die Liste der Ressourcen, an die Sie Ihre Rolle binden. In diesem Fall handelt es sich um ein einzelnes " ServiceAccount " mit dem Namen " cicd +".
Mit diesen erstellten Dateien können Sie + kubectl apply + erneut verwenden. Erstellen Sie diese neuen Ressourcen in Ihrem Kubernetes-Cluster, indem Sie den folgenden Befehl ausführen:
kubectl apply -f ~/kube-general/Sie erhalten eine Ausgabe ähnlich der folgenden:
Outputrolebinding.rbac.authorization.k8s.io/cicd created
role.rbac.authorization.k8s.io/cicd created
serviceaccount/cicd createdVersuchen Sie nun den Befehl, den Sie zuvor ausgeführt haben:
kubectl --insecure-skip-tls-verify --kubeconfig="/dev/null" --server= --token=$TOKEN get podsDa Sie keine Pods haben, erhalten Sie die folgende Ausgabe:
OutputNo resources found.In diesem Schritt haben Sie dem Dienstkonto, das Sie auf CircleCI verwenden möchten, die erforderliche Berechtigung erteilt, um sinnvolle Aktionen in Ihrem Cluster auszuführen, z. B. das Auflisten, Erstellen und Aktualisieren von Ressourcen. Jetzt ist es Zeit, Ihre Beispielanwendung zu erstellen.
Schritt 5 - Erstellen Sie Ihre Beispielanwendung
Das zu erstellende Kubernetes-Deployment verwendet das Image Nginx als Basis, und Ihre Anwendung ist eine einfache statische HTML-Seite. Dies ist ein guter Anfang, da Sie testen können, ob Ihre Bereitstellung funktioniert, indem Sie ein einfaches HTML direkt von Nginx aus bereitstellen. Wie Sie später sehen werden, können Sie den gesamten Datenverkehr, der an eine lokale Adresse "+ address: port +" gelangt, an Ihre Bereitstellung auf Ihrem Cluster umleiten, um zu testen, ob diese funktioniert.
Erstellen Sie in dem Repository, das Sie zuvor eingerichtet haben, eine neue Dockerfile-Datei und öffnen Sie sie mit einem Texteditor Ihrer Wahl:
nano ~/do-sample-app/DockerfileSchreiben Sie folgendes darauf:
~ / do-sample-app / Dockerfile
FROM nginx:1.14
COPY index.html /usr/share/nginx/html/index.htmlDadurch wird Docker angewiesen, den Anwendungscontainer aus einem + nginx + - Image zu erstellen.
Jetzt erstelle eine neue + index.html Datei und öffne sie:
nano ~/do-sample-app/index.htmlSchreiben Sie den folgenden HTML-Inhalt:
~ / do-sample-app / index.html
<!DOCTYPE html>
<title>DigitalOcean</title>
<body>
Kubernetes Sample Application
</body>Dieser HTML-Code zeigt eine einfache Meldung an, die Sie darüber informiert, ob Ihre Anwendung funktioniert.
Sie können testen, ob das Image korrekt ist, indem Sie es erstellen und dann ausführen.
Erstellen Sie zunächst das Image mit dem folgenden Befehl und ersetzen Sie "++" durch Ihren eigenen Docker Hub-Benutzernamen. Sie müssen Ihren Benutzernamen hier angeben, damit er beim späteren Senden an Docker Hub funktioniert:
docker build ~/do-sample-app/ -t /do-kubernetes-sample-appFühren Sie nun das Image aus. Verwenden Sie den folgenden Befehl, mit dem Ihr Image gestartet und jeglicher lokaler Datenverkehr an Port "+ 8080 " an den Port " 80 +" im Image weitergeleitet wird, den Port Nginx standardmäßig abhört:
docker run --rm -it -p 8080:80 /do-kubernetes-sample-appDie Eingabeaufforderung hört auf, interaktiv zu sein, während der Befehl ausgeführt wird. Stattdessen werden die Nginx-Zugriffsprotokolle angezeigt. Wenn Sie + localhost: 8080 + in einem Browser öffnen, sollte eine HTML-Seite mit dem Inhalt von + ~ / do-sample-app / index.html + angezeigt werden. Falls Sie keinen Browser zur Verfügung haben, können Sie ein neues Terminalfenster öffnen und den folgenden Befehl + curl + verwenden, um den HTML-Code von der Webseite abzurufen:
curl localhost:8080Sie erhalten folgende Ausgabe:
Output<!DOCTYPE html>
<title>DigitalOcean</title>
<body>
Kubernetes Sample Application
</body>Stoppen Sie den Container ("+ CTRL " + " C +" auf dem Terminal, auf dem er ausgeführt wird) und senden Sie dieses Bild an Ihr Docker Hub-Konto. Melden Sie sich dazu zuerst bei Docker Hub an:
docker loginGeben Sie die erforderlichen Informationen zu Ihrem Docker Hub-Konto ein und drücken Sie das Image mit dem folgenden Befehl (vergessen Sie nicht, das "++" durch Ihr eigenes zu ersetzen):
docker push /do-kubernetes-sample-appSie haben Ihr Beispielanwendungs-Image jetzt auf Ihr Docker Hub-Konto übertragen. Im nächsten Schritt erstellen Sie aus diesem Image ein Deployment auf Ihrem DOKS-Cluster.
Schritt 6 - Kubernetes-Bereitstellung und -Dienst erstellen
Wenn Ihr Docker-Image erstellt wurde und funktioniert, erstellen Sie jetzt ein Manifest, das Kubernetes mitteilt, wie ein Deployment daraus in Ihrem Cluster erstellt werden kann.
Erstellen Sie die YAML-Bereitstellungsdatei "+ ~ / do-sample-app / kube / do-sample-deployment.yml +" und öffnen Sie sie mit Ihrem Texteditor:
nano ~/do-sample-app/kube/do-sample-deployment.ymlSchreiben Sie den folgenden Inhalt in die Datei und achten Sie darauf, "++" durch Ihren Docker Hub-Benutzernamen zu ersetzen:
~ / do-sample-app / kube / do-sample-deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: do-kubernetes-sample-app
namespace: default
labels:
app: do-kubernetes-sample-app
spec:
replicas: 1
selector:
matchLabels:
app: do-kubernetes-sample-app
template:
metadata:
labels:
app: do-kubernetes-sample-app
spec:
containers:
- name: do-kubernetes-sample-app
image: /do-kubernetes-sample-app:latest
ports:
- containerPort: 80
name: httpKubernetes-Bereitstellungen stammen aus der API-Gruppe "+ apps ", daher ist die " apiVersion " Ihres Manifests auf " apps / v1 " festgelegt. Bei ` Metadaten ` haben Sie ein neues Feld hinzugefügt, das Sie zuvor noch nicht verwendet haben: ` metadata.labels `. Dies ist nützlich, um Ihre Bereitstellungen zu organisieren. Das Feld " spec " repräsentiert die Verhaltensspezifikation Ihrer Bereitstellung. Eine Bereitstellung ist für die Verwaltung eines oder mehrerer Pods verantwortlich. In diesem Fall wird ein einzelnes Replikat durch das Feld " spec.replicas +" erstellt. Das heißt, es wird ein einzelner Pod erstellt und verwaltet.
Um Pods verwalten zu können, muss Ihre Bereitstellung wissen, für welche Pods sie verantwortlich ist. Das Feld "+ spec.selector " gibt die entsprechenden Informationen an. In diesem Fall ist die Bereitstellung für alle Pods mit den Tags " app = do-kubernetes-sample-app " verantwortlich. Das Feld " spec.template " enthält die Details des " Pod ", den diese Bereitstellung erstellen wird. In der Vorlage befindet sich auch ein Feld " spec.template.metadata ". Das " labels " in diesem Feld muss mit dem in " spec.selector " verwendeten übereinstimmen. ` spec.template.spec ` ist die Spezifikation des Pods. In diesem Fall enthält es einen einzelnen Container namens " do-kubernetes-sample-app". Das Image dieses Containers ist das Image, das Sie zuvor erstellt und an Docker Hub gesendet haben.
Diese YAML-Datei teilt Kubernetes außerdem mit, dass dieser Container den Port "+ 80 " verfügbar macht, und gibt diesem Port den Namen " http +".
Um auf den von Ihrem "+ Deployment " offengelegten Port zuzugreifen, erstellen Sie einen Service. Erstellen Sie eine Datei mit dem Namen " ~ / do-sample-app / kube / do-sample-service.yml +" und öffnen Sie sie mit Ihrem bevorzugten Editor:
nano ~/do-sample-app/kube/do-sample-service.ymlFügen Sie als Nächstes der Datei die folgenden Zeilen hinzu:
~ / do-sample-app / kube / do-sample-service.yml
apiVersion: v1
kind: Service
metadata:
name: do-kubernetes-sample-app
namespace: default
labels:
app: do-kubernetes-sample-app
spec:
type: ClusterIP
ports:
- port: 80
targetPort: http
name: http
selector:
app: do-kubernetes-sample-appDiese Datei gibt Ihrem "+ Service +" die gleichen Bezeichnungen, die für Ihre Bereitstellung verwendet wurden. Dies ist nicht erforderlich, hilft aber bei der Organisation Ihrer Anwendungen auf Kubernetes.
Die Service-Ressource hat auch ein Feld "+ spec ". Das Feld " spec.type " ist für das Verhalten des Dienstes verantwortlich. In diesem Fall ist es ein " ClusterIP ", was bedeutet, dass der Dienst auf einer clusterinternen IP verfügbar ist und nur von Ihrem Cluster aus erreichbar ist. Dies ist die Standardeinstellung " spec.type " für Dienste. ` spec.selector ` ist das Label-Auswahlkriterium, das bei der Auswahl der Pods verwendet werden soll, die von diesem Service freigelegt werden sollen. Da Ihr Pod das Tag " app: to-kubernetes-sample-app" hat, haben Sie es hier verwendet. "+ spec.ports " sind die Ports, die von den Containern des Pod verfügbar gemacht werden, die Sie von diesem Service aus verfügbar machen möchten. Ihr Pod verfügt über einen einzelnen Container, der den Port " 80 " mit dem Namen " http " verfügbar macht. Sie verwenden ihn hier also als " targetPort ". Der Dienst macht diesen Port auch an Port " 80 +" mit demselben Namen verfügbar, aber Sie hätten auch eine andere Kombination aus Port und Name als die des Containers verwenden können.
Nachdem Sie die Manifestdateien "+ Service" und "+ Deployment" erstellt haben, können Sie diese Ressourcen jetzt mit "+ kubectl" in Ihrem Kubernetes-Cluster erstellen:
kubectl apply -f ~/do-sample-app/kube/Sie erhalten folgende Ausgabe:
Outputdeployment.apps/do-kubernetes-sample-app created
service/do-kubernetes-sample-app createdTesten Sie, ob dies funktioniert, indem Sie einen Port auf Ihrem Computer an den Port weiterleiten, den der Dienst in Ihrem Kubernetes-Cluster verfügbar macht. Sie können dies mit + kubectl port-forward + tun:
kubectl port-forward $(kubectl get pod --selector="app=do-kubernetes-sample-app" --output jsonpath='{.items[0].metadata.name}') 8080:80Der Subshell-Befehl "+ $ (kubectl get pod --selector =" app = do-kubernetes-sample-app "--output jsonpath = '{. Items [0] .metadata.name}') " ruft den Namen von ab der Pod, der dem von Ihnen verwendeten Tag entspricht. Andernfalls hätten Sie es mit ` kubectl get pods +` aus der Liste der Pods abrufen können.
Nachdem Sie "+ port-forward +" ausgeführt haben, wird die Shell nicht mehr interaktiv sein und stattdessen die an Ihren Cluster umgeleiteten Anforderungen ausgeben:
OutputForwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80Wenn Sie "+ localhost: 8080 " in einem beliebigen Browser öffnen, sollte die Seite wiedergegeben werden, die Sie beim Ausführen des Containers vor Ort gesehen haben, sie stammt jedoch jetzt aus Ihrem Kubernetes-Cluster! Wie zuvor können Sie auch in einem neuen Terminalfenster mit " curl +" prüfen, ob es funktioniert:
curl localhost:8080Sie erhalten folgende Ausgabe:
Output<!DOCTYPE html>
<title>DigitalOcean</title>
<body>
Kubernetes Sample Application
</body>Als Nächstes müssen Sie alle von Ihnen erstellten Dateien in Ihr GitHub-Repository übertragen. Dazu müssen Sie zuerst create a repository on GitHub mit dem Namen + digital-ocean-kubernetes-deploy + erstellen.
Um dieses Repository zu Demonstrationszwecken einfach zu halten, initialisieren Sie das neue Repository nicht mit einer README-, Lizenz- oder .gitignore-Datei, wenn Sie auf der GitHub-Benutzeroberfläche dazu aufgefordert werden. Sie können diese Dateien später hinzufügen.
Wenn das Repository erstellt ist, verweisen Sie Ihr lokales Repository auf das auf GitHub. Drücken Sie dazu "+ STRG " + " C ", um " kubectl port-forward " zu stoppen und die Befehlszeile wieder aufzurufen. Führen Sie dann die folgenden Befehle aus, um eine neue Fernbedienung mit dem Namen " origin +" hinzuzufügen:
cd ~/do-sample-app/
git remote add origin https://github.com//digital-ocean-kubernetes-deploy.gitEs sollte keine Ausgabe des vorhergehenden Befehls geben.
Übertragen Sie anschließend alle bisher erstellten Dateien in das GitHub-Repository. Fügen Sie zuerst die Dateien hinzu:
git add --allÜbertragen Sie als Nächstes die Dateien in Ihr Repository, und geben Sie eine Bestätigungsmeldung in Anführungszeichen ein:
git commit -m "initial commit"Dies ergibt eine Ausgabe ähnlich der folgenden:
Output[master (root-commit) db321ad] initial commit
4 files changed, 47 insertions(+)
create mode 100644 Dockerfile
create mode 100644 index.html
create mode 100644 kube/do-sample-deployment.yml
create mode 100644 kube/do-sample-service.ymlZum Schluss schieben Sie die Dateien zu GitHub:
git push -u origin masterSie werden aufgefordert, Ihren Benutzernamen und Ihr Passwort einzugeben. Sobald Sie dies eingegeben haben, sehen Sie die Ausgabe wie folgt:
OutputCounting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 907 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
To github.com:/digital-ocean-kubernetes-deploy.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.Wenn Sie zu Ihrer GitHub-Repository-Seite gehen, werden dort nun alle Dateien angezeigt. Mit Ihrem Projekt auf GitHub können Sie CircleCI jetzt als Ihr CI / CD-Tool einrichten.
Schritt 7 - Konfigurieren von CircleCI
In diesem Lernprogramm verwenden Sie CircleCI, um die Bereitstellung Ihrer Anwendung zu automatisieren, sobald der Code aktualisiert wird. Sie müssen sich daher mit Ihrem GitHub-Konto bei CircleCI anmelden und Ihr Repository einrichten.
Gehen Sie zunächst zu ihrer Homepage https://circleci.com [+ https: // circleci.com +] und drücken Sie * Sign Up *.
image: https://assets.digitalocean.com/articles/cart_64920/CircleCI_Main_Site.png [circleci-home-page]
Wenn Sie GitHub verwenden, klicken Sie auf die grüne Schaltfläche * Mit GitHub anmelden *.
CircleCI leitet zu einer Autorisierungsseite auf GitHub weiter. CircleCI benötigt einige Berechtigungen für Ihr Konto, um mit dem Erstellen Ihrer Projekte beginnen zu können. Auf diese Weise kann CircleCI Ihre E-Mail-Adresse abrufen, Schlüssel bereitstellen und Berechtigungen zum Erstellen von Hooks für Ihre Repositorys sowie zum Hinzufügen von SSH-Schlüsseln zu Ihrem Konto erteilen. Wenn Sie weitere Informationen darüber benötigen, wie CircleCI mit Ihren Daten umgeht, lesen Sie die Dokumentation zur GitHub-Integration.
Bild: https://assets.digitalocean.com/articles/cart_64920/CircleCI_GitHub_Sign_In.png [circleci-github-permission]
Nach der Autorisierung von CircleCI werden Sie zu deren Dashboard weitergeleitet.
image: https://assets.digitalocean.com/articles/cart_64920/CircleCI_Welcome_Page.png [circleci-project-dashboard]
Richten Sie als Nächstes Ihr GitHub-Repository in CircleCI ein. Klicken Sie im CircleCI-Dashboard auf "Neue Projekte einrichten" oder öffnen Sie als Verknüpfung den folgenden Link, um den hervorgehobenen Text mit Ihrem eigenen GitHub-Benutzernamen zu ändern: "+ https: //circleci.com/setup-project/gh//digital" -ocean-kubernetes-deploy + `.
Danach drücken Sie * Start Building *. Erstellen Sie noch keine Konfigurationsdatei in Ihrem Repository und machen Sie sich keine Sorgen, wenn der erste Build fehlschlägt.
image: https://assets.digitalocean.com/articles/cart_64840/Set_Up.png [circleci-start-building]
Geben Sie als Nächstes einige Umgebungsvariablen in den CircleCI-Einstellungen an. Sie können die Einstellungen des Projekts finden, indem Sie auf die kleine Schaltfläche mit dem Zahnradsymbol oben rechts auf der Seite klicken und dann * Umgebungsvariablen * auswählen, oder indem Sie die folgende URL verwenden, um direkt zur Seite mit den Umgebungsvariablen zu gelangen (merken Sie sich) Um Ihren Benutzernamen einzutragen: + https: // circleci.com / gh // digital-ocean-kubernetes-deploy / edit # env-vars + Drücken Sie * Variable hinzufügen *, um neue Umgebungsvariablen zu erstellen.
Fügen Sie zunächst zwei Umgebungsvariablen mit den Namen "+ DOCKERHUB_USERNAME " und " DOCKERHUB_PASS +" hinzu, die später benötigt werden, um das Image in Docker Hub zu übertragen. Stellen Sie die Werte auf Ihren Docker Hub-Benutzernamen bzw. Ihr Kennwort ein.
Fügen Sie dann drei weitere hinzu: + KUBERNETES_TOKEN +, + KUBERNETES_SERVER + und + KUBERNETES_CLUSTER_CERTIFICATE +.
Der Wert von "+ KUBERNETES_TOKEN +" ist der Wert der lokalen Umgebungsvariablen, die Sie zuvor zur Authentifizierung in Ihrem Kubernetes-Cluster mithilfe Ihres Dienstkontobenutzers verwendet haben. Wenn Sie das Terminal geschlossen haben, können Sie immer den folgenden Befehl ausführen, um es erneut abzurufen:
kubectl get secret $(kubectl get secret | grep cicd-token | awk '{print $1}') -o jsonpath='{.data.token}' | base64 --decode"+ KUBERNETES_SERVER " ist die Zeichenfolge, die Sie als " - Server " - Flag an " kubectl " übergeben haben, als Sie sich mit Ihrem " cicd " - Dienstkonto angemeldet haben. Sie finden dies nach " server: " in der Datei " ~ / .kube / config " oder in der Datei " kubernetes-deployment-tutorial-kubeconfig.yaml +", die Sie beim Erstellen der ersten Datei aus dem DigitalOcean-Dashboard heruntergeladen haben Einrichtung Ihres Kubernetes-Clusters.
"+ KUBERNETES CLUSTER CERTIFICATE " sollte auch in Ihrer " ~ / .kube / config" -Datei verfügbar sein. Dies ist das Feld "+ Zertifizierungsstellendaten" auf dem "+ Cluster" -Element, das sich auf Ihren Cluster bezieht. Es sollte eine lange Schnur sein; Stellen Sie sicher, dass Sie alles kopieren.
Diese Umgebungsvariablen müssen hier definiert werden, da die meisten vertrauliche Informationen enthalten und es nicht sicher ist, sie direkt in der CircleCI YAML-Konfigurationsdatei abzulegen.
Wenn CircleCI auf Änderungen in Ihrem Repository und die konfigurierten Umgebungsvariablen wartet, ist es an der Zeit, die Konfigurationsdatei zu erstellen.
Erstellen Sie ein Verzeichnis mit dem Namen "+ .circleci +" in Ihrem Beispielanwendungsrepository:
mkdir ~/do-sample-app/.circleci/Erstellen Sie in diesem Verzeichnis eine Datei mit dem Namen "+ config.yml +" und öffnen Sie sie mit Ihrem bevorzugten Editor:
nano ~/do-sample-app/.circleci/config.ymlFügen Sie der Datei den folgenden Inhalt hinzu, und stellen Sie sicher, dass "++" durch Ihren Docker Hub-Benutzernamen ersetzt wird:
~ / do-sample-app / .circleci / config.yml
version: 2.1
jobs:
build:
docker:
- image: circleci/buildpack-deps:stretch
environment:
IMAGE_NAME: /do-kubernetes-sample-app
working_directory: ~/app
steps:
- checkout
- setup_remote_docker
- run:
name: Build Docker image
command: |
docker build -t $IMAGE_NAME:latest .
- run:
name: Push Docker Image
command: |
echo "$DOCKERHUB_PASS" | docker login -u "$DOCKERHUB_USERNAME" --password-stdin
docker push $IMAGE_NAME:latest
workflows:
version: 2
build-master:
jobs:
- build:
filters:
branches:
only: masterDadurch wird ein Workflow mit einem einzelnen Job namens "+ build " eingerichtet, der für jedes Festschreiben an den Zweig " master " ausgeführt wird. Dieser Job verwendet das Image ` circleci / buildpack-deps: stretch `, um seine Schritte auszuführen. Dies ist ein Image von CircleCI, das auf dem offiziellen Docker-Image ` buildpack-deps +` basiert, jedoch einige zusätzliche Tools wie Docker-Binärdateien installiert hat sich.
Der Workflow besteht aus vier Schritten:
-
+ checkout +ruft den Code von GitHub ab. -
+ setup_remote_docker +richtet für jeden Build eine entfernte, isolierte Umgebung ein. Dies ist erforderlich, bevor Sie in einem Auftragsschritt einen Befehl+ dockerverwenden. Dies ist erforderlich, da die Schritte in einem Docker-Image ausgeführt werden, indem "+ setup_remote_docker +" einem anderen Computer die Ausführung der Befehle dort zuweist. -
Der erste "+ run " - Schritt erstellt das Bild, wie Sie es zuvor lokal getan haben. Dafür verwenden Sie die Umgebungsvariable, die Sie in ` environment: `, ` IMAGE_NAME +` deklariert haben (denken Sie daran, den hervorgehobenen Abschnitt mit Ihren eigenen Informationen zu ändern).
-
Mit dem letzten "+ run +" - Schritt wird das Image an Dockerhub gesendet. Dabei werden die Umgebungsvariablen verwendet, die Sie in den Projekteinstellungen für die Authentifizierung konfiguriert haben.
Übertragen Sie die neue Datei in Ihr Repository und übertragen Sie die Änderungen nach oben:
cd ~/do-sample-app/
git add .circleci/
git commit -m "add CircleCI config"
git pushDies wird einen neuen Build für CircleCI auslösen. Der CircleCI-Workflow wird nun ordnungsgemäß erstellt und Ihr Image an Docker Hub übertragen.
image: https://assets.digitalocean.com/articles/cart_64840/Build.png [CircleCI Build-Seite mit Informationen zum erfolgreichen Build]
Nachdem Sie Ihren CircleCI-Workflow erstellt und getestet haben, können Sie Ihren DOKS-Cluster so einrichten, dass er das aktuelle Image von Docker Hub abruft und es automatisch bereitstellt, wenn Änderungen vorgenommen werden.
Schritt 8 - Aktualisieren der Bereitstellung auf dem Kubernetes-Cluster
Jetzt, da Ihr Anwendungsimage jedes Mal erstellt und an Docker Hub gesendet wird, wenn Sie Änderungen an der Verzweigung "+ master +" in GitHub vornehmen, ist es an der Zeit, Ihre Bereitstellung auf Ihrem Kubernetes-Cluster so zu aktualisieren, dass das neue Image abgerufen und als verwendet wird Basis für die Bereitstellung.
Beheben Sie dazu zunächst ein Problem mit Ihrer Bereitstellung: Es hängt derzeit von einem Image mit dem Tag "+ latest +" ab. Dieses Tag sagt uns nicht, welche Version des Bildes Sie verwenden. Sie können Ihre Bereitstellung nicht einfach an dieses Tag sperren, da es jedes Mal überschrieben wird, wenn Sie ein neues Image an Docker Hub senden. Wenn Sie es auf diese Weise verwenden, verlieren Sie eines der besten Dinge, die mit containerisierten Anwendungen zu tun haben: Reproduzierbarkeit.
In diesem Artikel erfahren Sie mehr darüber, warum abhängig vom neuesten Docker-Tag ein Anti-Pattern ist.
Um dies zu korrigieren, müssen Sie zuerst einige Änderungen an Ihrem Build-Schritt "+ Push Docker Image" in der Datei "+ ~ / do-sample-app / .circleci / config.yml" vornehmen. Öffnen Sie die Datei:
nano ~/do-sample-app/.circleci/config.ymlFügen Sie dann die hervorgehobenen Linien zu Ihrem Schritt + Push Docker Image + hinzu:
~ / do-sample-app / .circleci / config.yml: 16-22
...
- run:
name: Push Docker Image
command: |
echo "$DOCKERHUB_PASS" | docker login -u "$DOCKERHUB_USERNAME" --password-stdin
docker push $IMAGE_NAME:latest
...Speichern und schließen Sie die Datei.
In CircleCI sind einige spezielle Umgebungsvariablen standardmäßig festgelegt. Eines davon ist "+ CIRCLE_SHA1 ", das den Hash des Commits enthält, das es erstellt. Die Änderungen, die Sie an " ~ / do-sample-app / .circleci / config.yml +" vorgenommen haben, verwenden diese Umgebungsvariable, um Ihr Image mit dem Commit zu versehen, aus dem es erstellt wurde. Dabei wird immer der neueste Build mit dem neuesten Tag versehen. Auf diese Weise haben Sie immer bestimmte Bilder zur Verfügung, ohne sie zu überschreiben, wenn Sie etwas Neues in Ihr Repository verschieben.
Ändern Sie als Nächstes Ihre Bereitstellungsmanifestdatei, um auf diese Datei zu verweisen. Dies wäre einfach, wenn Sie in + ~ / do-sample-app / kube / do-sample-deployment.yml + Ihr Image als + / do-kubernetes-sample-app festlegen könnten: $ COMMIT_SHA1 +, aber + kubectl + `ersetzt keine Variablen innerhalb der Manifeste, wenn Sie + kubectl apply + verwenden. Um dies zu berücksichtigen, können Sie https://www.gnu.org/software/gettext/manual/html_node/envsubst-Invocation.html [+ envsubst `] verwenden. ` envsubst +` ist ein Cli-Tool, das Teil des GNU-Gettext-Projekts ist. Hiermit können Sie Text übergeben. Wenn im Text eine Variable mit einer übereinstimmenden Umgebungsvariablen gefunden wird, wird diese durch den entsprechenden Wert ersetzt. Der resultierende Text wird dann als Ausgabe zurückgegeben.
Dazu erstellen Sie ein einfaches Bash-Skript, das für Ihre Bereitstellung verantwortlich ist. Erstellen Sie einen neuen Ordner mit dem Namen "+ scripts " in " ~ / do-sample-app / +":
mkdir ~/do-sample-app/scripts/Erstellen Sie in diesem Ordner ein neues Bash-Skript mit dem Namen "+ ci-deploy.sh +" und öffnen Sie es mit Ihrem bevorzugten Texteditor:
nano ~/do-sample-app/scripts/ci-deploy.shDarin schreiben Sie das folgende Bash-Skript:
~ / do-sample-app / scripts / ci-deploy.sh
#! /bin/bash
# exit script when any command ran here returns with non-zero exit code
set -e
COMMIT_SHA1=$CIRCLE_SHA1
# We must export it so it's available for envsubst
export COMMIT_SHA1=$COMMIT_SHA1
# since the only way for envsubst to work on files is using input/output redirection,
# it's not possible to do in-place substitution, so we need to save the output to another file
# and overwrite the original with that one.
envsubst <./kube/do-sample-deployment.yml >./kube/do-sample-deployment.yml.out
mv ./kube/do-sample-deployment.yml.out ./kube/do-sample-deployment.yml
echo "$KUBERNETES_CLUSTER_CERTIFICATE" | base64 --decode > cert.crt
./kubectl \
--kubeconfig=/dev/null \
--server=$KUBERNETES_SERVER \
--certificate-authority=cert.crt \
--token=$KUBERNETES_TOKEN \
apply -f ./kube/Lassen Sie uns dieses Skript anhand der Kommentare in der Datei durchgehen. Erstens gibt es Folgendes:
set -eDiese Zeile stellt sicher, dass ein fehlgeschlagener Befehl die Ausführung des Bash-Skripts stoppt. Wenn ein Befehl fehlschlägt, werden die nächsten nicht ausgeführt.
COMMIT_SHA1=$CIRCLE_SHA1
export COMMIT_SHA1=$COMMIT_SHA1Diese Zeilen exportieren die Umgebungsvariable CircleCI + $ CIRCLE_SHA1 + mit einem neuen Namen. Wenn Sie die Variable nur deklariert hätten, ohne sie mit "+ export " zu exportieren, wäre sie für den Befehl " envsubst +" nicht sichtbar.
envsubst <./kube/do-sample-deployment.yml >./kube/do-sample-deployment.yml.out
mv ./kube/do-sample-deployment.yml.out ./kube/do-sample-deployment.yml+ envsubst + kann keine direkte Substitution durchführen. Das heißt, es kann nicht den Inhalt einer Datei lesen, die Variablen durch ihre jeweiligen Werte ersetzen und die Ausgabe in dieselbe Datei zurückschreiben. Daher leiten Sie die Ausgabe in eine andere Datei um und überschreiben dann die ursprüngliche Datei mit der neuen.
echo "$KUBERNETES_CLUSTER_CERTIFICATE" | base64 --decode > cert.crtDie Umgebungsvariable "+ $ KUBERNETES_CLUSTER_CERTIFICATE ", die Sie zuvor in den Projekteinstellungen von CircleCI erstellt haben, ist in Wirklichkeit eine Base64-codierte Zeichenfolge. Um es mit ` kubectl ` zu verwenden, müssen Sie seinen Inhalt dekodieren und in einer Datei speichern. In diesem Fall speichern Sie es in einer Datei mit dem Namen " cert.crt +" im aktuellen Arbeitsverzeichnis.
./kubectl \
--kubeconfig=/dev/null \
--server=$KUBERNETES_SERVER \
--certificate-authority=cert.crt \
--token=$KUBERNETES_TOKEN \
apply -f ./kube/Schließlich führen Sie "+ kubectl " aus. Der Befehl hat ähnliche Argumente wie der, den Sie beim Testen Ihres Dienstkontos ausgeführt haben. Sie rufen " apply -f. / Kube / " auf, da das aktuelle Arbeitsverzeichnis auf CircleCI das Stammverzeichnis Ihres Projekts ist. `. / kube / ` hier ist dein ` ~ / do-sample-app / kube +` Ordner.
Speichern Sie die Datei und stellen Sie sicher, dass sie ausführbar ist:
chmod +x ~/do-sample-app/scripts/ci-deploy.shBearbeiten Sie nun + ~ / do-sample-app / kube / do-sample-deployment.yml +:
nano ~/do-sample-app/kube/do-sample-deployment.ymlÄndern Sie das Tag des Containerbildwerts so, dass es wie folgt aussieht:
~ / do-sample-app / kube / do-sample-deployment.yml
# ...
containers:
- name: do-kubernetes-sample-app
image: /do-kubernetes-sample-app:
ports:
- containerPort: 80
name: httpSpeichern und schließen Sie die Datei. Sie müssen Ihrer CI-Konfigurationsdatei jetzt einige neue Schritte hinzufügen, um die Bereitstellung auf Kubernetes zu aktualisieren.
Öffne + ~ / do-sample-app / .circleci / config.yml + in deinem bevorzugten Texteditor:
nano ~/do-sample-app/.circleci/config.ymlSchreiben Sie die folgenden neuen Schritte direkt unter das zuvor verwendete "+ Push Docker Image":
~ / do-sample-app / .circleci / config.yml
...
- run:
name: Install envsubst
command: |
sudo apt-get update && sudo apt-get -y install gettext-base
- run:
name: Install kubectl
command: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod u+x ./kubectl
- run:
name: Deploy Code
command: ./scripts/ci-deploy.shIn den ersten beiden Schritten werden einige Abhängigkeiten installiert, zuerst "+ envsubst " und dann " kubectl ". Der Schritt " Code bereitstellen +" ist für die Ausführung unseres Bereitstellungsskripts verantwortlich.
Um sicherzustellen, dass sich die Änderungen tatsächlich auf Ihre Kubernetes-Bereitstellung auswirken, bearbeiten Sie Ihre + index.html +. Ändern Sie den HTML-Code in etwas anderes wie:
~ / do-sample-app / index.html
<!DOCTYPE html>
<title>DigitalOcean</title>
<body>
Automatic Deployment is Working!
</body>Sobald Sie die obige Änderung gespeichert haben, übertragen Sie alle geänderten Dateien in das Repository und übertragen Sie die Änderungen in den Upstream:
cd ~/do-sample-app/
git add --all
git commit -m "add deploy script and add new steps to circleci config"
git pushSie werden sehen, wie der neue Build auf CircleCI ausgeführt wird und die Änderungen erfolgreich auf Ihrem Kubernetes-Cluster implementiert werden.
Warten Sie, bis der Build abgeschlossen ist, und führen Sie dann denselben Befehl aus, den Sie zuvor ausgeführt haben:
kubectl port-forward $(kubectl get pod --selector="app=do-kubernetes-sample-app" --output jsonpath='{.items[0].metadata.name}') 8080:80Stellen Sie sicher, dass alles funktioniert, indem Sie Ihren Browser unter der URL "+ localhost: 8080 " öffnen oder eine " curl +" -Anforderung an ihn senden. Es sollte das aktualisierte HTML anzeigen:
curl localhost:8080Sie erhalten folgende Ausgabe:
Output<!DOCTYPE html>
<title>DigitalOcean</title>
<body>
Automatic Deployment is Working!
</body>Herzlichen Glückwunsch, Sie haben die automatische Bereitstellung mit CircleCI eingerichtet!
Fazit
Dies war eine grundlegende Einführung in die Bereitstellung von DigitalOcean Kubernetes mit CircleCI. Von hier aus können Sie Ihre Pipeline auf viele Arten verbessern. Als Erstes können Sie einen einzelnen "+ build +" - Job für mehrere Bereitstellungen erstellen, von denen jede in verschiedenen Kubernetes-Clustern oder verschiedenen Namespaces bereitgestellt wird. Dies kann äußerst nützlich sein, wenn Sie verschiedene Git-Zweige für Entwicklungs-, Staging- und Produktionsumgebungen haben und sicherstellen, dass die Bereitstellungen immer getrennt sind.
Sie können auch ein eigenes Image für CircleCI erstellen, anstatt + buildpack-deps + zu verwenden. Dieses Image könnte darauf basieren, aber es könnten bereits Abhängigkeiten von + kubectl + und + envsubst + installiert sein.
Wenn Sie mehr über CI / CD auf Kubernetes erfahren möchten, lesen Sie die Tutorials für unsere CI/CD auf Kubernetes-Webinar-Reihe oder weitere Informationen zu Anwendungen auf Kubernetes finden Sie unter Modernizing Applications for Kubernetes.