Modifica

Condividi tramite

WordPress su servizio Azure Kubernetes

Cache di Azure per Redis
Frontdoor di Azure
Servizio Azure Kubernetes
Azure Load Balancer
Azure NetApp Files

Questo articolo descrive una soluzione contenitore per l'hosting di un'installazione a elevato utilizzo di archiviazione di WordPress in Azure. La soluzione ottimizza la scalabilità e la sicurezza. I componenti principali includono Frontdoor di Azure, servizio Azure Kubernetes (servizio Azure Kubernetes) e Azure NetApp Files.

Architettura

Diagramma dell'architettura di una distribuzione wordPress del servizio Azure Kubernetes. Azure NetApp Files archivia il contenuto statico. Gli endpoint privati forniscono l'accesso ad altri servizi.

Scaricare un file di Visio di questa architettura.

Nota

È possibile estendere questa soluzione implementando suggerimenti e raccomandazioni che non sono specifici di alcun metodo di hosting WordPress specifico. Per suggerimenti generali sulla distribuzione di un'installazione di WordPress, vedere WordPress in Azure.

Flusso di dati

  • Gli utenti accedono al sito Web front-end tramite Frontdoor di Azure con Web application firewall di Azure abilitato.
  • Frontdoor di Azure usa un'istanza interna di Azure Load Balancer come origine. Il servizio di bilanciamento del carico interno è un componente nascosto del servizio Azure Kubernetes. Frontdoor di Azure recupera tutti i dati non memorizzati nella cache.
  • Il servizio di bilanciamento del carico interno distribuisce il traffico in ingresso ai pod all'interno del servizio Azure Kubernetes.
  • Azure Key Vault archivia segreti come la chiave privata, ovvero un certificato X.509.
  • L'applicazione WordPress usa un endpoint privato per accedere a un'istanza flessibile del server di Database di Azure per MySQL. L'applicazione WordPress recupera informazioni dinamiche da questo servizio di database gestito.
  • Tutto il contenuto statico è ospitato in Azure NetApp Files. La soluzione usa il driver Astra Trident Container Storage Interface (CSI) con il protocollo NFS.

Componenti

  • Frontdoor di Azure è una rete di distribuzione di contenuti cloud moderna. Come rete distribuita di server, Frontdoor di Azure distribuisce in modo efficiente contenuti Web agli utenti. Le reti per la distribuzione di contenuti riducono al minimo la latenza archiviando contenuto memorizzato nella cache nei server perimetrali in posizioni di presenza vicino agli utenti finali.
  • Azure Rete virtuale consente alle risorse distribuite di comunicare tra loro, Internet e reti locali. Le reti virtuali forniscono isolamento e segmentazione. Filtrano e instradano anche il traffico e consentono di stabilire connessioni tra diverse posizioni. In questa soluzione, le due reti sono connesse tramite peering di rete virtuale.
  • Protezione DDoS di Azure offre funzionalità avanzate di mitigazione DDoS. Quando si combinano queste funzionalità con le procedure consigliate per la progettazione di applicazioni, consentono di difendersi dagli attacchi DDoS. È consigliabile abilitare Protezione DDoS nelle reti virtuali perimetrali.
  • I gruppi di sicurezza di rete usano un elenco di regole di sicurezza per consentire o negare il traffico di rete in ingresso o in uscita in base all'indirizzo IP, alla porta e al protocollo di origine o di destinazione. In questo scenario le regole del gruppo di sicurezza di rete limitano il flusso del traffico tra i componenti dell'applicazione.
  • Load Balancer distribuisce il traffico in ingresso in base alle regole e ai risultati del probe di integrità. Un servizio di bilanciamento del carico offre bassa latenza e velocità effettiva elevata. Distribuendo il traffico tra più server, un servizio di bilanciamento del carico aggiunge scalabilità alle applicazioni TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). In questo scenario, un servizio di bilanciamento del carico distribuisce il traffico dalla rete per la distribuzione di contenuti ai server Web front-end.
  • Il servizio Azure Kubernetes è un servizio Kubernetes completamente gestito che è possibile usare per distribuire, gestire e ridimensionare applicazioni in contenitori.
  • Azure NetApp Files offre una soluzione di archiviazione con utilizzo intensivo di prestazioni e latenza completamente gestita. In questa soluzione, Azure NetApp Files ospita tutto il contenuto di WordPress in modo che tutti i pod abbiano accesso ai dati.
  • cache di Azure per Redis è un archivio dati in memoria. È possibile usare cache di Azure per Redis per ospitare una cache chiave-valore in questa soluzione. Tale cache viene condivisa tra tutti i pod e viene usata per i plug-in di ottimizzazione delle prestazioni di WordPress.
  • Key Vault archivia e controlla l'accesso a password, certificati e chiavi.
  • Database di Azure per MySQL: il server flessibile è un servizio di database relazionale basato sul motore di database MySQL open source. L'opzione di distribuzione server flessibile è un servizio completamente gestito che offre un controllo granulare e flessibilità rispetto alle funzioni di gestione del database e alle impostazioni di configurazione. In questo scenario, Database di Azure per MySQL archivia i dati wordPress.

Alternative

  • Anziché usare il servizio gestito cache di Azure per Redis, è possibile usare un pod self-hosted all'interno del cluster del servizio Azure Kubernetes come cache.
  • Anziché usare una soluzione di archiviazione gestita come Azure NetApp Files, è possibile usare una soluzione self-hosted come l'archiviazione Rook-Ceph. Per altre informazioni, vedere Come usare Rook Ceph in servizio Azure Kubernetes.

