🥇Strumenti per gli sviluppatori di applicazioni in esecuzione su Kubernetes

L'approccio moderno all'operatività risolve molte problematiche urgenti per le aziende. I container e gli orchestratori consentono di scalare facilmente progetti di qualsiasi complessità, semplificano i rilasci di nuove versioni rendendoli più affidabili, ma allo stesso tempo creano anche problemi aggiuntivi per gli sviluppatori. Ciò che preoccupa principalmente un programmatore è il suo codice: architettura, qualità, prestazioni, eleganza, e non come verrà eseguito in Kubernetes e come sarà testato e debugato dopo anche le più piccole modifiche. Pertanto, è naturale che si sviluppino strumenti per Kubernetes che aiutano a risolvere i problemi anche dei programmatori più “arcaici”, consentendo loro di concentrarsi sull'essenziale.

In questa panoramica è presentata una breve informazione su alcuni strumenti che semplificano la vita del programmatore il cui codice gira nei pod di un cluster Kubernetes.

Semplici assistenti

Kubectl-debug

Nucleo: aggiungi il tuo container al Pod e osserva cosa accade al suo interno.
GitHub.
Breve statistica su GH: 715 stelle, 54 commit, 9 collaboratori.
Linguaggio: Go.
Licenza: Apache License 2.0.

Questo plugin per kubectl consente di creare un container aggiuntivo all'interno del pod di interesse, che condividerà lo spazio dei nomi dei processi con gli altri container. In esso è possibile eseguire il debug del funzionamento del pod: controllare la rete, ascoltare il traffico di rete, effettuare un strace sul processo di interesse, ecc.

Inoltre, è possibile passare al container del processo eseguendo chroot /proc/PID/root — questo è molto utile quando è necessario ottenere una shell root nel container per il quale nel manifesto è stato impostato securityContext.runAs.

Lo strumento è semplice ed efficace, quindi può essere utile a ogni sviluppatore. Abbiamo parlato di esso in un articolo separato.

Telepresence

Nucleo: trasferisci l'applicazione sul tuo computer. Sviluppa e fai il debug localmente.
Sito; GitHub.
Breve statistica su GH: 2131 stelle, 2712 commit, 33 collaboratori.
Linguaggio: Python.
Licenza: Apache License 2.0.

L'idea di questo strumento è quella di eseguire un container con l'applicazione sul computer utente locale e fare il proxy di tutto il traffico dal cluster a esso e viceversa. Questo approccio consente di sviluppare localmente, semplicemente modificando i file nel proprio IDE preferito: i risultati saranno immediatamente disponibili.

I vantaggi dell'esecuzione locale sono la facilità di apportare modifiche e il risultato immediato, oltre alla possibilità di eseguire il debug dell'applicazione in modo familiare. Tra gli svantaggi, invece, c'è l'esigenza di una connessione veloce, che si fa particolarmente sentire quando si lavora con applicazioni che hanno un RPS e un traffico piuttosto elevati. Inoltre, Telepresence presenta problemi con i volume mounts su Windows, il che può diventare un limite decisivo per gli sviluppatori abituati a questo sistema operativo.

Abbiamo già condiviso la nostra esperienza con l'uso di Telepresence qui.

Ksync

Nucleo: sincronizzazione quasi istantanea del codice con il container nel cluster.
GitHub.
Breve statistica di GH: 555 stelle, 362 commit, 11 contributori.
Linguaggio: Go.
Licenza: Apache License 2.0.

Lo strumento consente di sincronizzare il contenuto di una directory locale con una directory del container in esecuzione nel cluster. Questo strumento è particolarmente utile per gli sviluppatori che lavorano con linguaggi di programmazione di scripting, la cui principale difficoltà è quella di portare il codice in un container attivo. Ksync è progettato per alleviare questo problema.

Con una sola inizializzazione del comando ksync init nel cluster viene creato un DaemonSet, utilizzato per monitorare lo stato del file system del container selezionato. Sul proprio computer locale, lo sviluppatore esegue il comando ksync watch, che monitora le configurazioni e avvia syncthing, che si occupa della sincronizzazione diretta dei file con il cluster.

Rimane da istruire ksync su cosa e come sincronizzare. Ad esempio, un comando del genere:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

… creerà un watcher con nome myproject, che cercherà pod con etichetta app=backend e cercherà di sincronizzare la directory locale /home/user/myproject/ con la directory /var/www/myproject/ del container di nome php.

Problemi e note su ksync dalla nostra esperienza:

