{"id":56218,"date":"2020-02-07T00:00:00","date_gmt":"2020-02-06T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/dark-launch-v-istio-sekretnye-sluzhby"},"modified":"2020-02-18T14:04:26","modified_gmt":"2020-02-18T11:04:26","slug":"dark-launch-v-istio-sekretnye-sluzhby","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dark-launch-v-istio-sekretnye-sluzhby","title":{"rendered":"Dark Launch in Istio: servizi segreti","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00abIl pericolo \u00e8 il mio secondo nome\u00bb, diceva Austin Powers, uomo-mistero di portata internazionale. Ma ci\u00f2 che \u00e8 apprezzato dai super agenti e dai servizi segreti non si adatta affatto ai servizi informatici, dove la noia \u00e8 di gran lunga migliore dei pericoli. <\/p>\n

\"Dark
\n
\nE Istio insieme a OpenShift e Kubernetes rendono il dispiegamento dei microservizi un compito davvero noioso e prevedibile \u2013 e questo \u00e8 fantastico. Di questo e molto altro parleremo nel quarto e ultimo post della serie su Istio.
\n<\/a><\/noindex><\/p>\n

Quando la noia \u00e8 giusta<\/h3>\n

\nNel nostro caso, la noia si verifica solo nella fase finale, quando non resta che sedersi e osservare il processo. Ma per questo \u00e8 necessario configurare tutto in anticipo, e qui troverete molte cose interessanti.<\/p>\n

Quando si dispiega una nuova versione del proprio software, \u00e8 bene considerare tutte le opzioni per minimizzare i rischi. Lavorare in modalit\u00e0 parallela \u00e8 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 \u2013 'Lancio Segreto' (Dark Launch), che a sua volta viene attivato dalla funzionalit\u00e0 dal nome non meno spionistico 'mirroraggio del traffico'.<\/p>\n

Fate attenzione, nella prima frase del paragrafo precedente si utilizza il termine 'dispiegamento' (deploy) e non 'lancio' (release). Dovete davvero poter dispiegare \u2013 e, naturalmente, utilizzare \u2013 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 \u00e8 affatto necessario che il servizio venga rilasciato in produzione. Il dispiegamento e il rilascio del software non sono sempre la stessa cosa. Pu\u00f2 essere effettuato un dispiegamento ogni volta che lo si desidera, mentre il rilascio \u00e8 possibile solo quando si \u00e8 definitivamente pronti.<\/p>\n

Organizzare la noia \u00e8 interessante<\/h3>\n

\nDate 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 Istio Tutorial GitHub repo<\/a><\/noindex>), mentre le specchia sul microservizio recommendation v2:<\/p>\n

\"Dark
\nFate attenzione all'etichetta mirror:<\/code> in fondo allo schermo \u2013 \u00e8 proprio questa che definisce il mirroraggio del traffico. S\u00ec, \u00e8 davvero cos\u00ec semplice!<\/p>\n

Il risultato dell'applicazione di questa regola sar\u00e0 che il vostro sistema di produzione (v1) continuer\u00e0 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 \u2013 con dati e traffico autentici \u2013 senza interferire con il funzionamento del sistema di produzione. Questo rende l'organizzazione dei test noiosa? S\u00ec, senza dubbio. Ma \u00e8 fatto in modo interessante.<\/p>\n

Aggiungiamo un po' di dramma<\/h3>\n

\nSi prega di notare che nel codice di v2 \u00e8 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 \u2013 e questo \u00e8 un po' eccitante.<\/p>\n

Ripetiamo un punto importante <\/h3>\n

\nIl rilascio segreto con mirroraggio del traffico (Dark Launch\/Request Mirroring) pu\u00f2 essere effettuato senza toccare il codice.<\/p>\n

Cibo per pensare<\/h3>\n

\nE 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\" \u2013 un termine che risale all'industria mineraria<\/a><\/noindex>, e se avesse origini russe, probabilmente conteneva un riferimento a gatti<\/a><\/noindex>), e ora lo esamineremo pi\u00f9 nel dettaglio.<\/p>\n

Canary Deployment in Istio: semplifichiamo il rollout<\/h2>\n

<\/p>\n

Con cautela e gradualmente<\/h3>\n

\nIl concetto del modello di distribuzione Canary Deployment \u00e8 estremamente semplice: al momento del lancio di una nuova versione del proprio software (nel nostro caso \u2013 del microservizio) si concede prima l'accesso a un piccolo gruppo di utenti. Se tutto procede bene, si aumenta lentamente questo gruppo finch\u00e9 la nuova versione non inizia a dare problemi, o \u2013 se non succede \u2013 alla fine si trasferiscono tutti gli utenti. Introducendo nel sistema la nuova versione con attenzione e gradualmente, e switchando in modo controllato gli utenti, \u00e8 possibile ridurre i rischi e massimizzare il feedback.<\/p>\n

