Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastruttura come codice (IaC)<\/h2>\n
<\/p>\n
Breve descrizione della tecnologia<\/h3>\n
\n Ecco che siamo arrivati all'ultimo capitolo. Di solito, questa tecnologia e i compiti ad essa associati non rientrano nelle responsabilit\u00e0 degli ingegneri di automazione. E ci sono buone ragioni per questo. In primo luogo, in molte organizzazioni, le questioni infrastrutturali sono sotto il controllo del team DevOps e il team di sviluppo non si preoccupa molto di ci\u00f2 che sostiene il pipeline e come mantenere tutto ci\u00f2 che vi si collega. In secondo luogo, diciamolo chiaramente, la pratica dell'\"Infrastruttura come codice (IaC)\" non \u00e8 ancora adottata in molte aziende. Tuttavia, \u00e8 diventata una tendenza popolare ed \u00e8 importante cercare di essere coinvolti nei processi, approcci e strumenti ad essa correlati. O, perlomeno, rimanere aggiornati.<\/p>\n
Iniziamo motivando l'uso di questo approccio. Abbiamo gi\u00e0 discusso che per eseguire test in GitlabCI avremo bisogno di almeno le risorse per avviare Gitlab Runner. E per far funzionare contenitori con browser\/emulatori dobbiamo riservare una VM o un cluster. Oltre alle risorse per il testing, abbiamo bisogno di una quantit\u00e0 significativa di potenza per mantenere gli ambienti di sviluppo, staging, produzione, che comprendono anche database, pianificazioni automatiche, configurazioni di rete, bilanciatori di carico, diritti utenti, e cos\u00ec via. Il problema principale riguarda gli sforzi necessari per mantenere tutto questo. Ci sono diversi modi in cui possiamo apportare modifiche e rilasciare aggiornamenti. Ad esempio, nel contesto di GCP possiamo usare la console UI nel browser e compiere tutte le azioni cliccando sui pulsanti. Un metodo alternativo pu\u00f2 essere l'utilizzo delle chiamate API per interagire con le entit\u00e0 cloud o l'applicazione dello strumento da riga di comando gcloud per eseguire le manovre necessarie. Ma quando ci sono veramente un gran numero di diverse entit\u00e0 e elementi infrastrutturali, diventa difficile, se non impossibile, eseguire tutte le operazioni manualmente. Inoltre, tutte queste azioni manuali non sono controllate. Non possiamo sottoporle a revisione prima dell'esecuzione, usare un sistema di controllo versione e ripristinare rapidamente correzioni che hanno causato un incidente. Per risolvere tali problemi, gli ingegneri hanno creato e continuano a creare script bash\/shell automatizzati, che non sono molto meglio delle soluzioni precedenti, poich\u00e9 non sono cos\u00ec facili da leggere, comprendere, mantenere e modificare in stile procedurale.<\/p>\n
In questo articolo e nella guida pratica utilizzer\u00f2 2 strumenti legati alla pratica IaC. Questi sono Terraform e Ansible. Alcuni ritengono che non abbia senso usarli contemporaneamente, poich\u00e9 le loro funzionalit\u00e0 sono simili e si sostituiscono reciprocamente. Ma la verit\u00e0 \u00e8 che inizialmente si pongono obiettivi completamente diversi. E il fatto che questi strumenti debbano integrarsi \u00e8 stato confermato in una presentazione congiunta dai sviluppatori delle aziende HashiCorp e RedHat. La differenza concettuale \u00e8 che Terraform \u00e8 uno strumento di provisioning per gestire i server stessi. Mentre Ansible \u00e8 uno strumento di gestione delle configurazioni, il cui compito \u00e8 installare, configurare e gestire il software su quei server.<\/p>\n
Un'altra caratteristica distintiva di questi strumenti \u00e8 lo stile di scrittura del codice. A differenza di bash e Ansible, Terraform utilizza uno stile dichiarativo, basato sulla descrizione dello stato finale desiderato da raggiungere. Ad esempio, se intendiamo creare 10 VMs e applicare le modifiche tramite Terraform, avremo 10 VMs. Se eseguiamo lo script di nuovo, non succeder\u00e0 nulla, poich\u00e9 abbiamo gi\u00e0 10 VMs, e Terraform ne \u00e8 a conoscenza poich\u00e9 conserva lo stato attuale dell'infrastruttura in un file di stato. Ansible, invece, utilizza un approccio procedurale e, se gli chiediamo di creare 10 VMs, durante il primo avvio otterremo 10 VMs, analogamente a quanto accade con Terraform. Tuttavia, dopo un secondo avvio, avremo gi\u00e0 20 VMs. Questa \u00e8 la principale differenza. Nello stile procedurale non conserviamo lo stato attuale e descriviamo semplicemente la sequenza di passaggi da eseguire. Certamente, possiamo gestire diverse situazioni, aggiungere controlli sull'esistenza delle risorse e sullo stato attuale, ma non ha senso perdere tempo e sforzi per controllare questa logica. Inoltre, ci\u00f2 aumenta il rischio di commettere errori.\u00a0<\/p>\n
In sintesi, si pu\u00f2 concludere che per il provisioning dei server, lo strumento pi\u00f9 adatto \u00e8 Terraform con notazione dichiarativa. La gestione delle configurazioni \u00e8 meglio affidarla ad Ansible. Detto ci\u00f2, vediamo alcuni esempi di utilizzo nel contesto dell'automazione.<\/p>\n
Valore per l'infrastruttura di automazione<\/h3>\n
\n \u00c8 importante capire che l'infrastruttura per l'automazione dei test deve essere considerata parte dell'intera infrastruttura aziendale. Questo significa che tutte le pratiche IaC devono essere applicate globalmente alle risorse di tutta l'organizzazione. Chi \u00e8 responsabile dipende dai vostri processi. Il team DevOps \u00e8 pi\u00f9 esperto in queste questioni e ha una visione d'insieme. Tuttavia, gli ingegneri QA sono pi\u00f9 coinvolti nel processo di costruzione dell'automazione e nella struttura del pipeline, il che consente loro di vedere meglio tutte le modifiche necessarie e le opportunit\u00e0 di miglioramento. La soluzione migliore \u00e8 collaborare, scambiarsi conoscenze e idee per raggiungere il risultato desiderato.\u00a0<\/p>\n
Ecco alcuni esempi di utilizzo di Terraform e Ansible nel contesto dell'automazione dei test e degli strumenti che abbiamo discusso in precedenza:<\/p>\n
1. Descrivere tramite Terraform le caratteristiche e i parametri necessari per le VMs e i cluster.<\/p>\n
2. Installare tramite Ansible gli strumenti necessari per i test: docker, Selenoid, Selenium Grid e caricare le versioni richieste dei browser\/emulatori.<\/p>\n
3. Descrivere tramite Terraform le caratteristiche della VM in cui verr\u00e0 eseguito il GitLab Runner.<\/p>\n
4. Installare tramite Ansible il GitLab Runner e gli strumenti complementari, configurando le impostazioni.<\/p>\n
Illustrazione dello stato attuale dell'infrastruttura<\/h3>\n
\n![\"Gli](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Risorse per approfondire:<\/h3>\n
<\/p>\n