🥇Strumenti per sviluppatori di applicazioni eseguite in Kubernetes

Un approccio moderno alla gestione delle operazioni risolve molte delle questioni urgenti per le aziende. I container e gli orchestratori consentono una facile scalabilità di progetti di qualsiasi complessità, semplificano il rilascio di nuove versioni e ne aumentano l'affidabilità, ma allo stesso tempo creano ulteriori problemi per gli sviluppatori. L'attenzione di un programmatore è prima di tutto rivolta al suo codice: architettura, qualità, prestazioni, eleganza, piuttosto che a come verrà eseguito in Kubernetes e come testarlo e debuggare anche le più piccole modifiche. È quindi del tutto naturale che ci sia una crescente evoluzione degli strumenti per Kubernetes, che aiutano a risolvere i problemi anche dei programmatori più "arcaici" e consentono loro di concentrarsi sulle cose importanti.

Questa panoramica offre una breve introduzione a alcuni strumenti che semplificano la vita ai programmatori il cui codice gira nei pod del cluster Kubernetes.

Strumenti utili

Kubectl-debug

Essenza: aggiungi il tuo container al Pod e osserva cosa succede al suo interno.
GitHub.
Statistiche brevi di GH: 715 stelle, 54 commit, 9 collaboratori.
Linguaggio: Go.
Licenza: Apache License 2.0.

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

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

Questo strumento è semplice ed efficace, quindi può risultare utile a ogni sviluppatore. Abbiamo scritto di più su di esso in un articolo separato.

Telepresence

Essenza: trasferisci l'applicazione sul tuo computer. Sviluppa e fai debugging localmente..
Sito; GitHub.
Statistiche brevi di GH: 2131 stelle, 2712 commit, 33 collaboratori.
Linguaggio: Python.
Licenza: Apache License 2.0.

L'idea di questo strumento è quella di avviare un contenitore con l'applicazione sul computer dell'utente locale e di proxyare tutto il traffico dal cluster a esso e viceversa. Questo approccio consente di sviluppare localmente, modificando semplicemente i file nella propria IDE preferita: i risultati saranno immediatamente disponibili.

I vantaggi del lancio locale includono la facilità di modifica e risultati immediati, con la possibilità di debuggare l'applicazione nel modo consueto. Gli svantaggi riguardano le elevate richieste di velocità di connessione, particolarmente evidenti quando si lavora con applicazioni con un RPS e un traffico considerevoli. Inoltre, Telepresence presenta problemi con i mount dei volumi in Windows, che possono diventare un limite decisivo per gli sviluppatori abituati a questo sistema operativo.

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

Ksync

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

L'utilità consente di sincronizzare il contenuto di una directory locale con la cartella di un container in esecuzione nel cluster. Questo strumento è ideale per gli sviluppatori di linguaggi di scripting, la cui principale preoccupazione è trasferire il codice in un container funzionante. Ksync è progettato per risolvere questo problema.

Con un'inizializzazione singola tramite il comando ksync init Nel cluster viene creato un DaemonSet, utilizzato per monitorare lo stato del filesystem del contenitore selezionato. Sul proprio computer locale, lo sviluppatore esegue il comando ksync watch, che controlla le configurazioni e avvia syncthing, che esegue la sincronizzazione diretta dei file con il cluster.

È necessario istruire ksync su cosa sincronizzare e con cosa. 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 di nome myproject, che cercherà un pod con l'etichetta app=backend e tenterà di sincronizzare la directory locale /home/user/myproject/ con la directory /var/www/myproject/ del contenitore chiamato php.

Problemi e note su ksync dalla nostra esperienza:

