Oversigt over Skaffold til udvikling til Kubernetes

For halvandet år siden, den 5. marts 2018, udgav Google den første alpha-version af sit Open Source-projekt til CI/CD kaldet Skaffold, med det mål at skabe "simpel og reproducerbar udvikling under Kubernetes", så udviklerne kunne fokusere på udviklingen og ikke på administrationen. Hvad gør Skaffold interessant? Som det viser sig, har det flere tricks i ærmet, hvilket gør det til et stærkt værktøj for både udviklere og driftsingeniører. Lad os lære projektet og dets muligheder at kende.

NB: For øvrigt har vi allerede kort fortalt om Skaffold i vores generelle oversigt over værktøjer til udviklere, hvis liv er knyttet til Kubernetes.

Teori. Formål og muligheder

Så, hvis vi taler generelt, så løser Skaffold opgaven med automatisering af CI/CD-cyklussen (i faserne build, push, deploy) ved at tilbyde udvikleren hurtig feedback, altså muligheden for hurtigt at få resultater af de seneste kodeændringer - i form af en opdateret applikation, der kører i Kubernetes-klusteret. Og det kan arbejde i forskellige miljøer (dev, stage, production…), hvortil Skaffold hjælper med at beskrive de relevante pipelines til deployment.

Kildekoden til Skaffold er skrevet i Go-sprog, distribueres under vilkårene for Apache License 2.0 (GitHub).

Lad os se på de vigtigste funktioner og egenskaber. Blandt de første kan nævnes følgende:

• Skaffold tilbyder værktøjer til at oprette CI/CD-pipelines.
• Muliggør overvågning af ændringer i kildekoden i baggrunden og kører automatiserede byggprocesser, konverterer koden til containerbilleder, offentliggør disse billeder i Docker Registry og udfører deployment i Kubernetes-klusteret.
• Synkroniserer filer i repository med arbejdsbiblioteket i containeren.
• Udfører automatiske tests med container-structure-test.
• Pipper porte.
• Læser logfiler for applikationen, der kører i containeren.
• Hjælper med at debugge applikationer skrevet i Java, Node.js, Python, Go.

Nu til funktionerne:

• Skaffold har ikke komponenter på klusterets side. Det vil sige, det er ikke nødvendigt at konfigurere Kubernetes yderligere for at bruge dette værktøj.
• Forskellige pipelines til din applikation. Skal du uddeploye koden til lokal Minikube, mens du arbejder på udviklingen, og derefter til stage eller produktion? Til det er der muligheder. profiler og brugerkonfigurationer, miljøvariabler og flag, der gør det muligt at beskrive forskellige pipelines for én applikation.
• flagen -k til integration med. Kun et konsolværktøj og konfigurationer i YAML. På nettet kan man finde omtale af forsøg på at skabe et eksperimentelt GUI, men lige nu betyder det mere, at nogen har brug for det, men ikke særlig meget.
• Modularitet. Skaffold er ikke en selvstændig kombajn, men stræber efter at bruge separate moduler eller allerede eksisterende løsninger til specifikke opgaver.

Illustration af det sidste:

• På byggefasen kan der bruges:
  • docker build lokalt, i en klynge med kaniko eller i Google Cloud Build;
  • Bazel lokalt;
  • Jib Maven og Jib Gradle lokalt eller i Google Cloud Build;
  • tilpassede build-scripts, der køres lokalt. Hvis du har brug for at køre en anden (mere fleksibel/vanlig/…) bygning, beskrives den i scriptet, så Skaffold præcist kører den (eksempel fra dokumentationen). Dette gør det muligt at bruge hvilken som helst bygger, der kan kaldes via et script;
• På testfasen understøttes allerede nævnte container-structure-test;
• Til deployment er der tilvejebragt:
  • Kubectl;
  • Helm;
  • kustomize.

Takket være dette kan Skaffold kaldes en slags rammeværk for opbygning af CI/CD. Her er et eksempel på arbejdsprocessen ved dens anvendelse (fra projektets dokumentation):

Hvordan ser arbejdet med Skaffold overordnet set ud?

1. Værktøjet overvåger ændringer i kildedirektoriet. Hvis der foretages ændringer i filer, synkroniseres de med applikationen i Kubernetes-klyngen. Hvis det er muligt - uden at bygge billedet igen. Ellers bygges et nyt billede.
2. Det byggede billede kontrolleres med container-structure-test, tagges og sendes til Docker Registry.
3. Herefter deployes billedet - rulles ud i Kubernetes-klyngen.
4. Hvis kørslen blev initieret med kommandoen skaffold dev, så begynder vi at modtage logs fra applikationen, og Skaffold venter på ændringer for at gentage alle handlingerne.

Illustration af hovedstadierne for Skaffold

Praksis. Prøver Skaffold

For at demonstrere brugen af Skaffold vil jeg tage et eksempel fra GitHub-repositoriet for projektet. For resten, er den samme der kan man finde mange andre eksempler, der tager forskellige specifikationer i betragtning. Alle handlinger vil jeg udføre lokalt i Minikube. Installation er enkel og tager et par minutter, og for at komme i gang har du brug for kubectl.

Lad os installere 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 kloner Skaffold-repoet med de nødvendige eksempler:

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

Jeg valgte et eksempel med to pods, hver af dem indeholder en lille Go-applikation. Den ene applikation er frontend (leeroy-web), som videresender anmodninger til den anden applikation — backend (leeroy-app). Lad os se, hvordan det ser ud:

~/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 directories, 8 files

