 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

? 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

Oggi vengo a raccontare la mia esperienza riguardo alla configurazione di una pipeline con Bitbucket per poter compilare asset statici e DI (Dependency injection) per poi eseguire il deploy sui webserver.

Di cosa stiamo parlando? Pipeline, Continuous Integration (CI), Continuous Delivery (CD) sono termini che avrete già sentito nominare nel mondo DevOps, ma anche da sviluppatori prima o poi ne avrete a che fare.

 si intende il sistema dove il codice sorgente di un’applicazione viene scaricato dal repository dove risiede e viene eseguita una serie di step o task. Questo viene fatto in un ambiente isolato (di solito utilizzando un container Docker) il più simile possibile a quello che ospiterà l’applicazione vera e propria.

 è il procedimento automatico che porta le modifiche da un repository (server di controllo versione) verso un ambiente comune, di solito l’ambiente di staging. Questa operazione viene eseguita anche più volte al giorno e spesso vi sono collegati dei test di funzionalità per validare il lavoro. Questo per prevenire un disallineamento e incompatibilità delle versioni su vari rami di sviluppo e delle eventuali librerie esterne.

 invece è un procedura che compila il codice proveniente da un repository e attraverso vari step si occupa di distribuire l’applicazione fino all’utente finale o server web di produzione.

Utilizzando la versione di Magento 1.x sicuramente molti di voi avranno configurato una pipeline, con qualsiasi servizio di CI/CD come Bitbucket, Gitlab, Jenkins, Trevis o qualsiasi altro servizio senza grossi problemi. La parte fondamentale che agevola questo lavoro è l’utilizzo di composer per l’installazione dei moduli utilizzando 

magento-hackathon/magento-composer-installer

Con la versione 2.x di Magento avrete sicuramente avuto a che a fare con il deploy di asset statici, compilazione delle DI e le tante ottimizzazioni che si porta dietro la versione 2.x.

Questo richiede uno step successivo all’installazione dei moduli, ovviamente cerchiamo di eseguire questa procedura nella pipeline per non appesantire il server durante il deploy. Alla versione attuale (2.1.7) per eseguire i comandi necessari alla compilazione è necessaria la connessione al database, questo aggiunge una complicazione: essendo il container della pipeline isolato non è possibile connettersi al database dell’ambiente di destinazione e, anche potendo, non sarebbe una buona pratica.

Il primo requisito necessario è un repository su Bitbucket, nel caso usiate un altro servizio come GitLab potete usare il suo sistema di pipeline, molto ben fatto, oppure con GitHub un servizio esterno.

Aggiungete il file di configurazione della pipeline di Bitbucket, chiamato “bitbucket-pipelines.yml”.

La struttura del file è molto semplice, come prima riga indichiamo quale immagine Docker utilizzare per creare il container della pipeline, nel nostro caso abbiamo cucinato un’immagine molto simile al sistema usato sui server e in locale 

Aggiungiamo ora la dichiarazione della pipeline, qui ci sono due possibilità: usarla in modo automatico, ovvero ad ogni commit viene eseguita (filtrabile in base a tag o branch) oppure lasciare a noi il compito, con un semplice click. Nella maggior parte dei casi si utilizza un solo server di staging e per non sovrascrivere accidentalmente le modifiche di qualcun altro del team, che al momento sta testando una feature, è bene seguire la seconda strada.

Dichiariamo dunque che vogliamo una pipeline eseguita in modo manuale

custom:
    01_staging:

    02_production:

Abbiamo ora dichiarato due pipeline, una per ogni ambiente. Un consiglio utile è quello di anteporre al nome un numero incrementale, questo perchè Bitbucket le mostrerà in ordine alfabetico e non vogliamo che la prima selezionata sia “Production” invece di “Staging”.

Aggiungiamo ora i comandi che devono essere eseguiti, all’interno di “step” (al momento solo uno step per pipeline è supportato in futuro sarà possibile eseguirne più di uno in parallelo) e utilizziamo delle variabili d’ambiente per rendere tutto più configurabile. Un consiglio è quello di utilizzare lo stesso nome all’interno degli script e valorizzarle in base alla pipeline che vogliamo usare.

