«Il pericolo è il mio secondo nome», diceva Austin Powers, uomo-mistero di fama internazionale. Ma ciò che è apprezzato dai super agenti e dai servizi segreti non è affatto adatto ai servizi informatici, dove la noia è di gran lunga preferibile ai pericoli.
E Istio insieme a OpenShift e Kubernetes rendono il deployment di microservizi un'attività davvero noiosa e prevedibile – ed è meraviglioso. Di questo e molto altro parleremo nel quarto e ultimo post della serie su Istio.
Quando la noia è giusta
Nel nostro caso, la noia si presenta solo nella fase finale, quando non resta che sedersi e osservare il processo. Ma per questo è necessario configurare tutto in anticipo, e qui vi attende molto di interessante.
Quando si distribuisce una nuova versione del proprio software, è importante considerare tutte le opzioni per ridurre i rischi. Lavorare in parallelo è un metodo di test molto efficace e collaudato, e Istio consente di impiegare un "servizio segreto" (una versione nascosta del proprio microservizio) senza interferire con il funzionamento del sistema di produzione. Esiste anche un termine specifico per questo: "lancio segreto" (Dark Launch), che a sua volta viene attivato da una funzione con un nome altrettanto intrigante: "mirroraggio del traffico".
Nota che nella prima frase del paragrafo precedente si usa il termine «deploy» invece di «release». Dovresti davvero essere in grado di effettuare il deployment – e, naturalmente, utilizzare – il tuo microservizio ogni volta che lo desideri. Questo servizio dovrebbe essere in grado di ricevere e elaborare il traffico, restituire risultati, oltre a registrare nei log e essere monitorato. Tuttavia, non è necessario pubblicare questo servizio in produzione. Deployment e rilascio del software non sono sempre la stessa cosa. Puoi effettuare il deployment ogni volta che vuoi, mentre il rilascio solo quando sei completamente pronto.
Organizzare la noia è interessante
Guarda la seguente regola di routing Istio, che instrada tutte le richieste HTTP al microservizio recommendation v1 (tutti gli esempi sono presi da ), mentre le rispecchia sul microservizio recommendation v2:
Nota l'etichetta mirror: in basso allo schermo – è questa che definisce il mirror del traffico. Sì, è così semplice!
Il risultato di questa regola sarà che il vostro sistema di produzione (v1) continuerà a elaborare le richieste in arrivo, ma queste ultime verranno anche replicate in modo asincrono su v2, cioè lì verranno inviati i loro duplicati completi. In questo modo, potrete testare il funzionamento di v2 in condizioni reali, su dati e traffico autentici, senza interferire con il funzionamento del sistema di produzione. Rende questo processo di testing noioso? Certamente. Ma è fatto in modo interessante.
Aggiungiamo drammaticità
Si prega di notare che nel codice v2 devono essere previste situazioni in cui le richieste in arrivo possono comportare modifiche ai dati. Le richieste stesse vengono replicate facilmente e senza problemi, ma la scelta del metodo di elaborazione nel test rimane a voi – e questo è un po' emozionante.
Ripetiamo un punto importante
Il lancio segreto con la replicazione del traffico (Dark Launch/Request Mirroring) può essere effettuato senza toccare il codice.
Cibo per pensare
E se invece di inviare tutte le richieste su v1, ne inviassimo una parte su v2? Ad esempio, l'uno percento di tutte le richieste o solo quelle da un gruppo specifico di utenti. E poi, osservando come funziona v2, potremmo gradualmente migrare tutte le richieste alla nuova versione. O, al contrario, tornare tutto su v1, se qualcosa con v2 non va. Mi sembra che questo venga chiamato Canary Deployment («canarino» – termine , e se avesse origine russa, probabilmente farebbe riferimento a ), e ora lo esamineremo più da vicino.
Canary Deployment in Istio: semplificare l'implementazione
Con cautela e gradualmente
La sostanza del modello di distribuzione Canary Deployment è estremamente semplice: quando lanciate una nuova versione del vostro software (nel nostro caso un microservizio), iniziate a dare accesso a un piccolo gruppo di utenti. Se tutto va bene, aumentate lentamente questo gruppo fino a quando la nuova versione non inizia a dare problemi, oppure – se ciò non accade – alla fine trasferite tutti gli utenti. Introdurre gradualmente e con attenzione una nuova versione, monitorando il passaggio degli utenti, consente di ridurre i rischi e massimizzare il feedback.
Naturalmente, Istio semplifica il Canary Deployment, offrendo diverse opzioni valide per il routing intelligente delle richieste. E sì, tutto questo può essere fatto senza dover toccare il vostro codice sorgente.
Filtriamo il browser
Uno dei criteri di routing più semplici è il reindirizzamento in base al browser. Supponiamo che vogliate indirizzare le richieste dalla versione 2 solo dai browser Safari. Ecco come si fa:
Applichiamo questa regola di routing e poi con il comando curl simuleremo in un ciclo richieste reali al microservizio. Come si vede nello screenshot, tutte vanno a v1:
E dove sono i segnali su v2? Poiché nel nostro esempio tutte le richieste provenivano solo dalla nostra stessa riga di comando, semplicemente non ci sono. Ma notate le righe in basso dello screenshot sopra: questa è la reazione a una richiesta effettuata dal browser Safari, che ha restituito quanto segue:
Potere illimitato
Abbiamo già scritto che le espressioni regolari offrono possibilità molto potenti per il routing delle richieste. Guardate il seguente esempio (pensiamo che possiate capire da soli cosa fa):
Ora, probabilmente avete già un'idea di cosa siano capaci le espressioni regolari.
Agisci con intelligenza
Il routing intelligente, in particolare la gestione degli header dei pacchetti con l'uso di espressioni regolari, consente di gestire il traffico come desideri. E questo semplifica notevolmente l'implementazione di nuovo codice: è semplice, non richiede modifiche al codice stesso e, se necessario, tutto può essere rapidamente ripristinato com'era.
Sei interessato?
Hai voglia di sperimentare con Istio, Kubernetes e OpenShift sul tuo computer? Il team ha preparato un ottimo a questo proposito ho reso disponibili al pubblico tutti i file associati. Quindi andate avanti, e non negatevi nulla.
Istio Egress: uscita attraverso il negozio di souvenir
Utilizzando Istio insieme a Red Hat OpenShift e Kubernetes, è possibile semplificare notevolmente la gestione dei microservizi. La service mesh Istio è integrata all'interno dei pod di Kubernetes, mentre il tuo codice viene eseguito (principalmente) isolatamente. Prestazioni, facilità di modifica, tracciamento e altro – tutto ciò è facilmente utilizzabile grazie all'uso dei container sidecar. Ma cosa fare se il tuo microservizio deve comunicare con altri servizi situati al di fuori del tuo sistema OpenShift-Kubernetes?
Qui entra in gioco Istio Egress. In breve, consente di accedere alle risorse (leggi: "servizi") che non fanno parte del tuo sistema di pod Kubernetes. Senza configurazioni aggiuntive, in un ambiente Istio Egress il traffico viene instradato solo all'interno del cluster di pod e tra tali cluster in base alle tabelle IP interne. E questa segmentazione funziona perfettamente finché non hai bisogno di accesso a servizi esterni.
Egress consente di bypassare le tabelle IP sopra menzionate, sia sulla base delle regole Egress che per un intervallo di indirizzi IP.
Supponiamo di avere un programma Java che effettua una richiesta GET a httpbin.org/headers.
(httpbin.org è semplicemente una risorsa utile per testare le richieste di servizio in uscita.)
Se inseriamo nel terminale curl http://httpbin.org/headers, vedremo quanto segue:
Oppure possiamo aprire lo stesso indirizzo nel browser:
Come possiamo vedere, il servizio lì presente restituisce semplicemente gli header a lui inviati.
Sostituzione diretta
Ora prendiamo il codice Java di questo servizio esterno rispetto al nostro sistema e lo eseguiamo da noi, dove, ricordiamo, è presente Istio. (Puoi farlo tu stesso consultando il .) Creando l'immagine appropriata e avviandola sulla piattaforma OpenShift, chiameremo questo servizio con il comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, dopo di che vedremo sullo schermo quanto segue:
Oh no, cosa è successo? Funzionava solo poco fa. Cosa significa Not Found? Abbiamo appena configurato curl.
Ampliamo le tabelle IP per l'intero internet.
Dobbiamo ringraziare (o incolpare) Istio per questo. Infatti, Istio è semplicemente un container sidecar, che si occupa della scoperta e del routing (e di molte altre cose di cui abbiamo parlato in precedenza). Per questo motivo, le tabelle IP sanno solo quello che si trova all'interno del proprio cluster. E httpbin.org si trova all'esterno, e quindi non è accessibile. Qui entra in gioco Istio Egress – senza alcuna modifica nel vostro codice sorgente.
La regola Egress riportata di seguito costringe Istio a cercare (se necessario, anche in tutto il web) il servizio richiesto, in questo caso, httpbin.org. Come si può vedere da questo file (egress_httpbin.yml), la funzionalità è piuttosto semplice:
Rimane solo da applicare questa regola:
istioctl create -f egress_httpbin.yml -n istioegress
È possibile visualizzare le regole Egress con il comando istioctl get egressrules:
E infine, rieseguiamo il comando curl – e vediamo che tutto funziona:
Pensiamo in modo aperto
Come potete vedere, Istio consente di organizzare l'interazione con il mondo esterno. In altre parole, potete continuare a creare servizi OpenShift e gestirli tramite Kubernetes, mantenendo tutto nei pod, che si scalano su e giù secondo necessità. E inoltre, potete tranquillamente accedere a servizi esterni rispetto al vostro ambiente. E sì, ripetiamo, tutto questo è possibile senza toccare il vostro codice.
Questo è stato l'ultimo post della serie su Istio. Restate con noi: ci sono molte cose interessanti in arrivo!
Fonte: habr.com
