Un’approfondita analisi condotta da Giulio Destri su come affrontare le problematiche di gestione di infrastrutture IT basate su software open source

[section_title title=La soluzione è open source? Parte 5]

Metodologie di gestione di infrastrutture basate su open source

Se analizziamo i servizi IT forniti al business, vediamo che questi si compongono di applicazioni, il cui funzionamento si basa su

  • Librerie e framework di librerie (come, ad esempio, Hibernate nel caso di Java)
  • Software infrastrutturale (come, ad esempio, Apache e MySQL)
  • Sistema operativo (Linux o BSD, nelle loro varie versioni).

Il primo passaggio è quindi la costruzione di matrici di dipendenza, ovvero matrici di configuration item, che, per ogni applicativo stabiliscano le dipendenze dalle opportune versioni dei software suddetti.
Il processo completo di costruzione di un ambiente applicativo di fornitura di servizi prende allora questa forma:

  • Individuare con precisione i servizi richiesti e le applicazioni che li compongono
  • Definire quali servizi che l’ambiente operativo da costruire dovrà contenere
  • Individuare ed usare soltanto hardware supportati
  • Mettere in opera il sistema con procedure documentando i passaggi
  • Notare tutte le caratteristiche
  • Collaudare il sistema

Poi, in funzione dell’uso del sistema, si può definire la sua politica di aggiornamento.

Se i servizi sono interni alla intranet e quindi protetti da firewall, accessibili solo via VPN ecc… allora la gestione deve essere orientata alla stabilità, con una bassa necessità di aggiornamenti. Infatti, molti sistemi aziendali come i file server, i DBMS server ecc… non vengono quasi aggiornati o vengono applicati solo i pochi aggiornamenti automatici delle distribuzioni che sono veramente raccomandati per migliorare la stabilità.
Ben diversa è la situazione quando i servizi sono esposti su Internet. Ad esempio siti Web, applicazioni Web offerte come SAAS, servizi Web ecc… In questo caso le problematiche di security impongono aggiornamenti frequenti. E non sempre gli aggiornamenti dei pacchetti delle distribuzioni coprono rapidamente problemi di security, mentre potrebbero farlo più rapidamente i produttori dei singoli moduli. Ad esempio, l’Apache Consortium aggiorna ogni due-tre mesi il server Web Apache inserendo correttivi di sicurezza e miglioramenti, ma le distribuzioni più stabili come Red Hat recepiscono questi cambiamenti solo raramente. Ecco quindi la possibile necessità di aggiornamenti “manuali” che vanno accuratamente gestiti.
Per queste ragioni diventa indispensabile disporre di un ambiente di test, che potrebbe anche essere costituito da macchine virtuali, su cui fare tutte le prove di corretto funzionamento delle applicazioni che formano i servizi in occasione dei cambi di versione dei componenti dell’infrastruttura.
In sede di progettazione di un servizio allora occorre porsi le opportune domande per definire la piattaforma dove opererà o dove lo si vuole trasportare nel caso di migrazioni:

  • L’hardware su cui si vuole installare il sistema è supportato?
  • Le librerie integrate sono compatibili con le applicazioni?
  • Il software infrastrutturale integrato è compatibile con le applicazioni?
  • Sono necessari altri componenti non già compresi nella distribuzione?
  • Esistono i package per la distribuzione con tali componenti?

E se si devono aggiungere componenti non presenti nella distribuzione, come per esempio librerie speciali?

Qui sono possibile essenzialmente tre strade:

  1. Cercare una installazione pacchettizzata dei componenti, che possa essere installata tramite le utility di sistema operativo (ad esempio, nel caso di Red Hat, il programma rpm);
  2. Scaricare un precompilato in formato non pacchettizzato; ad esempio il Java di Oracle è disponibile per Linux in un formato auto esplodente che prevede di installarlo manualmente in una cartella a scelta dell’amministratore di sistema;
  3. Scaricare e compilare i sorgenti del componente.

La compilazione da zero di sorgenti è potenzialmente complessa. Infatti, se la maggioranza dei componenti viene organizzata dagli autori secondo una struttura standard, basata sui file di autoconfigurazione che creano dei makefile, ossia i file di gestione della compilazione, adattati all’ambiente dove il software sarà installato, esistono anche componenti la cui struttura è non standard e quindi la compilazione va studiata ad hoc.

Tutte le azioni di cui sopra devono essere poi opportunamente procedurizzate e documentate: in ambiente di test, bisogna determinare tutti i passaggi delle procedure per fare aggiornamenti ed installazioni, per poi costruire procedure operative con tutti i comandi. Dalle procedure si potranno eventualmente ottenere anche script che realizzano il tutto in automatico.
Le procedure dovranno poi essere periodicamente validate con le nuove versioni del software.
Il processo di compilazione potrà anche servire come procedura di disaster recovery con la necessità di ricostruire le infrastrutture da zero.

Per leggere una case study consultare la pagina sucessiva