{"id":7381,"date":"2024-10-30T17:42:02","date_gmt":"2024-10-30T16:42:02","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=7381"},"modified":"2024-10-30T17:41:27","modified_gmt":"2024-10-30T16:41:27","slug":"halloween-special-infrastrutture-cloud-da-incubo-episodio-3","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/halloween-special-infrastrutture-cloud-da-incubo-episodio-3\/","title":{"rendered":"Halloween Special: Infrastrutture Cloud da Incubo – Episodio 3"},"content":{"rendered":"\n

“Hai visto cose orribili. Un esercito di creature da incubo. Ma non sono nulla in confronto a ci\u00f2 che \u00e8 venuto prima. Ci\u00f2 che si trova sotto. \u00c8 nostro compito placare gli Antichi. Come \u00e8 tuo essere offerto a loro. Perdonaci. E facciamo presto.”<\/em>   <\/p>\n\n\n\n

The Cabin in the Woods<\/strong><\/p>\n\n\n\n

Ciao cari amanti dell’horror! Bentornati nel nostro piccolo angolo spaventoso!<\/p>\n\n\n\n

Come molti di voi gi\u00e0 sanno, questo periodo dell’anno \u00e8 perfetto per raccontare tutte le storie spaventose su errori e problemi di design che si sono rivelati veri e propri mostri da combattere.\u00a0<\/p>\n\n\n\n

In questo articolo, vedremo cosa \u00e8 andato storto negli ultimi 12 mesi, perch\u00e9 e come evitare certe cose in futuro…\u00a0<\/p>\n\n\n\n

Come sempre, non siamo qui a puntare il dito contro nessuno: a volte, le pessime decisioni dipendono dal contesto e dal momento… e fanno anche un po’ crescere!<\/p>\n\n\n\n

Quindi, sedetevi, rilassatevi (se ci riuscite) e continuate con la lettura! <\/p>\n\n\n\n

Se ve li siete persi, ecco il primo<\/a> e il secondo<\/a> episodio.<\/p>\n\n\n\n

Complessit\u00e0 complessa<\/h2>\n\n\n\n

“A volte morto \u00e8 meglio.”<\/em><\/p>\n\n\n\n

Pet Sematary<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure><\/div>\n\n\n

<\/p>\n\n\n\n

Cosa fare quando troviamo un potenziale problema che si auto-alimenta e cresce senza che nessuno provi a fermare questo comportamento? <\/p>\n\n\n\n

La nostra storia inizia durante una soleggiata giornata estiva. <\/p>\n\n\n\n

Durante una Well-Architected Review, ci siamo imbattuti in un workload critico in esecuzione su EKS su EC2 ed un secondo cluster EKS basato su Fargate. Come sempre, alla ricerca di possibili miglioramenti su gestione ed elasticit\u00e0, abbiamo domandato se ci fosse un piano per adottare Fargate per il workload EKS su EC2.\u00a0<\/p>\n\n\n\n

Non c’era nessun piano: il workload poteva girare su Fargate, ma Karpenter si occupava dello scaling del cluster. Abbiamo pensato che, comunque, fosse una cosa pi\u00f9 che buona: Karpenter \u00e8 un ottimo strumento ed \u00e8 appena stato promosso uscendo dallo stato di beta. Eravamo piuttosto soddisfatti di questa scoperta perch\u00e9 \u00e8 stata presa in considerazione la possibilit\u00e0 di\u00a0 automatizzare l’eliminazione e l’aggiunta automatica di risorse quando necessario, anche se alcuni miglioramenti potevano essere fatti pensando all’aspetto della gestibilit\u00e0.\u00a0<\/p>\n\n\n\n

Abbiamo aperto una piccola parentesi per farci raccontare di come siano stati affrontati il tema dell’elasticit\u00e0 e il lavoro di ricerca e sviluppo fatto per comparare le soluzioni visto che il carico dell’applicazione era piuttosto imprevedibile. Alla fine abbiamo convenuto che fosse stato fatto un ottimo lavoro!<\/p>\n\n\n\n

Abbiamo quindi dato un’occhiata al cluster EKS basato su Fargate e abbiamo scoperto che veniva utilizzato… per eseguire Karpenter! <\/p>\n\n\n\n

A questo punto ci \u00e8 venuto naturale domandare se il primo cluster analizzato fosse stato migrato da Autoscaler a Karpenter. Come purtroppo temevamo la risposta \u00e8 stata no: avevano creato un secondo cluster per migrare l’applicazione.<\/p>\n\n\n\n

Eravamo perplessi: perch\u00e9 non usare Fargate (o, ancora meglio, aggiungere\u00a0un profilo Fargate al cluster e iniziare a migrare pod) se era necessaria una migrazione? La risposta \u00e8 stata semplice semplice: “Perch\u00e9 usiamo Karpenter!” A questo punto eravamo ancora pi\u00f9 confusi, ma dovevamo proseguire; abbiamo preso nota del fatto per il report (e questo articolo!).\u00a0<\/p>\n\n\n\n

La complessit\u00e0 legata all’esecuzione ed al mantenimento di uno strumento per gestire la scalabilit\u00e0 di risorse che in realt\u00e0 possono scalare nativamente ed in modo gestito porta sicuramente a errori e problemi in futuro (soprattutto per quanto riguarda aggiornamenti e modifiche). Invece di gestire un solo componente, occorre prendersi cura di un elemento aggiuntivo e valutarne l’interazione. <\/p>\n\n\n\n

In questo caso, un pattern potrebbe emergere: cosa succederebbe se in futuro venisse messo a disposizione\u00a0 un componente che implementa una GUI per Karpenter? Possiamo scommetterci: troveremmo la GUI in esecuzione durante la Well-Architected review! \u00c8 un ciclo infinito che aggiunge complessit\u00e0 a un sistema per gestire la sua complessit\u00e0.\u00a0<\/p>\n\n\n\n

Quando aggiungiamo un componente, dobbiamo valutarne l’impatto. Anche se sembra facilitare il nostro lavoro, dobbiamo sempre chiederci: c’\u00e8 un servizio gestito progettato per questo?<\/p>\n\n\n\n

CI\/CR (Continuous Integration, Continuous Rollback)<\/h2>\n\n\n\n

“Le forze diaboliche sono formidabili. Queste forze sono eterne ed esistono ancora oggi. La fiaba \u00e8 vera. Il diavolo esiste. Dio esiste. E per noi, come persone, il nostro stesso destino dipende da quale di essi scegliamo di seguire.” <\/em><\/p>\n\n\n\n

The Conjuring<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

\n
\"\"<\/figure><\/div><\/figure>\n\n\n\n

<\/p>\n\n\n\n

“Per il nostro progetto, abbiamo bisogno di tre ambienti diversi e, ovviamente, di pipeline CI\/CD per il front end ed il back end”. <\/p>\n\n\n\n

Niente ci rende pi\u00f9 felici di sentire questo genere di richieste durante le call all’avvio di un progetto! Finalmente, lo scenario “Developmenttestproduction<\/a>” era un lontano ricordo.<\/p>\n\n\n\n

In mancanza di particolari requisiti sullo stack tecnologico, abbiamo utilizzato CodeBuild e CodePipeline e concordato di utilizzare tre branch differenti per i diversi ambienti: dev, test e production, ciascuno associato a una pipeline in esecuzione nell’ambiente specifico. <\/p>\n\n\n\n

Per “promuovere” il codice tra gli ambienti, deve essere effettuato un merge da dev a test, e cos\u00ec via. Qualcuno potrebbe obiettare che esistono flussi migliori, ma questo sembrava adattarsi bene al workflow di sviluppo gi\u00e0 in uso dagli sviluppatori.<\/p>\n\n\n\n

Dopo qualche tempo di sviluppo IaC con CDK, gli ambienti dev e test per frontend e backend erano pronti. A questo punto ci \u00e8 stato chiesto di utilizzare l’ID del commit per identificare le release delle immagini contenute nel repository ECR e degli asset nei bucket S3. \u00c8 stato un gioco da ragazzi, ma non avevamo idea di cosa stava per succedere.<\/p>\n\n\n\n

Dopo un altro po’ di tempo (e sviluppo), l’ambiente di produzione era pronto e il team ha richiesto un passaggio di approvazione manuale in pipeline e, successivamente, di applicare un ulteriore un git tag nel repository per identificare meglio le release. Solo dopo una settimana o due la situazione \u00e8 diventata chiara: abbiamo ricevuto una richiesta di modificare le pipeline per il repository di test e produzione per poter selezionare da quale tag far partire la pipeline e fare il deploy.\u00a0<\/p>\n\n\n\n

Questo per poter scegliere quale versione di front end e back end distribuire in ogni ambiente per facilitare i rollback… “perch\u00e9 non si sa mai”.\u00a0<\/p>\n\n\n\n

Inutile dire che questa \u00e8 la strada giusta per raggiungere il disastro perfetto: fare rollback di diversi componenti pu\u00f2 portare a interazioni sconosciute e inaspettate. Ad esempio per investigare un bug nell’ambiente di test (o, peggio, in produzione) bisogner\u00e0 fare il rollback dell’intera catena negli ambienti, anche negli ambienti di sviluppo locali. <\/p>\n\n\n\n

Molti articoli gi\u00e0 parlano del costo del rollback e dei problemi che possono derivare dall’avere ambienti divergenti. In alcuni casi poi, policy aziendali rigorose vietano il deploy di versioni che non siano in esecuzione e validate nell’ambiente di test. <\/p>\n\n\n\n

In tutto questo non abbiamo preso in considerazione l’errore umano: selezionare manualmente il tag sbagliato \u00e8 molto pi\u00f9 probabile rispetto all’avere una pipeline che distribuisce automaticamente l’ultima versione da un branch… Se qualcosa va storto in un deploy, poi, \u00e8 pi\u00f9 facile fare il fix e andare avanti che elaborare un workflow complicato “just in case”!<\/p>\n\n\n\n

Dopo un po’ di tempo e spiegazioni, abbiamo continuato a usare il workflow “normale”, e indovinate un po’? Non \u00e8 mai stato fatto un rollback!<\/p>\n\n\n\n

Anche i cattivi piangono<\/h2>\n\n\n\n

“Nonostante la mia macabra reputazione, ho davvero il cuore di un bambino. Lo tengo in un barattolo sulla mia scrivania.”<\/em> <\/p>\n\n\n\n

Robert Bloch<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

\n
\"\"<\/figure><\/div><\/figure>\n\n\n\n

<\/p>\n\n\n\n

A volte, la sfortuna colpisce anche i cattivi. <\/p>\n\n\n\n

Un’azienda ci ha contattato in emergenza dopo aver trovato il Luned\u00ec mattina un’istanza EC2 sconosciuta. Il team IT era piccolo e quindi il check interno \u00e8 stato breve: nessuno aveva avviato quella istanza, tantomeno una cos\u00ec grande.\u00a0<\/p>\n\n\n\n

La preoccupazione maggiore riguardava la possibile perdita di credenziali amministrative; abbiamo quindi iniziato ad analizzare CloudTrail per scoprire che un indirizzo IP sconosciuto da un paese straniero aveva usato una Access Key per descrivere le quota e le region in uso per poi per avviare l’istanza, scegliendo eu-west-3 (Parigi), una region non comunemente utilizzata – specialmente da utenti italiani – tranne che dal nostro cliente che, per motivi storici, l’aveva sempre utilizzata come principale (e con poche istanze).<\/p>\n\n\n\n

\u00a0Individuare l’anomalia \u00e8 stato quindi questione di pochi minuti. Dopo qualche indagine abbiamo scoperto che l’accesso anomalo era stato fatto dai “soliti” bot, i quali avevano trovato una vulnerabilit\u00e0 nel framework PHP di un sito web, avevano ottenuto la chiave di accesso (che purtroppo aveva permessi troppo ampi) e usato le credenziali per avviare un cripto-miner in una regione che, per il bot, sembrava una buona idea perch\u00e9 non comune ed abilitata di default. <\/p>\n\n\n\n

Alla fine, essere un cattivo non \u00e8 un compito facile; la sfortuna pu\u00f2 capitare a chiunque!<\/p>\n\n\n\n

Riguardo al nostro nuovo cliente, dopo una revisione di emergenza, abbiamo elaborato un piano per risolvere molte criticit\u00e0. Stiamo ancora lavorando su tutti i problemi, ma affidarsi alle best practice \u00e8 meglio che affidarsi alla dea bendata! A proposito: avere credenziali temporanee utilizzando gli IAM roles pu\u00f2 evitare molti mal di testa, fidatevi…<\/p>\n\n\n\n

Home disautomation<\/h2>\n\n\n\n

\u201cSai, penso che questa cosa del Natale non sia cos\u00ec complicata come sembra! Ma perch\u00e9 dovrebbero divertirsi solo loro? Dovrebbe appartenere a chiunque! In realt\u00e0 non chiunque, ma io! Perch\u00e9, potrei fare un albero di Natale! E non c’\u00e8 una ragione che posso trovare per cui non potrei avere un periodo natalizio! Scommetto che potrei migliorarlo anche io! Ed \u00e8 esattamente quello che far\u00f2!\u201d<\/em><\/p>\n\n\n\n

  Jack Skellington, the Nightmare before Christmas<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

\n
\"\"<\/figure><\/div><\/figure>\n\n\n\n

<\/p>\n\n\n\n

Ehi, sono io! Sono il Damiano dal passato, ti ricordi di me? Stai prendendo in giro chi ha fatto un sacco di disastri, ma non sei perfetto. Come nerd, sei vulnerabile al richiamo delle nuove tecnologie, ansioso di provarle ad ogni opportunit\u00e0, anche a casa. Quindi, sii coraggioso e racconta loro del tuo progetto di domotica che ha trasformato le luci della tua casa in veri e propri ribelli.<\/em>..<\/p>\n\n\n\n

Ok, va bene. <\/p>\n\n\n\n

Questa storia parla di come la mia pigrizia e passione per le nuove tecnologie mi abbiano tradito. Era il 2018 e in quell’anno acquistai il mio primo smart switch SonOff da usare in combinazione con Alexa per accendere una lampada nel mio soggiorno perch\u00e9 un interruttore della luce non era disponibile nel punto in cui lo volevo.\u00a0<\/p>\n\n\n\n

Non ci volle molto prima di scoprire la domotica con i chip Wi-Fi ESP8266, Home Assistant, Tasmota ed il protocollo MQTT. La tecnologia era nei primi anni di sviluppo e il miglior modo per imparare \u00e8 sperimentare, anche con ci\u00f2 che usiamo quotidianamente. Come sempre, prima di capire bene l’ordine delle cose e come funziona una tecnologia in un sistema complesso, dobbiamo fare errori.<\/p>\n\n\n\n

Era Luglio, ero in vacanza in Sardegna; il telefono suon\u00f2 ed all’altro capo i miei genitori mi avvisarono di una luce accesa in cucina impossibile da spegnere. Infatti, entrarono in casa mia ed invano provarono tutti i pulsanti. Sapendo che in quel periodo stavo facendo esperimenti con le luci a casa (probabilmente anche perch\u00e9 mio padre elettricista mi ha insegnato un po’ troppe cose), sapevano gi\u00e0 che qualcosa non era andato come previsto.<\/p>\n\n\n\n

Era ovviamente colpa mia… ecco come sono andate le cose.<\/p>\n\n\n\n

Avendo scoperto i chip ESP8266 e le loro capacit\u00e0, ho iniziato a prototipare un “extender per pulsanti Wi-Fi” per poter controllare pi\u00f9 lampadine con un singolo interruttore, attivando diversi eventi per diverse azioni, come ad esempio doppi clic, pressioni prolungate, ecc. L’idea era di estendere le capacit\u00e0 di un semplice pulsante incorporando ed aggiungendo un chip ESP8266, che potesse controllare altri dispositivi smart (anche fatti in casa) tramite webhook. In questo modo avrei potuto accendere o spegnere tutte le luci e controllare quelle in stanze differenti!\u00a0<\/p>\n\n\n\n

Ecco un (brutto) prototipo di quell’anno:<\/p>\n\n\n\n

<\/p>\n\n\n\n

\n
\"\"<\/figure><\/div><\/figure>\n\n\n\n

<\/p>\n\n\n\n

I problemi relativi alla luce che non si spegneva erano dovuti al fatto che:<\/p>\n\n\n\n