Översikt av Skaffold för utveckling under Kubernetes

För ett och ett halvt år sedan, den 5 mars 2018, släppte Google den första alfa-versionen av sitt Open Source-projekt för CI/CD med namnet Skaffold, vars mål var att skapa "en enkel och reproducerbar utvecklingsmiljö för Kubernetes" så att utvecklare kunde fokusera på själva utvecklingen snarare än på administration. Vad kan Skaffold intressera? Det visar sig att det har flera ess i rockärmen som kan göra det till ett kraftfullt verktyg för både utvecklare och driftsingenjörer. Låt oss bekanta oss med projektet och dess möjligheter.

NB: För övrigt har vi redan kortfattat berättat om Skaffold i vår övergripande översikt över verktyg för utvecklare, vars liv är kopplat till Kubernetes.

Teori. Syfte och funktioner

Så, om vi pratar allmänt, löser Skaffold problemet med automatisering av CI/CD-cykeln (i faserna build, push, deploy), genom att erbjuda utvecklaren snabb återkoppling, dvs. möjligheten att snabbt få resultat av de senaste kodändringarna — i form av en uppdaterad applikation som körs i Kubernetes-klustret. Det kan fungera i olika miljöer (dev, stage, production…), och för detta hjälper Skaffold till att beskriva de relevanta pipelines för distribution.

Källkoden till Skaffold är skriven i Go-språket, sprids under villkoren för den fria licensen Apache License 2.0 (GitHub).

Låt oss titta på de grundläggande funktionerna och egenskaperna. Till de första kan vi nämna följande:

• Skaffold erbjuder verktyg för att skapa CI/CD-pipelines.
• Det möjliggör att i bakgrunden övervaka ändringar i källkoden och starta en automatiserad process för att bygga koden till containerbilder, publicera dessa bilder i Docker Registry och distribuera dem till Kubernetes-klustret.
• Synkroniserar filer i repositoryt med arbetskatalogen i containern.
• Automatiskt testar med hjälp av container-structure-test.
• Vidarebefordrar portar.
• Läser loggar från applikationen som körs i containern.
• Hjälper till med att felsöka applikationer skrivna i Java, Node.js, Python, Go.

Nu — om funktionerna:

• Skaffold har inga komponenter på kluster-sidan.Det betyder att ytterligare konfiguration av Kubernetes för att använda detta verktyg inte krävs.
• Olika pipelines för din applikation.Behöver du distribuera koden till den lokala Minikube medan du utvecklar, och sedan till stage eller produktion? Detta är möjligt med profiler och användarkonfigurationer, miljövariabler och flaggor som gör det möjligt att beskriva olika pipelines för en och samma applikation.
• CLI. Endast ett kommandoradsverktyg och konfigurationer i YAML. På nätet kan man hitta omnämnanden av försök att skapa experimentellt GUI, men för närvarande innebär det snarare att det är någon som behöver det, men inte så mycket.
• Modularitet. Skaffold är ingen fristående maskin, utan strävar efter att använda separata moduler eller redan existerande lösningar för specifika uppgifter.

En illustration av det senaste:

• Under byggsteget kan du använda:
  • docker build lokalt, i klustret med hjälp av kaniko eller i Google Cloud Build;
  • Bazel lokalt;
  • Jib Maven och Jib Gradle lokalt eller i Google Cloud Build;
  • anpassade build-skript som körs lokalt. Om du behöver köra en annan (mer flexibel / bekant / ...) lösning för byggande, beskrivs den i skriptet så att Skaffold exakt kör den (exempel från dokumentationen). Detta gör det möjligt att använda vilken byggare som helst som kan anropas med hjälp av skript;
• Under teststeget stöds redan nämnda container-structure-test;
• För distribution finns:
  • Kubectl;
  • Helm;
  • kustomize.

Tack vare detta kan Skaffold kallas en slags ramverk för att bygga CI/CD. Här är ett exempel på arbetsflödet vid användning av det (från projektets dokumentation):

Hur ser Skaffold ut i grova drag?

1. Verktyget övervakar ändringar i källkoden. Om filer modifieras synkroniseras de med podden i applikationen i Kubernetes-klustret. Om det är möjligt — utan att bygga om bilden. I annat fall — byggs en ny bild.
2. Den byggda bilden verifieras med hjälp av container-structure-test, taggas och skickas till Docker Registry.
3. Efter det distribueras bilden — den rullas ut i Kubernetes-klustret.
4. Om körningen har initierats med kommandot skaffold dev, börjar vi få loggar från applikationen, och Skaffold väntar på förändringar för att upprepa alla åtgärder.

En illustration av de grundläggande stegen i Skaffolds arbete

Praktik. Låt oss prova Skaffold

För att demonstrera användningen av Skaffold tar jag ett exempel från GitHub-repositoriet för projektet. Förresten, där finns även många andra exempel som tar hänsyn till olika specifikationer. Alla åtgärder kommer att utföras lokalt i Minikube. Installation är enkel och tar några minuter, och för att komma igång behövs kubectl.

Installera 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.1

