In questo articolo vedremo come sia possibile creare, in pochi minuti, un pool di risorse virtuali dalla console di gestione di Amazon EC2, con particolare riferimento alle istanze Windows e Linux.
Come abbiamo già trattato nel precedente articolo, Amazon offre servizi di cloud computing e specialmente di IaaS e PaaS. EC2 è il nome del servizio principe di IaaS di Amazon, che ci permette di allocare on-demand una potenza computazionale discretamente alta con un tasso di affidabilità considerevole. I principali competitor di un servizio del genere sono i fornitori di prodotti IaaS come: Microsoft (con la sua offerta Windows Azure), Google (con le sua macchine virtuali) ed anche aziende italiane del calibro di Aruba (con la sua offerta Cloud.it).
Perchè un utente dovrebbe scegliere uno o l’altro fornitore? È una domanda che mi viene fatta spesso e la risposta, se c’è, almeno per quanto riguarda lo IaaS, è molto complessa. Infatti lo IaaS è un genere di offerta molto “anonima” e molto sostituibile. Scegliere un fornitore di IaaS rispetto ad un altro è un pò come scegliere dove comprare lo stesso modello di stampante: che sia un negozio piccolo o un grande magazzino, che sia vicino o lontano, l’hardware che ci viene venduto è lo stesso e, al limite, il differenziale competitivo si gioca sul terreno dei servizi post-vendita.
È innegabile infatti che esistano aziende che, pur offrendo gli stessi prodotti, si giocano il margine di competitività sull’assistenza, sulla garanzia e/o, come spesso accade nel caso dei prodotti di Cloud Computing, sullo SLA (Service Level Agreement).
Scegliere l'istanza: Windows o Linux?
In un’offerta di IaaS, ciò che viene “venduto” è un noleggio di una fetta di risorsa hardware per un certo intervallo di tempo. A differenza dei noleggi tradizionali, nello IaaS il noleggio è quasi sempre su base oraria e non ci sono canoni fissi e/o costi di attivazione/disattivazione, pena il decadimento del concetto stesso di Cloud Computing. Considerando quanto sia semplice comprendere come questo modello di fatturazione possa essere applicato all’hardware (dividendo teoricamente il costo di una macchina rispetto alle risorse erogate), altrettanto facilmente lo si può fare con il software. Il software infatti può avere un minore o maggior costo di acquisizione: si pensi ad esempio al costo di una licenza di Microsoft Windows (diverse centinaia di euro) in confronto al costo di una licenza di Linux Ubuntu (costo quasi, se non totalmente, nullo). Il modello di billing con cui operano quindi i vendor di IaaS, è un modello basato sulla maggiorazione del prezzo orario di noleggio della risorsa, nel caso in cui essa abbia un sistema operativo a pagamento oppure uno gratuito.
Nel caso di AWS EC2, questo modello è sintetizzabile nella seguente tabella (da: http://aws.amazon.com/ec2/pricing/).
| Tipologia di istanza | Dimensione | Linux/UNIX (prezzo per ora) |
Windows Usage (prezzo per ora) |
|---|---|---|---|
| Standard On-Demand Instances | Small (Default) | $0.065 | $0.091 |
| Medium | $0.130 | $0.182 | |
| Large | $0.260 | $0.364 | |
| Extra Large | $0.520 | $0.728 | |
| Second Generation Standard On-Demand Instances | Extra Large | $0.550 | $0.780 |
| Double Extra Large | $1.100 | $1.560 | |
| Micro On-Demand Instances | Micro | $0.020 | $0.035 |
| High-Memory On-Demand Instances | Extra Large | $0.460 | $0.510 |
| Double Extra Large | $0.920 | $1.020 | |
| Quadruple Extra Large | $1.840 | $2.040 | |
| High-CPU On-Demand Instances | Medium | $0.165 | $0.225 |
| Extra Large | $0.660 | $0.900 | |
| Cluster Compute Instances | Eight Extra Large | $2.700 | $2.970 |
| Cluster GPU Instances | Quadruple Extra Large | $2.36 per Hour | $2.60 per Hour |
| High-I/O On-Demand Instances | Quadruple Extra Large | $3.410 | $3.580 |
Per un compendio sul significato, in termini di risorse e performance, delle diverse dimensioni di macchine sopra, si rimanda alla lettura dell’articolo precedente.
Dalla tabella sopra si deduce che il costo della licenza di sistema operativo per Microsoft Windows è “spalmato” su base oraria, incrementando considerevolmente la tariffa della macchina virtuale. Una istanza Micro infatti (la più piccola istanza disponibile in AWS) costa 2 centesimi di dollaro l’ora se ospita sistema Linux (in distribuzioni gratuite), mentre sale a 3,5 centesimi di dollaro l’ora se ospita Windows Server (2008, 2008R2 e 2012). L’istanza Micro inoltre è una particolare istanza facente parte dell’iniziativa di AWS chiamata Free Tier, ovvero un monte mensile di risorse gratuite disponibili a tutti gli utenti del servizio.
Nella logica Cloud infatti, ogni risorsa rappresenta un costo solamente relativo all'effettivo utilizzo, per cui è molto comodo stabilire dei “pacchetti” di consumo, così come farebbe un qualsiasi operatore di telefonia mobile ad offrire dei pacchetti "combo" Internet/Minuti/SMS.
Il Free Tier di Amazon EC2
Il primo anno di utilizzo del servizio, ogni cliente di AWS EC2 ha a disposizione queste risorse mensili, il cui consumo è gratuito fino al raggiungimento delle soglie. Un consumo superiore alle soglie definite sotto, comporterà un costo fatturabile al cliente AWS:
- 750 ore mensili per istanze Micro con SO Linux
- 750 ore mensili per istanze Micro con SO Windows
- 750 ore mensili di bilanciatore del carico con 15GB di banda inclusi
- 30GB mensili di storage SBS e 1GB di snapshots inclusi
- 15GB mensili di banda complessiva in uscita da ogni servizio AWS
Questa modalità gratuita ci permette quindi di testare il servizio senza incorrere in costi, anche utilizzando le risorse EC2 per servizi di produzione attivi H24 (infatti, 750 ore al mese bastano sempre per poter coprire qualsiasi mese poiché il mese più lungo dura 744 ore).
Passo per passo: creazione di un account
Il primo passo è creare un account su aws.amazon.com: processo alquanto banale. Basta seguire le istruzioni e compilare i dati sotto:
Una volta profilato l’utente (che se è in possesso di un account Amazon, può utilizzare le proprie credenziali precedentemente create), è necessario inserire i dati di carta di credito, al fine di poter sia verificare l’identità dell’utente, sia per ragioni di garanzia/deposito (pre)cauzionale: al di sopra delle soglie gratuite, il servizio è da intendersi come un servizio di produzione, con conseguente applicazione delle tariffe di listino.
Step-by-step: creazione di una istanza Windows
Una volta creato l’account abilitato a tutti i servizi a pagamento di AWS, è necessario recarsi nella AWS Management Console, link sempre disponibile in alto a destra nella home page di AWS. Atterrati nella console web, abbiamo a disposizione un menù dei servizi (in alto a sinistra), un menù dei datacenter (in alto a destra) e un dettaglio delle singole voci per il servizio selezionato (in un menù verticale a sinistra).
A questo punto, il nostro interesse volge alla creazione di una macchina virtuale, dapprima con sistema operativo Windows Server 2012 a 64bit. Lanciamo quindi il wizard “Launch instance”:
Proseguiamo quindi scegliendo una tipologia di istanza molto interessante, una macchina Windows Server 2012 a 64bit con preinstallato SQL Server Express su un volume EBS da 30GB. Se qualcuno si stesse chiedendo se il fatto di avere un altro software preinstallato comporti una maggiore spesa oraria, in questo caso la risposta è negativa, ma solamente poichè il software in questione (SQL Server Express) è un software messo a disposizione gratuitamente da Microsoft.
Diversamente sarebbe andata se avessimo scelto una macchina con SQL Server Standard, prodotto certamente a pagamento e che avrebbe influito quindi sulla maggiorazione della tariffa oraria dell’istanza stessa. A questo punto, procedendo, dobbiamo scegliere innanzitutto la dimensione dell’istanza, che nel nostra caso sarà di tipo Micro:
Possiamo poi decidere quante istanze tutte uguali attivare contemporaneamente (nella figura è scelto il valore 5 a titolo esemplificativo) e in che zona del datacenter collocarle. A questo proposito si ricorda che i datacenter di Amazon sono 8: tre negli Stati Uniti, uno in Europa, tre in Asia e uno in Sud America. Ogni datacenter a sua volta ha diverse “regioni” interne, ovvero diverse collocazioni seppur nella stessa sede.
A questo punto rimangono le ultime opzioni, come ad esempio la possibilità di abilitare un monitoring avanzato delle risorse (il prodotto CloudWatch, un SaaS a tutti gli effetti), di associare dati custom all’istanza e di impostare la politica di terminazione. La politica di terminazione è quella azione da effettuare nel caso l’utente spenga l’istanza dopo averla attivata. Sebbene sia molto intuitivo pensare che se l’istanza dovesse venire spenta, significherebbe l’equivalente di spegnere un computer, in realtà in AWS “spegnere” una istanza significa distruggerla, a meno di non indicare esplicitamente il contrario, proprio grazie all’opzione “Shutdown behavior” impostata a Stop (contrariamente a “Terminate”).
Nel caso sopra inoltre, a maggiore tutela della nostra istanza, chiediamo inoltre che, anche in caso di richiesta terminazione, ci venga presentata una speciale conferma dell’operazione, per evitare appunto, cancellazioni accidentali.
Ora è il momento di decidere le prestazioni del disco di sistema (considerando che si potrebbe incorrere in un maggior costo) e, soprattutto, gli eventuali dischi aggiuntivi oltre al primo da montare sull’istanza:
Una operazione utile è “taggare” le proprie istanze: nel caso infatti ci fossero centinaia o migliaia di istanze nel nostro pannello di gestione, una ricerca per tag sarebbe certamente comoda. Inoltre i tag creati sotto, sono anche delle label presenti nella griglia di gestione delle istanze, informazione utile anche nei casi più modesti di utilizzo di AWS:
Il passaggio successivo è infine di estrema importanza: si tratta di creare una coppia di chiavi per la mutua autenticazione verso l’istanza da creare. AWS infatti, genererà una nuova istanza codificando le informazioni di accesso (su ambienti Windows la credenziale amministrativa) con la chiave pubblica della coppia di chiavi, lasciando quindi la possibilità di decriptarne il contenuto solo a noi, in quanto detentori di quella privata.
Bisogna fare molta attenzione a dove si conserva la chiave privata poichè essa rappresenta la porta d’accesso alla nostra istanza. Prima di confermare la creazione dell’istanza dovremo impostare le regole di firewall, in modo da permettere perlomeno la gestione (via RDP su ambienti Windows) e successivamente l’accesso ai servizi (come SQL e/o HTTP(s)) da parte del mondo esterno.
Un breve sommario ci ricorda le impostazioni di lancio dell’istanza, dopodichè basta solo confermare e attendere una decina di minuti affinchè il sistema venga correttamente distribuito sulle risorse appena allocate e venga completato il bootstrap del sistema operativo.
Passo per passo: creazione di una istanza Linux
Siccome la creazione di una istanza Linux è un processo identico al precdente, varieremo un pò la ricetta introducendo un interessante elemento già superficialmente trattato nel precedente articolo. L’elemento interessante è il concetto di AMI, ovvero di immagine “preconfezionata” di sistema operativo pronto all’utilizzo, però fornito da terze parti piuttosto che da AWS stessa. Il caso che affrontiamo è quello di Bitnami, un popolare prodotto gratuito in grado di installare e configurare un intero stack applicativo (l’esempio più popolare è lo stack LAMP) in un singolo setup.
Bitnami mette a disposizione su Amazon delle AMI di terze parti che possono quindi essere riprese da chiunque, attraverso un codice, in modo da poter utilizzare il sistema operativo preconfigurato ed ottimizzato per l’uno o l’altro scopo.
Una volta scelto il codice dell’AMI (in questo caso la preferenza è su una AMI europea) scegliamo se affidarci ad uno storage transiente o di tipo EBS. Supponendo quindi di utilizzare EBS (preferibile, vista la necessità di MySQL sulla macchina da creare) annotiamo il numero “ami-68b4bc1c” corrispondente alla versione 3.5.1 di WordPress, già configurato in modalità Multisite.
Ora possiamo lanciare di nuovo il wizard di creazione di una istanza, stavolta però con qualche modifica rispetto al flusso precedente. Infatti, piuttosto che selezionare una AMI di Amazon (avevamo scelto una immagine Windows Server) preferiamo indicare di voler utilizzare una Community AMI con il codice ottenuto prima:
Da qui in poi il processo è identico a quello compiuto precedentemente, che ci porta ad avere una seconda istanza di dimensione Micro in esecuzione nella nostra dashboard. Vedremo ora come poter accedere alle istanze create.
Passo per passo: accesso ad una istanza Windows
Per accedere ad una instanza Windows è generalmente necessario un indirizzo IP e una coppia credenziali. L’IP, o meglio un DNS di test autogenerato dall’ambiente, lo possiamo reperire nel pannello di dettaglio di una istanza:
In questo caso è già possibile accedere all’istanza usando il nome DNS:
ec2-79-125-97-75.eu-west-1.compute.amazonaws.com
Volendo piuttosto assegnare un IP statico alla nostra istanza, possiamo recarci nel pannello di gestione degli Elastic IPs e allocare un nuovo IP:
A questo punto associamo il nuovo IP creato all’istanza Windows:
Ed ecco che ora la nostra istanza potrà rispondere protocollo RDP sull’IP sopra indicato. Mancano soltanto le credenziali amministrative, che possono essere raccolte dal pannello delle istanze, cliccando con il destro sull’istanza desiderata e:
Incollando nella finestra sotto il contenuto della chiave privata generata prima, otteniamo la password di accesso.
Ed ora possiamo connetterci all’istanza con Remote Desktop Connection:
Passo per passo: accesso ad una istanza Linux
L’accesso remoto ad una istanza Linux è, di default, un accesso SSH. Nel caso corrente, non è necessario ottenere le credenziali di root della macchina, poichè essa utilizza un metodo di autenticazione diverso. SSH infatti supporta metodi alternativi di autenticazione come, in questo caso, l’utilizzo di un certificato. E quale migliore certificato se non quello utilizzato in fase di creazione dell’istanza, ovvero la nostra chiave privata? Ora quindi possiamo armarci di un terminale SSH (in ambiente Windows è comodo usare PuTTY), indicare l’IP di connessione, l’eventuale nome utente (nel nostro caso per BitNami, è indicato che lo username di default è proprio “bitnami”) e il certificato.
Prima di procedere però notiamo che PuTTY necessita di un certificato in formato PPK e non PEM come in nostro possesso. Quindi otteniamo anche lo strumento PuTTYgen (sempre disponibile allo stesso indirizzo) dal quale generiamo, a partire dal PEM, il PPK corrispondente:
A questo punto apriamo PuTTY e compiliamo l’host destinazione:
Andiamo poi nelle impostazioni avanzate Connection => SSH => Auth e indichiamo dove si trova la chiave privata con estensione PPK generata poco fa:
E finalmente avremo accesso alla nostra istanza Linux, in questo caso già preconfigurata con una installazione WordPress Multisite, PHP, MySQL e Apache.
Conclusioni
In questo articolo abbiamo visto come creare istanze Windows e Linux utilizzando il Free Tier di AWS per i nuovi clienti. Abbiamo inoltre affrontato il problema dell’accesso remoto alle macchine, sia in RDP (per Windows) che in SSH (per Linux).