Naturalmente, Istio semplifica il Canary Deployment, offrendo diverse ottime opzioni per il routing intelligente delle richieste. E s\u00ec, tutto questo pu\u00f2 essere fatto senza toccare il vostro codice sorgente.<\/p>\n

Filtriamo il browser<\/h3>\n

\nUno dei criteri di routing pi\u00f9 semplici \u00e8 il reindirizzamento in base al browser. Supponiamo che vogliate che solo le richieste dai browser Safari vengano instradate a v2. Ecco come si fa:<\/p>\n

\"Dark
\nApplichiamo questa regola di routing e poi con il comando curl<\/code> simuleremo in un ciclo richieste reali al microservizio. Come si vede nello screenshot, tutte vanno a v1:<\/p>\n

\"Dark
\nMa dov'\u00e8 il traffico a v2? Poich\u00e9 nel nostro esempio tutte le richieste sono state effettuate dalla nostra riga di comando, non ce n'\u00e8 affatto. Ma notate le righe inferiori nello schermo sopra: \u00e8 la reazione a una richiesta eseguita dal browser Safari, che ha restituito quanto segue:<\/p>\n

\"Dark<\/p>\n

Potere illimitato<\/h3>\n

\nAbbiamo gi\u00e0 scritto che le espressioni regolari offrono enormi possibilit\u00e0 per il routing delle richieste. Guardate il seguente esempio (pensiamo che voi capiate gi\u00e0 cosa fa):<\/p>\n

\"Dark
\nOra probabilmente avete gi\u00e0 un'idea del potenziale delle espressioni regolari.<\/p>\n

Agite con intelligenza<\/h3>\n

\nIl 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: \u00e8 semplice, non richiede modifiche al codice stesso e, se necessario, si pu\u00f2 facilmente tornare indietro.<\/p>\n

Interessati?<\/h3>\n

\nAvete voglia di sperimentare con Istio, Kubernetes e OpenShift sul vostro computer? Il team Red Hat Developer Team<\/a><\/noindex> ha preparato un ottimo un tutorial<\/a><\/noindex> su questo argomento e ha reso disponibili tutti i file correlati. Quindi andate avanti e non trattenetevi.
\n\u2003<\/p>\n

Istio Egress: uscita attraverso il negozio di souvenir<\/h2>\n

\nUtilizzando Istio insieme a Red Hat OpenShift e Kubernetes, \u00e8 possibile semplificarsi notevolmente la vita con i microservizi. La service mesh di Istio \u00e8 incapsulata all'interno dei pod di Kubernetes, mentre il vostro codice viene eseguito (principalmente) in isolamento. Prestazioni, semplicit\u00e0 di modifica, tracciabilit\u00e0 e altro - tutto ci\u00f2 \u00e8 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?<\/p>\n

Qui entra in gioco Istio Egress. In poche parole, consente di accedere a risorse (leggi: \u00abservizi\u00bb) 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\u00e9 non hai bisogno di accedere ai servizi esterni.<\/p>\n

Egress consente di aggirare le tabelle IP sopra citate, sia sulla base di regole Egress, sia per un intervallo di indirizzi IP.<\/p>\n

Immagina di avere un programma Java che effettua una richiesta GET a httpbin.org\/headers.<\/p>\n

(httpbin.org \u00e8 semplicemente una risorsa utile per testare le richieste dei servizi in uscita.)<\/p>\n

Se inseriamo nella riga di comando curl http:\/\/httpbin.org\/headers<\/code>, vedremo quanto segue:<\/p>\n

\"Dark
\nOppure puoi aprire lo stesso indirizzo nel browser:<\/p>\n

\"Dark
\nCome vediamo, il servizio l\u00ec presente restituisce semplicemente gli header che gli sono stati inviati.<\/p>\n

Facciamo un cambio radicale<\/h3>\n

\nOra prendiamo il codice Java di questo servizio esterno rispetto al nostro sistema ed eseguiamolo localmente, dove, ricordiamo, \u00e8 installato Istio. (Puoi farlo autonomamente consultando il nostro manuale su Istio<\/a><\/noindex>.) Una volta costruita l'immagine appropriata e avviata sulla piattaforma OpenShift, invocheremo questo servizio con il comando curl egresshttpbin-istioegress.$(minishift ip).nip.io<\/code>, dopodich\u00e9 vedremo sullo schermo questo:<\/p>\n

\"Dark
\nOh, cosa \u00e8 successo? Funzionava solo poco fa. Cosa significa Not Found? Abbiamo appena creato per esso curl<\/code>.<\/p>\n

Espandiamo le tabelle IP a tutto internet<\/h3>\n