Vi klonar Skaffold-repot med nödvändiga exempel:

git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservices

Jag har valt exemplet med två poddar, var och en innehållande en liten applikation i Go. En applikation är frontenden (leeroy-web) som dirigerar förfrågningar till den andra applikationen — backend (leeroy-app). Låt oss se hur det ser ut:

~/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 kataloger, 8 filer

leeroy-app och leeroy-web innehåller kod i Go och enkla Dockerfiles för lokal byggnation av denna kod:

~/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 .

Jag kommer inte att ge koden för applikationerna — det räcker att veta att leeroy-web tar emot förfrågningar och proxar dem till leeroy-app. Därför finns det en service i filerna Deployment.yaml bara för app (för intern ruttning). Porten för podden web kommer vi att vidarebefordra för snabb åtkomst till applikationen.

Hur ser det ut 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

Här beskrivs alla steg som nämnts ovan. Utöver denna konfiguration finns det även en fil med globala inställningar — ~/.skaffold/config. Den kan redigeras manuellt eller via CLI — till exempel så här:

skaffold config set --global local-cluster true

Detta kommando ställer in den globala variabeln local-cluster till värdet true, varefter Skaffold inte kommer att försöka "push"-a bilder till ett fjärrregister. Om du utvecklar lokalt kan du använda detta kommando för att lagra bilder lokalt också.

Låt oss återkomma till skaffold.yaml:

• Under fasen build vi anger att vi ska bygga och spara bilden lokalt. När bygget körs första gången ser vi följande:

  // т.к. 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.1MB

  Som man kan se har Skaffold automatiskt taggat bilderna. Förresten, flera taggningspolicyer stöds.

• Därefter anges i konfigen context: ./leeroy-app/, dvs. den kontext som används för att bygga bilden.
• Under deployment, it is determined that we will use kubectl and the mask for the required manifests.
• PortForward: similar to how we usually forward ports using kubectl port-forward, we provide Skaffold with instructions to invoke this command. In this case, the local port 9000 is forwarded to 8080 in a Deployment named leeroy-web.

Now is the time to run skaffold dev: the command will create a continuous "feedback loop", i.e., it will not only build everything and deploy it to the cluster, but also report on the current state of the pods, watch for changes, and update the pod states.

Here are the results of starting skaffold dev --port-forward on a rebuild:

First of all, we see that caching is being used. Next, the application is being built, deployed, and ports are being forwarded. Since it is specified --port-forward, Skaffold has forwarded the port to web, as requested, but it app forwarded at its own discretion (it chose the nearest available one). After that, we get the first logs from the applications.

Shall we check the functionality?

~\/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!!!

Let's modify the file leeroy-app\/app.go — a few seconds pass… and:

~\/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!!!

At the same time, Skaffold output the same thing to the console as before, with one exception: it only emitted leeroy-app, rather than everything at once.

More practice

It is worth mentioning that when creating a new project, Skaffold configs can be 'bootstrapped' using the command init, which is very convenient. Furthermore, you can write several configs: develop on the default config, and then deploy to stage using the command run (the same process as dev, just not monitoring changes), using a different config.

On Katacoda, there is en guide an even simpler example. It offers a ready-made sandbox with Kubernetes, an application, and Skaffold. A great option if you're interested in trying out the basics yourself.

Ett av de möjliga användningsområdena för Skaffold är att hantera utveckling på en fjärrkluster. Inte alla tycker att det är bekvämt att köra Minikube på sin egen hårdvara och sedan lansera applikationen och vänta på att den ska fungera korrekt… I sådana fall löser Skaffold uppgiften utmärkt, vilket kan bekräftas av till exempel Reddit-ingenjörer, vilket vi redan har nämnt. om finnas i vår blogg.

Och i denna publikation från Weaveworks finns ett exempel på hur man skapar en pipeline för produktion.

Slutsats

Skaffold är ett praktiskt verktyg för att bygga pipelines som innebär lansering av applikationer i Kubernetes och som främst är inriktade på utvecklarens behov. Det är ganska enkelt att skapa en "kort" pipeline som tar hänsyn till utvecklarens grundläggande behov, men om så önskas kan man också organisera mer omfattande processer. Som ett av de tydliga exemplen på tillämpningen av Skaffold i CI/CD-processer redogörs för en sådan ett testprojekt som består av 10 mikrotjänster som använder sig av Kubernetes, gRPC, Istio och OpenCensus Tracing.

Skaffold har redan fått nästan 8000 stjärnor på GitHub, utvecklas av Google och är en del av GoogleContainerTools — så i allmänhet finns det just nu all anledning att tro att projektet kommer att fortsätta att utvecklas långsiktigt och framgångsrikt.

P.S.

Läs även i vår blogg:

• «Verktyg för utvecklare av applikationer som körs i Kubernetes»;
• «werf — vårt verktyg för CI/CD i Kubernetes (översikt och videoföreläsning)»;
• «Garden v0.10.0: Din bärbara dator behöver inte Kubernetes»;
• «Kubernetes tips & tricks: om lokal utveckling och Telepresence».

Källa: habr.com