«Il pericolo è il mio secondo nome», diceva Austin Powers, uomo-mistero di portata internazionale. Ma ciò che è apprezzato dai super agenti e dai servizi segreti non si adatta affatto ai servizi informatici, dove la noia è di gran lunga migliore dei pericoli.
E Istio insieme a OpenShift e Kubernetes rendono il dispiegamento dei microservizi un compito davvero noioso e prevedibile – e questo è fantastico. 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 verifica solo nella fase finale, quando non resta che sedersi e osservare il processo. Ma per questo è necessario configurare tutto in anticipo, e qui troverete molte cose interessanti.
Quando si dispiega una nuova versione del proprio software, è bene considerare tutte le opzioni per minimizzare i rischi. Lavorare in modalità parallela è un metodo molto potente e collaudato per il testing, e Istio consente di utilizzare per questo una 'servizio segreto' (versione nascosta del proprio microservizio) senza interferire con il funzionamento del sistema di produzione. Esiste anche un termine apposito – 'Lancio Segreto' (Dark Launch), che a sua volta viene attivato dalla funzionalità dal nome non meno spionistico 'mirroraggio del traffico'.
Fate attenzione, nella prima frase del paragrafo precedente si utilizza il termine 'dispiegamento' (deploy) e non 'lancio' (release). Dovete davvero poter dispiegare – e, naturalmente, utilizzare – il vostro microservizio ogni volta che lo desiderate. Questo servizio deve essere in grado di ricevere e elaborare il traffico, restituire risultati, e scrivere nei log e essere monitorato. Ma non è affatto necessario che il servizio venga rilasciato in produzione. Il dispiegamento e il rilascio del software non sono sempre la stessa cosa. Può essere effettuato un dispiegamento ogni volta che lo si desidera, mentre il rilascio è possibile solo quando si è definitivamente pronti.
Organizzare la noia è interessante
Date un'occhiata alla seguente regola di instradamento di Istio, che indirizza tutte le richieste HTTP al microservizio recommendation v1 (tutti gli esempi sono tratti da ), mentre le specchia sul microservizio recommendation v2:
Fate attenzione all'etichetta mirror: in fondo allo schermo – è proprio questa che definisce il mirroraggio del traffico. Sì, è davvero così semplice!
Il risultato dell'applicazione di questa regola sarà che il vostro sistema di produzione (v1) continuerà a gestire le richieste in arrivo, ma queste richieste verranno mirrorate in modo asincrono su v2, ovvero verranno inviate delle loro copie complete. In questo modo, potrete testare il funzionamento di v2 in condizioni reali – con dati e traffico autentici – senza interferire con il funzionamento del sistema di produzione. Questo rende l'organizzazione dei test noiosa? Sì, senza dubbio. Ma è fatto in modo interessante.
Aggiungiamo un po' di dramma
Si prega di notare che nel codice di v2 è necessario prevedere situazioni in cui le richieste in arrivo possano comportare modifiche ai dati. Le richieste stesse vengono mirrorate facilmente e in modo trasparente, ma la scelta del modo in cui elaborarle nei test rimane a voi – e questo è un po' eccitante.
Ripetiamo un punto importante
Il rilascio segreto con mirroraggio del traffico (Dark Launch/Request Mirroring) può essere effettuato senza toccare il codice.
Cibo per pensare
E se invece di mirrorare tutte le richieste le si inviasse parzialmente non a v1, ma a v2? Ad esempio, un percento di tutte le richieste o solo quelle provenienti da un determinato gruppo di utenti. E poi, osservando come funziona v2, si potrebbe gradualmente trasferire tutte le richieste alla nuova versione. Oppure, al contrario, riportare tutto su v1 se qualcosa non funziona in v2. Sembra che questo venga chiamato Canary Deployment ("distribuzione canarino" – un termine , e se avesse origini russe, probabilmente conteneva un riferimento a ), e ora lo esamineremo più nel dettaglio.
Canary Deployment in Istio: semplifichiamo il rollout
Con cautela e gradualmente
Il concetto del modello di distribuzione Canary Deployment è estremamente semplice: al momento del lancio di una nuova versione del proprio software (nel nostro caso – del microservizio) si concede prima l'accesso a un piccolo gruppo di utenti. Se tutto procede bene, si aumenta lentamente questo gruppo finché la nuova versione non inizia a dare problemi, o – se non succede – alla fine si trasferiscono tutti gli utenti. Introducendo nel sistema la nuova versione con attenzione e gradualmente, e switchando in modo controllato gli utenti, è possibile ridurre i rischi e massimizzare il feedback.
Naturalmente, Istio semplifica il Canary Deployment, offrendo diverse ottime opzioni per il routing intelligente delle richieste. E sì, tutto questo può essere fatto senza toccare il vostro codice sorgente.
Filtriamo il browser
Uno dei criteri di routing più semplici è il reindirizzamento in base al browser. Supponiamo che vogliate che solo le richieste dai browser Safari vengano instradate a v2. 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:
Ma dov'è il traffico a v2? Poiché nel nostro esempio tutte le richieste sono state effettuate dalla nostra riga di comando, non ce n'è affatto. Ma notate le righe inferiori nello schermo sopra: è la reazione a una richiesta eseguita dal browser Safari, che ha restituito quanto segue:
Potere illimitato
Abbiamo già scritto che le espressioni regolari offrono enormi possibilità per il routing delle richieste. Guardate il seguente esempio (pensiamo che voi capiate già cosa fa):
Ora probabilmente avete già un'idea del potenziale delle espressioni regolari.
Agite con intelligenza
Il routing intelligente, in particolare la gestione degli header dei pacchetti utilizzando espressioni regolari, consente di gestire il traffico come desiderate. E questo semplifica notevolmente l'introduzione di nuovo codice: è semplice, non richiede modifiche al codice stesso e, se necessario, si può facilmente tornare indietro.
Interessati?
Avete voglia di sperimentare con Istio, Kubernetes e OpenShift sul vostro computer? Il team ha preparato un ottimo su questo argomento e ha reso disponibili tutti i file correlati. Quindi andate avanti e non trattenetevi.
Istio Egress: uscita attraverso il negozio di souvenir
Utilizzando Istio insieme a Red Hat OpenShift e Kubernetes, è possibile semplificarsi notevolmente la vita con i microservizi. La service mesh di Istio è incapsulata all'interno dei pod di Kubernetes, mentre il vostro codice viene eseguito (principalmente) in isolamento. Prestazioni, semplicità di modifica, tracciabilità e altro - tutto ciò è facilmente gestibile proprio grazie all'uso di container sidecar. Ma cosa fare se il vostro microservizio deve comunicare con altri servizi che si trovano al di fuori del vostro sistema OpenShift-Kubernetes?
Qui entra in gioco Istio Egress. In poche parole, consente di accedere a risorse (leggi: «servizi») che non fanno parte dei tuoi pod Kubernetes. Se non vengono effettuate ulteriori configurazioni, 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. Questo isolamento funziona perfettamente finché non hai bisogno di accedere ai servizi esterni.
Egress consente di aggirare le tabelle IP sopra citate, sia sulla base di regole Egress, sia per un intervallo di indirizzi IP.
Immagina di avere un programma Java che effettua una richiesta GET a httpbin.org/headers.
(httpbin.org è semplicemente una risorsa utile per testare le richieste dei servizi in uscita.)
Se inseriamo nella riga di comando curl http://httpbin.org/headers, vedremo quanto segue:
Oppure puoi aprire lo stesso indirizzo nel browser:
Come vediamo, il servizio lì presente restituisce semplicemente gli header che gli sono stati inviati.
Facciamo un cambio radicale
Ora prendiamo il codice Java di questo servizio esterno rispetto al nostro sistema ed eseguiamolo localmente, dove, ricordiamo, è installato Istio. (Puoi farlo autonomamente consultando il .) Una volta costruita l'immagine appropriata e avviata sulla piattaforma OpenShift, invocheremo questo servizio con il comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, dopodiché vedremo sullo schermo questo:
Oh, cosa è successo? Funzionava solo poco fa. Cosa significa Not Found? Abbiamo appena creato per esso curl.
Espandiamo le tabelle IP a tutto internet
È colpa (o merito) di Istio. Infatti, Istio consiste semplicemente in contenitori sidecar che si occupano della scoperta e del routing (e di molte altre cose di cui abbiamo parlato in precedenza). Per questo motivo, le tabelle IP conoscono solo ciò che si trova all'interno del tuo sistema di cluster. E httpbin.org si trova all'esterno e, di conseguenza, non è accessibile. E qui interviene Istio Egress, senza alcuna modifica al tuo codice sorgente.
La seguente regola Egress 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à qui è abbastanza semplice:
Rimane solo da applicare questa regola:
istioctl create -f egress_httpbin.yml -n istioegress
Puoi visualizzare le regole Egress con il comando istioctl get egressrules:
E infine, avviamo di nuovo il comando curl – e vediamo che tutto funziona:
Pensiamo in modo aperto
Come vedete, Istio consente di organizzare l'interazione anche con il mondo esterno. In altre parole, potete continuare a creare servizi OpenShift e gestirli tramite Kubernetes, mantenendo tutto all'interno dei pod che scalano verso l'alto e verso il basso a seconda delle necessità. E mentre lo fate, potete tranquillamente accedere ai servizi esterni rispetto al vostro ambiente. E sì, ripetiamo ancora una volta che tutto questo può essere fatto senza toccare il vostro codice.
Questo è stato l'ultimo post di una serie su Istio. Restate con noi – ci sono molte altre cose interessanti in arrivo!
Fonte: habr.com