\n\u00c8 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\u00f2 che si trova all'interno del tuo sistema di cluster. E httpbin.org si trova all'esterno e, di conseguenza, non \u00e8 accessibile. E qui interviene Istio Egress, senza alcuna modifica al tuo codice sorgente.<\/p>\n

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\u00f2 vedere da questo file (egress_httpbin.yml), la funzionalit\u00e0 qui \u00e8 abbastanza semplice:<\/p>\n

\"Dark
\nRimane solo da applicare questa regola:<\/p>\n

istioctl create -f egress_httpbin.yml -n istioegress\n<\/code><\/pre>\n
\nPuoi visualizzare le regole Egress con il comando istioctl get egressrules<\/code>:<\/p>\n
\"Dark
\nE infine, avviamo di nuovo il comando curl<\/i> \u2013 e vediamo che tutto funziona:<\/p>\n
\"Dark<\/p>\n
Pensiamo in modo aperto<\/h3>\n
\nCome 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\u00e0. E mentre lo fate, potete tranquillamente accedere ai servizi esterni rispetto al vostro ambiente. E s\u00ec, ripetiamo ancora una volta che tutto questo pu\u00f2 essere fatto senza toccare il vostro codice.<\/p>\n
Questo \u00e8 stato l'ultimo post di una serie su Istio. Restate con noi \u2013 ci sono molte altre cose interessanti in arrivo!
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u00ab\u041e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u2013 \u043c\u043e\u0435 \u0432\u0442\u043e\u0440\u043e\u0435 \u0438\u043c\u044f\u00bb, \u2013 \u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u043b \u041e\u0441\u0442\u0438\u043d \u041f\u0430\u0443\u044d\u0440\u0441, \u0447\u0435\u043b\u043e\u0432\u0435\u043a-\u0437\u0430\u0433\u0430\u0434\u043a\u0430 \u043c\u0435\u0436\u0434\u0443\u043d\u0430\u0440\u043e\u0434\u043d\u043e\u0433\u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0430. \u041d\u043e \u0442\u043e, \u0447\u0442\u043e \u0432 \u043f\u043e\u0447\u0435\u0442\u0435 \u0443 \u0441\u0443\u043f\u0435\u0440\u0430\u0433\u0435\u043d\u0442\u043e\u0432 \u0438 \u0441\u043f\u0435\u0446\u0441\u043b\u0443\u0436\u0431, \u0441\u043e\u0432\u0441\u0435\u043c \u043d\u0435 \u0433\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043b\u044f \u0441\u043b\u0443\u0436\u0431 \u043a\u043e\u043c\u043f\u044c\u044e\u0442\u0435\u0440\u043d\u044b\u0445, \u0433\u0434\u0435 \u0441\u043a\u0443\u043a\u043e\u0442\u0438\u0449\u0430 \u0433\u043e\u0440\u0430\u0437\u0434\u043e \u043b\u0443\u0447\u0448\u0435 \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0435\u0439. \u0418 Istio \u0432\u043c\u0435\u0441\u0442\u0435 OpenShift \u0438 Kubernetes \u043f\u0440\u0435\u0432\u0440\u0430\u0449\u0430\u044e\u0442 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0434\u0435\u043b\u043e \u043f\u043e-\u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u043c\u0443 \u0441\u043a\u0443\u0447\u043d\u043e\u0435 \u0438 \u043f\u0440\u0435\u0434\u0441\u043a\u0430\u0437\u0443\u0435\u043c\u043e\u0435 \u2013 \u0438 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e. \u041e\u0431 \u044d\u0442\u043e\u043c \u0438 \u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-56218","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Dark Launch in Istio: servizi segreti | ProHoster","description":"\u00abIl pericolo \u00e8 il mio secondo nome\u00bb, diceva Austin Powers, l'uomo-mistero su scala internazionale.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dark-launch-v-istio-sekretnye-sluzhby","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Dark Launch \u0432 Istio: \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0441\u043b\u0443\u0436\u0431\u044b | ProHoster","og:description":"\u00ab\u041e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u2013 \u043c\u043e\u0435 \u0432\u0442\u043e\u0440\u043e\u0435 \u0438\u043c\u044f\u00bb, \u2013 \u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u043b \u041e\u0441\u0442\u0438\u043d \u041f\u0430\u0443\u044d\u0440\u0441, \u0447\u0435\u043b\u043e\u0432\u0435\u043a-\u0437\u0430\u0433\u0430\u0434\u043a\u0430 \u043c\u0435\u0436\u0434\u0443\u043d\u0430\u0440\u043e\u0434\u043d\u043e\u0433\u043e \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0430.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dark-launch-v-istio-sekretnye-sluzhby","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-06T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56218","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:28:24","updated":"2022-10-05 04:55:29","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/56218","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=56218"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/56218\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=56218"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=56218"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=56218"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}