Herziening van Skaffold voor de ontwikkeling van Kubernetes

Herziening van Skaffold voor de ontwikkeling van Kubernetes

Anderhalf jaar geleden, op 5 maart 2018, bracht Google de eerste alfaversie van zijn Open Source-project voor CI/CD uit, genaamd schavot, wiens doel het was om “eenvoudige en herhaalbare Kubernetes-ontwikkeling” te creëren, zodat ontwikkelaars zich konden concentreren op ontwikkeling in plaats van op beheer. Wat is er interessant aan Skaffold? Het blijkt dat het een paar trucjes in petto heeft die het tot een krachtig hulpmiddel kunnen maken voor de ontwikkelaar, en misschien zelfs voor de operations engineer. Laten we kennis maken met het project en de mogelijkheden ervan.

NB: Trouwens, we hebben het in onze generaal al kort over Skaffold gehad beoordeling van ontwikkelaarstools, wiens levens verbonden zijn met Kubernetes.

Theorie. Doel en mogelijkheden

Over het algemeen lost Skaffold dus het probleem op van het automatiseren van de CI/CD-cyclus (in de fasen van bouwen, pushen en implementeren), door de ontwikkelaar snelle feedback te bieden, d.w.z. de mogelijkheid om snel het resultaat van daaropvolgende codewijzigingen te ontvangen - in de vorm van een bijgewerkte applicatie die draait in het Kubernetes-cluster. En het kan in verschillende circuits werken (ontwikkelaar, podium, productie...), waarvoor Skaffold helpt bij het beschrijven van de bijbehorende pijplijnen voor uitrol.

De broncode van Skaffold is geschreven in Go, gedistribueerd door onder de gratis Apache-licentie 2.0 (GitHub).

Laten we eens kijken naar de belangrijkste functies en kenmerken. De eerste omvatten het volgende:

  • Skaffold biedt tools voor het maken van CI/CD-pijplijnen.
  • Hiermee kunt u wijzigingen in de broncode op de achtergrond volgen en een geautomatiseerd proces uitvoeren waarbij code in containerimages wordt samengevoegd, deze images in de Docker Registry worden gepubliceerd en in het Kubernetes-cluster worden geïmplementeerd.
  • Synchroniseert bestanden in de repository met de werkmap in de container.
  • Test automatisch met behulp van container-structure-test.
  • Poorten vooruit.
  • Leest de logboeken van een applicatie die in een container draait.
  • Helpt bij het debuggen van applicaties geschreven in Java, Node.js, Python, Go.

Nu over de kenmerken:

  • Skaffold zelf heeft geen componenten aan de clusterzijde. Dat wil zeggen dat het niet nodig is om Kubernetes verder te configureren om dit hulpprogramma te gebruiken.
  • Verschillende pijpleidingen voor uw toepassing. Moet u de code tijdens de ontwikkeling naar de lokale Minikube uitrollen, en vervolgens naar het podium of de productie? Voor dit doel zijn er profielen en gebruikersconfiguraties, omgevingsvariabelen en vlaggen, waarmee u verschillende pijplijnen voor één toepassing kunt beschrijven.
  • CLI. Alleen consolehulpprogramma en configuraties in YAML. Op internet kun je verwijzingen vinden naar pogingen tot creatie experimentele GUIOp dit moment betekent dit echter hoogstwaarschijnlijk alleen dat iemand hem nodig heeft, maar niet echt.
  • Modulariteit. Skaffold is geen op zichzelf staande oogstmachine, maar streeft ernaar om voor specifieke taken individuele modules of bestaande oplossingen te gebruiken.

Illustratie van dit laatste:

  • In de montagefase kunt u het volgende gebruiken:
    • docker lokaal bouwen, in een cluster met kaniko of in Google Cloud Build;
    • Bazel lokaal;
    • Jib Maven en Jib Gradle lokaal of in Google Cloud Build;
    • op maat gemaakte scripts worden lokaal uitgevoerd. Als u een andere (flexibelere/vertrouwde/...) build-oplossing moet uitvoeren, wordt dit in het script beschreven, zodat Skaffold deze start (voorbeeld uit documentatie). Hierdoor kunt u elke verzamelaar gebruiken die met een script kan worden aangeroepen;
  • In de testfase, het reeds genoemde container-structuur-test;
  • Voor inzet is het volgende voorzien:
    • Kubectl;
    • Roer;
    • aanpassen.

