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 è stato creare «uno sviluppo semplice e riproducibile su Kubernetes», in modo che gli sviluppatori potessero concentrarsi sulla programmazione e non sull'amministrazione. Cosa rende Skaffold interessante? Come si è rivelato, ha diverse carte vincenti che possono farlo diventare un potente strumento per gli sviluppatori, e magari anche per gli ingegneri operativi. Scopriamo il progetto e le sue funzionalità.
NB: A proposito, abbiamo già parlato brevemente di Skaffold nella nostra panoramica generale , la cui vita è legata a Kubernetes.
Teoria. Scopo e funzionalità
Pertanto, se parliamo in generale, Skaffold affronta il compito di automatizzare il ciclo CI/CD (nelle fasi di build, push, deploy), offrendo allo sviluppatore un feedback immediato, cioè la possibilità di ricevere rapidamente i risultati delle modifiche al codice — sotto forma di un'applicazione aggiornata, funzionante nel cluster Kubernetes. E può funzionare in diversi ambienti (dev, stage, production…), per i quali Skaffold aiuta a descrivere i rispettivi pipeline per il deploy.
Il codice sorgente di Skaffold è scritto in Go, sotto licenza Apache License 2.0 (GitHub).
Esaminiamo le funzionalità principali e le caratteristiche. Tra le prime possiamo menzionare:
- Skaffold offre strumenti per la creazione di pipeline CI/CD.
- Permette di monitorare in background le modifiche nel codice sorgente e avviare un processo automatizzato di costruzione del codice in immagini dei contenitori, pubblicazione di queste immagini nel Docker Registry e loro deploy nel cluster Kubernetes.
- Sincronizza i file nel repository con la directory di lavoro nel contenitore.
- Testa automaticamente utilizzando container-structure-test.
- Fornisce accesso alle porte.
- Legge i log delle applicazioni in esecuzione nel contenitore.
- Aiuta nel debug delle applicazioni scritte in Java, Node.js, Python, Go.
Ora — sulle caratteristiche:
- Skaffold non ha componenti sul lato del cluster. Ciò significa che non è necessario configurare ulteriormente Kubernetes per utilizzare questo strumento.
- Diverse pipeline per la tua applicazione. Devi distribuire il codice su Minikube locale mentre sviluppi e, successivamente, su stage o produzione? A questo scopo sono previste e le configurazioni utente, le variabili ambientali e i flag che consentono di descrivere pipeline diverse per una singola applicazione.
- CLI. Solo un'utilità da linea di comando e configurazioni in YAML. In rete si possono trovare menzioni a tentativi di creare , tuttavia al momento questo significa più che altro che a qualcuno serve, ma non molto.
- Modularità. Skaffold non è un raccoglitore autonomo, ma cerca di utilizzare moduli separati o soluzioni già esistenti per compiti specifici.
Illustrazione dell'ultimo:
- Nella fase di costruzione si possono 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 è necessario eseguire un'altra soluzione (più flessibile / familiare / ...) per la costruzione, essa è descritta nello script affinché Skaffold la esegua proprio (). Questo permette di utilizzare qualsiasi costruttore che può essere chiamato tramite uno script;
- Nella fase di test è già supportato il già menzionato ;
- Per il deploy sono previsti:
- Kubectl;
- Helm;
- kustomize.
Grazie a questo, Skaffold può essere considerato una sorta di framework per la costruzione di CI/CD. Ecco un esempio di workflow utilizzando questo strumento (dalla documentazione del progetto):
Come appare in generale il funzionamento di Skaffold?
- L'utilità monitora le modifiche nella directory del codice sorgente. Se i file vengono modificati, essi vengono sincronizzati con il pod dell'applicazione nel cluster Kubernetes. Se possibile, senza ricostruire l'immagine. In caso contrario, viene costruita una nuova immagine.
- L'immagine costruita viene verificata tramite container-structure-test, etichettata e inviata al Docker Registry.
- Dopo di ciò, l'immagine viene deployata — distribuita nel cluster Kubernetes.
- Se l'avvio è stato inizializzato con 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 funzionamento di Skaffold
Pratica. Proviamo Skaffold
Per dimostrare l'uso di Skaffold prendo un esempio dal . A proposito, si possono trovare anche molti altri esempi che tengono conto di diverse specificità. Tutte le azioni verranno eseguite localmente in Minikube. L'installazione è semplice e richiederà pochi minuti, e per iniziare a lavorare sarà necessario 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 l'esempio con due pod, ognuno dei quali contiene una piccola applicazione scritta in Go. Un'applicazione è il frontend (leeroy-web), che reindirizza le richieste all'altra 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 in Go e semplici Dockerfile per la compilazione locale di tale 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 citerò il codice delle applicazioni — basta sapere che leeroy-web riceve richieste e le instrada a leeroy-app. Pertanto, nei file Deployment.yaml c'è un Service solo per app (per il routing interno). La porta del pod web la manderemo in uscita per un accesso rapido all'applicazione.
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 descritti tutti i passaggi menzionati in precedenza. Oltre a questo file di configurazione, esiste anche un file con impostazioni globali — ~/ .skaffold/config. Può essere modificato manualmente oppure tramite CLI — ad esempio, in questo modo:
skaffold config set --global local-cluster true Questo comando imposterà la variabile globale local-cluster a valore true, dopo di che Skaffold non cercherà di 'push'are le immagini in un registro remoto. Se stai sviluppando localmente, puoi utilizzare questo comando per conservare le immagini localmente.
Torniamo a skaffold.yaml:
- Nella fase
buildindichiamo che dobbiamo costruire e conservare l'immagine localmente. Dopo che la build verrà eseguita per la prima volta, 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 si può vedere, Skaffold ha automaticamente etichettato le immagini. A proposito, vengono supportate diverse politiche di etichettatura.
- Successivamente, nel file di configurazione è specificato
context: ./leeroy-app/, vale a dire, è stato impostato il contesto in cui viene costruita l'immagine. - Nella fase di deploy si determina che utilizzeremo kubectl e un filtro per i manifest appropriati.
-
PortForward: analogamente a come solitamente facciamo per inoltrare le porte conkubectl port-forward, diamo istruzioni a Skaffold per eseguire questo comando. In questo caso, la porta locale 9000 viene inoltrata sulla 8080 nel Deployment con nomeleeroy-web.
È il momento di avviare skaffold dev: il comando creerà un 'ciclo di feedback' continuo, cioè non solo compilerà tutto e lo metterà nel cluster, ma comunicherà anche lo stato dei pod in quel momento, monitorerà le modifiche e aggiornerà lo stato dei pod.
Ecco il risultato dell'avvio skaffold dev --port-forward alla ricompilazione:
Prima di tutto, è evidente che viene utilizzata la cache. Poi, l'applicazione viene compilata, distribuita e le porte vengono inoltrate. Poiché è stato specificato --port-forward, Skaffold ha inoltrato la porta a web, come richiesto, ma ha anche app inoltrato a sua discrezione (ha scelto la porta libera più vicina). Dopo di che, otteniamo i primi log dalle applicazioni.
Controlliamo se funziona?
~/skaffold/examples/microservices # kubectl get po
NOME PRONTO STATO RIAVVII ETÀ
leeroy-app-6998dfcc95-2nxvf 1/1 Esecuzione 0 103s
leeroy-web-69f7d47c9d-5ff77 1/1 Esecuzione 0 103s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy app!!! Modifichiamo il file leeroy-app/app.go — passano pochi secondi… e:
~/skaffold/examples/microservices # kubectl get po
NOME PRONTO STATO RIAVVII ETÀ
leeroy-app-ffd79d986-l6nwp 1/1 Esecuzione 0 11s
leeroy-web-69f7d47c9d-5ff77 1/1 Esecuzione 0 4m59s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy Habr!!! Allo stesso tempo, Skaffold ha mostrato in console lo stesso di prima, tranne per un punto: ha restituito solo leeroy-app, e non tutto insieme.
Più pratica
Vale la pena menzionare che quando si crea un nuovo progetto, le configurazioni per Skaffold possono essere 'bootstrap' con il comando join, il che è molto comodo. Inoltre, è possibile scrivere diverse configurazioni: sviluppare con la configurazione predefinita e poi distribuire in stage con il comando run (lo stesso processo di dev, solo non monitora le modifiche), utilizzando un'altra configurazione.
Su katacoda c'è un esempio ancora più semplice. Lì viene proposta una sandbox già pronta con Kubernetes, un'applicazione e Skaffold. Un'ottima opzione se sei interessato a provare da solo le basi.
Una delle possibilità di utilizzo di Skaffold è lo sviluppo su un cluster remoto. Non a tutti è comodo avviare Minikube sulla propria macchina, per poi distribuire l'applicazione e aspettarsi che funzioni correttamente… In tal caso, Skaffold risolve perfettamente il compito, come possono confermare, ad esempio, gli ingegneri di Reddit, di cui abbiamo già parlato nel nostro blog.
E a di Weaveworks si può trovare un esempio di creazione di un pipeline per la produzione.
Conclusione
Skaffold è uno strumento utile per costruire pipeline che prevedono il deployment di applicazioni in Kubernetes e che sono principalmente orientate ai bisogni dello sviluppo. È piuttosto semplice creare una pipeline 'corta', che tenga conto delle esigenze fondamentali dello sviluppatore, ma se desiderato è possibile organizzare anche processi più complessi. Come uno dei chiari esempi di utilizzo di Skaffold nei processi CI/CD un composto da 10 microservizi, che utilizzano le funzionalità di Kubernetes, gRPC, Istio e OpenCensus Tracing.
Skaffold ha già ricevuto quasi 8000+ stelle su GitHub, è sviluppato da Google ed è parte di — in generale, al momento ci sono tutte le ragioni per credere che il progetto si svilupperà a lungo e felicemente.
P.S.
Leggi anche nel nostro blog:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
