Gjennomgang av Skaffold for Kubernetes utvikling

Gjennomgang av Skaffold for Kubernetes utvikling

For halvannet år siden, 5. mars 2018, ga Google ut den første alfaversjonen av sitt Open Source-prosjekt for CI/CD kalt Skaffold, hvis mål var å skape "enkel og repeterbar Kubernetes-utvikling" slik at utviklere kunne fokusere på utvikling i stedet for administrasjon. Hva kan være interessant med Skaffold? Som det viser seg, har den noen triks i ermet som kan gjøre den til et kraftig verktøy for utvikleren, og kanskje til og med driftsingeniøren. La oss bli kjent med prosjektet og dets evner.

NB: Vi har forresten allerede snakket kort om Skaffold i vår general gjennomgang av utviklerverktøy, hvis liv er knyttet til Kubernetes.

Teori. Formål og evner

Så, generelt sett, løser Skaffold problemet med å automatisere CI/CD-syklusen (i bygge-, push-, distribusjonsstadiene), og gi utvikleren rask tilbakemelding, dvs. muligheten til raskt å motta resultatet av påfølgende kodeendringer - i form av en oppdatert applikasjon som kjører i Kubernetes-klyngen. Og det kan fungere i forskjellige kretser (dev, scene, produksjon...), som Skaffold hjelper til med å beskrive de tilsvarende rørledningene for utrulling.

Skaffolds kildekode er skrevet i Go, distribuert av under gratis Apache License 2.0 (GitHub).

La oss se på hovedfunksjonene og funksjonene. De første inkluderer følgende:

  • Skaffold tilbyr verktøy for å lage CI/CD pipelines.
  • Lar deg overvåke endringer i kildekoden i bakgrunnen og kjøre en automatisert prosess for å sette sammen kode til containerbilder, publisere disse bildene i Docker-registret og distribuere dem til Kubernetes-klyngen.
  • Synkroniserer filer i depotet med arbeidskatalogen i beholderen.
  • Tester automatisk ved hjelp av container-structure-test.
  • Forwarder porter.
  • Leser loggene til et program som kjører i en beholder.
  • Hjelper med å feilsøke applikasjoner skrevet i Java, Node.js, Python, Go.

Nå om funksjonene:

  • Skaffold i seg selv har ingen komponenter på klyngesiden. Det vil si at det ikke er nødvendig å konfigurere Kubernetes ytterligere for å bruke dette verktøyet.
  • Ulike rørledninger for din applikasjon. Trenger du å rulle ut koden til lokale Minikube mens du utvikler, og deretter til scene eller produksjon? For dette formålet er det profiler og brukerkonfigurasjoner, miljøvariabler og flagg, som lar deg beskrive forskjellige rørledninger for én applikasjon.
  • CLI. Kun konsollverktøy og konfigurasjoner i YAML. På Internett kan du finne referanser til forsøk på å lage eksperimentell GUI, men for øyeblikket betyr dette mest sannsynlig bare at noen trenger ham, men egentlig ikke.
  • Modularitet. Skaffold er ikke en frittstående hogstmaskin, men har som mål å bruke individuelle moduler eller eksisterende løsninger for spesifikke oppgaver.

Illustrasjon av sistnevnte:

  • På monteringsstadiet kan du bruke:
    • docker bygge 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 byggeskript kjøres lokalt. Hvis du trenger å kjøre en annen (mer fleksibel/kjent/...) byggeløsning, er den beskrevet i scriptet slik at Skaffold starter den (eksempel fra dokumentasjon). Dette lar deg bruke hvilken som helst samler som kan kalles ved hjelp av et skript;
  • På teststadiet, den allerede nevnte beholder-struktur-test;
  • For distribusjon er følgende gitt:
    • Kubectl;
    • Ror;
    • tilpasse.

Takket være dette kan Skaffold kalles en unik rammeverk for å bygge CI/CD. Her er et eksempel på en arbeidsflyt når du bruker den (fra prosjektdokumentasjonen):

Gjennomgang av Skaffold for Kubernetes utvikling

Hvordan ser Skaffolds arbeid ut generelt sett?

  1. Verktøyet overvåker endringer i kildekodekatalogen. Hvis det gjøres endringer i filene, synkroniseres de med programpoden i Kubernetes-klyngen. Hvis mulig, uten å sette sammen bildet på nytt. Ellers settes et nytt bilde sammen.
  2. Det sammensatte bildet kontrolleres ved hjelp av container-structure-test, merkes og sendes til Docker Registry.
  3. Etter dette distribueres bildet - distribuert i Kubernetes-klyngen.
  4. Hvis lanseringen ble initialisert ved hjelp av kommandoen skaffold dev, så begynner vi å motta logger fra applikasjonen, og Skaffold venter på endringer for å gjenta alle handlingene igjen.

Gjennomgang av Skaffold for Kubernetes utvikling
Illustrasjon av hovedstadiene i Skaffold-driften

Øve på. Prøver Skaffold

For å demonstrere bruken av Skaffold skal jeg ta et eksempel fra GitHub-prosjektlager. Forresten, der Du kan finne mange andre eksempler som tar hensyn til ulike detaljer. Jeg vil utføre alle handlinger lokalt i Minikube. Installasjonen er enkel og tar noen minutter, og du trenger kubectl for å komme i gang.

Installer 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

