Migrare un’installazione WordPress ad una configurazione scalabile in HA su AWS

Pubblicato da Andrea il

Step per creare e convertire un’applicazione WordPress monolitica in un’applicazione scalabile in alta affidabilità:

  1. creare un account su AWS;
  2. creare un security group;
  3. avviare una AMI standard WordPress;
  4. dividere il layer Applicativo dal layer DB;
  5. configurare un frontend in HA e Load Balancing con l’Auto Scaling;
  6. migrare il contenuto su EFS.

Ho scritto questo tutorial per un amico, se avete già un sito WordPress su AWS andate allo step 4!

Step 1 – Creare un account su AWS

Se non avete già un account su AWS createne uno, è gratuito, c’è anche un piano gratuito che include alcune risorse utilizzate in questo test.

Quando avrete finito, avrete un nuovo VPC (Virtual Private Cloud) da poter utilizzare.

Step 2 – Creare un security group

Fate attenzione alla regione che state utilizzando prima di iniziare, è sempre buona norma creare un nuovo Security Group invece di utilizzare quello di default, nel servizio EC2 createne uno aggiungendo HTTP (80) e SSH (22) traffic, ho messo 0.0.0.0/0 in Source per il protocollo SSH ma dovete inserire il vostro indirizzo IP pubblico.

Step 3 – Avviare una AMI standard WordPress

Sempre in EC2 sotto il menu Images potete trovare il menu AMIs, inserite wordpress e aggiungete Platform: Ubuntu, Root Device Type: EBS, Description: bitnami e Virtualization type: HVM dal menù a tendina.

In questo momento, l’ultima versione per un server non multisite è la 4.7.2. Selezionate l’ultima e premete Launch.

Ora dovete selezionare il tipo di istanza, per iniziare un test la t2.micro è perfetta, premete Next.

Configurate i dettagli e premete Next.

Lasciate lo storage come è, premete Next.

Aggiungete dei Tags e premete Next.

Selezionate il Security Group e premete Review and Launch.

Controllate che tutto sia corretto e premete Launch.

 

Create una nuova coppia di chiavi per amministrare la vostra istanza, fate il Download della chiave privata e premete Launch Instances.

Nel menu Instance di EC2 potete verificare lo status e  trovare, se è in running, l’ip e il nome dns.

Ora potete collegarvi all’istanza via SSH, utilizzando la chiave scaricata, bitnami è l’utente di default o visitare il sito blog in HTTP.

Per prima cosa dovete cambiare l’utente e password di default del vostro nuovo WordPress (default user/ bitnami), connettetevi alla pagina wp-login.php ed editate il vostro profilo, ricordatevi di aggiornare WordPress e i Plug-in WordPress  se necessario.

Successivamente, disabilitate il banner bitnami eseguendo dalla console:

sudo /opt/bitnami/apps/wordpress/bnconfig –disable_banner 1

e aggiornate il S.O. Ubuntu con:

sudo apt-get update

sudo apt-get upgrade

Per raggiungere il vostro blog con un nome DNS semplice, aggiungete un record DNS di tipo A alla vostra zona DNS con l’IP pubblico dell’istanza.

Poi cambiate l’indirizzo di default di WordPress, cercate il file wp-config.php:

sudo find / -name wp-config.php

