🥇Strumenti per sviluppatori di applicazioni in esecuzione su Kubernetes

Un approccio moderno alle operazioni risolve molti problemi aziendali urgenti. Contenitori e orchestratori facilitano la scalabilità di progetti di qualsiasi complessità, semplificano il rilascio di nuove versioni, li rendono più affidabili, ma allo stesso tempo creano ulteriori problemi agli sviluppatori. Il programmatore, prima di tutto, si preoccupa del suo codice: architettura, qualità, prestazioni, eleganza - e non come funzionerà in Kubernetes e come testarlo ed eseguirne il debug dopo aver apportato modifiche anche minime. Pertanto, è anche del tutto naturale che vengano sviluppati attivamente strumenti per Kubernetes, che aiutano a risolvere i problemi anche degli sviluppatori più "arcaici" e consentono loro di concentrarsi sulla cosa principale.

Questa recensione fornisce brevi informazioni su alcuni degli strumenti che semplificano la vita a un programmatore il cui codice viene eseguito nel pod'ax di un cluster Kubernetes.

Aiutanti semplici

Kubectl-debug

La linea di fondo: aggiungi il tuo contenitore a un pod e guarda cosa succede al suo interno.
GitHub.
Brevi statistiche GH: 715 stelle, 54 commit, 9 contributori.
Lingua: vai.
Licenza: Licenza Apache 2.0.

Questo plugin per kubectl permette di creare un contenitore aggiuntivo all'interno del pod di interesse, che condividerà lo spazio dei nomi del processo con altri contenitori. In esso puoi eseguire il debug del funzionamento del pod: controllare la rete, ascoltare il traffico di rete, eseguire una traccia del processo di interesse, ecc.

È anche possibile passare al contenitore del processo eseguendo chroot /proc/PID/root - questo può essere molto comodo quando è necessario ottenere una shell di root in un contenitore per il quale è impostata nel manifest securityContext.runAs.

Lo strumento è semplice ed efficace, quindi può essere utile a ogni sviluppatore. Ne abbiamo scritto di più in articolo separato.

Telepresence

La linea di fondo: trasferisci l'applicazione sul tuo computer. Sviluppare ed eseguire il debug localmente.
sito web; GitHub.
Brevi statistiche di GH: 2131 stelle, 2712 commit, 33 contributori.
Linguaggio: Pitone.
Licenza: Licenza Apache 2.0.

L'idea di questo snap-in è di avviare un contenitore con l'applicazione sul computer dell'utente locale e inoltrare tutto il traffico dal cluster ad esso e viceversa. Questo approccio ti consente di sviluppare localmente semplicemente modificando i file nel tuo IDE preferito: i risultati saranno immediatamente disponibili.

I vantaggi dell'esecuzione locale sono la comodità di modifiche e risultati immediati, la possibilità di eseguire il debug dell'applicazione nel solito modo. Lo svantaggio è che richiede velocità di connessione, il che è particolarmente evidente quando si lavora con un'applicazione con RPS e traffico piuttosto elevati. Inoltre la Telepresence ha problemi con il montaggio del volume su Windows, il che può rappresentare un limite decisivo per gli sviluppatori abituati a questo sistema operativo.

Abbiamo già condiviso la nostra esperienza nell'utilizzo della Telepresenza qui.

Ksync

La linea di fondo: sincronizzazione quasi istantanea del codice con il contenitore nel cluster.
GitHub.
Brevi statistiche GH: 555 stelle, 362 commit, 11 contributori.
Lingua: vai.
Licenza: Licenza Apache 2.0.

L'utilità consente di sincronizzare il contenuto di una directory locale con la directory di un contenitore in esecuzione nel cluster. Tale strumento è perfetto per gli sviluppatori di linguaggi di programmazione di scripting, il cui problema principale è fornire il codice a un contenitore in esecuzione. Ksync è progettato per alleviare questo mal di testa.

Quando inizializzato una volta dal comando ksync init Nel cluster viene creato un DaemonSet che viene utilizzato per monitorare lo stato del file system del container selezionato. Sul suo computer locale, lo sviluppatore esegue il comando ksync watch, che monitora le configurazioni e le esecuzioni syncthing, che sincronizza direttamente i file con il cluster.

Tutto ciò che resta è istruire ksync su cosa sincronizzare con cosa. Ad esempio, questo comando:

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

...creerà un osservatore denominato myprojectche cercherà un pod con un'etichetta app=backend e prova a sincronizzare la directory locale /home/user/myproject/ con catalogo /var/www/myproject/ al contenitore chiamato php.

Problemi e note su ksync dalla nostra esperienza:

