 dei Security Group per consentire l'accesso ad IP dinamici.

Le nostre infrastrutture sono progettate per restare isolate in una sottorete privata della VPC, questo per aumentare il livello di sicurezza e bloccare ogni tipo di accesso indesiderato direttamente dal layer network. Per ragioni varie di gestione, verifiche e troubleshooting abbiamo la necessità di accedere alle risorse contenute in queste infrastrutture isolate.

La soluzione comune per questo tipo di setup è 

, ovvero un'istanza EC2 esposta al mondo che consente di accedere alle altre risorse isolate. Per bloccare eventuali accessi indesiderati utilizziamo un sistema di whitelist tramite le regole di 

 del security group dell'istanza bastione. Ogni accesso SSH è bloccato se non determinati IP che vengono manualmente aggiunti a richiesta.

Questo sistema è molto robusto: delega il controllo dell'accesso al security group, una risorsa gestita da AWS, così facendo non dobbiamo farci carico dell'onere di configurazioni del sistema (ad esempio iptables) e gestire varie ed eventuali patch di sicurezza.

Questa soluzione è ottima quando si parla di IP statici, viene fatta una richiesta al team DevOps di aggiungere in whitelist un determinato IP e questo viene aggiunto tra le regole di 

 per la porta specifica del servizio richiesto (porta 22 per l'accesso SSH). Questo funziona bene quando la richiesta di accesso proviene da altre infrastrutture oppure uffici o coworking che dispongono di un IP fisso.

Essendo la nostra azienda distribuita ed adottando il regime di 

 spesso e volentieri gli sviluppatori oppure il team DevOps si collegano da network con IP dinamici. Questo vuol dire gestire di continuo le regole del security group dell'istanza bastione togliendo ed aggiungendo IP quasi quotidianamente.

Dopo aver vagliato alcune soluzioni abbiamo deciso di adottare un sistema serverless basato su API Gateway e Lambda che in automatico aggiunga l'IP in whitelist sul security group. Per entrare più nel dettaglio: abbiamo esposto un'API HTTP usando il servizio API Gateway di AWS che, ricevuta una richiesta HTTP, innesca l'esecuzione di una Lambda. Quest'ultima recupera l'IP del chiamante dall'evento in input e modifica le regole di 

 del security group per permettergli l'accesso in SSH.

Di per sè il sistema è molto semplice ed essendo basato su servizi serverless, con un traffico molto ridotto, il costo è nullo. Il codice della Lambda è molto semplice:

Come si può notare, per verificare la provenienza della richiesta abbiamo optato per passare un determinato token come un parametro del path. Questo perchè volevamo che l'utilizzo di questo endpoint fosse il più semplice possibile e in questo modo possiamo aprire direttamente un link simile a questo: https://xxxxxxxxx.execute-api.us-east-1.amazonaws.com/stage/whitelist/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

direttamente nel browser senza dover impostare un header particolare (ad esempio 

 utilizzando il sistema build-in di API Gateway) che avrebbe necessitato, ad esempio, una chiamata curl da terminale.

La configurazione di questo token, ID del security group, protocollo, porta e descrizione viene fatta tramite variabili d'ambiente, in questo modo possiamo eseguire il deploy dello stesso codice della Lambda per ambienti ed infrastrutture diverse.

 (incrementabile fino a 1000 tramite una richiesta ad AWS) che potrebbe venire colpito dopo alcuni mesi di utilizzo del sistema. In aggiunta, questo sistema automatico viene utilizzato esclusivamente da chi si connette utilizzando un IP dinamico, questo vuol dire che l'IP verrà riassegnato a qualcun'altro e deve quindi essere rimosso dalla whitelist.

La soluzione che abbiamo adottato è quella di aggiungere un'altra Lambda, questa volta scatenata da un evento schedultato di CloudWatch, che andrà a ripulire le regole del security group.

Ovviamente non vogliamo che vengano rimosse anche le regole impostate manualmente per gli IP statici: causerebbe altrimenti un blocco involontario degli accessi di integrazioni di terze parti. Per risolvere questo problema utilizziamo come discriminante la descrizione della regola, impostata tramite la variabile d'ambiente 

 nella Lambda descritta precedentemente. In questo modo andiamo a ripulire solamente le regole aggiunte tramite questo sistema automatico e concedendo al team DevOps di gestire lo stesso alcune regole manualmente.

Il codice della Lambda anche in questo caso è molto semplice:

Questo sistema soddisfa le nostre necessità ed ha un buon compromesso tra sicurezza e usabilità. Questo sistema concede solamente l'accesso da parte di un determinato IP verso il servizio SSH esposto dal bastione, ma non concede l'accesso alla macchina, chi si vuole connettere deve comunque utilizzare la propria chiave SSH personale.

Regole di ingresso per IP dinamici

Ingress rules for dynamic IPs

Negli ultimi anni personalmente non ho mai perso un’edizione di quello che considero 

il più importante evento in Italia dedicato all’e-commerce

. Vuoi perché è interessante vedere come evolve l’offerta di servizi che ruotano attorno a questo mondo in rapida evoluzione, vuoi perché è stato sempre un’ottima occasione per concentrare in un paio di giorni una serie di incontri con quei partner, prospect e clienti con i quali, per via della distanza territoriale, capita raramente di vedersi di persona.

Mai prima di oggi, però, avevamo preso in considerazione di partecipare come espositori per un motivo molto semplice: il servizio da noi erogato era principalmente legato allo 

sviluppo tecnologico sulla piattaforma Magento

 e, come potete immaginare, la richiesta portata dal solo passaparola è sempre stata ben superiore all’offerta che potevamo mettere a disposizione con un team in crescita costante, ma organica al fine di preservare il livello di competenza e qualità. In una situazione come questa farsi conoscere da un pubblico più ampio rischia di essere più controproducente che altro. Qualche tempo fa avevo scritto anche 

Prima per offrire un servizio di qualità ai nostri clienti, poi come effettiva opportunità di business, nel corso degli ultimi anni in Bitbull abbiamo iniziato a maturare competenze sempre più verticali sulle infrastrutture cloud e, in particolare, sfruttando i servizi forniti da Amazon Web Services. Questo tipo di soluzione si è dimostrata ideale per coprire le esigenze di scalabilità, affidabilità e distribuzione territoriale di chi con l’e-commerce si trova a dover sostenere numeri sempre più importanti sia per quanto riguarda il traffico sia per quanto riguarda l’acquisizione di ordini.

Un percorso, il  nostro, che ha avuto  una naturale evoluzione l’anno scorso, il 2018, anno in cui siamo diventati ufficialmente partner. Questo  passo, di fatto, ci ha consentito di aprire un dialogo diretto con AWS e ci ha permesso di cogliere l’opportunità di presentarci insieme all’edizione 2019 del Netcomm Forum.

Lo scopo principale della nostra partecipazione è quello di presentare un servizio per il quale ci siamo resi conto non esserci molta concorrenza in Italia, il cui valore risiede principalmente nell’unire le 

 su una determinata piattaforma e-commerce (ad oggi Magento, ma stiamo ampliando l’offerta ad altre soluzioni) alle 

 verticali su uno strumento leader mondiale nei servizi in cloud. Come spesso succede, quando ci si affaccia al mercato lavorando bene in un determinato ambito, le opportunità si allargano anche ad altri settori, motivo per cui oggi ci ritroviamo a gestire infrastrutture che vanno anche oltre al mondo dell’e-commerce.

Come potrà notare chi passerà a farci visita al nostro stand, puntiamo molto sul tema dell’

. Pur avendo un forte background tecnologico, ci siamo resi conto in questi anni di quanto la tecnologia, a seconda dell’utilizzo che se ne fa, possa incidere tanto positivamente quanto negativamente in un rapporto costi / benefici nel 

Un uso intelligente e pragmatico degli strumenti che oggi abbiamo a disposizione può portare enormi benefici non soltanto al processo di vendita attraverso il canale digitale, ma anche nell’ottimizzazione di tutta una serie di processi ad esso correlati che vanno dalla logistica all’amministrazione, dalla gestione del proprio catalogo fino al customer care. Una visione a 360° permette quindi di portare l’investimento tecnologico ad essere funzionale sia ad una riduzione dei costi di gestione, sia ad un’ottimizzazione dei processi che impattano su tutto l’ambito aziendale.

Questa consapevolezza ci ha fatto capire che il valore che possiamo portare va oltre a quello del “semplice” partner tecnologico, abbiamo quindi iniziato a proporre un 

 che  sta portando riscontri particolarmente positivi da parte dei nostri clienti, ormai costretti a doversi confrontare con un mondo in rapida evoluzione che impone un ripensamento di attività consolidate da anni, ma talvolta incompatibili con le attuali esigenze del mercato.

Quando decidiamo di fare un passo in genere preferiamo non limitarci al semplice compitino, quindi abbiamo deciso di tenere anche un workshop per raccontare tramite un caso reale come, utilizzando i giusti strumenti, è possibile migliorare le prestazioni ed ottenere una maggiore stabilità ottimizzando contestualmente i costi. Il tutto senza cambiare il fornitore dei servizi in cloud, ma sfruttando al meglio le caratteristiche e le opportunità che esso offre.

Per maggiori informazioni vi rimando alla 

, la speranza ovviamente sarà quella di potervi accogliere numerosi! :)