Sui nodi del cluster Kubernetes deve essere utilizzato overlay2 come driver di archiviazione per Docker. Nessun altro strumento funzionerà.
Utilizzando Windows come sistema operativo client, è possibile che il watcher del filesystem non funzioni correttamente. Questo bug è stato riscontrato durante l'uso di grandi directory — con un numero elevato di file e directory annidate. Abbiamo creato un problema corrispondente nel progetto syncthing, ma finora non ci sono stati progressi (dall'inizio di luglio).
Utilizza 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 ogni volta che ci sono modifiche ai file. Questo è comodo per Node.js, ma assolutamente superfluo per PHP. È meglio disattivare opcache e usare il flag --reload=false.
La configurazione può sempre essere corretta in $HOME/.ksync/ksync.yaml.

Squash

Essenza: debugga i processi direttamente nel cluster.
GitHub.
Statistiche brevi di GH: 1154 stelle, 279 commit, 23 collaboratori.
Linguaggio: Go.
Licenza: Apache License 2.0.

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

delve — per applicazioni Go;
GDB — tramite target remote + port forwarding;
port forwarding JDWP per il debugging delle applicazioni Java.

Dal lato IDE, il supporto è disponibile solo in VScode (con estensione), ma sono previsti supporto per Eclipse e Intellij nel piano corrente (2019).

Per il debug dei processi, Squash avvia un contenitore privilegiato sui nodi del cluster, quindi è necessario iniziare familiarizzando con le funzionalità del modo sicuro per evitare problemi di sicurezza.

Soluzioni complete

Passiamo ora all'artiglieria pesante: progetti più 'su larga scala' progettati per soddisfare immediatamente molte esigenze dei programmatori.

NB: In questo elenco c'è sicuramente spazio per il nostro strumento Open Source werf (precedentemente noto come dapp). Tuttavia, abbiamo già scritto e parlato di essa, quindi abbiamo deciso di non includerla nella rassegna. Per chi desidera esplorare le sue funzionalità più da vicino, consigliamo di leggere/ascoltare la presentazione "werf — il nostro strumento per CI/CD in Kubernetes».

DevSpace

Essenza: per chi vuole iniziare a lavorare con Kubernetes, ma non vuole addentrarsi troppo nei suoi meandri..
GitHub.
Brevi statistiche di GH: 630 stelle, 1912 commit, 13 contributori.
Linguaggio: Go.
Licenza: Apache License 2.0.

Soluzione dell'omonima azienda che fornisce cluster managed con Kubernetes per lo sviluppo di team. L'utilità è stata creata per cluster commerciali, ma funziona perfettamente anche con qualsiasi altro.

Eseguendo il comando devspace init nella cartella del progetto, ti verrà proposto (in modalità interattiva):

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

Dopo tutti questi passaggi preparatori, è possibile iniziare lo sviluppo eseguendo il comando devspace dev. Questo raccoglierà il contenitore, lo caricherà nel repository, distribuerà il deployment nel cluster e avvierà il forwarding delle porte e la sincronizzazione del contenitore con la directory locale.

Facoltativamente, verrà proposta la possibilità di collegarsi al contenitore tramite terminale. Non è consigliabile rifiutare, poiché in realtà il contenitore si avvia con il comando sleep e per testare realmente l'app è necessario avviarla manualmente.

Infine, il comando devspace deploy distribuisce l'applicazione e l'infrastruttura associata nel cluster, dopo di che tutto inizia a funzionare in modalità operativa.

L'intera configurazione del progetto è memorizzata nel file devspace.yaml. Oltre alle impostazioni ambientali per lo sviluppo, in questo file si può trovare anche la descrizione dell'infrastruttura, simile ai manifesti standard di Kubernetes, ma notevolmente semplificata.

Architettura e principali passaggi per lavorare con DevSpace

Inoltre, è facile aggiungere un componente predefinito al progetto (ad esempio, un database MySQL) o un chart Helm. Maggiori dettagli si trovano in documentazione — è semplice.

Skaffold

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

