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 E siamo giunti all'ultimo capitolo. Di solito, questa tecnologia e i compiti ad essa correlati non rientrano nelle responsabilit\u00e0 degli ingegneri dell'automazione. E questo ha le sue ragioni. In primo luogo, in molte organizzazioni le questioni infrastrutturali sono sotto il controllo del dipartimento DevOps e il team di sviluppo non si preoccupa granch\u00e9 di ci\u00f2 che fa funzionare il pipeline e in che modo mantenere tutto ci\u00f2 che lo riguarda. In secondo luogo, diciamolo chiaramente, la pratica \"Infrastruttura come codice (IaC)\" non \u00e8 ancora adottata in molte aziende. Ma \u00e8 sicuramente diventata una tendenza popolare ed \u00e8 importante cercare di essere coinvolti nei processi, approcci e strumenti correlati. O, almeno, essere al corrente degli eventi.<\/p>\n
Iniziamo con la motivazione per l'utilizzo di questo approccio. Abbiamo gi\u00e0 discusso che per avviare i test in GitlabCI avremo bisogno di almeno risorse per eseguire Gitlab Runner. E per avviare i contenitori con i browser\/emulatori dobbiamo riservare una VM o un cluster. Oltre alle risorse per il testing, abbiamo bisogno di un numero significativo di risorse per supportare gli ambienti di sviluppo, staging, produzione, il che include anche database, pianificazioni automatiche, configurazioni di rete, load balancer, diritti degli utenti e cos\u00ec via. Il problema chiave riguarda gli sforzi richiesti per mantenere tutto ci\u00f2. Ci sono diversi modi in cui possiamo apportare modifiche e implementare aggiornamenti. Ad esempio, nel contesto di GCP possiamo usare la console UI nel browser e svolgere tutte le operazioni cliccando sui pulsanti. Un'alternativa potrebbe essere l'utilizzo delle chiamate API per interagire con le entit\u00e0 cloud o l'applicazione dell'utility da riga di comando gcloud per eseguire le necessarie manipolazioni. Tuttavia, con un numero davvero elevato di diverse entit\u00e0 ed elementi infrastrutturali, diventa difficile se non impossibile eseguire tutte le operazioni manualmente. Inoltre, tutte queste azioni manuali sono incontrollabili. Non possiamo inviarle in revisione prima dell'esecuzione, utilizzare un sistema di controllo versioni e ripristinare rapidamente le modifiche che hanno causato un incidente. Per affrontare tali problemi, gli ingegneri hanno creato e stanno creando script automatici in bash\/shell, il che non \u00e8 molto diverso dai metodi precedenti, poich\u00e9 non sono cos\u00ec facili da leggere, comprendere, mantenere e modificare rapidamente in uno stile procedurale.<\/p>\n
In questo articolo e guida pratica utilizzo 2 strumenti legati alla pratica dell'IaC. Questi sono Terraform e Ansible. Alcuni ritengono che non abbia senso usarli contemporaneamente, poich\u00e9 le loro funzionalit\u00e0 sono simili e sono intercambiabili. Ma il punto \u00e8 che inizialmente vengono posti obiettivi completamente diversi. E il fatto che questi strumenti debbano completarsi a vicenda \u00e8 stato confermato durante una presentazione congiunta da sviluppatori che rappresentano le aziende HashiCorp e RedHat. La differenza concettuale sta nel fatto che Terraform \u00e8 uno strumento di provisioning per la gestione dei server stessi. Mentre Ansible \u00e8 uno strumento di gestione delle configurazioni, il cui compito \u00e8 l'installazione, la configurazione e la gestione del software su questi server.<\/p>\n
Un'altra caratteristica chiave 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 come risultato dell'esecuzione. Ad esempio, se intendiamo creare 10 VM e applicare le modifiche tramite Terraform, otterremo 10 VM. Se applichiamo lo script di nuovo, non accadr\u00e0 nulla, poich\u00e9 abbiamo gi\u00e0 10 VM, e Terraform \u00e8 a conoscenza di questo, poich\u00e9 memorizza lo stato attuale dell'infrastruttura in un file di stato. D'altra parte, Ansible utilizza un approccio procedurale e, se gli chiediamo di creare 10 VM, al primo avvio otterremo 10 VM, analogamente a Terraform. Ma dopo un secondo avvio, avremo gi\u00e0 20 VM. Qui sta la differenza importante. Nello stile procedurale non memorizziamo lo stato attuale e descriviamo semplicemente la sequenza di passaggi che devono essere eseguiti. Naturalmente, possiamo gestire diverse situazioni, aggiungere controlli sull'esistenza delle risorse e lo stato attuale, ma non ha senso sprecare il nostro tempo e fare sforzi per controllare questa logica. Inoltre, ci\u00f2 aumenta il rischio di commettere errori.\u00a0<\/p>\n
Riassumendo tutto quanto detto sopra, si pu\u00f2 concludere che per il provisioning dei server lo strumento pi\u00f9 adatto \u00e8 Terraform e la notazione dichiarativa. Mentre il lavoro di gestione delle configurazioni \u00e8 meglio delegarlo ad Ansible. Capito questo, 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 come parte dell'intera infrastruttura aziendale. Ci\u00f2 significa che tutte le pratiche IaC devono essere applicate globalmente alle risorse dell'intera organizzazione. La responsabilit\u00e0 di questo dipende dai vostri processi. Il team DevOps ha pi\u00f9 esperienza in queste questioni, vedendo l'intero quadro degli eventi. 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 richieste e le opportunit\u00e0 di miglioramento. La soluzione migliore \u00e8 lavorare insieme, scambiando conoscenze e idee per raggiungere il risultato atteso.\u00a0<\/p>\n
Ecco alcuni esempi di utilizzo di Terraform e Ansible nel contesto dell'automazione dei test e degli strumenti che abbiamo discusso finora:<\/p>\n
1. Descrivere attraverso Terraform le caratteristiche e i parametri necessari delle VM e dei cluster.<\/p>\n
2. Installare con Ansible gli strumenti necessari per i test: docker, Selenoid, Selenium Grid e caricare le versioni desiderate dei browser\/emulatori.<\/p>\n
3. Descrivere tramite Terraform le caratteristiche della VM in cui sar\u00e0 eseguito GitLab Runner.<\/p>\n
4. Installare con Ansible GitLab Runner e gli strumenti ausiliari necessari, impostare le configurazioni.<\/p>\n
Illustrazione dello stato attuale dell'infrastruttura<\/h3>\n
\n![\"Strumenti](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Riferimenti per l'approfondimento:<\/h3>\n
<\/p>\n