Sul perché quest’anno saremo presenti al Netcomm e perché lo saremo insieme ad Amazon Web Services

? Io davvero tante, troppe forse, quindi ho deciso di intraprendere questo viaggio alla scoperta di questa nuova tecnologia.

Preparo quindi lo zaino, gli scarponi, corda, imbraghi e parto..

Fuori è una giornata uggiosa, autunnale, il clima giusto per restare in casa con una tazza di caffè e il notebook. Click sul mio fido compagno Firefox, da dove iniziare? Prima di tutto devo scegliere quale provider cloud usare.. 5 secondi per pensare.. AWS ovviamente.

Le prime ricerche mi portano a centinaia e centinaia di articoli di blog, davvero tanto tanto materiale. Cerco di fare un riassunto così mi autoconvinco di aver capito:

Avete presente i server? Quei computer strani, in stanze buie, ecco, non vanno più di moda.. perchè? Sono difficili da gestire, devi usare mille accortezze, gruppi di continuità nel caso vada via la luce, la temperatura giusta, assolutamente niente polvere, porte tagliafuoco, sistemi antincendio con argon etc..etc.. quindi per garantire un servizio stabile senza venirne matti e spendere un sacco di soldi ecco che servizi come AWS, Google Cloud, Azure e molti altri "affittano" parte dei loro data center, a te rimane solo da configurare l'infrastruttura con qualche click e preoccuparti solo della parte software.

Dopo questo grandioso passo avanti arrivano altri problemi (e ovviamente a nessuno piacciono), devi tenere aggiornato il sistema operativo installato nei tuoi server virtuali, installare le patch di sicurezza, configurare uno scaling delle risorse computazionali, ridondare l'infrastruttura in modo da garantire un'alta affidabilità del servizio e tutto quanto, quindi cosa si sono inventati i cloud provider per venire in contro? Gestire alcuni dei servizi come MySQL, Elasticsearch, Redis, RabbitMQ e molti altri, servendoti direttamente l'accesso senza che tu ti debba occupare di installare e aggiornare tali servizi, ovviamente la configurazione (anche se un po' limitata) è sempre possibile.