Questo strumento di Google si propone di coprire tutte le esigenze di un sviluppatore il cui codice verrà eseguito in un cluster Kubernetes. Iniziare a usarlo non è così semplice come con devspace: niente interattività, definizione del linguaggio e autogenerazione Dockerfile non vi verrà offerto qui.

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

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

Il workflow, in varie versioni, è descritto in modo dichiarativo nel file skaffold.yaml. È possibile definire più profili per il progetto, in cui modificare parzialmente o completamente le fasi di build e deployment. Ad esempio, si può specificare un'immagine di base comoda per gli sviluppatori per la sviluppo, mentre per staging e production si può utilizzare una versione minimale (+ utilizzare securityContext per i container o ridefinire il cluster in cui l'applicazione sarà distribuita).

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

Vale la pena 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 tracciando gli exit status e controllando l'output testuale del comando.
Verifica della presenza di file nel container e corrispondenza degli attributi a quelli specificati.
Controllo del contenuto dei file tramite espressioni regolari.
Confronto dei metadati dell'immagine (ENV, ENTRYPOINT, VOLUMES e simili).
Verifica della compatibilità delle licenze.

La sincronizzazione dei file con il contenitore non avviene nel modo più ottimale: Skaffold crea semplicemente un archivio con il codice sorgente, lo copia e lo decomprime nel contenitore (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 consente di astrarsi dai manifest di Kubernetes e non ha alcuna interattività, quindi potrebbe sembrare difficile da apprendere. Ma è proprio questo il suo punto forte: offre una maggiore libertà d'azione.

Garden

Sito; GitHub.
Statistiche brevi di GH: 1063 stelle, 1927 commit, 17 contributori.
Linguaggio: TypeScript (Si prevede di suddividere il progetto in più componenti, alcuni dei quali saranno in Go, e di creare un SDK per lo sviluppo di estensioni in TypeScript/JavaScript e Go).
Licenza: Apache License 2.0.

Come Skaffold, Garden è progettato per automatizzare i processi di distribuzione del codice dell'applicazione nel cluster K8s. Per fare ciò, è necessario prima descrivere la struttura del progetto in un file YAML e poi eseguire il comando garden dev. Questo farà tutta la magia:

Costruirà i contenitori con le varie parti del progetto.
Eseguirà test di integrazione e unitari, se previsti.
Distribuirà tutti i componenti del progetto nel cluster.
In caso di modifica del codice sorgente, riavvierà l'intero pipeline.

L'uso di questo strumento si concentra sulla condivisione collaborativa del cluster remoto da parte del team di sviluppo. In questo caso, se alcune fasi di build e test sono già state completate, questo accelererà 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 manifest per kubectl apply o anche una funzione OpenFaaS. Qualsiasi modulo può essere estratto da un repository Git remoto. Il modulo può definire (o meno) servizi, attività e test. I servizi e le attività possono avere dipendenze, consentendo di definire la sequenza di distribuzione dei vari servizi, ordinare l'esecuzione delle attività e dei test.

Garden fornisce all'utente un bellissimo dashboard (attualmente in stato sperimentale)), che mostra il diagramma del progetto: componenti, sequenza di compilazione, esecuzione di attività e test, le loro relazioni e dipendenze. È possibile visualizzare direttamente nel browser anche i log di tutti i componenti del progetto, controllare cosa restituisce un determinato componente via HTTP (se, naturalmente, è stato dichiarato una risorsa ingress).

Pannello per Garden

Questo strumento ha anche una modalità hot-reload, che sincronizza semplicemente le modifiche degli script con il contenitore nel cluster, accelerando notevolmente il processo di debug dell'applicazione. Garden offre un buon documentazione e soddisfacente insieme di esempi, che permettono di orientarsi rapidamente e iniziare ad utilizzarlo. A proposito, 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 ancora molte utilità utili e pratiche, meritevoli, se non di un articolo a parte, almeno di una menzione. Raccontateci quali strumenti utilizzate, quali problemi avete riscontrato e come li avete risolti!