Panoramica di Skaffold per lo sviluppo su Kubernetes

Un anno e mezzo fa, il 5 marzo 2018, Google ha rilasciato la prima versione alfa del suo progetto Open Source per CI/CD chiamato Skaffold, il cui obiettivo è creare uno «sviluppo semplice e riproducibile su Kubernetes», in modo che gli sviluppatori possano concentrarsi proprio sullo sviluppo, piuttosto che sull'amministrazione. Cosa rende Skaffold interessante? Come si è rivelato, ha diversi assi nella manica che possono farne uno strumento potente per gli sviluppatori e, forse, anche per gli ingegneri di produzione. Scopriamo il progetto e le sue potenzialità.

NB: A proposito, abbiamo già parlato brevemente di Skaffold nella nostra generale panoramica sugli strumenti per gli sviluppatori, la cui vita è legata a Kubernetes.

Teoria. Scopo e funzionalità

Quindi, se parliamo in generale, Skaffold affronta il problema dell'automazione del ciclo CI/CD (nelle fasi di build, push, deploy), offrendo agli sviluppatori un feedback rapido, ossia la possibilità di ottenere rapidamente il risultato delle ultime modifiche al codice - sotto forma di un'applicazione aggiornata in esecuzione nel cluster Kubernetes. E può funzionare in diversi ambienti (dev, stage, production…), per cui Skaffold aiuta a descrivere i relativi pipeline di distribuzione.

Il codice sorgente di Skaffold è scritto in Go, distribuito sotto licenza aperta Apache License 2.0 (GitHub).

Esaminiamo le principali funzionalità e caratteristiche. Tra le prime possiamo includere:

• Skaffold offre strumenti per la creazione di pipeline CI/CD.
• Consente di monitorare in background le modifiche nel codice sorgente e avviare un processo automatizzato di costruzione del codice in immagini di container, pubblicazione di queste immagini nel Docker Registry e il loro deploy nel cluster Kubernetes.
• Sincronizza i file nel repository con la directory di lavoro nel container.
• Testa automaticamente utilizzando container-structure-test.
• Instrada le porte.
• Legge i log dell'applicazione in esecuzione nel container.
• Aiuta nel debug di applicazioni scritte in Java, Node.js, Python, Go.

Ora - sulle caratteristiche:

• Skaffold stesso non ha componenti sul lato del cluster. Non è necessario configurare ulteriormente Kubernetes per utilizzare questo strumento.
• Pipeline diverse per la tua applicazione. Devi rilasciare il codice in Minikube locale mentre sviluppi, e poi - in stage o production? Per questo, sono previste di isolamento delle chiamate di sistema. Per eseguire un programma in modalità di isolamento, basta specificare il nome dell'applicazione come argomento dell'utilità firejail, ad esempio, «firejail firefox» o «sudo firejail /etc/init.d/nginx start». configurazioni personalizzate, variabili d'ambiente e flag, che consentono di descrivere diverse pipeline per una sola applicazione.
• CLI. Solo un'utility da console e configurazioni in YAML. In rete puoi trovare riferimenti a tentativi di creare un'interfaccia grafica sperimentale, ma al momento ciò significa solo che è necessaria, ma non troppo.
• Modularità. Skaffold non è un apparecchio autonomo, ma cerca di utilizzare singoli moduli o soluzioni esistenti per compiti specifici.

Illustrazione dell'ultimo punto:

• Nella fase di build puoi utilizzare:
  • docker build localmente, nel cluster con kaniko o in Google Cloud Build;
  • Bazel localmente;
  • Jib Maven e Jib Gradle localmente o in Google Cloud Build;
  • script di build personalizzati eseguiti localmente. Se hai bisogno di eseguire un altro (più flessibile/abituale/…) soluzione per la build, essa viene descritta nello script, affinché Skaffold la esegua esattamente (esempio dalla documentazione). Questo consente di utilizzare qualsiasi builder che possa essere richiamato tramite uno script;