Dopo questo ultimo passo avanti rimane ancora il problema delle macchine virtuali che faranno girare il tuo software (sempre lo stesso problema riportato sopra) quindi qual è il prossimo step? Il Serverless! Ovvero piattaforme gestite dove l'unica cosa di cui ti devi preoccupare è il tuo codice, nient'altro, è il provider cloud che si occuperà automaticamente di scalare, aggiornare i sistemi operativi che ospita il tuo codice e garantirne l'affidabilità.

Server-less non vuol dire che non ci sono i server ma che non li gestite voi :)

Dopo lo studio iniziale fatto ieri, oggi è il giorno del test pratico! Ci sono molte guide che spiegano come creare una semplice API usando i servizi di AWS, però i passaggi di attivazione dei servizi vengono fatti direttamente dalla console web, per quanto sia comodo non permette di riprodurre facilmente gli step di configurazione e le modifiche non sono tracciate. AWS mette a disposizione un servizio chiamato 

 con cui, descrivendo l'infrastruttura con un file JSON o YAML puoi fare il provisioning di tutte le risorse che ti servono in un colpo solo, gestire gli aggiornamenti e rollback in caso di errore.

Certo che scrivere un enorme file JSON o YAML non è comodissimo, quindi ho cercato quali framework AWS mette a disposizione:

Sinceramente ho trovato un po' di confusione su cosa usare ma il consiglio è: SAM per servizi API, Mobile CLI da evitare, Amplify per applicazioni più complesse dotate anche di frontend. Ho puntato quindi su quest'ultimo, per provare l'esperienza completa e vedere le novità.

Molto molto facile da usare, forse anche troppo, basta scaricare la cli

entrare nel cartella principale della vostra applicazione web e aggiungere Amplify come dipendenza

e come ultimo step inizializzare lo stack base di CloudFormation dove verranno create giusto un paio di regole di accesso e poco altro

Ora arriva la parte davvero divertente, aggiungere i servizi di cui la nostra applicazione ha bisogno, la CLI di Amplify userà sempre degli step guidati per farteli configurare. Facendo una panoramica di cosa si può aggiungere vediamo:

Wow! C'è praticamente tutto e si può aggiungere con un semplice comando

e una volta configurato il servizio selezionato fare il deploy delle modifiche

Veramente bello, alcuni servizi li conoscevo già come 

Amplify è davvero un gran strumento, soprattutto per le integrazioni con React, AngularJS e Vue.js che ti permettono di collegare i servizi con rapidità usando il framework che più ti piace. Ci sono voluti 15 minuti per avere una semplice applicazione (sì, la solita vecchia TODO list) up&running, però se non ci si sporca le mani infilandole nel motore non mi sento del tutto soddisfatto.

Comincio allora ad integrare la mia applicazione scritta in 

 partendo dall'autenticazione. La configurazione di Cognito viene semplificata davvero tanto:

1 minuto ed è tutto pronto per gestire le utenze.

Mi sono stupito di quante funzionalità offra Cognito: conferma della mail e/o numero di telefono attraverso un codice (via SMS per il telefono), login con Google, Facebook, Amazon e OpenID, fino a servirti su un piatto d'argento un server OAuth2 completo. Creare questo, da zero, con un server PHP o NodeJS almeno 1/2 giornate di lavoro sarebbero servite, pensare di averci messo 1 minuto è pazzesco.

Veniamo ora alla base dati, avevo già usato in passato DynamoDB per alcune integrazioni, ma mai in combinazione con 

, un servizio abbastanza recente (non ha più di 1 anno e mezzo) che aiuta a gestire l'accesso ai tuoi dati usando endpoint GraphQL. È il caso di dirlo: all'ultima moda!

Con Amplify è stato davvero semplice, bisogna certo avere un po' di esperienza con GraphQL.

la risposta di questo comando parla chiaro:

? Please select from one of the below mentioned services (Use arrow keys)
❯ GraphQL
 REST

non solo endpoint GraphQL ma anche REST! un passo avanti per scegliere il metodo di autenticazione

? Please select from one of the below mentioned services GraphQL
? Provide API name: myNotesApi
? Choose an authorization type for the API (Use arrow keys)
❯ API key
 Amazon Cognito User Pool

si possono usare sia delle chiavi statiche (generate durante questo processo) oppure andare ad utilizzare il sistema di autenticazione creato prima con Cognito, ovviamente scelgo quest'ultima opzione.

Oggi ho iniziato a scrivere i modelli per la mia applicazione. Una delle funzionalità più comode di Amplify è la generazione automatica dei resolver di GraphQL, addirittura con dei 

 per poter specificare il livello di accesso. Questa ultima parte è vitale per limitare l'accesso degli utenti solo ai loro dati e non all'intera tabella di DynamoDB.

Qui è sorto il primo problema, ho cercato di seguire fedelmente la documentazione ma niente, controllando i resolvers generati non vedevo differenza utilizzando oppure no il trasformatore 

. Ho perso parecchio tempo su questo finchè, arreso, ho creato una 

 sul respository di Github per chiedere supporto, mi hanno risposto veramente in fretta e si è scoperto che effettivamente non stava proprio funzionando... va bene, cose che possono succedere.

Durante il debug ho scoperto che gli indici delle tabelle di DynamoDB venivano creati con il 

 per Reads and Writes a 5, senza possibilità di essere modificato.

Per chi non lo sapesse, questo valore è uno dei parametri che viene utilizzato per calcolare il costo del servizio di DynamoDB: il numero di accessi in lettura o scrittura al secondo (non così semplice ma non mi addentro del calcolo). Per non scendere troppo nei dettagli, questo database non relazionale risponde per ogni query alla massima velocità possibile indifferentemente dal quantitativo di dati e non c'è limite al numero di righe (paghi per il peso in GB della tabella). La parte negativa è un motore di query un po' ostico e bisogna creare con attenzione gli indici della tabella, vitali per ordinamento e query.

Tornando a noi, non mi aspettavo quindi che per qualsiasi test si pagasse da 13$ in sù di fattura, un po' tantino visto che con meno di 1$ ho 2 progetti di IoT, una action di GoogleHome, il mio sito web (con due ambienti) e uso S3 per fare un backup criptato di alcuni file importanti. Con giusto 5/6 modelli arrivavo a cifre spropositate, con un tabella di DynamoDB pronta per la produzione quando ancora l'applicazione non era nata. Ho quindi aperto un'altra 

, questa volta non ancora presa in considerazione.

Ho quindi eliminato il progetto e mi sono perso, avevo trovato uno strumento molto facile da usare e potente però è ancora troppo giovane per poter essere usato. Essendo così semplice non permette neanche una modifica così profonda di alcune sue parti se non con diversi workaround.

Seguono diverse sere passate a valutare alternative.

Nel corso delle giornate ho collezionato diverse alternative ad Amplify, difficile trovarne perchè non ci sono altre CLI che con un paio di comandi fai TUTTO.

, un framework molto potente e modulare con una grande community dietro che sviluppa centinaia di plugin. L'ho già usato in precedenza per alcuni progetti di automazione di infrastrutture cloud ed API e ne sono sempre stato soddisfatto.

Organizzare bene la struttura del progetto

La gestione delle risorse usa direttamente i template di CloudFormation, questo garantisce di essere sempre aggiornata ed utilizza le funzionalità servite da AWS senza doversi riportare le modifiche all'interno del framework (un esempio, 

 usa la sua sintassi, la sua integrazione ai servizi, non riesce a stare al passo con gli aggiornamenti e ho trovato sempre decine di bug).

Quando ci sono molte risorse da aggiungere fuori da quelle gestite da Serverless la 

 spiega come crearle all'interno del file, non fate l'errore di mettere tutto all'interno di un solo file di 2000 righe difficile da mantenere, meglio spezzarlo in più file

resources:
 - ${file(resources/cognito.yml)}
 - ${file(resources/userRole.yml)}
 - ${file(resources/queues.yml)}
 - ${file(resources/tables/todos.yml)}
 - ${file(resources/tables/projects.yml)}
 - ${file(resources/tables/categories.yml)}
 - ${file(resources/outputs.yml)}

e poi all'interno di questi file specificare le risorse

Resources:
 AccountTable:
   Type: AWS::DynamoDB::Table
   Properties:
     TableName: "${self:service}-${self:provider.stage}-${self:custom.todosTableName}"
     AttributeDefinitions:
       -
         AttributeName: userId
         AttributeType: S
       -
         AttributeName: id
         AttributeType: S
     KeySchema:
       -
         AttributeName: userId
         KeyType: HASH
       -
         AttributeName: id
         KeyType: RANGE
     ProvisionedThroughput:
       ReadCapacityUnits: 1
       WriteCapacityUnits: 1
     StreamSpecification:
       StreamViewType: "NEW_AND_OLD_IMAGES"

in questo modo il codice sarà molto più organizzato e i file più piccoli e mantenibili.

Usare un file separato per le configurazioni

Il discorso precedente vale anche per le configurazioni del progetto, meglio specificare un file separato in modo da poterlo cambiare a seconda dell'ambiente o progetto senza usare centinaia di variabili d'ambiente

service: MyService
custom: ${file(./config.yml)}

provider:
 name: aws
 runtime: nodejs8.10
 stage: ${opt:stage,self:custom.env}
 region: ${self:custom.region}

il file di configurazione diventa molto più facile da visualizzare

env: "Stage"
region: "eu-west-1"

todosTableName: "Todos"

Attirato da Amplify ad usare GraphQL ho subito iniziato ad usare 

, facile da usare e con un po' di organizzazione e riuso dei resolvers sono arrivato ad un buon punto. Mi sono accorto però che stavo scrivendo davvero tanto codice, troppo, ciò voleva dire mantenerlo, testarlo, ottimizzarlo e portava via tanto tempo nel creare una semplice funzionalità CRUD per i modelli.

Mi è sorto un dubbio: mi servono davvero delle API in graphQL? Certo sono davvero comode, espressive e facili da tenere aggiornate ma perchè? Più nello specifico: mi servono delle API da consumare? Le API vengono usate principalmente per accedere alla base dati, aggiungere della logica server-side (che l'utente non può manipolare) e rendere fruibile il servizio a servizi terzi.

DynamoDB ha una sua funzionalità build-in per limitare l'accesso a righe, colonne ed operazioni in base all'utente, ovvero un utente può vedere solo determinati attributi dell'oggetto salvato (le "colonne"), accedere solamente agli oggetti che lui ha creato (le "righe") e leggere alcune tabelle senza la possibilità di modificarle, tutto questo identificando l'utente tramite l'autenticazione di Cognito.
Cosa vuol dire? Che ha un sistema di sicurezza per l'accesso CRUD già servito, senza dover mettersi a fare questi controlli via codice, è già fatto! È AWS a garantirti questa sicurezza, pensi di essere TU sviluppatore a fare meglio del team di 100 sviluppatori Amazon? Potresti, ma nel 99% dei casi starai tralasciando qualche vulnerabilità.

Si può dire tutto sull'ecosistema AWS a seconda dei pareri, che sia scomodo, costoso, ostico, complicato ma non si può dire che non sia sicuro, quindi ok, delego a loro questa parte.

Nota a margine: una volta autenticato un utente con Cognito può accedere a qualsiasi risorsa AWS limitandone l'accesso e operazioni tramite le 

, non tutte le risorse supportano una granularità come DynamoDB ma già solo per l'upload di file il servizio S3 può farlo (pensate all'avatar dell'utente per esempio, comodo!).

Mi serve? Cosa sto facendo che devo nascondere all'utente? Se già so che lui accederà solo alle sue righe, al massimo, sta spaccando la formattazione dei suoi dati, beh, non potrà visualizzarli correttamente.

Sicuro prima o poi ci sarà la necessità di chiamare servizi terzi per aggiungere qualche funzionalità, non c'è problema, con 

 dove poter fare tutto quello che si vuole, gli eventi che possono scatenare questa logica custom sono infiniti: dalla creazione o modifica di oggetto in DynamoDB all'upload di un file su S3, perfino tutto il flusso di autenticazione/registrazione/conferma degli utenti Cognito, non serve altro.

Serve già? Abbiamo già dei partner che chiedono di poter sfruttare i nostri servizi? se la risposta è sì, è possibile creare tutto il comparto API che si vuole con Serverless 

 creando solo gli endpoint che servono, altrimenti si può saltare benissimo questa parte.

 è un servizio di AWS che permette di organizzare endpoint di API e manipolare parametri

No, non mi servono per il momento. Ho voluto dare un'altra possibilità ad Amplify e uso direttamente il client per accedere a DynamoDB e usare le risorse AWS che mi servono. Molto pulito e davvero semplice da usare.

In ogni caso per l'autenticazione all'endpoint delle API si può usare sia direttamente Cognito (utile nel caso vengano chiamate dalla stessa applicazione che serve il login) delle chiavi fisse e un access key generato 

. Questa ultima opzione rende molto professionale l'endpoint utilizzando la sicurezza di un accesso OAuth2 e permette di configurare degli scope custom per regolare l'accesso alle risorse.

Messo in piedi il comparto backend è venuto il momento di cominciare a creare la parte di frontend. Non ho avuto molti dubbi sulla tecnologia da usare, avendo abbastanza esperienza con 

 ho deciso di scegliere questo framework.

 è stato immediato lo startup del progetto

e seguendo la procedura guidata ho scelto una configurazione molto semplice e poi salvata come preset. La configurazione da inserire nel file 

{
 "packageManager": "npm",
 "useTaobaoRegistry": false,
 "presets": {
   "vue-router-vuex": {
     "useConfigFiles": true,
     "plugins": {
       "@vue/cli-plugin-babel": {},
       "@vue/cli-plugin-pwa": {},
       "@vue/cli-plugin-eslint": {
         "config": "base",
         "lintOn": [
           "commit"
         ]
       }
     },
     "router": true,
     "routerHistoryMode": true,
     "vuex": true,
     "cssPreprocessor": "stylus"
   },
 }
}

? È stata una scelta guidata dalla libreria di componenti che ho voluto utilizzare: 

. L'ho già usato per qualche progetto e mi sono sempre trovato bene, lo trovo molto completo per il quantitativo di componenti e, cosa molto importante, davvero molto personalizzabile.

Anche qui, grazie alle Vue CLI è bastato un comando per aggiungere questa libreria insieme ad alcune configurazioni di esempio

Il mio viaggio nel mondo serverless

My serverless journey

Scaling automatico e temporizzato di un database RDS Read Replica con Lambda e Route53

Una delle nostre infrastrutture in hosting su AWS di recente ha riscontrato qualche problema dovuto ad un enorme e rapido aumento di traffico durante alcuni orari prestabiliti, in concomitanza ad una newsletter che portava velocemente molti più utenti del solito a visitare l’e-commerce Magento.

Il numero di richieste fatte al nostro ElasticLoadBalancer passava da 400 a 3000 al minuto in meno di 5 minuti, questo non ci dava il tempo di scalare sul momento l’infrastruttura prima che cadesse rovinosamente.
Da una nostra analisi abbiamo individuato il collo di bottiglia nel database, in particolare nelle query di lettura delle categorie e catalogo, dinamiche in base a varie configurazioni e basate sull’utente collegato.

Per tenere meglio sotto controllo il carico sul database abbiamo deciso di utilizzare due istanze RDS, una master per le operazioni di scrittura e una replica per le operazioni di lettura in modo da scalare solo la parte necessaria e tenere sotto controllo i costi.
Abbiamo notato un miglioramento ma lo stesso la read replica soffriva del carico e si saturavano velocemente le connessioni al database.

Per prepararci al traffico in arrivo, un’ora prima del picco di traffico cambiavamo il puntamento del database dalle configurazioni di Magento per non usare la replica. Finito lo scaling portavamo di nuovo la configurazione com’era in precedenza.

Questa soluzione funzionava correttamente ma era molto scomoda: per cambiare le configurazioni di Magento dovevamo svuotare la cache e questo comportava un ulteriore carico alle prime visite successive del sito in aggiunta al fatto di dover fare le procedure manualmente con il rischio dell’errore umano.

La soluzione che abbiamo adottato per non dover modificare le configurazioni di connessione al database di Magento è stata quella di utilizzare dei DNS interni alla VPC gestiti con Route53 mappando gli hostname delle istanze RDS con nomi di dominio, utilizzando dei record CNAME, così da inserire quest’ultimi nelle configurazioni di magento.

In questo modo abbiamo il controllo del puntamento dell’applicativo web al database in maniera agnostica alle sue configurazioni. Questo ci permette di redirigere le connessioni della read replica verso il master durante lo scaling per non generare downtime.

Arrivati ad una soluzione stabile che ci consenta di scalare senza momenti di down rimaneva solo da impostare questa procedura in modo automatico.

“Questo è un compito per Lambda” ci siamo detti, quindi abbiamo scritto due funzioni Lambda in NodeJS che siano in grado di modificare l’istanza RDS e il record DNS di Route53 collegato al suo endpoint.
Per questo piccolo progetto abbiamo scelto di utilizzare il framework Serverless già utilizzato in passato con ottime soddisfazioni. Abbiamo usato questa configurazione:

functions:
  routingToMaster:
    handler: route53.changeRecord
    environment:
      Msg: "${self:custom.MsgRoutingToMaster}"
      HostedZoneId: "${self:custom.HostedZoneId}"
      RecordName: "${self:custom.RecordName}"
      RecordValue: "${self:custom.MasterEndpoint}"

  scaleUp:
    handler: rds.scale
    environment:
      Msg: "${self:custom.MsgScaleUp}"
      InstanceIdentifier: "${self:custom.InstanceIdentifier}"
      InstanceClass: "${self:custom.InstanceClassBig}"

  scaleDown:
    handler: rds.scale
    environment:
      Msg: "${self:custom.MsgScaleDown}"
      InstanceIdentifier: "${self:custom.InstanceIdentifier}"
      InstanceClass: "${self:custom.InstanceClassSmall}"

  routingToReplica:
    handler: route53.changeRecord
    environment:
      Msg: "${self:custom.MsgRoutingToReplica}"
      HostedZoneId: "${self:custom.HostedZoneId}"
      RecordName: "${self:custom.RecordName}"
      RecordValue: "${self:custom.ReplicaEndpoint}"


Le due funzioni Lambda vengono chiamate con due diverse configurazioni ciascuna, riguardo il DNS prima per puntare verso il master poi per ri-puntare verso la replica

'use strict';
const AWS = require('aws-sdk');
const route53 = new AWS.Route53();
const sns = require('./lib/sns.js');

module.exports.changeRecord = (event, context, callback) => {

  route53.changeResourceRecordSets({
    ChangeBatch: {
      Changes: [{
        Action: 'UPSERT',
        ResourceRecordSet: {
          Name: process.env.RecordName,
          Type: 'CNAME',
          ResourceRecords: [{
            Value: process.env.RecordValue
          }],
          TTL: 60
        }
      }],
      Comment: "managed by lambda"
    },
    HostedZoneId: process.env.HostedZoneId
  }, function(err, data){
    if(err){
      sns.error("Cannot change DNS record "+process.env.RecordName+" to value "+process.env.RecordValue, function(){
        callback(err);
      })
    }else{
      sns.notify(process.env.Msg, callback)
    }
  });
};

per RDS per uno scale-up e uno scale-down alla taglia di partenza.

'use strict';
const AWS = require('aws-sdk');
const rds = new AWS.RDS();
const sns = require('./lib/sns.js');

module.exports.scale = (event, context, callback) => {

  rds.modifyDBInstance({
    DBInstanceIdentifier: process.env.InstanceIdentifier,
    DBInstanceClass: process.env.InstanceClass,
    ApplyImmediately: true
  }, function(err, data){
    if(err){
      sns.error("Cannot scale RDS instance "+process.env.InstanceIdentifier+" to "+process.env.InstanceClass, function(){
        callback(err);
      })
    }else{
      sns.notify(process.env.Msg, callback)
    }
  });

};

Abbiamo aggiunto l’invio di messaggi in un topic SNS per essere notificati quando le operazioni avvenivano e nel caso di problemi essere pronti ad intervenire.

'use strict';
const AWS = require('aws-sdk');
const sns = new AWS.SNS();

module.exports.notify = (msg, callback) => {

  sns.publish({
    Message: msg,
    TopicArn: process.env.NotificationSNS
  }, callback);

};

module.exports.error = (error, callback) => {

  sns.publish({
    Message: process.env.MsgError +": "+ error,
    TopicArn: process.env.NotificationSNS
  }, callback);

};

Una nostra funzione Lambda generica è in ascolto su un determinato topic ed è in grado di elaborare molti tipi di messaggi in arrivo inoltrandoli in una stanza specifica di Slack.

Una volta scritto il codice, minimale e semplice, e configurato il progetto Serverless è bastato eseguire un comando di deploy per avere tutto l’ambiente up&running.

Non rimaneva che impostare gli orari delle esecuzioni delle Lambda. Dopo numerose esecuzione abbiamo fatto una stima di quanto tempo impiegava ogni step e deciso di cadenzare le esecuzioni utilizzando degli eventi CloudWatch schedulati con questo tipo di configurazione:

Questo dà al DNS 5 minuti per propagarsi (utilizzando un TTL di 60s) e concede all’istanza RDS 10/12 minuti per completare lo scaling, tempo dello scaling più parte del tempo di propagazione della seconda modifica al DNS.

Abbiamo analizzato l’elenco degli eventi lanciati dai servizi RDS e Route53 per poterci collegare ad uno oppure ad un altro e ci sono venuti alcuni dubbi.

Cambiare il valore di un record del DNS comporta l’attesa della sua propagazione e la chiusura di eventuali connessioni già attive, non ci sono eventi al riguardo e non sarebbe possibile attendere con un long polling che la modifica sia terminata.

La modifica di un’istanza RDS scatena alcuni eventi durante questo tipo di modifica, il primo “DB instance shutdown” quando l’istanza comincia lo scaling, successivamente “DB instance restarted” al riavvio dell’istanza. Essendo però una replica ha bisogno di un po’ di tempo aggiuntivo per terminare la sincronizzazione con il master e non ci ha del tutto convinto una soluzione event-driven..

Ci riserviamo di analizzare meglio questa soluzione nel caso passeremo a questo tipo di configurazione.

Perché non utilizzare questo o quello
Non abbiamo collegato un allarme di utilizzo di CPU o memoria dei RDS per scatenare lo scaling visto l’aumento repentino di connessioni non c’era il tempo per scalare e sopportare il traffico.

Perché non tenere in stop una seconda replica molto grossa e dirottare il traffico su di essa dopo averla accesa? Come specificato nella documentazione di AWS non è possibile mettere in stato di stop una read replica. Nel caso volessimo una istanza più grossa o più piccola ci basta cambiare una variabile d’ambiente della Lambda invece di scalare un’istanza in stato di stop.

Abbiamo scelto di scalare invece di distruggere e ricreare visto che utilizzando Terraform per gestire l’infrastruttura avremmo dovuto importare il nuovo identificativo dell’istanza continuamente nel tfstate e questo causava non pochi grattacapi.

Scaling Automatico Temporizzato Rds

Automatic Temporized Rds Scaling

Qualche settimana fa ho partecipato all’<a href="https://aws.amazon.com/it/awsomedaysitalia-2016/" target="_blank">AWSome Day</a> a Padova, evento gratuito organizzato da Amazon Web Service; si è trattato di una giornata di formazione e consulenza dagli esperti AWS, rivolta a IT Manager e sviluppatori che hanno iniziato a utilizzare le soluzioni di  Cloud Computing di Amazon o che, come me, sono (anzi – erano) totalmente ignoranti sull’argomento.

Il taglio dell’evento era sicuramente entry-level, quindi perfetto per me che conoscevo questa tecnologia solo per sentito dire e che sono curiosa di approfondire, anche perché AWS è la nostra infrastruttura di riferimento per i servizi di hosting evoluti.

Ho preso un sacco di appunti con l’intenzione di condividere i contenuti di questa giornata con alcuni colleghi che, come me, sentono parlare di AWS ma non sono mai entrati nel merito della soluzione. Alla fine ho pensato che il nostro primo strumento di diffusione della conoscenza, internamente ed esternamente all’azienda, è il blog quindi perchè non trasformare dei sommari appunti in un vero e proprio articolo?

Il Cloud Computing è una tecnologia che mette a disposizione, tramite la rete Internet, servizi basati sull’erogazione di risorse hardware e software con formula on demand.

Le risorse erogate comprendono, ad esempio: potenza di calcolo, spazio di archiviazione, strumenti di trasmissione dati e veri e propri servizi applicativi.

Un’azienda che necessita questo tipo di risorse per erogare i propri servizi online può appoggiarsi ad un provider di servizi cloud per acquistare e configurare un set di risorse, con la garanzia di poter ampliare questo set nel tempo in base alle esigenze di business e di capacità del sistema.

Le caratteristiche che hanno reso il Cloud Computing una tecnologia di successo sono:

<li style="font-weight: 400">
contenimento dei costi
</li>
<li style="font-weight: 400">
scalabilità del sistema
</li>
<li style="font-weight: 400">
garanzia della sicurezza
</li>

 principalmente si elimina l’esigenza di gestire un’infrastruttura IT personale, dall’acquisto dell’hardware e del software alla manutenzione del sistema passando dall’esigenza di avere in azienda figure specializzate. Inoltre il concetto di Cloud Computing si accompagna al concetto di flessibilità del costo in base alle reali risorse utilizzate (costo a consumo).

 possibilità di ampliare o diminuire le risorse a disposizione in base alla capacità richiesta per sopportare il carico garantendo stabilità al sistema; ad esempio incrementare le risorse a disposizione all’aumento della mole di dati da gestire, oppure all’aumento del traffico verso un servizio online.

 un buon service provider si occupa di mettere in atto tutte le pratiche necessarie per garantire il rispetto delle policy di sicurezza, la protezione dei dati memorizzati nel cloud e la conformità con una serie di certificazioni necessarie per la messa in opera di servizi che richiedono adeguati livelli di sicurezza (crittografia dei dati, autenticazione, antivirus, cifratura dei dischi ecc…)

Le principali tipologie di tecnologia Cloud sono così classificate:

<li style="font-weight: 400">
DaaS (Data as a service): il provider eroga e gestisce unicamente lo storage dati
</li>
<li style="font-weight: 400">
SaaS (Software as a service): il provider eroga e gestisce un servizio software
</li>
<li style="font-weight: 400">
IaaS (Infrastructure as a service): il provider eroga e gestisce l’infrastruttura di sole risorse hardware
</li>
<li style="font-weight: 400">
PaaS (Platform as a service): il provider eroga e gestisce l’infrastruttura hardware corredata dalle risorse software che permettono di avere una soluzione integrata per l’erogazione di applicazioni
</li>

Il cloud AWS è un sistema PaaS distribuito e disponibile in 190 paesi, suddivisi in aree geografiche (regions). Attualmente sono attive 14 regioni ma nel prossimo anno è prevista la nascita di altre 4.

Ogni regione comprende diverse zone di disponibilità (AZ – Availability Zone): le zone di disponibilità sono a tutti gli effetti dei data center distribuiti che permettono di replicare le applicazioni in modo da garantire scalabilità e disponibilità in caso di guasti su una particolare zona.

La scelta della regione da cui erogare i propri servizi e applicazioni dovrebbe essere dipendente dalla provenienza della maggior parte dei visitatori.

Componenti AWS, traduciamo un po’ di sigle

Nel sistema AWS quasi ogni componente o servizio è identificato, o meglio riconosciuto, da una sigla. Vediamo di far luce sulle principali.

E’ il primo componente nato in Amazon: si tratta di un servizio di archiviazione di risorse accessibili e condivisibili. E’ particolarmente adatto all’archiviazione di risorse statiche (storage, backup, media, componenti software da scaricare al boot per il delivery di macchine EC2).

<li style="font-weight: 400">
le risorse vengono archiviate all’interno di buckets, ovvero contenitori logici su cui è possibile impostare i permessi di accesso
</li>
<li style="font-weight: 400">
ad ogni risorsa salvata è associata una chiave all’interno del bucket
</li>
<li style="font-weight: 400">
le risorse archiviate sono disponibili via http e puntando alla url del servizio e alla chiave dell’oggetto e sono anche accessibili via rest/soap API tramite protocollo https
</li>
<li style="font-weight: 400">
non ha limiti di storage
</li>
<li style="font-weight: 400">
servizio scalabile, durevole e affidabile
</li>
<li style="font-weight: 400">
gestisce versioning e lifetime delle risorse
</li>
<li style="font-weight: 400">
le chiamate a S3 sono tutte crittografate con una chiave tramite un servizio
</li>
<li style="font-weight: 400">
si può attivare il logging di accesso alle risorse
</li>
<li style="font-weight: 400">
si possono configurare eventi (al get/put delle risorse)
</li>
<li style="font-weight: 400">
si paga lo spazio occupato
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/s3" target="_blank">https://aws.amazon.com/it/s3</a>

Si tratta dell’infrastruttura che consente di disporre on demand di istanze di macchine virtuali configurabili in base alle proprie necessità.

E’ possibile ridimensionare, accendere e spegnere le istanze in base all’esigenza di potenza di calcolo necessaria per far fronte al carico: la prima caratteristica è quindi la scalabilità in termini di capacità di carico.

Per attivare una macchina si può partire da un’immagine (

) o da un template precedentemente salvato, che è a tutti gli effetti un “modello di macchina”.

Si scelgono quindi il sistema operativo (Linux / Windows), l’availability zone in cui accendere la macchina, la dimensione della macchina selezionando famiglia (famiglie: T2, M3, M4, C3, C4, R3, G2, I2, D2), l’architettura della macchina configurando RAM, CPU, dischi di storage e rete.

Successivamente si procede alla configurazione dell’istanza specificando le regole di shutdown, il monitoraggio, i permessi di accesso e altre specifiche.

Il self-configuration della macchina mette a disposizione due importanti strumenti:

<li style="font-weight: 400">
Metadata: tutte le informazioni associate alla macchina. in qualsiasi momento si può verificare lo status dell’istanza interrogando i Metadata.
</li>
<li style="font-weight: 400">
User Data: informazioni da mandare all’istanza in modo che vengano eseguiti degli script al boot della macchina.
</li>

<li style="font-weight: 400">
alta scalabilità
</li>
<li style="font-weight: 400">
possibilità di sfruttare il servizio di Auto-Scaling: vengono accese in automatico delle istanze in base a logiche da noi definite; possiamo impostare metriche sulle risorse (ad es cpu) o su fasce orarie in base al traffico previsto
</li>
<li style="font-weight: 400">
accesso di root alla macchina
</li>
<li style="font-weight: 400">
possibilità di definizione di una chiave di accesso alla macchina via ssh
</li>
<li style="font-weight: 400">
massimo controllo della risorsa (sotto il profilo hardware e software)
</li>
<li style="font-weight: 400">
possibilità di gestire dei tag sulle risorse in modo da identificarle all’interno del cloud
</li>
<li style="font-weight: 400">
possibilità di configurare security groups
</li>
<li style="font-weight: 400">
possibilità di sfruttare il bilanciamento di traffico mediante Elastic Load Balancing
</li>
<li style="font-weight: 400">
usa hardware intel xeon sempre aggiornato
</li>
<li style="font-weight: 400">
si pagano solo le risorse utilizzate (dal momento in cui accendo la macchina)
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/ec2/" target="_blank">https://aws.amazon.com/it/ec2/</a>

Sono volumi di storage (dischi) montati sulle istanze EC2.

Risiedono nella medesima availability zone dell’istanza EC2 su cui vengono montati e sono particolarmente adatti come storage per dati che richiedono alta persistenza (indipendentemente dallo stato della macchina a cui sono collegati). Sono quindi adatti per l’utilizzo come file system primario o per lo storage di database o per memorizzare e gestire dati ad alta frequenza di lettura/scrittura.

Su una singola istanza EC2 possono essere montati diversi volumi EBS, un singolo volume EBS può però servire una singola istanza EC2 alla volta.

Per alti carichi di input/output su un disco si può scegliere la tipologia Provisioned IOPS SSD per garantire maggiori performance di I/O sul disco.

Tramite il servizio Amazon EBS Snapshot si possono gestire i backup dei dischi e bisogna fare attenzione alla tipologia di IP collegati, per garantire la persistenza degli indirizzi IP di riferimento in caso di azioni stop/start sull’istanza EC2 su cui è montato il volume.

Per approfondimenti: <a href="https://aws.amazon.com/it/ebs/" target="_blank">https://aws.amazon.com/it/ebs/</a>

Si tratta di un ambiente privato virtuale, logicamente isolato all’interno di AWS, in cui far risiedere le istanze EC2.

Bitbull

Aws

Regole di ingresso per IP dinamici

Sul perché quest’anno saremo presenti al Netcomm e perché lo saremo insieme ad Amazon Web Services

Il mio viaggio nel mondo serverless

Scaling Automatico Temporizzato Rds

AWS for dummies