Vor anderthalb Jahren, am 5. März 2018, hat Google die erste Alpha-Version seines Open-Source-Projekts für CI/CD mit dem Namen , das darauf abzielt, eine "einfache und reproduzierbare Entwicklung unter Kubernetes" zu schaffen, damit sich Entwickler auf das Entwickeln und nicht auf die Administration konzentrieren können. Was macht Skaffold interessant? Es hat sich herausgestellt, dass es einige Vorteile bietet, die es zu einem leistungsstarken Werkzeug für Entwickler und möglicherweise auch für Betriebsingenieure machen. Lassen Sie uns das Projekt und seine Möglichkeiten näher kennenlernen.
NB: Übrigens haben wir bereits kurz über Skaffold in unserem allgemeinen , die mit Kubernetes verbunden sind, berichtet.
Theorie. Zweck und Möglichkeiten
Zusammenfassend lässt sich sagen, dass Skaffold die Automatisierung des CI/CD-Zyklus (in den Phasen Build, Push, Deploy) erleichtert und dem Entwickler sofortige Rückmeldungen bietet, also die Möglichkeit, schnell die Ergebnisse von Codeänderungen zu sehen – in Form einer aktualisierten Anwendung, die im Kubernetes-Cluster läuft. Es kann in verschiedenen Umgebungen (Dev, Stage, Production...) arbeiten, und Skaffold unterstützt dabei, die entsprechenden Pipelines für das Deployment zu beschreiben.
Der Quellcode von Skaffold ist in der Programmiersprache Go geschrieben, unter der freien Lizenz Apache License 2.0 (GitHub).
Betrachten wir die Hauptfunktionen und Merkmale. Zu den ersten gehören:
- Skaffold bietet Werkzeuge zur Erstellung von CI/CD-Pipelines.
- Es überwacht im Hintergrund Änderungen im Quellcode und startet den automatisierten Prozess zur Erstellung von Container-Images, veröffentlicht diese Images im Docker Registry und deployt sie im Kubernetes-Cluster.
- Es synchronisiert Dateien im Repository mit dem Arbeitsverzeichnis im Container.
- Testet automatisch mit container-structure-test.
- Leitet Ports weiter.
- Li оқt die Logs der Anwendung, die im Container läuft.
- Unterstützt bei der Fehlersuche von Anwendungen, die in Java, Node.js, Python, Go geschrieben wurden.
Jetzt zu den Besonderheiten:
- Skaffold hat keine Komponenten auf der Clusterseite. Das bedeutet, dass Kubernetes nicht zusätzlich konfiguriert werden muss, um dieses Tool zu nutzen.
- Verschiedene Pipelines für Ihre Anwendung. Müssen Sie den Code in Minikube lokal bereitstellen, während Sie entwickeln, und danach in der Stage- oder Produktionsumgebung? Dafür gibt es und benutzerdefinierte Konfigurationen, Umgebungsvariablen und Flags, die es ermöglichen, verschiedene Pipelines für eine Anwendung zu beschreiben.
- CLI. Nur die Konsolenanwendung und Konfigurationen in YAML. Im Internet finden sich Hinweise auf Versuche, ein , jedoch bedeutet dies momentan eher, dass es dafür einen Bedarf gibt, aber nicht wirklich existiert.
- Modularität. Skaffold ist kein eigenständiges Tool, sondern zielt darauf ab, einzelne Module oder bereits bestehende Lösungen für spezifische Aufgaben zu nutzen.
Ein Beispiel dafür:
- Während der Build-Phase können folgende Optionen verwendet werden:
- docker build lokal, im Cluster mit kaniko oder in Google Cloud Build;
- Bazel lokal;
- Jib Maven und Jib Gradle lokal oder in Google Cloud Build;
- benutzerdefinierte Build-Skripte, die lokal ausgeführt werden. Wenn Sie eine andere (flexiblere / vertrautere / ...) Lösung für den Build-Prozess verwenden möchten, wird diese im Skript beschrieben, sodass Skaffold genau das startet (). Dadurch kann jeder beliebige Build-Werkzeug verwendet werden, das über das Skript aufgerufen werden kann;
- In der Testphase wird bereits das erwähnte ;
- Für den Deployment-Prozess stehen zur Verfügung:
- Kubectl;
- Helm;
- kustomize.
Dies macht Skaffold zu einer Art Framework für CI/CD. Hier ist ein Beispiel für einen Workflow bei dessen Verwendung (aus der Projektdokumentation):
Wie sieht der Arbeitsablauf von Skaffold im Großen und Ganzen aus?
- Das Tool überwacht Änderungen im Quellverzeichnis. Wenn Änderungen an Dateien vorgenommen werden, werden diese mit dem Pod der Anwendung im Kubernetes-Cluster synchronisiert. Wenn möglich — ohne das Image erneut zu bauen. Andernfalls wird ein neues Image erstellt.
- Das erstellte Image wird mit container-structure-test überprüft, getaggt und in das Docker Registry hochgeladen.
- Anschließend wird das Image bereitgestellt — es wird im Kubernetes-Cluster deployt.
- Wenn der Start über den Befehl
skaffold dev, dann beginnen wir, Protokolle von der Anwendung zu erhalten, während Skaffold auf Änderungen wartet, um alle Aktionen erneut auszuführen.
Illustration der Hauptphasen der Skaffold-Arbeit
Praxis. Wir probieren Skaffold aus
Zur Demonstration der Verwendung von Skaffold nehme ich ein Beispiel aus . Übrigens gibt es viele weitere Beispiele, die verschiedene Besonderheiten berücksichtigen. Alle Aktionen führe ich lokal in Minikube aus. Die Installation ist einfach und dauert nur wenige Minuten, wobei für den Start kubectl benötigt wird.
Wir installieren Skaffold:
curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
skaffold version
v0.37.1Wir klonen das Skaffold-Repository mit den benötigten Beispielen:
git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservicesIch habe ein Beispiel mit zwei Pods ausgewählt, von denen jeder eine kleine Anwendung in Go enthält. Eine Anwendung ist das Frontend (leeroy-web), das Anfragen an die zweite Anwendung, das Backend (leeroy-app), weiterleitet. Sehen wir uns an, wie das aussieht:
~/skaffold/examples/microservices # tree
.
├── leeroy-app
│ ├── app.go
│ ├── Dockerfile
│ └── kubernetes
│ └── deployment.yaml
├── leeroy-web
│ ├── Dockerfile
│ ├── kubernetes
│ │ └── deployment.yaml
│ └── web.go
├── README.adoc
└── skaffold.yaml
4 Verzeichnisse, 8 Dateienleeroy-app und leeroy-web enthalten Go-Code sowie einfache Dockerfiles für den lokalen Build dieses Codes:
~/skaffold/examples/microservices # cat leeroy-app/Dockerfile
FROM golang:1.12.9-alpine3.10 as builder
COPY app.go .
RUN go build -o /app .
FROM alpine:3.10
CMD ["./app"]
COPY --from=builder /app . Ich werde den Anwendungscode nicht aufzeigen — es genügt zu wissen, dass leeroy-web Anfragen entgegennimmt und diese an leeroy-appweiterleitet. Daher gibt es in den Deployment.yaml eine Service-Konfiguration nur für app (für die interne Routenführung). Den Port des Pods web werden wir für einen schnellen Zugriff auf die Anwendung weiterleiten.
Wie sieht skaffold.yaml:
~/skaffold/examples/microservices # cat skaffold.yaml
apiVersion: skaffold/v1beta13
kind: Config
build:
artifacts:
- image: leeroy-web
context: ./leeroy-web/
- image: leeroy-app
context: ./leeroy-app/
deploy:
kubectl:
manifests:
- ./leeroy-web/kubernetes/*
- ./leeroy-app/kubernetes/*
portForward:
- resourceType: deployment
resourceName: leeroy-web
port: 8080
localPort: 9000 Hier werden alle vorher genannten Phasen beschrieben. Neben diesem Config-Datei gibt es auch eine Datei mit globalen Einstellungen — ~/.skaffold/config. Sie können es manuell oder über die CLI bearbeiten — zum Beispiel so:
skaffold config set --global local-cluster true Dieser Befehl setzt die globale Variable local-cluster auf true, wonach Skaffold nicht mehr versuchen wird, Images in ein entferntes Repository zu pushen. Wenn Sie lokal entwickeln, können Sie diesen Befehl verwenden, um die Images ebenfalls lokal zu speichern.
Kehren wir zurück zu skaffold.yaml:
- In der Phase
buildwir geben an, dass das Image lokal gebaut und gespeichert werden soll. Nach dem ersten Start des Builds sehen wir Folgendes:// т.к. Minikube создает кластер в отдельной виртуальной машине, // придется проникнуть внутрь, чтобы найти образы # minikube ssh $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE leeroy-app 7d55a50803590b2ff62e47e6f240723451f3ef6f8c89aeb83b34e661aa287d2e 7d55a5080359 4 hours ago 13MB leeroy-app v0.37.1-171-g0270a0c-dirty 7d55a5080359 4 hours ago 13MB leeroy-web 5063bfb29d984db1ff70661f17d6efcc5537f2bbe6aa6907004ad1ab38879681 5063bfb29d98 5 hours ago 13.1MB leeroy-web v0.37.1-171-g0270a0c-dirty 5063bfb29d98 5 hours ago 13.1MBWie zu sehen ist, hat Skaffold die Images automatisch getaggt. Übrigens werden mehrere Tagging-Politiken unterstützt.
- Im Konfigurationsfile steht weiterhin
context: ./leeroy-app/, das heißt, der Kontext, in dem das Image erstellt wird, ist festgelegt. - In der Deployment-Phase wird festgelegt, dass wir kubectl und eine Maskierung für die erforderlichen Manifestdateien verwenden.
-
PortForward: ähnlich wie wir normalerweise Ports überkubectl port-forwardweiterleiten, geben wir Skaffold Anweisungen, diesen Befehl aufzurufen. In diesem Fall wird der lokale Port 9000 auf 8080 im Deployment mit dem Namenleeroy-web.
Es ist Zeit, es zu starten skaffold dev: Das Team erstellt einen fortlaufenden „Feedback-Zyklus“, der nicht nur alles sammelt und im Cluster bereitstellt, sondern auch den aktuellen Zustand der Pods überwacht, Änderungen verfolgt und den Status der Pods aktualisiert.
Hier ist das Ergebnis des Starts skaffold dev --port-forward bei der erneuten Erstellung:
Zunächst ist zu erkennen, dass der Cache verwendet wird. Danach wird die Anwendung zusammengestellt, bereitgestellt und die Ports weitergeleitet. Da angegeben ist --port-forward, hat Skaffold den Port bis zu web, wie gewünscht, weitergeleitet, während app er nach eigenem Ermessen weitergeleitet hat (den nächsten verfügbaren ausgewählt). Nach diesem Schritt erhalten wir die ersten Logs von den Anwendungen.
Überprüfen wir die Funktionsfähigkeit?
~/skaffold/examples/microservices # kubectl get po
NAME READY STATUS RESTARTS AGE
leeroy-app-6998dfcc95-2nxvf 1/1 Running 0 103s
leeroy-web-69f7d47c9d-5ff77 1/1 Running 0 103s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy app!!! Modifizieren Sie die Datei leeroy-app/app.go — es vergehen einige Sekunden… und:
~/skaffold/examples/microservices # kubectl get po
NAME READY STATUS RESTARTS AGE
leeroy-app-ffd79d986-l6nwp 1/1 Running 0 11s
leeroy-web-69f7d47c9d-5ff77 1/1 Running 0 4m59s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy Habr!!! Dabei hat Skaffold in der Konsole das gleiche ausgegeben wie zuvor, mit einer Ausnahme: es hat nur leeroy-app, und nicht alles auf einmal.
Mehr Praxis
Es ist erwähnenswert, dass beim Erstellen eines neuen Projekts die Konfigurationen für Skaffold mit dem Befehl initschnell eingerichtet werden können, was sehr praktisch ist. Außerdem lassen sich mehrere Konfigurationen schreiben: Die Entwicklung erfolgt mit der Standardkonfiguration, die dann mit dem Befehl run (der gleiche Prozess wie dev, nur dass keine Änderungen verfolgt werden), unter Verwendung einer anderen Konfiguration aktualisiert wird.
Auf Katacoda gibt es ein noch einfacheres Beispiel. Dort wird bereits eine funktionierende Sandbox mit Kubernetes, einer Anwendung und Skaffold angeboten. Eine großartige Option, wenn Sie selbst die Grundlagen ausprobieren möchten.
Eine mögliche Verwendung von Skaffold ist die Entwicklung auf einem Remote-Cluster. Nicht jeder möchte Minikube auf seiner eigenen Hardware starten, das Anwendung bereitstellen und auf dessen angemessene Funktion warten… In diesem Fall löst Skaffold die gestellte Aufgabe hervorragend, was zum Beispiel die Ingenieure von Reddit bestätigen können, worüber wir bereits in unserem Blog.
Und in Von Weaveworks finden Sie ein Beispiel für die Erstellung eines Pipelines für die Produktion.
Fazit
Skaffold — ein praktisches Tool zur Erstellung von Pipelines für die Bereitstellung von Anwendungen in Kubernetes, das sich in erster Linie an die Bedürfnisse der Entwicklung richtet. Mit ihm ist es recht einfach, eine "kurze" Pipeline zu entwickeln, die die grundlegenden Anforderungen der Entwickler berücksichtigt, während auch umfangreichere Prozesse organisiert werden können. so mit 10 Microservices, die die Möglichkeiten von Kubernetes, gRPC, Istio und OpenCensus Tracing nutzen.
Skaffold hat bereits über 8000 Sterne auf GitHub erhalten, wird von Google entwickelt und ist Teil von Somit gibt es derzeit alle Gründe zu glauben, dass das Projekt langfristig erfolgreich sein wird.
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «»;
- «»;
- «».
Quelle: habr.com