• Nella fase di test è supportato già menzionato container-structure-test;
• Per il deploy sono previsti:
  • Kubectl;
  • Helm;
  • kustomize.

Grazie a ciò Skaffold può essere considerato un framework per la costruzione di CI/CD. Ecco un esempio di flusso di lavoro durante il suo utilizzo (dalla documentazione del progetto):

Come appare in linea generale il lavoro di Skaffold?

1. L'utility monitora le modifiche nella directory con il codice sorgente. Se vengono apportate modifiche ai file, vengono sincronizzate con il pod dell'applicazione nel cluster Kubernetes. Se possibile, senza ricostruire l'immagine. Altrimenti, viene costruita una nuova immagine.
2. L'immagine costruita viene verificata utilizzando container-structure-test, taggata e inviata al Docker Registry.
3. Dopo di ciò l'immagine viene deployata - distribuita nel cluster Kubernetes.
4. Se l'avvio è stato inizializzato tramite il comando skaffold dev, iniziamo a ricevere i log dall'applicazione e Skaffold attende modifiche per ripetere tutte le azioni da capo.

Illustrazione delle fasi principali del lavoro di Skaffold

Pratica. Proviamo Skaffold

Per dimostrare l'utilizzo di Skaffold prenderò un esempio dal repository GitHub del progetto. A proposito, lì stesso puoi trovare anche molti altri esempi che considerano varie specificità. Tutte le operazioni verranno eseguite localmente in Minikube. L'installazione è semplice e richiederà pochi minuti, e per iniziare a lavorare avrai bisogno di kubectl.

Installiamo 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

Cloniamo il repository di Skaffold con gli esempi necessari:

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

Ho scelto l'esempio con due pod, ognuno dei quali contiene una piccola applicazione in Go. Un'applicazione è il front-end (leeroy-web), che reindirizza le richieste all'altra applicazione, che è il back-end (leeroy-app). Vediamo come appare:

~/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 e leeroy-web contengono codice in Go e semplici Dockerfile per la costruzione locale di questo codice:

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

Non riporterò il codice delle applicazioni — è sufficiente sapere che leeroy-web riceve richieste e le proxy verso leeroy-app. Pertanto, nei file Deployment.yaml esiste un Service solo per app (per il routing interno). La porta del pod web la esporremo per un accesso rapido all'applicazione.

Ecco come appare 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

Qui vengono descritte tutte le fasi menzionate sopra. Oltre a questo file di configurazione, esiste anche un file con le impostazioni globali — ~/.skaffold/config. Può essere modificato manualmente o tramite CLI, ad esempio in questo modo:

skaffold config set --global local-cluster true

Questo comando imposterà la variabile globale local-cluster su true, dopo di che Skaffold non tenterà di 'push'are le immagini in un registro remoto. Se stai sviluppando localmente, puoi utilizzare questo comando per salvare le immagini anche localmente.

Tornando a skaffold.yaml:

• Nella fase build indichiamo che dobbiamo costruire e salvare l'immagine localmente. Dopo che la build verrà eseguita per la prima volta, vedremo il seguente output:

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

  Come si può vedere, Skaffold ha automaticamente taggato le immagini. A proposito, supporta diverse politiche di tagging.

• Successivamente, nella configurazione è indicato context: ./leeroy-app/, cioè è impostato il contesto in cui viene costruita l'immagine.
• Nella fase di deployment viene definito che utilizzeremo kubectl e un pattern per i manifesti necessari.
• PortForward: analogamente a come diamo istruzioni per esporre le porte con kubectl port-forward, diamo istruzioni a Skaffold per invocare questo comando. In questo caso, la porta locale 9000 viene esposta sulla 8080 nel Deployment di nome leeroy-web.

È ora di avviare skaffold dev: il comando creerà un 'loop di feedback' continuo, ovvero non solo costruirà tutto e lo deploierà nel cluster, ma fornirà anche informazioni sullo stato dei pod in questo momento, monitorando le modifiche e aggiornando lo stato dei pod.

