Distribuire una piattaforma Apache su AWS: pro e contro

Uno dei maggiori vantaggi nell’utilizzare AWS sta nella miriade di servizi che il cloud di Amazon mette a disposizione degli sviluppatori e ciò consente ai fornitori di applicazioni di avere una infrastruttura capace di ospitare applicazioni in modo rapido, sicuro e dalle elevate prestazioni.

In questo articolo analizzeremo principalmente le potenzialità e i limiti di alcuni servizi AWS nel distribuire una piattaforma basata su Apache, in grado potenzialmente di servire decine di migliaia di siti web, basandoci sull’esperienza accumulata su un progetto di migrazione che abbiamo realizzato.

Trattandosi di un applicativo già esistente e non studiato per il cloud, le sfide da superare sono state diverse.

In un primo momento abbiamo studiato un modo per trasformare l’applicativo da stateful a stateless: per farlo abbiamo rimosso la gestione dei virtualhost ad Apache, delegando la gestione dei domini e dei loro certificati SSL al Load Balancer.

Limite 1

L’Application Load Balancer non può gestire più di 50 certificati SSL (il soft limit è di 25) e questo per l’infrastruttura rappresenta un grosso limite in quanto la piattaforma deve gestire migliaia di domini.

Soluzione

Abbiamo utilizzato più Application Load Balancer in funzione del numero crescente dei clienti. Di conseguenza, abbiamo affrontato il problema della gestione di più listeners su diversi Load Balancer (l’applicativo richiede l’utilizzo sia della porta 80 che 443 senza redirect) automizzando il più possibile ogni deploy dell’applicativo.

Limite 2

Avendo scelto di utilizzare il Blue/Green Deployment come strategia per il CI e dovendo gestire più Load Balancer, abbiamo riscontrato un’altra pecca di CodeDeploy: non può aggiornare più listeners.

Infatti, ogni applicativo su CodeDeploy può avere solo due targetGroup e due listeners (blue e green).

Soluzione

La soluzione per bypassare questa difficoltà è stata di implementare una lambda (scritta in Go) che venisse triggerata da uno degli hook che mette a disposizione CodeDeploy (AfterAllowTraffic).

La lambda, che verrà richiamata nel momento in cui CodeDeploy ha completato lo spostamento del traffico verso il nuovo target group, leggerà il target group del listener di prod e lo sostituirà in tutti gli altri listeners.

Per la creazione dell'infrastruttura, abbiamo usato terraform, un tool IaC, che permette di automatizzare anche la creazione della lambda e di non dover definire manualmente alla lambda i vari listeners da aggiornare, proprio perché potrà leggerli direttamente dalle variabili d’ambiente:

Conclusione

Nonostante alcune problematiche che magari in un primo momento potrebbero scoraggiare, l’utilizzo di servizi AWS e del cloud di Amazon permette, grazie alla varietà dei suoi servizi, di trovare le soluzioni alternative e di garantire ottimi risultati dal punto di vista della scalabilità. A volte però serve giusto un pizzico di ingegno in più!