01_staging:
      - step:
          script:
            - export LOCALES="en_US it_IT"
            - chmod +x deploy-scripts/Build.sh && ./deploy-scripts/Build.sh

Notiamo che tutti i comandi verranno eseguiti da un file contenuto nel repository, questo per rendere tutto più leggibile.

È possibile configurare le variabili d’ambiente dal pannello di impostazioni e offuscare quelle più a rischio come le credenziali dell’utente AWS.

Andiamo ora a scrivere i comandi bash necessari per la compilazione creando il file 

#!/usr/bin/env bash

set -e # interrompe l’esecuzione in caso di errore

TAG=$BITBUCKET_COMMIT

#Configurazione di composer

COMPOSER_AUTH=$(cat &lt;&lt;EOF { "github-oauth": { "github.com": "$COMPOSER_AUTH_GITHUB_TOKEN" }, "http-basic": { "repo.magento.com": { "username": "$COMPOSER_AUTH_MAGENTO_REPO_USERNAME", "password": "$COMPOSER_AUTH_MAGENTO_REPO_PASSWORD" } } } EOF ) mkdir -p /root/.composer && echo "$COMPOSER_AUTH" &gt; /root/.composer/auth.json

composer install --no-dev

Con questi comandi ora verranno installati i moduli di Magento e il suo stesso core, consiglio di tenere sotto controllo versione il file composer.lock per non avere sorprese durante questo step ma sapere in anticipo quali versioni verranno installate.

Ora manca qualcosa, il database a cui collegarsi! Ci viene quindi in aiuto Bitbucket che permette la creazione di un servizio, ovvero un secondo container docker, collegato a quello che esegue i comandi.

Torniamo sul file di configurazione e aggiungiamo al fondo del file bitbucket-pipelines.yml quanto segue

definitions:
  services:
    mysql:
      image: mysql
      environment:
        MYSQL_DATABASE: 'magento'
        MYSQL_ROOT_PASSWORD: 'root'

In questo modo stiamo aggiungendo un container MySQL con un database già creato “magento” e una password per l’utente root.

Aggiungiamo questo servizio alla dichiarazione della pipeline

01_staging:
      - step:
          script:
            ...
          services:
            - mysql

Ora possiamo collegarci al nostro database temporaneo e caricare un dump preso dall’ambiente di staging e alleggerito dalla tabelle di log.

# Connessione al database ed esecuzione del dump

M2_DB_HOSTNAME=127.0.0.1
M2_DB_NAME=magento
M2_DB_USERNAME=root
M2_DB_PASSWORD=root

aws s3 cp s3://$CODEDEPLOY_S3_BUCKET/$CODEDEPLOY_ENVIRONMENT/dump.sql /tmp/dump-$TAG.sql # scarichiamo da un bucket S3 il file di dump
mysql -h $M2_DB_HOSTNAME -u $M2_DB_USERNAME -p"$M2_DB_PASSWORD" $M2_DB_NAME &lt; /tmp/dump-$TAG.sql # applichiamo il dump

ENV_FILE=$(cat &lt;&lt;EOF ADMIN_FRONTNAME="admin" APP_KEY="$APP_KEY" SESSION_SAVE="files" DB_HOSTNAME="$M2_DB_HOSTNAME" DB_NAME="$M2_DB_NAME" DB_USERNAME="$M2_DB_USERNAME" DB_PASSWORD="$M2_DB_PASSWORD" MAGE_MODE="production" CACHE_MODE="disable" WEBSERVER_USER="www-data" EOF ) echo "$ENV_FILE" &gt; .env
composer run-script generate-config # usiamo un modulo sviluppato da noi per creare il file di configurazione env.php 

Ora Magento è collegato al database, non ci resta che eseguire i comandi della CLI per la compilazione vera e propria

# Magento deploy
php bin/magento module:enable --all # abilitiamo tutti i moduli

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy $LOCALES