Dettagli dello scenario

Questo scenario di esempio è appropriato per installazioni di wordPress a elevato utilizzo di archiviazione. Questo modello di distribuzione può essere ridimensionato per soddisfare i picchi di traffico verso il sito.

Potenziali casi d'uso

  • Blog ad alto traffico che usano WordPress come sistema di gestione dei contenuti
  • Siti Web aziendali o di e-commerce che usano WordPress

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Quando si distribuisce questa soluzione, prendere in considerazione i consigli seguenti:

  • La soluzione usa pod nel servizio Azure Kubernetes e un servizio di bilanciamento del carico per distribuire il traffico in ingresso. Questo approccio offre disponibilità elevata anche in caso di errore del pod.
  • La soluzione supporta più aree, replica dei dati e scalabilità automatica. I componenti distribuiscono il traffico ai pod. I probe di integrità vengono usati in modo che il traffico venga distribuito solo ai pod integri.
  • Tutti i componenti di rete sono frontdoor di Azure. Questo approccio rende le risorse di rete e l'applicazione resilienti ai problemi che altrimenti compromettono il traffico e influiscono sull'accesso degli utenti finali.
  • Frontdoor di Azure è un servizio globale che supporta i set di scalabilità di macchine virtuali distribuiti in un'altra area.
  • Quando si usa Frontdoor di Azure per memorizzare nella cache tutte le risposte, si ottiene un vantaggio di disponibilità ridotto. In particolare, quando l'origine non risponde, è comunque possibile accedere al contenuto. Tuttavia, la memorizzazione nella cache non offre una soluzione di disponibilità completa.
  • Per aumentare la disponibilità, replicare l'archiviazione di Azure NetApp Files tra aree abbinate. Per altre informazioni, vedere Replica tra aree con Azure NetApp Files.
  • Per aumentare Database di Azure per MySQL disponibilità, seguire le opzioni di disponibilità elevata che soddisfano le proprie esigenze.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Quando si distribuisce questa soluzione, prendere in considerazione le procedure consigliate seguenti:

  • Usare Web Application Firewall in Frontdoor di Azure per proteggere il traffico di rete virtuale che passa al livello applicazione front-end. Per altre informazioni, vedere Web application firewall di Azure in Frontdoor di Azure.
  • Non consentire il flusso del traffico Internet in uscita dal livello di database.
  • Non consentire l'accesso pubblico all'archiviazione privata e disabilitare l'accesso pubblico alle risorse. Usare endpoint privati per Database di Azure per MySQL, cache di Azure per Redis, Key Vault e Registro Azure Container. Per altre informazioni, vedere collegamento privato di Azure.

Per altre informazioni sulla sicurezza di WordPress, vedere Suggerimenti generali sulla sicurezza e sulle prestazioni di WordPress e documentazione sulla sicurezza di Azure.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Quando si distribuisce questa soluzione, esaminare le considerazioni sui costi seguenti:

  • Aspettative del traffico (GB/mese). Il volume di traffico è il fattore che ha il massimo effetto sul costo. La quantità di traffico ricevuta determina il numero di nodi del servizio Azure Kubernetes necessari e il prezzo per il trasferimento dei dati in uscita. Il volume di traffico è correlato direttamente anche alla quantità di dati forniti dalla rete per la distribuzione di contenuti, in cui i costi di trasferimento dei dati in uscita sono più economici.
  • Quantità di dati ospitati. È importante considerare la quantità di dati che si ospitano, perché i prezzi di Azure NetApp Files si basano sulla capacità riservata. Per ottimizzare i costi, riservare la capacità minima necessaria per i dati.
  • Percentuale di scrittura. Valutare la quantità di nuovi dati scritti nel sito Web e il costo per l'archiviazione. Per le distribuzioni in più aree, la quantità di nuovi dati scritti nel sito Web è correlata alla quantità di dati con mirroring tra le aree.
  • Contenuto statico e dinamico. Monitorare le prestazioni e la capacità di archiviazione del database per determinare se uno SKU più economico può supportare il sito. Il database archivia il contenuto dinamico e la rete per la distribuzione di contenuti memorizza nella cache il contenuto statico.
  • Ottimizzazione del cluster del servizio Azure Kubernetes. Per ottimizzare i costi del cluster del servizio Azure Kubernetes, seguire i suggerimenti generali per il servizio Azure Kubernetes, ad esempio indicazioni sulle dimensioni delle macchine virtuali e sulle prenotazioni di Azure. Per altre informazioni, vedere Ottimizzazione dei costi del servizio Azure Kubernetes.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Questo scenario usa i pod nel servizio Azure Kubernetes per ospitare il front-end. Con la funzionalità di scalabilità automatica, il numero di pod che eseguono il livello applicazione front-end può essere ridimensionato automaticamente in risposta alla domanda dei clienti. Possono anche essere ridimensionati in base a una pianificazione definita. Per altre informazioni, vedere Opzioni di ridimensionamento per le applicazioni in servizio Azure Kubernetes (servizio Azure Kubernetes).

Importante

Per ottenere prestazioni ottimali, è essenziale montare un volume permanente che usa il protocollo NFS versione 4.1. Nell'esempio YAML seguente viene illustrato come configurare un PersistentVolume oggetto a questo scopo. Prendere nota del valore del mountOptions campo.

kind: PersistentVolume
...
    accessModes:
    - ReadWriteMany
    mountOptions:
    - vers=4.1
    nfs:
      server: xx.xx.xx.xx

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

  • Adrian Calinescu | Senior Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Documentazione sui prodotti:

Moduli di formazione Microsoft: