Google Cloud Platform e Amazon Web Services mettono a disposizione moltissime infrastrutture diverse su cui far girare un'applicazione web. Mettere mano a un nuovo servizio, però, può intimidire. Quando si comincia a familiarizzare con un servizio, di solito conviene avviare un'istanza minima direttamente da riga di comando.
In questo articolo vedremo come prendere dimestichezza in tempi rapidi con nove servizi di Google Cloud e AWS grazie ai "Quickstart" che ho realizzato. In questo contesto, un Quickstart è uno script di basso livello che porta allo stadio "Hello World!" del servizio corrispondente, aiutando al tempo stesso a comprendere i processi sottostanti che hanno permesso di arrivarci.
Questi Quickstart aiutano a superare con facilità la prima fase scoraggiante, in cui si capisce poco o nulla della tecnologia, per arrivare al traguardo rassicurante in cui si può finalmente dire: "Funziona!". Da quel momento in poi si possono aggiungere, in modo incrementale, le altre funzionalità che si vogliono esplorare.
I principi alla base dei Quickstart
Ogni Quickstart è costruito secondo gli stessi principi: tutti sono automatizzati, minimali e completi.
Automatizzati
La GUI va bene per dare una prima occhiata, ma per la fase "Hello, World!" gli script sono più efficaci, perché permettono di distribuire ripetutamente lo stesso servizio mentre si apportano modifiche e si aggiungono funzionalità.
Minimali
Gli script "Hello, World!" sono minimali: il codice strettamente necessario per ottenere la risposta HTTP.
GCP utilizza il termine "Quickstart" per indicare un tutorial che illustra il percorso più rapido per mettere in funzione una specifica tecnologia. Il mio repository semplifica ulteriormente l'approccio concentrandosi sugli script eseguibili, in genere ancora più snelli di quanto si trovi in articoli di questo tipo.
In AWS, un Quick Start è un template CloudFormation che mette in funzione una specifica tecnologia. È utile, ma ho preferito creare degli script di shell perché aiutano a capire i comandi di più basso livello: un aspetto importante quando, in un secondo momento, si passa a costruire un sistema completo.
Mi piace pensarli come dei Quickstart ancora più rapidi.
Completi
Gli script distribuiscono tutto il necessario, compresi ruoli IAM, cluster e così via. Gli unici prerequisiti sono gli strumenti da riga di comando e l'autenticazione su un account cloud. Una volta soddisfatti, l'obiettivo è avviare tutto ciò che serve. Se qualcosa va storto, si può ripartire da zero senza dover capire come riportare ogni singolo componente a uno stato stabile.
Preferibilmente, gli script sono ri-eseguibili e consentono quindi di distribuire nuovo codice sopra una distribuzione precedente. Alcuni degli script qui presentati lo sono, altri no, perché aggiungere questa capacità avrebbe richiesto troppo codice. In quei casi, eliminate la vecchia istanza prima della ridistribuzione, oppure avviate ogni nuova versione con un nome diverso. (Ma attenzione ai costi! Cancellate le vecchie istanze appena possibile.)
Prerequisiti
Il README di ogni directory descrive i prerequisiti, tra cui:
gcloud, autenticato (congcloud init)- Lo strumento AWS CLI con le credenziali.
- Un plugin di AWS CLI dedicato a Lightsail
- Lo strumento
ebdi Elastic Beanstalk. - Lo strumento
ecs-cliper ECS, che però viene installato automaticamente dallo script. - Per elaborare l'output dei comandi, alcuni script richiedono
envsubst(lo si installa con il pacchettogettext) ejq.
Le infrastrutture supportate
Ecco gli script che ho creato per:
- AWS Elastic Beanstalk
- AWS Lambda
- Amazon Elastic Container Service
- Amazon Lightsail
- Google App Engine Standard Environment
- Google App Engine Flexible Environment
- GCP Cloud Functions
- GCP Cloud Run
- Google Kubernetes Engine
Script
Il repository git contiene uno script deploy.sh per ciascuna tecnologia di infrastruttura, organizzato in sottodirectory. Per chi ha spirito d'avventura, è possibile eseguirli tutti insieme tramite run_all.sh nella directory principale.
Se trovate utile questo lavoro e volete vederne altri, inviate una pull request con il vostro script, oppure aprite una issue per richiedere il vostro servizio preferito.
Un buon passo successivo sarebbe Elastic Kubernetes Service, seguito da EC2, Google Compute Engine e le offerte di altri cloud provider.
Differenze di semplicità
Le tecnologie di infrastruttura si differenziano per semplicità e flessibilità.
In App Engine Standard Environment e Cloud Functions, lo script si riduce a un singolo comando deploy, seguito dall'accesso a un URL noto. In altri casi la complessità è maggiore. Cloud Run ed ECS, ad esempio, richiedono di costruire un container e farne il push, mentre Lambda necessita anche di un ruolo IAM.
Si tratta comunque di differenze non determinanti. Una volta che "Hello, World!" è in esecuzione, questi script aiutano ad automatizzare e nascondere la complessità.
Approfondimenti
Per una spiegazione dei passaggi che portano a "Hello, World!", consultate i Quickstart o gli articoli "Getting Started" linkati in ciascun README.