Sui nodi del cluster Kubernetes deve essere utilizzato overlay2 come storage driver per Docker. Non funzionerà con nessun altro.
Quando si utilizza Windows come sistema operativo client, potrebbero verificarsi problemi con il funzionamento del watcher del file system. Questo bug è stato notato quando si lavora con directory di grandi dimensioni, che contengono un numero elevato di file e sottodirectory. Abbiamo creato un issue corrispondente nel progetto syncthing, ma non ci sono stati progressi finora (dall'inizio di luglio).
Utilizzare il file .stignore per specificare i percorsi o i modelli di file che non devono essere sincronizzati (ad esempio, le directory app/cache e .git).
Per impostazione predefinita, ksync riavvierà il contenitore a ogni modifica dei file. Questo è comodo per Node.js, ma del tutto superfluo per PHP. È meglio disattivare opcache e utilizzare il flag --reload=false.
La configurazione può sempre essere corretta in $HOME/.ksync/ksync.yaml.

Squash

Nucleo: esegui il debug dei processi direttamente nel cluster.
GitHub.
Statistiche brevi di GH: 1154 stelle, 279 commit, 23 contributor.
Linguaggio: Go.
Licenza: Apache License 2.0.

Questo strumento è progettato per il debug dei processi direttamente nei pod. L'utilità è semplice e in modalità interattiva consente di scegliere il giusto debugger (vedi sotto) e namespace + pod, nel processo del quale è necessario intervenire. Attualmente sono supportati:

delve - per le applicazioni in Go;
GDB - tramite target remote + port forwarding;
port forwarding JDWP per il debug delle applicazioni Java.

Dalla parte dell'IDE, il supporto esiste solo in VScode (con l'aiuto di estensione), tuttavia nei piani per l'anno corrente (2019) ci sono Eclipse e Intellij.

Per il debug dei processi, Squash avvia un contenitore privilegiato sui nodi del cluster, quindi è necessario prima familiarizzare con le capacità di modalità sicura per evitare problemi di sicurezza.

Soluzioni complesse

Passiamo all'artiglieria pesante: progetti più "scalabili" che mirano a soddisfare subito molte delle esigenze degli sviluppatori.

NB: In questo elenco, certamente, c'è posto anche per il nostro strumento Open Source werf (precedentemente noto come dapp). Tuttavia, abbiamo già scritto e parlato di essa molte volte, quindi abbiamo deciso di non includerla nella panoramica. Per chi desidera conoscerne meglio le funzionalità, consigliamo di leggere/ascoltare la relazione "werf — il nostro strumento per CI/CD in Kubernetes».

DevSpace

Nucleo: per chi vuole iniziare a lavorare in Kubernetes, ma non vuole addentrarsi troppo nelle sue complessità.
GitHub.
Statistiche brevi di GH: 630 stelle, 1912 commit, 13 contributor.
Linguaggio: Go.
Licenza: Apache License 2.0.

Soluzione della società omonima, che fornisce cluster gestiti con Kubernetes per lo sviluppo di team. L'utilità è stata creata per cluster commerciali, ma funziona ottimamente anche con qualsiasi altro.

Quando si esegue il comando devspace init nella directory del progetto, vi verrà chiesto (in modalità interattiva):

di scegliere un cluster Kubernetes attivo,
di utilizzare quello esistente Dockerfile (o di generarne uno nuovo) per creare un contenitore basato su di esso,
di scegliere un repository per memorizzare le immagini dei contenitori e così via.

Dopo tutte queste azioni di preparazione, puoi iniziare lo sviluppo eseguendo il comando devspace dev. Questo raccoglierà il contenitore, lo caricherà nel repository, effettuerà il deployment nel cluster e avvierà il forwarding delle porte e la sincronizzazione del contenitore con la directory locale.

Facoltativamente verrà proposto di accedere al contenitore tramite terminale. Non è consigliabile rifiutare, poiché in realtà il contenitore si avvia con il comando sleep, e per il test reale è necessario avviare manualmente l'applicazione.

Infine, il comando devspace deploy effettua il deployment dell'applicazione e delle relative infrastrutture nel cluster, dopodiché tutto inizia a funzionare in modalità operativa.

Tutta la configurazione del progetto è conservata nel file devspace.yaml. Oltre alle impostazioni dell'ambiente di sviluppo, in esso puoi trovare anche la descrizione dell'infrastruttura, simile ai manifest standard di Kubernetes, ma molto semplificata.

Architettura e principali passaggi di lavoro con DevSpace

Inoltre, è facile aggiungere un componente predefinito al progetto (ad esempio, un DBMS MySQL) o un Helm chart. Leggi di più in documentazione — non è complesso.

Skaffold

Sito; GitHub.
Statistiche brevi di GH: 7423 stelle, 4173 commit, 136 collaboratori.
Linguaggio: Go.
Licenza: Apache License 2.0.

Questo strumento di Google mira a soddisfare tutte le esigenze di uno sviluppatore il cui codice verrà eseguito in un cluster Kubernetes. Iniziare a usarlo non è così semplice come con devspace: qui non ci sono interazioni, definizioni di lingua e creazione automatica Dockerfile non ti verrà proposta.

Tuttavia, se questo non ti spaventa, ecco cosa permette di fare Skaffold:

Monitorare le modifiche al codice sorgente.
Sincronizzarlo con il contenitore del pod, se non richiede compilazione.
Compilare i contenitori con il codice, se il linguaggio di programmazione è interpretato, oppure compilare gli artefatti e impacchettarli nei contenitori.
Controllare automaticamente le immagini risultanti con container-structure-test.
Taggare e caricare le immagini nel Docker Registry.
Distribuire l'applicazione nel cluster utilizzando kubectl, Helm o kustomize.
Effettuare il forwarding delle porte.
Debuggare applicazioni scritte in Java, Node.js, Python.