Hierdoor kan Skaffold een unicum worden genoemd raamwerk voor het bouwen van CI/CD. Hier is een voorbeeldworkflow wanneer u deze gebruikt (uit de projectdocumentatie):

Herziening van Skaffold voor de ontwikkeling van Kubernetes

Hoe ziet het werk van Skaffold er in algemene termen uit?

  1. Het hulpprogramma controleert wijzigingen in de broncodedirectory. Als er wijzigingen in de bestanden worden aangebracht, worden deze gesynchroniseerd met de applicatiepod in het Kubernetes-cluster. Indien mogelijk zonder de afbeelding opnieuw in elkaar te zetten. Anders wordt een nieuwe afbeelding samengesteld.
  2. De samengestelde afbeelding wordt gecontroleerd met behulp van container-structuurtest, getagd en naar de Docker Registry gestuurd.
  3. Hierna wordt de image geïmplementeerd - geïmplementeerd in het Kubernetes-cluster.
  4. Als de lancering is geïnitialiseerd met behulp van de opdracht skaffold dev, dan beginnen we logbestanden van de applicatie te ontvangen en wacht Skaffold op wijzigingen om alle acties opnieuw te herhalen.

Herziening van Skaffold voor de ontwikkeling van Kubernetes
Illustratie van de belangrijkste fasen van de Skaffold-operatie

Oefening. Skaffold proberen

Om het gebruik van Skaffold te demonstreren, zal ik een voorbeeld nemen GitHub-projectrepository... Trouwens, daar U kunt nog veel meer voorbeelden vinden die rekening houden met verschillende specifieke kenmerken. Ik voer alle acties lokaal uit in Minikube. De installatie is eenvoudig en duurt een paar minuten, en je hebt kubectl nodig om aan de slag te gaan.

Installeer steiger:

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

Laten we de repository van Skaffold klonen met de nodige voorbeelden:

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

Ik heb een voorbeeld gekozen met twee pods, die elk één kleine Go-applicatie bevatten. Eén applicatie is de frontend (leeroy-web), die het verzoek doorstuurt naar de tweede applicatie: de backend (leeroy-app). Laten we eens kijken hoe het eruit ziet:

~/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 en leeroy-web bevatten Go-code en eenvoudige Dockerfiles om deze code lokaal te bouwen:

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

Ik zal de applicatiecode niet geven - het is voldoende om dat te weten leeroy-web accepteert verzoeken en geeft er volmachten aan leeroy-app. Daarom in de bestanden Deployment.yaml er is alleen een dienst voor app (voor interne routering). Pod-poort web we sturen het naar onszelf door voor snelle toegang tot de applicatie.

Hoe het eruit ziet 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 bovengenoemde fasen worden hier beschreven. Naast deze configuratie is er ook een bestand met algemene instellingen - ~/.skaffold/config. Het kan handmatig of via de CLI worden bewerkt, bijvoorbeeld als volgt:

skaffold config set --global local-cluster true

Met deze opdracht wordt de globale variabele ingesteld local-cluster in betekenis true, waarna Skaffold niet zal proberen afbeeldingen naar het externe register te pushen. Als u lokaal ontwikkelt, kunt u deze opdracht gebruiken om afbeeldingen lokaal te bouwen.

Terug naar skaffold.yaml:

  • Op het podium build we specificeren dat u de afbeelding lokaal moet verzamelen en opslaan. Nadat de build voor de eerste keer is uitgevoerd, zullen we het volgende zien:
    // т.к. 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

    Zoals je kunt zien, heeft Skaffold de afbeeldingen zelf getagd. Overigens worden verschillende taggingbeleidsregels ondersteund.

  • Verderop in de configuratie wordt dit aangegeven context: ./leeroy-app/, d.w.z. de context waarin de afbeelding wordt verzameld, wordt gespecificeerd.
  • In de implementatiefase wordt bepaald dat we kubectl en een masker zullen gebruiken voor de noodzakelijke manifesten.
  • PortForward: vergelijkbaar met de manier waarop we gewoonlijk poorten doorsturen met behulp van kubectl port-forward, geven we instructies aan Skaffold om dit commando aan te roepen. In dit geval wordt de lokale poort 9000 doorgestuurd naar 8080 in Deployment met de naam leeroy-web.