rm app/etc/env.php
rm .env
rm -r var/cache/*
rm -r .git/
rm docker-compose.yml
rm Vagrantfile

Parte fondamentale delle CI/CD è la creazione dell’artefatto, ovvero un archivio contenente la versione dell’applicazione pronta per essere eseguita.

Adesso la nostra versione è pronta per il deploy. Per questo ultimo step in Bitbull utilizziamo un servizio AWS apposito chiamato 

 che con qualche configurazione ci permette di portare la nuova versione all’interno dei nostri server. È possibile con un paio di righe aggiuntive

aws s3 cp /tmp/release-$TAG.zip s3://$CODEDEPLOY_S3_BUCKET/$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip
aws deploy register-application-revision --application-name $CODEDEPLOY_APP_NAME --s3-location bundleType=zip,bucket=$CODEDEPLOY_S3_BUCKET,key=$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip --region $AWS_REGION

aws deploy create-deployment --application-name $CODEDEPLOY_APP_NAME --deployment-group-name $CODEDEPLOY_DEPLOYMENT_GROUP --s3-location bundleType=zip,bucket=$CODEDEPLOY_S3_BUCKET,key=$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip --region $AWS_REGION

Questo comando è asincrono quindi qui la pipeline terminerà senza aspettare CodeDeploy, quindi per monitorare il progresso e controllare eventuali errori è necessario accedere alla console di AWS. Noi abbiamo collegato le notifiche di CodeDeploy al nostro Slack così da essere notificati per eventuali errori.

Salvate il file di script e quello di configurazione delle pipelines e fate una commit.

Ora che la nostra pipeline è pronta non ci rimane che eseguirla.

Andiamo ora su Bitbucket e scegliamo la commit da cui fare partire la pipeline, è possibile anche selezionare un ramo e verrà usata l’ultima commit su di esso. Troverete sulla vostra destra il comando 

, cliccate su di esso e verranno mostrate le pipeline dichiarate nel file di configurazione.

Una volta lanciata si aprirà un pannello di controllo apposito che mostrerà l’output dei comandi, nel caso di errori questo è il posto giusto per controllare qual è il problema.

Durante l’esecuzione apparirà a sinistra un bottone 

 con cui è possibile bloccarne l’esecuzione, in caso sia stata lanciata per errore. Al termine, invece, tramite il pulsante 

 è possibile eseguirla un’altra volta partendo dallo stesso commit.

Per velocizzare lo scaricamento del moduli composer è comodo utilizzare la cache della pipeline. Attenzione ad utilizzare quella di default di Bitbucket, altrimenti verranno messi in cache i moduli sotto /vendor e non verranno creati i symlinks al core di Magento creati durante il composer install. In Bitbull utilizziamo un soluzione che in parte aiuta ma non ancora ottimizzata.

Al fondo del file bitbucket-pipelines.yml aggiungiamo

definitions:
  services:
    ...
  caches:
    composercache: ~/.composer/cache

e poi all’interno della dichiarazione della pipeline

01_staging:
      - step:
          caches:
            - composercache


Nel caso usiate Slack come app di messaggistica troverete sicuro comodo creare un webhook per inviare le notifiche nel canale usato per il progetto.

Pipeline Magento2

 il 12 e 13 Marzo siamo stati a Verona al 

, un evento tutto incentrato sul mondo PHP (come si può intuire dal nome dell’evento).

Il primo intervento che ci ha dato il benvenuto è stato tenuto da 

, molto molto interessante. Anche se in Bitbull non facciamo alcuna distinzione tra uomo o donna come se fosse una cosa normalissima, è sempre bello sentire che la comunità di sviluppatori ha così tanto a cuore la questione, molto bello l’accenno alle giovani leve e come “non insegnare la discriminazione”.

Bitbull

Fabio Gollinucci

Articoli scritti da Fabio Gollinucci

Regole di ingresso per IP dinamici

Il mio viaggio nel mondo serverless

Scaling Automatico Temporizzato Rds

Pipeline Magento2

PHPDAY 2017

Electron – Una nuova era per le applicazioni desktop