Abbiamo illustrato in un precedente articolo cosa sono Kubernetes, i container ed i Pod. In questo affronteremo alcuni comuni design pattern per lo sviluppo modulare di applicativi.
Sidecar Container
I Sidecar Container estendono e migliorare il container principale, in pratica partendo da un container esistente lo migliorano. Per esempio considera un container in cui viene eseguita un’istanza di Nginx web server ed un altro container che sincronizza il file system con un repository git, ne condivide il file system così da avere un sistema push-to-deploy.
Così facendo hai realizzato un sistema modulare in cui in sincronizzatore può essere sviluppato da personale differente ed inoltre può essere riutilizzato per altri Web Server. Grazie questa modularità puoi lavorare sul sincronizzatore solo una volta e reimpiegarlo in numerose applicazioni.
Ambassador Container
Un ambassador container fa da proxy per un connessione locale verso l’esterno. Per esempio considera un cluster Redis con diverse repliche in modalità lettura ed un singolo master in modalità scrittura. In questo caso puoi creare un Pod che raggruppa l’applicazione principale con un ambassador container. Quest’ultimo container è responsabile dell’aggiornamento degli shards Redis.
Poichè questi due container condividono lo spazio di rete e quindi l’indirizzo IP, l’applicazione può aprire una connessione locale ed utilizzare direttamente il proxy. In pratica sarebbe come avere il server Redis che gira in locale. Anche in questo caso la modularità semplifica lo sviluppo e la scalabilità.
Adapter Container
Gli Adapter Container standardizzano e normalizzano gli output. Per esempio considera l’attività di monitorare diverse applicazioni ed ogni applicazione è costruita in modo da esportare dati in modalità differenti ma ogni sistema di monitoraggio vuole dati consistenti per essere gestiti.
Grazie all’utilizzo del pattern composito di Adapter Container puoi trasformare dati eterogenei di diversi sistemi in dati unificati semplicemente creando dei Pod che raggruppano i container applicativi con l’adapter.
Poichè nel Pod vengono condivisi namespace e file system la coordinazione tra i vari container è immediata e semplice.
Conclusioni e Glue Labs
Nelle casistiche presentate abbiamo usato i container come confini astratti che ci permettono di costruire componenti modulari e riusabili ed è uno dei tanti pregi di Kubernetes e dei Pod.
Poi provare Kubernetes con il nostro servizio di Hosting Google Cloud con consulenza gratuita, inoltre possiamo fornirti supporto ed assistenza nella creazione, implementazione di container e di cluster di Pod. Contattaci subito senza impegno per maggiori informazioni.