con l’editor nano cambiate il parametro WP_HOME e WP_SITEURL con “define(‘WP_HOME’,’http://example.com’);” e “define(‘WP_SITEURL’,’http://example.com’);”.

Salvate, uscite e riavviate apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Ok, ora è tutto installato e funzionante!

Step 4 – Dividere il layer Applicativo dal layer DB

Questo step incrementerà le performance, avrete 2 istanze invece di una sola con tutto dentro, la disponibilità, per la configurazione multi-zone dei servizi RDS e la gestione di BackUp/Snapshot fatta da Amazon… ma anche i costi, fate sempre attenzione perchè è molto semplice ricevere una fattura alta aggiungendo servizi su Amazon.

Per prima cosa create una snapshot dal menu volumes.

Connettetevi alla console del server e cambiate la directory in quella precedentemente trovata, editate il file wp-config.php per leggere la password attuale del DB:

cd /opt/bitnami/apps/wordpress/htdocs/

sudo nano wp-config.php

Troverete database name, connection username a password e il campo dove inserire il nome dell’host del server DB che attualmente è localhost:3306.

Chiudete l’editor e fate un backup del DB con phpMyAdmin o con il comando:

mysqldump -u bn_wordpress -pDBPassword bitnami_wordpress > /home/bitnami/backup.sql

Verificate l’attuale versione MySQL:

sudo mysql –version

Create una istanza RDS instance per spostare il DB fuori dal server utilizzando launch instance sotto il menu instance del servizio RDS.

Scegliete MySQL e premete Select.

Scegliete una istanza Production MySQL e premete Next Step.

Selezionate la versione corretta del DB Engine, inserite “wordpressdb” come DB Instance Identifier e le altre informazioni con i dati recuperati prima, premete Next Step.

Inserite gli altri parametri congruenti con le finestre di Maintenance del vostro sito e premete Launch DB Instance.

Dopo aver inserito nel security group una regola inbound per permettere il traffico sulla porta 3306 con source address la vostra subnet privata VPC, potete fare l’upload del dump del DB al nuovo servizio dalla console del server WordPress con il comando:

mysql -u bn_wordpress -pDBPassword –database=bitnami_wordpress –host=RDSinstance < backup.sql

Successivamente con l’editor nano cambiate l’indirizzo del server DB da “localhost” all’endpoint name del server RDS a riavviate Apache:

sudo nano wp-config.php

sudo /opt/bitnami/ctlscript.sh restart apache

Ora avete un applicazione a due livelli con una replica sincrona del Database.

Non dimenticate di creare una nuova snapshot, cancellate la precedente e rimuovete mysql dall’istanza WordPress.

Questo comando lo disabilita:

sudo /opt/bitnami/ctlscript.sh stop mysql

sudo mv /opt/bitnami/mysql/scripts/ctl.sh  /opt/bitnami/mysql/scripts/ctl.sh.disable

sudo mv /opt/bitnami/mysql /opt/bitnami/mysql-disabled

Step 5 – Configurare un frontend in HA e Load Balancing con l’Auto Scaling

Ora dobbiamo creare dal web-server attuale una immagine AMI da utilizzare come base, nel menu instance di EC2, selzionate il vostro web-server e dal menu Actions selezionate il menu Image e fate click su Create Image.

L’operazione necessita un reboot dell’istanza per confermare l’integrità del file system, pianificatela in una finestra di maintenance.

Ora disponete di una nuova AMI privata “Owned by me”.

Create un Elastic Load Balancer per distribuire le richieste verso le istanze del layer applicativo, nel menu Load Balancers premete Create Load Balancer.

Inserite i dati come sotto riportati e premete Netx: Configure Security Settings.

Riceverete un warning perchè non avete definito un listner HTTPS, fate click su Next: Configure Security Settings.

Create un nuovo security group con abilitata solo la porta HTTP da ovunque e premete Next: Configure Routing.

Scegliete di creare un nuovo target group senza registrare instance, premete Next: Register Targets.

Rivedete i dati inseriti e premete Create, apparirà una pagina di conferma.

Ora potete scegliere se lanciare un’altra istanza dalla vostra nuova AMI e collegare entrambe al load balancer o creare un Auto Scaling Group che vi aiuterà a dimensionare dinamicamente il numero di istanze.

Io ho optato per la seconda, più complicata ma molto più potente, avviando il wizard su Create Auto Scaling group sotto il menu Auto Scaling Groups di EC2.

Select da My AMIs l’immagine WordPress-Base creata in precedenza.

Selezionate il tipo istanza t2.micro e premete Next:Configure details.

Inserite i dettagli e premete su  Next: Add Storage.

Lasciate tutto come è, fate click su Next: Configure Security Group.

Create un nuovo Security Group con SSH limitato al vostro IP pubblico e HTTP aperto da ovunque. Premete Review.

Controllate tutto e fate click su Create launch configuration.

Selezionate le Key pair utilizzate per amministrare il vostro WordPress, mettete il flag per confermare che avete la chiave e premete su Create launch configuration.

Inserite il nome del gruppo, la dimensione iniziale, le 3 subnet del vostro VPC, mettete un flag su receive traffic from load balancers e scegliete il Target Group, diminuite il parametro Health Check Grace Period a 120 per il test o impostatelo in base al tempo di avvio della vostra applicazione e mettete il flag sul monitoring delle istanze con CloudWatch. Premete su Next: Configure scaling policies

Ora aggiungete le policie per lo scale up e lo scale down, dovete creare un topic per ricevere le notifiche, premete su add new alarm. Inserite il numero massimo di istanze. Ora fate click su Next: Configure Notification.


Continuate aggiungendo i Tag e premete su Review.

Verificate il tutto e premete Create Auto Scaling group.

Ora troverete due o più istanze nuove nel vostro VPC e potete testare l’applicazione con il nome DNS del load balancer. Se tutto è ok cambiate il DNS record per puntare al vostro load balancer.

Quando la propagazione DNS è completata, potete terminare la vostra istanza iniziale.

Step 6 – Migrare il contenuto su EFS

Create un FileSystem NFS dal menu del servizio EFS aggiungendo il security group dell’AutoScaling e premete su Next Step.

Aggiungete i Tags e premete su Next Step

Rivedete l’installazione e premete su Create File System.

Dalla schermata di conferma potete leggere le istruzioni per l’utilizzo premento di Amazon EC2 mount instructions.

Ora aggiuingete la porta NFS (2049) al Security Group.

Dovete ora procedere a modificare l’istanza, diminuite il numero delle istanze da 2 a 1 modificando i parametri dell’AutoScaling Group.

Connettetevi alla vostra istanza rimasta in SSH ed eseguite i comandi per installare il supporto a NFS.

sudo apt-get install nfs-common

Ora create la nuova directory e montate il FileSystem.

cd /opt/bitnami/apps/wordpress/htdocs/wp-content/

sudo mkdir efs

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 DNS name:/ efs

Copiate il contenuto statico nella nuova cartella, in questo esempio muoveremola directory uploads.

sudo cp -a –p /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads /opt/bitnami/apps/wordpress/htdocs/wp-content/efs/uploads

Ora modificate il file di configurazione per aggiungere il nuovo path.

sudo nano /opt/bitnami/apps/wordpress/htdocs/wp-config.php

Aggiungete una nuova linea dopo “ABSPATH . ‘wp-settings.php’);”  con scritto:
define( ‘UPLOADS’, ‘/blog/wp-content/uploads’ );