Ecco il risultato dell'esecuzione skaffold dev --port-forward alla nuova build:

In primo luogo, è evidente che viene utilizzata la cache. Inoltre, l'applicazione viene costruita, deploata e le porte vengono esposte. Poiché è stata specificata --port-forward, Skaffold ha esposto la porta come richiesto, mentre webè stata esposta a sua discrezione (ha scelto la porta libera più vicina). Dopo di ciò, riceviamo i primi log dalle applicazioni. app Controlliamo se funziona?

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

Modifichiamo il file

leeroy-app/app.go — passano alcuni secondi… e: ~/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!!!

Nel mentre, Skaffold ha mostrato in console lo stesso output di prima, con l'eccezione di un dettaglio: ha rilasciato solo

, e non tutto insieme. leeroy-appPiù pratica

Vale la pena menzionare che, quando si crea un nuovo progetto, i file di configurazione di Skaffold possono essere 'bootstrapati' con il comando

, molto utile. Inoltre, puoi scrivere diversi file di configurazione: lavorare sul file di configurazione predefinito e poi rilasciarlo in fase con il comando init(lo stesso processo di prima, solo non monitora le modifiche), utilizzando un altro file di configurazione. run Su katacoda ci sono devun esempio anche più semplice. Qui viene proposta una sandbox già pronta con Kubernetes, un'applicazione e Skaffold. Ottima opzione se sei interessato a provare da solo le basi.

Uno dei possibili usi di Skaffold è lo sviluppo su un cluster remoto. Non tutti trovano comodo eseguire Minikube sulla propria macchina e poi lanciare un'applicazione sperando che funzioni bene... In tal caso, Skaffold risolve egregiamente il compito, come possono confermare, ad esempio, gli ingegneri di Reddit, di cui abbiamo già parlato. la guida con un esempio ancora più semplice. Invece, lì è già disponibile un ambiente pronto con Kubernetes, un'applicazione e Skaffold. Un'ottima opzione se sei interessato a provare autonomamente le basi.

Una delle possibili applicazioni di Skaffold è lo sviluppo su un cluster remoto. Non è sempre comodo eseguire Minikube sulla propria macchina, per poi distribuire l'app e aspettarsi che funzioni correttamente... In tal caso, Skaffold risolve perfettamente il problema, come possono confermare, ad esempio, gli ingegneri di Reddit, di cui abbiamo già discusso. scritto trovarli nel nostro blog.

E in questa pubblicazione Puoi trovare un esempio di creazione di un pipeline per la produzione da Weaveworks.

Conclusione

Skaffold è uno strumento pratico per costruire pipeline per il rilascio di applicazioni in Kubernetes, progettato principalmente per soddisfare le esigenze degli sviluppatori. Con esso, è piuttosto semplice creare un 'breve' pipeline che prenda in considerazione le principali necessità dello sviluppatore, ma se si desidera, è possibile organizzare anche processi più complessi. Come uno dei casi pratici di utilizzo di Skaffold nei processi CI/CD viene riportato questo un progetto di prova composto da 10 microservizi che utilizzano le capacità di Kubernetes, gRPC, Istio e OpenCensus Tracing.

Skaffold ha già ricevuto quasi 8000 stelle su GitHub, è sviluppato da Google ed è parte di GoogleContainerTools — insomma, al momento ci sono tutte le ragioni per credere che il progetto avrà un lungo e prospero sviluppo.

P.S.

Leggete anche nel nostro blog:

• «Strumenti per sviluppatori di applicazioni in esecuzione su Kubernetes»;
• «werf — il nostro strumento per CI/CD in Kubernetes (panoramica e video della presentazione)»;
• «Garden v0.10.0: Il tuo laptop non ha bisogno di Kubernetes»;
• «Kubernetes tips & tricks: sullo sviluppo locale e Telepresence».

Fonte: habr.com