La oss klone Skaffolds depot med de nødvendige eksemplene:

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

Jeg valgte et eksempel med to pods, som hver inneholder en liten Go-applikasjon. En applikasjon er frontend (leeroy-web), som omdirigerer forespørselen til den andre applikasjonen - backend (leeroy-app). La oss se hvordan 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 directories, 8 files

leeroy-app og leeroy-web inneholder Go-kode og enkle Dockerfiler for å bygge denne koden lokalt:

~/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 gi søknadskoden - det er nok å vite det leeroy-web godtar forespørsler og fullmakter dem til leeroy-app. Derfor i filene Deployment.yaml det er kun en tjeneste for app (for intern ruting). Pod port web vi vil videresende den til oss selv for rask tilgang til applikasjonen.

Ser ut som 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

Alle stadiene nevnt ovenfor er beskrevet her. I tillegg til denne konfigurasjonen er det også en fil med globale innstillinger - ~/.skaffold/config. Den kan redigeres manuelt eller via CLI - for eksempel slik:

skaffold config set --global local-cluster true

Denne kommandoen vil angi den globale variabelen local-cluster til mening true, hvoretter Skaffold ikke vil prøve å skyve bilder til det eksterne registeret. Hvis du utvikler lokalt, kan du bruke denne kommandoen til å bygge bilder lokalt.

Tilbake til skaffold.yaml:

  • På scenen build vi spesifiserer at du må samle inn og lagre bildet lokalt. Etter at byggingen kjører for første gang, 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 du ser har Skaffold tagget bildene selv. Forresten, flere tagging-policyer støttes.

  • Videre i konfigurasjonen er det indikert context: ./leeroy-app/, dvs. konteksten bildet er samlet i er spesifisert.
  • På distribusjonsstadiet er det bestemt at vi skal bruke kubectl og en maske for de nødvendige manifestene.
  • PortForward: ligner på hvordan vi vanligvis videresender porter ved hjelp av kubectl port-forward, gir vi instruksjoner til Skaffold om å kalle denne kommandoen. I dette tilfellet videresendes lokal port 9000 til 8080 i Deployment med navnet leeroy-web.

Det er på tide å lansere skaffold dev: Teamet vil opprette en pågående "feedback loop", dvs. ikke bare vil den samle alt og distribuere det til klyngen, men vil også fortelle deg om tilstanden til podene for øyeblikket, overvåke endringer og oppdatere tilstanden til podene.

Her er resultatet av lanseringen skaffold dev --port-forward ved gjenmontering:

Gjennomgang av Skaffold for Kubernetes utvikling

Først kan du se at cachen blir brukt. Deretter settes applikasjonen sammen, distribueres og porter videresendes. Siden spesifisert --port-forward, videresendte Skaffold havnen til web, som han ble spurt, men her app han kastet etter eget skjønn (valgte den nærmeste frie). Etter dette mottar vi de første loggene fra søknadene.

La oss sjekke om det fungerer?

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

Modifisering av filen leeroy-app/app.go - det går noen sekunder... og:

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

Samtidig viste Skaffold selv det samme i konsollen som før, med unntak av ett punkt: den rullet bare ut leeroy-app, og ikke alt på en gang.

Mer trening

Det er også verdt å nevne at når du oppretter et nytt prosjekt, kan konfigurasjoner for Skaffold bootstrappes ved å bruke kommandoen init, noe som er veldig praktisk. I tillegg kan du skrive flere konfigurasjoner: utføre utvikling på standard konfigurasjon, og deretter rulle ut til scenen med kommandoen run (samme prosess som dev, overvåker bare ikke endringer), ved å bruke en annen konfigurasjon.

På katacoda er det lederskap Det er enda enklere med et eksempel. Men den tilbyr en ferdig sandkasse med Kubernetes, en applikasjon og Skaffold. Et flott alternativ hvis du er interessert i å prøve det helt grunnleggende selv.

Et mulig bruksområde for Skaffold er å drive utvikling på en ekstern klynge. Ikke alle er komfortable med å kjøre Minikube på egen maskinvare, for så å rulle ut applikasjonen og forvente at den skal fungere tilstrekkelig... I dette tilfellet løser Skaffold problemet perfekt, noe som for eksempel kan bekreftes av Reddit-ingeniører, slik vi har allerede diskutert skrev i bloggen vår.

Og i denne publikasjonen fra Weaveworks kan du finne et eksempel på å lage en pipeline for produksjon.

Konklusjon

Skaffold er et praktisk verktøy for å bygge rørledninger som innebærer utrulling av applikasjoner til Kubernetes og primært fokusert på utviklingsbehov. Det gjør det ganske enkelt å lage en "kort" pipeline som tar hensyn til utviklerens grunnleggende behov, men om ønskelig kan du organisere større prosesser. Som et av de tydelige eksemplene på bruk av Skaffold i CI/CD-prosesser er gitt slik testprosjekt av 10 mikrotjenester som bruker egenskapene til Kubernetes, gRPC, Istio og OpenCensus Tracing.

Skaffold har allerede nesten 8000+ stjerner på GitHub, er utviklet av Google og er en del av GoogleContainerTools — Generelt er det for øyeblikket all grunn til å tro at prosjektet vil utvikle seg lykkelig i alle sine dager.

PS

Les også på bloggen vår:

Kilde: www.habr.com

Legg til en kommentar