Salvando e uscendo l’applicazione caricherà le risorse dal nuovo percorso, come potete vedere da questo esempio:

Ora impostiamo ubuntu per montare in automatico il FS all’avvio modificando il file FSTAB.

sudo nano /etc/fstab

Inserite alla fine la seguente riga:

DNS NAME:/ /opt/bitnami/apps/wordpress/htdocs/wp-content/efs nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 0 0

Ora create, come già fatto in precedenza, una nuova immagine base dall’istanza chiamandola WordPress-Base-EFS.

Copiate il Launch Configurations dal menù Actions.

Modificate l’AMI da utilizzare premendo su Edit AMI.

Selezionate la nuova AMI premendo su Select.

Selezionate il tipo di istanza e premete su Next: Configure details.

Modificate i dettagli e premete su Next: Add Storage.

Lasciate invariato lo storage e premete su Next: Configure Security Group.

Selezionate il Security Group AutoScaling e premete Review.

Verificate che tutti i parametri siano corretti e premete su Create launch configuration.

Selezionate le chiavi da utilizzare per amministrare le istanze e premete su Create launch configuration.

Chiudete il tutto e riportate i valori dell’Auto Scaling Group alla normalità cambianto la configurazione di avvio.

Ora potete cancellare la vecchia AMI e tutto ciò che era associato (volumi, snapshot, launch configuration ecc.).

That’s all folks!

No… ci sono diverse cose da cambiare nella vostra applicazione WordPress per gestire correttamente un frontend applicativo multiplo, come ad esempio muovere i contenuti statici su un bucket S3 (con WP Offload S3 Plug-in), cambiare i plug-in che non funzionano bene in questa configurazione, cambiare le vostre procedure per patch e upgrade dell’applicazione (prendete in considerazione AWS CloudFormation per migrare l’infrastruttura su un nuovo deploy), ecc..

Monitorate tutto e se necessario cambiate il numero delle istanze nel target group, il tipo delle istanze, configurate una o più repliche di lettura del DB (con il necessario plug-in) per incrementare la velocità di lettura e diminuire il traffico inter-zone.

Spero che troverete utile il tutorial 😉

Categorie: Informatica

0 commenti

Leave a Reply

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.