{"id":3473,"date":"2021-08-20T13:59:00","date_gmt":"2021-08-20T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3473"},"modified":"2021-08-20T13:47:32","modified_gmt":"2021-08-20T11:47:32","slug":"come-sfruttare-i-servizi-gestiti-di-aws-e-i-container-docker-per-semplificare-la-gestione-di-un-sito-wordpress-su-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-sfruttare-i-servizi-gestiti-di-aws-e-i-container-docker-per-semplificare-la-gestione-di-un-sito-wordpress-su-aws\/","title":{"rendered":"Come sfruttare i servizi gestiti di Aws e i container Docker per semplificare la gestione di un sito WordPress su AWS"},"content":{"rendered":"\n
WordPress \u00e8 la piattaforma di creazione contenuti pi\u00f9 facile ed immediata da utilizzare. La flessibilit\u00e0 che mette a disposizione \u00e8 ci\u00f2 che la rende la piattaforma pi\u00f9 diffusa in assoluto tra gli autori: utilizzando alcuni plugin \u00e8 possibile creare e mantenere in modo semplice e con pochi clic qualsiasi tipo di contenuto, da semplici gallerie di immagini, fino ai pi\u00f9 complessi siti di e-commerce.<\/p>\n\n\n\n
Se per gli autori di contenuti WordPress risulta essere quindi una vera e propria manna dal cielo, dal punto di vista di chi lavora nell\u2019IT \u00e8 spesso considerato un software infernale. Garantirne il buon funzionamento \u00e8 un compito che tiene svegli sistemisti e DevOps di tutto il mondo: la scalabilit\u00e0 non \u00e8 immediata, l\u2019installazione non \u00e8 scriptata ed uno stack LAMP non \u00e8 facile da mantenere aggiornato.\u00a0<\/p>\n\n\n\n
In questo articolo vi forniremo alcuni suggerimenti tecnici per rendere meno tragica la gestione di WordPress ospitati in un ambienti Cloud. In particolare,sfrutteremo i servizi offerti dal provider Amazon Web Services utilizzando il maggior numero possibile di servizi gestiti. In questo modo, elimineremo tutte le attivit\u00e0 ripetitive, e quindi potenzialmente pi\u00f9 pericolose, semplificando notevolmente gestione e manutenzione. <\/p>\n\n\n\n
Per prima cosa, vogliamo che il nostro database possa essere altamente affidabile e che riesca a scalare sostenendo senza fatica l\u2019andamento del traffico. La miglior scelta per soddisfare questi requisiti risiede nell\u2019utilizzo di Amazon Aurora MySQL. <\/p>\n\n\n\n
Utilizzando Amazon Aurora, infatti, non dovremo preoccuparci dello spazio utilizzato perch\u00e9 lo storage pu\u00f2 scalare automaticamente quando necessario. Inoltre, il point-in-time recovery rende possibile il recupero dei dati con la granularit\u00e0 di secondi.<\/p>\n\n\n\n
Sono possibili anche configurazioni \u201cMulti-AZ\u201d con repliche in lettura (read replica) che possono essere promosse in caso di fallimento di una availability zone: quando si crea un cluster Aurora, AWS assegna automaticamente un endpoint (a cui \u00e8 associato un record DNS) per la lettura e uno per la scrittura. <\/p>\n\n\n\n
In caso di fallimento (o di operazioni di manutenzione) la read replica viene automaticamente promossa per diventare l\u2019istanza di scrittura e l\u2019endpoint viene modificato di conseguenza.<\/p>\n\n\n\n
Basta semplicemente impostare il file wp-config.php per utilizzare l\u2019endpoint di scrittura ed AWS si occuper\u00e0 di fare tutto il resto. Con Amazon Aurora \u00e8 possibile aggiungere fino a 15 read replica. <\/p>\n\n\n\n
Se il tipo di traffico che il sito dovr\u00e0 sopportare sar\u00e0 prevalentemente di lettura \u00e8 possibile sfruttare questa possibilit\u00e0, ma occorre fare in modo che WordPress riesca ad utilizzare tutte le repliche. Il plugin hyperdb (https:\/\/wordpress.org\/plugins\/hyperdb\/<\/a>) permette proprio di fare questo, definendo un database master ed un numero di repliche a piacere. In caso di basso traffico al sito o di traffico incerto in cui non \u00e8 noto quando e se sia necessario scalare, invece, la miglior scelta possibile ricade su Aurora Serverless. Questo database ha la possibilit\u00e0 di scalare la capacit\u00e0 computazionale in modo automatico e di rimanere \u201cin pausa\u201d quando il sito web non \u00e8 utilizzato, permettendo di ottimizzare al massimo i costi.<\/p>\n\n\n\n Vogliamo poter utilizzare l\u2019elasticit\u00e0 che i servizi cloud mettono a disposizione, per cui gli Autoscaling Group di EC2 potrebbero sembrare la soluzione pi\u00f9 naturale. Ci spingeremo oltre e utilizzeremo container Docker su un cluster ECS in modalit\u00e0 Fargate, anche se sar\u00e0 necessario un po\u2019 di refactoring applicativo. <\/p>\n\n\n\n L\u2019utilizzo di container, infatti, riduce le attivit\u00e0 di manutenzione necessarie per l\u2019aggiornamento dei sistemi operativi e rende pi\u00f9 semplice implementare la scalabilit\u00e0. Un ulteriore vantaggio ottenibile con poco sforzo deriva dalla possibilit\u00e0 di automatizzare l’intero flusso di deployment attraverso l’utilizzo di Pipeline. Pi\u00f9 avanti nell\u2019articolo vedremo come fare.<\/p>\n\n\n\n
Il file di configurazione \u00e8 ben documentato (https:\/\/plugins.trac.wordpress.org\/browser\/hyperdb\/trunk\/db-config.php<\/a> ) e questa \u00e8 una configurazione di esempio:<\/p>\n\n\n\nwpdb->add_database(array(\n 'host'\t=> mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com,\n 'user'\t=> DB_USER,\n 'password'\t=> DB_PASSWORD,\n 'name' \t=> DB_NAME,\n));\n\n$wpdb->add_database(array(\n 'host' \t=> mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com,\n 'user'\t=> DB_USER,\n 'password'\t=> DB_PASSWORD,\n 'name'\t=> DB_NAME,\n 'write'\t=> 0,\n 'read'\t=> 1,\n));<\/code><\/pre>\n\n\n\n
Compute<\/h2>\n\n\n\n