Un anno e mezzo fa, il 5 marzo 2018, Google ha rilasciato la prima versione alpha del suo progetto Open Source per CI/CD chiamato , il cui obiettivo era quello di creare uno "sviluppo Kubernetes semplice e ripetibile" in modo che gli sviluppatori potessero concentrarsi sullo sviluppo piuttosto che sull'amministrazione. Cosa potrebbe esserci di interessante in Skaffold? A quanto pare, ha alcuni assi nella manica che possono renderlo uno strumento potente per lo sviluppatore e forse anche per l'ingegnere operativo. Facciamo conoscenza con il progetto e le sue capacità.
NB: A proposito, abbiamo già parlato brevemente di Skaffold nel nostro generale , le cui vite sono collegate a Kubernetes.
Teoria. Scopo e capacità
Quindi, in generale, Skaffold risolve il problema dell'automazione del ciclo CI/CD (nelle fasi di build, push, deploy), offrendo allo sviluppatore un feedback tempestivo, ovvero la possibilità di ricevere rapidamente il risultato delle successive modifiche al codice, sotto forma di un'applicazione aggiornata in esecuzione nel cluster Kubernetes. E può funzionare in diversi circuiti (sviluppo, fase, produzione...), per i quali Skaffold aiuta a descrivere le corrispondenti pipeline per l'implementazione.
Il codice sorgente di Skaffold è scritto in Go, sotto la licenza gratuita Apache 2.0 (GitHub).
Vediamo le principali funzioni e caratteristiche. I primi includono quanto segue:
- Skaffold offre strumenti per la creazione di pipeline CI/CD.
- Consente di monitorare le modifiche nel codice sorgente in background ed eseguire un processo automatizzato di assemblaggio del codice in immagini contenitore, pubblicando queste immagini nel registro Docker e distribuendole nel cluster Kubernetes.
- Sincronizza i file nel repository con la directory di lavoro nel contenitore.
- Esegue automaticamente il test utilizzando container-structure-test.
- Porti avanti.
- Legge i log di un'applicazione in esecuzione in un contenitore.
- Aiuta nel debug di applicazioni scritte in Java, Node.js, Python, Go.
Ora riguardo alle funzionalità:
- Skaffold stesso non ha componenti lato cluster. Cioè, non è necessario configurare ulteriormente Kubernetes per utilizzare questa utilità.
- Pipeline diverse per la tua applicazione. Hai bisogno di implementare il codice su Minikube locale durante lo sviluppo e poi sullo stage o sulla produzione? A questo scopo ci sono e configurazioni utente, variabili di ambiente e flag, che consentono di descrivere diverse pipeline per un'applicazione.
- CLI. Solo utilità console e configurazioni in YAML. Su Internet puoi trovare riferimenti a tentativi di creazione , tuttavia, al momento questo molto probabilmente significa solo che qualcuno ha bisogno di lui, ma non proprio.
- Modularità. Skaffold non è una mietitrice autonoma, ma si impegna a utilizzare moduli individuali o soluzioni esistenti per compiti specifici.
Illustrazione di quest'ultimo:
- In fase di assemblaggio è possibile utilizzare:
- docker build localmente, in un cluster utilizzando Kaniko o in Google Cloud Build;
- Bazel localmente;
- Jib Maven e Jib Gradle localmente o in Google Cloud Build;
- gli script di build personalizzati vengono eseguiti localmente. Se è necessario eseguire un'altra soluzione di build (più flessibile/familiare/...), è descritta nello script in modo che Skaffold la avvii (). Ciò ti consente di utilizzare qualsiasi raccoglitore che può essere chiamato utilizzando uno script;
- In fase di test, il già menzionato ;
- Per la distribuzione vengono forniti:
- Kubectl;
- Timone;
- personalizzare.
Grazie a questo, Skaffold può essere definito unico framework per la creazione di CI/CD. Ecco un esempio di flusso di lavoro quando lo si utilizza (dalla documentazione del progetto):
Come si presenta il lavoro di Skaffold in termini generali?
- L'utilità monitora le modifiche nella directory del codice sorgente. Se vengono apportate modifiche ai file, queste vengono sincronizzate con il pod dell'applicazione nel cluster Kubernetes. Se possibile, senza rimontare l'immagine. Altrimenti, viene assemblata una nuova immagine.
- L'immagine assemblata viene controllata utilizzando container-structure-test, contrassegnata e inviata al registro Docker.
- Successivamente, l'immagine viene distribuita, distribuita nel cluster Kubernetes.
- Se il lancio è stato inizializzato utilizzando il comando
skaffold dev, quindi iniziamo a ricevere i registri dall'applicazione e Skaffold attende le modifiche per ripetere nuovamente tutte le azioni.
Illustrazione delle fasi principali dell'operazione Skaffold
Pratica. Provando Skaffold
Per dimostrare l'uso di Skaffold, prenderò un esempio da . A proposito Puoi trovare molti altri esempi che tengono conto di varie specificità. Eseguirò tutte le azioni localmente in Minikube. L'installazione è semplice e richiede pochi minuti e per iniziare avrai bisogno di kubectl.
Installa 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.1Cloniamo il repository di Skaffold con gli esempi necessari:
git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservicesHo scelto un esempio con due pod, ciascuno contenente una piccola applicazione Go. Un'applicazione è il frontend (leeroy-web), che reindirizza la richiesta alla seconda applicazione, il backend (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 filesleeroy-app e leeroy-web contengono codice Go e semplici file Docker per creare questo codice localmente:
~/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 fornirò il codice dell'applicazione: è sufficiente saperlo leeroy-web accetta le richieste e le delega a leeroy-app. Pertanto nei fascicoli Deployment.yaml c'è un servizio solo per app (per il routing interno). Porta pod web lo inoltreremo a noi stessi per un rapido accesso all'applicazione.
Sembra 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
Tutte le fasi sopra menzionate sono descritte qui. Oltre a questa configurazione, c'è anche un file con le impostazioni globali: ~/.skaffold/config. Può essere modificato manualmente o tramite la CLI, ad esempio in questo modo:
skaffold config set --global local-cluster true
Questo comando imposterà la variabile globale local-cluster nel significato true, dopodiché Skaffold non tenterà di inviare immagini al registro remoto. Se stai sviluppando localmente, puoi utilizzare questo comando per creare immagini localmente.
Torniamo a skaffold.yaml:
- Sul palco
buildspecifichiamo che è necessario raccogliere e salvare l'immagine in locale. Dopo la prima esecuzione della build, vedremo quanto segue:// т.к. 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.1MBCome puoi vedere, Skaffold ha taggato lui stesso le immagini. A proposito, sono supportate diverse politiche di tagging.
- Più avanti nella configurazione è indicato
context: ./leeroy-app/, cioè. viene specificato il contesto in cui l'immagine viene raccolta. - Nella fase di distribuzione è stabilito che utilizzeremo kubectl e una maschera per i manifest necessari.
-
PortForward: simile al modo in cui solitamente inoltriamo le porte utilizzandokubectl port-forward, diamo istruzioni a Skaffold per chiamare questo comando. In questo caso, la porta locale 9000 viene inoltrata alla 8080 in Deployment con il nomeleeroy-web.
È ora di lanciare skaffold dev: Il team creerà un “ciclo di feedback” continuo, vale a dire non solo raccoglierà tutto e lo distribuirà nel cluster, ma ti parlerà anche dello stato dei pod in questo momento, monitorerà le modifiche e aggiornerà lo stato dei pod.
Ecco il risultato del lancio skaffold dev --port-forward durante il rimontaggio:
Innanzitutto, puoi vedere che la cache è in uso. Successivamente, l'applicazione viene assemblata, distribuita e le porte vengono inoltrate. Da specificato --port-forward, Skaffold ha inoltrato il porto a web, come gli è stato chiesto, ma qui app ha lanciato a sua discrezione (ha scelto quello libero più vicino). Successivamente, riceviamo i primi log dalle applicazioni.
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!!!
Modifica del 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!!!
Allo stesso tempo, lo stesso Skaffold ha mostrato nella console la stessa cosa di prima, ad eccezione di un punto: è stato lanciato solo leeroy-app, e non tutto in una volta.
Più pratica
Vale anche la pena ricordare che quando si crea un nuovo progetto, le configurazioni per Skaffold possono essere avviate utilizzando il comando init, il che è molto conveniente. Inoltre, puoi scrivere diverse configurazioni: esegui lo sviluppo sulla configurazione predefinita e poi esegui il rollout sullo stage con il comando run (stesso processo di dev, semplicemente non monitora le modifiche), utilizzando una configurazione diversa.
Su katacoda c'è È ancora più semplice con un esempio. Ma offre un sandbox già pronto con Kubernetes, un'applicazione e Skaffold. Un'ottima opzione se sei interessato a provare tu stesso le nozioni di base.
Un possibile caso d'uso per Skaffold è condurre lo sviluppo su un cluster remoto. Non tutti si sentono a proprio agio nell'utilizzare Minikube sul proprio hardware, per poi lanciare l'applicazione e aspettarsi che funzioni adeguatamente... In questo caso, Skaffold risolve perfettamente il problema, cosa che può essere confermata, ad esempio, dagli ingegneri di Reddit, come abbiamo fatto noi già discusso nel nostro blog.
E in da Weaveworks puoi trovare un esempio di creazione di una pipeline per la produzione.
conclusione
Skaffold è uno strumento utile per la creazione di pipeline che implicano l'implementazione di applicazioni su Kubernetes e si concentrano principalmente sulle esigenze di sviluppo. Rende abbastanza semplice la creazione di una pipeline “breve” che tenga conto delle esigenze di base dello sviluppatore, ma se lo si desidera è possibile organizzare processi più ampi. Come uno dei chiari esempi di utilizzo di Skaffold nei processi CI/CD tale di 10 microservizi che utilizzano le funzionalità di Kubernetes, gRPC, Istio e OpenCensus Tracing.
Skaffold ha già quasi 8000+ stelle su GitHub, è sviluppato da Google e ne fa parte — in generale, al momento ci sono tutte le ragioni per credere che il progetto si svilupperà per sempre felici e contenti.
PS
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com