Il workflow in varie varianti è descritto in modo dichiarativo nel file skaffold.yaml. È possibile anche definire diversi profili per il progetto, nei quali modificare parzialmente o completamente le fasi di costruzione e distribuzione. Ad esempio, per lo sviluppo è possibile specificare un'immagine di base conveniente per gli sviluppatori, mentre per staging e produzione - la minimale (+ utilizzare securityContext per i container oppure ridefinire il cluster in cui l'applicazione verrà distribuita).

La costruzione dei container Docker può avvenire localmente o da remoto: in Google Cloud Build o nel cluster utilizzando Kaniko. Sono supportati anche Bazel e Jib Maven/Gradle. Per il tagging, Skaffold supporta numerose strategie: per hash del commit git, data/ora, somma sha256 dei sorgenti, ecc.

È importante notare la possibilità di testare i container. Il framework già menzionato container-structure-test offre i seguenti metodi di verifica:

Esecuzione di comandi nel contesto del container con tracciamento degli stati di uscita e controllo dell'output testuale del comando.
Verifica della presenza di file nel container e corrispondenza degli attributi a quelli specificati.
Controllo del contenuto dei file attraverso espressioni regolari.
Verifica dei metadati dell'immagine (ENV, ENTRYPOINT, VOLUMES ecc.).
Verifica della compatibilità delle licenze.

La sincronizzazione dei file con il container non avviene nel modo più ottimale: Skaffold crea semplicemente un archivio con i sorgenti, lo copia e lo estrae nel container (deve essere installato tar). Pertanto, se il tuo obiettivo principale è la sincronizzazione del codice, è meglio considerare una soluzione specializzata (ksync).

Fasi principali del lavoro di Skaffold

In generale, lo strumento non permette di astrarsi dai manifest Kubernetes e non ha alcuna interattività, quindi potrebbe sembrare complesso da apprendere. Ma è proprio in questo che risiede il suo vantaggio: una maggiore libertà di azione.

Garden

Sito; GitHub.
Statistiche brevi di GH: 1063 stelle, 1927 commit, 17 contributori.
Lingua: TypeScript (si prevede di suddividere il progetto in diversi componenti, alcuni dei quali saranno in Go, e realizzare un SDK per sviluppare estensioni in TypeScript/JavaScript e Go).
Licenza: Apache License 2.0.

Come Skaffold, Garden è mirato all'automazione dei processi di consegna del codice delle applicazioni nel cluster K8s. Per farlo, è prima necessario descrivere la struttura del progetto in un file YAML, dopodiché eseguire il comando garden dev. Questo eseguirà tutta la magia:

Compilare i container con le varie parti del progetto.
Effettuare test di integrazione e unitari, se stati descritti.
Estrapolerà tutti i componenti del progetto nel cluster.
In caso di modifica del codice sorgente, riavvierà l'intero pipeline.

Questo strumento si concentra principalmente sulla condivisione di un cluster remoto da parte del team di sviluppo. In questo caso, se alcune fasi di costruzione e test sono già state completate, ciò accelera notevolmente l'intero processo, poiché Garden potrà utilizzare i risultati memorizzati nella cache.

Un modulo del progetto può essere un container, un container Maven, un chart Helm, un manifesto per kubectl apply o persino una funzione OpenFaaS. Inoltre, ciascuno di questi moduli può essere estratto da un repository Git remoto. Un modulo può definire (o meno) servizi, compiti e test. I servizi e i compiti possono avere dipendenze, permettendo di definire l'ordine di distribuzione di un certo servizio e di organizzare l’esecuzione di compiti e test.

Garden offre all'utente un bel dashboard (attualmente in fase sperimentale), che mostra un grafico del progetto: componenti, sequenza di costruzione, esecuzione di compiti e test, le loro connessioni e dipendenze. È possibile visualizzare direttamente nel browser anche i log di tutti i componenti del progetto e verificare cosa restituisce ciascun componente via HTTP (se ovviamente è stato dichiarato una risorsa ingress per esso).

Pannello di Garden

Questo strumento ha anche una modalità di hot-reload, che sincronizza semplicemente le modifiche agli script con il container nel cluster, accelerando notevolmente il processo di debug dell'applicazione. Garden ha un buon documentazione e un discreto set di esempi, che consentono di orientarsi rapidamente e di iniziare a utilizzare. Tra l'altro, di recente abbiamo pubblicato la traduzione di un articolo dei suoi autori.

Conclusione

Naturalmente, questo elenco non esaurisce gli strumenti per lo sviluppo e il debug delle applicazioni in Kubernetes. Ci sono molte altre utilità molto utili e pratiche, meritevoli di una menzione se non di un articolo a sé stante. Raccontaci quali strumenti utilizzi, con quali problemi hai dovuto confrontarti e come li hai risolti!

Strumenti per sviluppatori di applicazioni eseguite in Kubernetes