Het is tijd om te lanceren skaffold dev: Het team zal een voortdurende “feedbackloop” creëren, d.w.z. Het zal niet alleen alles verzamelen en in het cluster implementeren, maar zal u ook vertellen over de status van de pods op dit moment, veranderingen monitoren en de status van de pods bijwerken.

Hier is het lanceringsresultaat skaffold dev --port-forward bij het opnieuw monteren:

Herziening van Skaffold voor de ontwikkeling van Kubernetes

Ten eerste kunt u zien dat de cache wordt gebruikt. Vervolgens wordt de applicatie samengesteld, geïmplementeerd en worden poorten doorgestuurd. Sinds gespecificeerd --port-forward, Skaffold heeft de haven doorgestuurd web, zoals hem werd gevraagd, maar hier app hij gooide naar eigen goeddunken (koos de dichtstbijzijnde vrije). Hierna ontvangen wij de eerste logs van de applicaties.

Laten we eens kijken of het werkt?

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

Het bestand aanpassen leeroy-app/app.go - er gaan een paar seconden voorbij... en:

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

Tegelijkertijd liet Skaffold zelf hetzelfde zien in de console als voorheen, met uitzondering van één punt: het rolde alleen uit leeroy-app, en niet allemaal tegelijk.

Meer oefening

Het is ook de moeite waard te vermelden dat bij het maken van een nieuw project configuraties voor Skaffold kunnen worden opgestart met behulp van de opdracht init, wat erg handig is. Bovendien kunt u verschillende configuraties schrijven: voer de ontwikkeling uit op de standaardconfiguratie en rol deze vervolgens uit naar de fase met de opdracht run (zelfde proces als dev, houdt alleen geen wijzigingen in de gaten), met behulp van een andere configuratie.

Op katacoda is er руководство Nog makkelijker is het met een voorbeeld. Maar het biedt een kant-en-klare sandbox met Kubernetes, een applicatie en Skaffold. Een geweldige optie als je geïnteresseerd bent om de basisprincipes zelf uit te proberen.

Een mogelijke use case voor Skaffold is het uitvoeren van ontwikkeling op een extern cluster. Niet iedereen vindt het prettig om Minikube op zijn eigen hardware te draaien, de applicatie vervolgens uit te rollen en te verwachten dat deze naar behoren functioneert... In dit geval lost Skaffold het probleem perfect op, wat bijvoorbeeld kan worden bevestigd door Reddit-technici, zoals wij hebben gedaan al besproken писали op onze blog.

En in deze publicatie van Weaveworks vindt u een voorbeeld van het creëren van een pijplijn voor productie.

Conclusie

Skaffold is een handig hulpmiddel voor het bouwen van pijplijnen waarbij applicaties naar Kubernetes worden uitgerold en die primair gericht zijn op ontwikkelingsbehoeften. Het maakt het vrij eenvoudig om een ​​‘korte’ pipeline te creëren die rekening houdt met de basisbehoeften van de ontwikkelaar, maar desgewenst kun je grotere processen organiseren. Als een van de duidelijke voorbeelden van het gebruik van Skaffold in CI/CD-processen is gegeven dergelijk testproject van 10 microservices met behulp van de mogelijkheden van Kubernetes, gRPC, Istio en OpenCensus Tracing.

Skaffold heeft al bijna 8000+ sterren op GitHub, is ontwikkeld door Google en is onderdeel van GoogleContainerTools — over het algemeen is er op dit moment alle reden om aan te nemen dat het project zich nog lang en gelukkig zal ontwikkelen.

PS

Lees ook op onze blog:

Bron: www.habr.com

Voeg een reactie