Deve essere utilizzato sui nodi del cluster Kubernetes overlay2 come driver di archiviazione per Docker. L'utilità non funzionerà con nessun altro.
Quando si utilizza Windows come sistema operativo client, il watcher del file system potrebbe non funzionare correttamente. Questo bug è stato notato quando si lavora con directory di grandi dimensioni, con un gran numero di file e directory nidificati. Abbiamo creato questione rilevante nel progetto syncthing, ma non ci sono ancora progressi (dall'inizio di luglio).
Usa file .stignore per specificare percorsi o modelli di file che non devono essere sincronizzati (ad esempio, directory app/cache и .git).
Per impostazione predefinita, ksync riavvierà il contenitore ogni volta che i file cambiano. Per Node.js questo è conveniente, ma per PHP è completamente inutile. È meglio disattivare opcache e utilizzare il flag --reload=false.
La configurazione può sempre essere corretta $HOME/.ksync/ksync.yaml.

Squash

La linea di fondo: eseguire il debug dei processi direttamente nel cluster.
GitHub.
Brevi statistiche di GH: 1154 stelle, 279 commit, 23 contributori.
Lingua: vai.
Licenza: Licenza Apache 2.0.

Questo strumento è progettato per eseguire il debug dei processi direttamente nei pod. L'utilità è semplice e consente di selezionare in modo interattivo il debugger desiderato (vedi sotto) e namespace + pod, nel processo del quale è necessario intervenire. Attualmente supportato:

delve: per le applicazioni Go;
GDB - tramite destinazione remota + port forwarding;
Inoltro porta JDWP per il debug delle applicazioni Java.

Sul lato IDE, il supporto è disponibile solo in VScode (utilizzando espansione), tuttavia, i piani per l'anno in corso (2019) includono Eclipse e Intellij.

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

Soluzioni complete

Passiamo all'artiglieria pesante: progetti più “su larga scala” progettati per soddisfare immediatamente molte delle esigenze degli sviluppatori.

NB: In questa lista, ovviamente, c'è posto per la nostra utility Open Source werf (precedentemente noto come dapp). Ne abbiamo però già scritto e parlato più di una volta, e quindi abbiamo deciso di non inserirlo nella recensione. Per chi volesse approfondire le sue potenzialità consigliamo la lettura/ascolto del report “werf è il nostro strumento per CI/CD in Kubernetes'.

Spazio di sviluppo

La linea di fondo: per coloro che vogliono iniziare a lavorare in Kubernetes, ma non vogliono addentrarsi nella sua giungla.
GitHub.
Brevi statistiche di GH: 630 stelle, 1912 commit, 13 contributori.
Lingua: vai.
Licenza: Licenza Apache 2.0.

Una soluzione dell'omonima azienda che mette a disposizione cluster gestiti con Kubernetes per lo sviluppo del team. L'utilità è stata creata per i cluster commerciali, ma funziona perfettamente con tutti gli altri.

Quando si esegue il comando devspace init nel catalogo dei progetti ti verranno proposti (in modo interattivo):

seleziona un cluster Kubernetes funzionante,
utilizzare esistente Dockerfile (o generarne uno nuovo) per creare un contenitore basato su di esso,
selezionare un repository per archiviare le immagini del contenitore, ecc.

Dopo tutti questi passaggi preparatori, puoi avviare lo sviluppo eseguendo il comando devspace dev. Costruirà il contenitore, lo caricherà nel repository, distribuirà la distribuzione al cluster e avvierà il port forwarding e la sincronizzazione del contenitore con la directory locale.

Facoltativamente, ti verrà richiesto di spostare il terminale nel contenitore. Non dovresti rifiutare, perché in realtà il contenitore si avvia con il comando sleep e per testare realmente l'applicazione è necessario avviare manualmente.

Infine, la squadra devspace deploy distribuisce l'applicazione e l'infrastruttura associata al cluster, dopodiché tutto inizia a funzionare in modalità combattimento.

Tutta la configurazione del progetto è memorizzata in un file devspace.yaml. Oltre alle impostazioni dell'ambiente di sviluppo, puoi trovare anche una descrizione dell'infrastruttura al suo interno, simile ai manifest Kubernetes standard, solo notevolmente semplificata.

Architettura e fasi principali del lavoro con DevSpace

Inoltre, è semplice aggiungere al progetto un componente predefinito (ad esempio un DBMS MySQL) o un grafico Helm. Leggi di più in documentazione - non è complicato.

Scaffold

sito web; GitHub.
Brevi statistiche di GH: 7423 stelle, 4173 commit, 136 contributori.
Lingua: vai.
Licenza: Licenza Apache 2.0.

Questa utility di Google afferma di coprire tutte le esigenze di uno sviluppatore il cui codice verrà in qualche modo eseguito su un cluster Kubernetes. Iniziare a usarlo non è facile come devspace: nessuna interattività, rilevamento della lingua e creazione automatica Dockerfile non te lo offriranno qui.

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

Tieni traccia delle modifiche al codice sorgente.
Sincronizzalo con il contenitore della pod se non necessita di montaggio.
Raccogli contenitori con codice, se il linguaggio viene interpretato, oppure compila artefatti e impacchettali in contenitori.
Le immagini risultanti vengono controllate automaticamente utilizzando test della struttura del contenitore.
Taggare e caricare immagini nel registro Docker.
Distribuisci un'applicazione in un cluster utilizzando kubectl, Helm o kustomize.
Eseguire il port forwarding.
Debug di applicazioni scritte in Java, Node.js, Python.

Il flusso di lavoro in varie varianti è descritto in modo dichiarativo nel file skaffold.yaml. Per un progetto è inoltre possibile definire diversi profili in cui è possibile modificare parzialmente o completamente le fasi di assemblaggio e distribuzione. Ad esempio, per lo sviluppo, specificare un'immagine di base conveniente per lo sviluppatore e per la gestione temporanea e la produzione, un'immagine minima (+ use securityContext contenitori o ridefinire il cluster in cui verrà distribuita l'applicazione).

I contenitori Docker possono essere creati localmente o in remoto: in Creazione Google Cloud o in un cluster utilizzando Kaniko. Sono supportati anche Bazel e Jib Maven/Gradle. Per i tag, Skaffold supporta molte strategie: tramite hash git commit, data/ora, somma sha256 delle fonti, ecc.

Separatamente, vale la pena notare la possibilità di testare i contenitori. Il già citato framework container-structure-test offre i seguenti metodi di verifica:

Esecuzione di comandi nel contesto di un contenitore con tracciamento degli stati di uscita e controllo dell'output testuale del comando.
Verifica della presenza di file nel contenitore e corrispondenza con gli attributi specificati.
Controllo del contenuto dei file utilizzando espressioni regolari.
Verifica dei metadati dell'immagine (ENV, ENTRYPOINT, VOLUMES ecc).
Verifica della compatibilità della licenza.

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

Fasi principali dell'operazione Skaffold

In generale, lo strumento non consente di astrarre dai manifest Kubernetes e non ha alcuna interattività, quindi potrebbe sembrare difficile da padroneggiare. Ma questo è anche il suo vantaggio: una maggiore libertà d'azione.

Garden

sito web; GitHub.
Brevi statistiche GH: 1063 stelle, 1927 commit, 17 contributori.
Linguaggio: dattiloscritto (si prevede di dividere il progetto in diversi componenti, alcuni dei quali saranno in Go, e anche di creare un SDK per creare componenti aggiuntivi in TypeScript/JavaScript e Go).
Licenza: Licenza Apache 2.0.

Come Skaffold, Garden mira ad automatizzare i processi di distribuzione del codice dell'applicazione al cluster K8. Per fare ciò, devi prima descrivere la struttura del progetto in un file YAML, quindi eseguire il comando garden dev. Farà tutta la magia:

Raccogli contenitori con varie parti del progetto.
Conduce test di integrazione e unitari, se descritti.
Distribuisce tutti i componenti del progetto al cluster.
Se il codice sorgente cambia, riavvierà l'intera pipeline.

L'obiettivo principale dell'utilizzo di questo strumento è condividere un cluster remoto con un team di sviluppo. In questo caso, se alcune fasi di creazione e test sono già state eseguite, ciò accelererà notevolmente l'intero processo, poiché Garden sarà in grado di utilizzare i risultati memorizzati nella cache.

Un modulo di progetto può essere un contenitore, un contenitore Maven, un grafico Helm, un manifest per kubectl apply o anche una funzione OpenFaaS. Inoltre, qualsiasi modulo può essere estratto da un repository Git remoto. Un modulo può definire o meno servizi, attività e test. Servizi e attività possono avere dipendenze, quindi è possibile determinare la sequenza di distribuzione di un particolare servizio e organizzare l'avvio di attività e test.

Garden fornisce all'utente una bellissima dashboard (attualmente in stato sperimentale), che visualizza il grafico del progetto: componenti, sequenza di assemblaggio, esecuzione di attività e test, le loro connessioni e dipendenze. Direttamente nel browser, puoi visualizzare i log di tutti i componenti del progetto e verificare cosa restituisce un particolare componente tramite HTTP (se, ovviamente, viene dichiarata una risorsa di ingresso per esso).

Pannello per Giardino

Questo strumento dispone anche di una modalità di ricaricamento a caldo, che sincronizza semplicemente le modifiche dello script con il contenitore nel cluster, accelerando notevolmente il processo di debug dell'applicazione. Il giardino ne ha uno bello la documentazione e non male serie di esempi, permettendoti di abituarti rapidamente e iniziare a usarlo. A proposito, proprio di recente abbiamo pubblicato traduzione dell'articolo dai suoi autori.

conclusione

Naturalmente, questo elenco di strumenti per lo sviluppo e il debug di applicazioni in Kubernetes non è limitato a. Ci sono molte altre utilità molto utili e pratiche che meritano, se non un articolo separato, almeno una menzione. Raccontaci cosa usi, quali problemi hai riscontrato e come li hai risolti!

Strumenti per sviluppatori di applicazioni in esecuzione su Kubernetes