In questo articolo affronteremo i seguenti temi:
Benefici e ostacoli dell’approccio IaC sulla bilancia
Sin dagli albori dell’informatica, e in particolar modo di quella business-oriented (o “enterprise”), gestione e configurazione della propria infrastruttura sono stati compiti manuali, designati ad un gruppo più o meno grande di persone altamente specializzate.
Qualsivoglia modifica infrastrutturale si volesse effettuare, doveva necessariamente passare per questo gruppo di pochi eletti, utilizzando metodi di varia natura: da una semplice chiamata telefonica o e-mail fino ad arrivare a complessi ticketing system, soprattutto nei casi in cui gli utenti e le richieste fossero di un numero considerevole.
Problematiche dell'approccio artigianale
Sebbene il suddetto approccio sia stato utilizzato per diverso tempo, presenta non pochi problemi. Sono due, però, quelli che potrebbero essere considerati i più degni di nota.
Il primo problema riguarda la mancanza di documentazione circa la configurazione o design infrastrutturale, soprattutto a fronte delle progressive modifiche avvenute nel tempo e mirate a soddisfare le perennemente mutevoli esigenze di business. Questo punto è particolarmente dolente nel contesto della sostituzione dei dipendenti; i quali, soprattutto nelle fasi iniziali, si troveranno a lavorare su un ambiente a loro non familiare e senza una documentazione sulla attuale configurazione infrastrutturale né su quelle che sono le “regole non scritte” del gestire quella infrastruttura che magari solo chi ci ha lavorato a lungo ha appreso.
Il secondo problema concerne invece quello che è il semplice errore umano. Anche nell’idilliaco caso in cui tutti i processi per configurare l’infrastruttura siano ben documentati, in un qualunque formato, il rischio di sbagliare un passaggio – che sia il click di un pulsante o un banale errore di battitura – è sempre dietro l’angolo.
Ciò che promette l’approccio Infrastructure as Code
Che succederebbe, invece, se la documentazione della nostra infrastruttura fosse anche qualcosa che possiamo “eseguire” (nella connotazione informatica, dall’inglese “run”) affinché svolga quanto descritto nella documentazione stessa?
Questo è, infatti, ciò che promette l’approccio IaC: la stesura di codice, scritto in linguaggi differenti, che può essere eseguito. Con questo approccio, fare cambiamenti all’infrastruttura si tradurrà, nella pratica, nell’effettuare cambiamenti al codice, come fosse il codice sorgente di una regolare applicazione, e rieseguire il tutto. Nel caso si volesse raggiungere massima efficienza e correttezza operazionale, è possibile testare l’infrastruttura risultante dal nostro codice, ai fini di verificare che ciò che pensiamo di aver scritto in codice sia effettivamente ciò che viene realizzato.
Strumenti che ci permettono di adottare l’approccio IaC
Tanti sono gli strumenti che ci permettono di adottare l’approccio IaC, che agiscono anche a livelli differenti dell’infrastruttura stessa. Vediamo alcuni esempi e si ricordi che la seguente è una lista assolutamente non esaustiva!
Terraform
Lo strumento pioniere dell’Infrastructure as Code è Terraform, un progetto ormai piuttosto maturo – non più di un anno fa ha finalmente raggiunto la version 1.0 – manutenuto da HashiCorp; azienda che fa dell’Infrastructure as Code il perno di tutti i propri progetti.
Terraform ci permette di scrivere cosa metter su della nostra infrastruttura in in linguaggio dichiarativo, chiamato HCL. A fini puramente dimostrativi e non didattici, qui in basso vi è un esempio di codice HCL per istanziare una virtual machine EC2 sul cloud provider AWS, nella region “us-west-2”.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
required_version = ">= 1.2.0"
}
provider "aws" {
region = "us-west-2"
}
resource "aws_instance" "app_server" {
ami = "ami-830c94e3"
instance_type = "t2.micro"
tags = {
Name = "ExampleAppServerInstance"
}
}
Ansible
Ansible è invece uno strumento manutenuto da RedHat, ormai in piedi da diversi anni. Definirlo solamente “maturo” sarebbe riduttivo.
Ansible ci permette di descrivere in quelli che vengono definiti “playbook” la configurazione dei nostri host e delle nostre virtual machine, con particolare focus alla configurazione a livello di Guest OS.
I playbook sono stilati utilizzando file YAML ed enumerano dei task che saranno eseguiti sulle nostre macchine. Possiamo qui osservare un esempio di Ansible playbook:
- name: Update web servers
hosts: webservers
remote_user: root
tasks:
- name: Ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
- name: Write the apache config file
ansible.builtin.template:
src: /srv/httpd.j2
dest: /etc/httpd.conf
- name: Update db servers
hosts: databases
remote_user: root
tasks:
- name: Ensure postgresql is at the latest version
ansible.builtin.yum:
name: postgresql
state: latest
- name: Ensure that postgresql is started
ansible.builtin.service:
name: postgresql
state: started
Il file sopra riportato, se dato in pasto ad Ansible, si assicurerà di installare e configurare il pacchetto httpd per gli host raggruppati sotto il nome di “webservers” e di installare e configurare PostgreSQL sugli host raggruppati sotto il nome di “databases”.
Considerazioni - Da grandi poteri derivano grandi responsabilità
Sebbene l’approccio IaC possa sembrare fantastico da un punto di vista operazionale – e lo è – non sarà facile adattarsi, soprattutto per i neofiti. Solamente cambiando rigorosamente qualsiasi cosa per mezzo del codice sorgente di riferimento, senza esclusione alcuna, l’approccio IaC potrà realmente brillare. Guadagneremo infatti, come già detto, la totale assenza del fattore “errore umano”, oltre a codice che effettuerà per noi cambiamenti infrastrutturali – e che implicitamente sarà anche documentazione della stessa – ma, da non sottovalutare, guadagneremo anche la possibilità di poter versionare utilizzando strumenti di version control come Git, tutti i cambiamenti effettuati alla nostra infrastruttura. Saremo in grado di rispondere a domande quali “Chi ha effettuato modifica X al datacenter di Milano? Quando? E perché?”. Tutte domande alle quali era impensabile rispondere, soprattutto in assenza di documentazione o di un flusso rigoroso come quello che ci propone IaC.
Tuttavia, sarebbe ipocrita nascondere che, soprattutto nelle fasi inziali, l’approccio IaC genererà un po’ di attrito. Forte sarà la tentazione di bypassare il flusso IaC perché “si tratta solo di un piccolo cambiamento”. È proprio qui che non bisognerà lasciarsi prendere da quell’istinto e seguire le regole. Si rischia, altrimenti, di compromettere l’integrità dell’intero flusso IaC.
Fortunatamente, transizionare ad un approccio IaC può avvenire gradualmente. Il che ci dà l’opportunità di valutare, nel mentre, se e quanto è conveniente per il nostro specifico caso d’uso. Sì può, per esempio, cominciare da Ansible per la parte di configuration management, creando quindi le virtual machine in maniera manuale, per poi accoppiarlo con Terraform per poter automatizzare anche la creazione di quest’ultime. La cosa fondamentale sarà sempre rispettare a pieno i canoni dell’approccio IaC!
Condividi l’articolo!!
Scopri i nostri corsi!
Gianluca Recchia
DCA | CKA | AWS SAP | AAI Instructor
Trainer e consulente con forte background in programmazione e scripting. Ho formato numerosi studenti su argomenti riguardo il mondo Devops, dell’automation, delle cloud infrastructure e della system administration. Advocate per tecnologie open-source e open-standards, spendo la mia vita in una continua quest volta al rendere il mio workflow più efficiente e produttivo possibile.