leeroy-app og leeroy-web indeholder Go-kode og enkle Dockerfiles til lokal bygning af denne kode:

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

Jeg vil ikke vise koden for applikationerne — det er tilstrækkeligt at vide, at leeroy-web modtager anmodninger og videresender dem til leeroy-app. Derfor findes der en Service i filerne Deployment.yaml kun for app (til intern routing). Porten på pod'en web vil vi videresende til os selv for hurtig adgang til applikationen.

Hvordan ser det ud 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

Her beskrives alle faser nævnt ovenfor. Udover denne konfiguration findes der også en fil med globale indstillinger — ~/ .skaffold/config. Den kan redigeres manuelt eller gennem CLI — for eksempel sådan her:

skaffold config set --global local-cluster true

Denne kommando vil sætte en global variabel local-cluster til værdien true, hvorefter Skaffold ikke vil forsøge at 'push' billeder til et eksternt register. Hvis du udvikler lokalt, kan du bruge denne kommando for at gemme billeder også lokalt.

Lad os vende tilbage til skaffold.yaml:

• I stadiet build her angiver vi, at billedet skal bygges og gemmes lokalt. Efter den første bygning, vil vi se følgende:

  // т.к. 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 det kan ses, har Skaffold automatisk tagget billederne. For øvrigt understøtter det flere tagging-politikker.

• Dernæst i konfigurationen angives context: ./leeroy-app/, dvs. den kontekst, hvori billedet bygges.
• I deployering bestemmes det, at vi vil bruge kubectl og en maske til de nødvendige manifester.
• PortForward: svarende til, hvordan vi normalt videresender porte ved hjælp af kubectl port-forward, giver vi instruktioner til Skaffold om at kalde denne kommando. I dette tilfælde videresendes lokal port 9000 til 8080 i Deployment med navnet leeroy-web.

Det er tid til at starte skaffold dev: kommandoen vil oprette en vedvarende "feedback-loop", dvs. den vil ikke bare bygge alt og udrulle det i klyngen, men også fortælle om tilstanden af pod'erne på nuværende tidspunkt, overvåge ændringer og opdatere tilstanden af pod'erne.

Her er resultatet af opstarten skaffold dev --port-forward ved genopbygning:

For det første kan vi se, at der bruges cache. Dernæst - applikationen bygges, udrulles, og porte videresendes. Da --port-forward, har Skaffold videresendt port til web, som ønsket, men app den har videresendt efter eget valg (valgt den nærmeste ledige). Efter dette får vi de første logs fra applikationerne.

Skal vi teste det?

~ /skaffold /eksempler /mikrotjenester # 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 /eksempler /mikrotjenester # curl localhost:9000
leeroooooy app!!!

Vi modificerer filen leeroy-app /app.go — der går nogle sekunder… og:

~ /skaffold /eksempler /mikrotjenester # 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 /eksempler /mikrotjenester # curl localhost:9000
leeroooooy Habr!!!

Samtidig viste Skaffold det samme i konsollen som før, bortset fra et punkt: det viste kun leeroy-app, og ikke alt på én gang.

Mere praksis

Det er værd at nævne, at når man opretter et nyt projekt, kan konfigurationerne til Skaffold 'bootstrap'es ved hjælp af kommandoen init, hvilket er meget praktisk. Desuden kan man skrive flere konfigurationer: udvikle på standardkonfigurationen og derefter udrulle til stage med kommandoen run (den samme proces som dev, bare uden at overvåge ændringer), ved at bruge en anden konfiguration.

På katacoda er der vejledning med et eksempel, der er endnu enklere. Der tilbydes allerede en klar sandkasse med Kubernetes, applikationen og Skaffold. En fremragende mulighed, hvis du er interesseret i at prøve de grundlæggende ting selv.

En af de mulige anvendelsesmuligheder for Skaffold er at føre udviklingen på et eksternt cluster. Ikke alle har det nemt med at køre Minikube på eget udstyr, hvorefter de implementerer applikationen og venter på dens ordentlige funktion… I sådanne tilfælde løser Skaffold opgaven glimrende, hvilket eksempelvis ingeniører fra Reddit kan bekræfte, om vi allerede har skrevet på vores blog.

Og i i bloggen. fra Weaveworks kan finde et eksempel på oprettelse af en pipeline til produktion.

Konklusion

Skaffold er et praktisk værktøj til opbygning af pipelines, der indebærer implementering af applikationer i Kubernetes og primært er rettet mod udviklingsbehov. Det er ret nemt at skabe en "kort" pipeline, der tager højde for udviklerens grundlæggende behov, men hvis ønskes, kan der også organiseres mere omfattende processer. Som et af de illustrative eksempler på anvendelsen af Skaffold i CI/CD-processer gives sådan testprojektet bestående af 10 mikroservices, der bruger mulighederne i Kubernetes, gRPC, Istio og OpenCensus Tracing.

Skaffold har allerede fået næsten 8000+ stjerner på GitHub, udvikles af Google og indgår i GoogleContainerTools — generelt er der i øjeblikket alle grunde til at tro, at projektet vil udvikle sig længe og lykkeligt.

P.S.

Læs også på vores blog:

• «Værktøjer til udviklere af applikationer, der køres i Kubernetes»;
• «werf — vores værktøj til CI/CD i Kubernetes (oversigt og video af præsentationen)»;
• «Garden v0.10.0: Din bærbare computer har ikke brug for Kubernetes»;
• «Kubernetes tips & tricks: om lokal udvikling og Telepresence».

Kilde: habr.com