Modifier

WordPress sur Azure Kubernetes Service

Cache Azure pour Redis
Azure Front Door
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure NetApp Files

Cet article décrit une solution de conteneur pour héberger une installation volumineuse et gourmande en stockage de WordPress sur Azure. La solution optimise la scalabilité et la sécurité. Les composants clés incluent Azure Front Door, Azure Kubernetes Service (AKS) et Azure NetApp Files.

Architecture

Architecture diagram of an AKS WordPress deployment. Azure NetApp Files stores static content. Private endpoints provide access to other services.

Téléchargez un fichier Visio de cette architecture.

Notes

Vous pouvez étendre cette solution en implémentant des conseils et des recommandations qui ne sont pas spécifiques à une méthode d’hébergement WordPress particulière. Pour obtenir des conseils d’ordre général sur le déploiement d’une installation WordPress, consultez l’article WordPress sur Azure (uniquement disponible en anglais pour le moment).

Dataflow

  • Les utilisateurs accèdent au front-end du site web via Azure Front Door avec Azure Web Application Firewall activé.
  • Azure Front Door utilise une instance interne de Azure Load Balancer comme origine. L’équilibreur de charge interne est un composant masqué d’AKS. Azure Front Door récupère toutes les données qui ne sont pas mises en cache.
  • L’équilibreur de charge interne distribue le trafic d’entrée aux pods au sein d’AKS.
  • Azure Key Vault stocke des secrets tels que la clé privée, qui est un certificat X.509.
  • L’application WordPress utilise un point de terminaison privé pour accéder à une instance de serveur flexible de Azure Database pour MySQL. L’application WordPress récupère des informations dynamiques dans la base de données.
  • Tout le contenu statique est hébergé dans Azure NetApp Files. La solution utilise le pilote CSI (Astra Trident Container Storage Interface) avec le protocole NFS.

Composants

  • Azure Front Door est un réseau de distribution de contenu cloud moderne. En tant que réseau distribué de serveurs, Azure Front Door fournit efficacement du contenu web aux utilisateurs. Les réseaux de distribution de contenu (CDN) réduisent la latence en stockant le contenu en cache sur des serveurs Edge dans des points de présence (POP) proches des utilisateurs finaux.
  • Le réseau virtuel Microsoft Azure permet aux ressources déployées de communiquer de manière sécurisée entre elles, avec Internet et sur des réseaux locaux. Les réseaux virtuels assurent l’isolation et la segmentation. Ils filtrent et acheminent également le trafic, et permettent d’établir des connexions entre différents emplacements. Dans cette solution, les deux réseaux sont connectés par appairage de réseaux virtuels.
  • Azure DDoS Protection fournit des fonctionnalités d’atténuation DDoS améliorées. Combinées aux meilleures pratiques en matière de conception d’applications, ces fonctionnalités vous permettent de vous protéger contre les attaques DDoS. Vous devez activer Azure DDoS Protection sur vos réseaux virtuels de périmètre.
  • Les groupes de sécurité réseau contiennent une liste de règles de sécurité qui autorisent ou refusent le trafic réseau entrant ou sortant en fonction de l’adresse IP de la source/destination, du port et du protocole. Dans les sous-réseaux de ce scénario, les règles de groupe de sécurité réseau limitent le flux de trafic entre les composants de l’application.
  • Azure Load Balancer distribue le trafic entrant en fonction des règles et des sondes d’intégrité. Un équilibreur de charge fournit une latence faible et un débit élevé. En répartissant le trafic sur plusieurs serveurs, un équilibreur de charge ajoute la scalabilité aux applications TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Dans ce scénario, un équilibreur de charge permet de distribuer le trafic à partir du réseau de distribution de contenu vers les serveurs web de front-end.
  • AKS est un service Kubernetes complètement managé que vous pouvez utiliser pour déployer, gérer et mettre à l’échelle des applications conteneurisées.
  • Azure NetApp Files fournit une solution de stockage entièrement managée, très performante et faible en latence. Dans cette solution, Azure NetApp Files héberge tout le contenu WordPress afin que tous les pods aient accès aux données.
  • Azure Cache pour Redis est un magasin de données en mémoire. Vous pouvez utiliser Azure Cache pour Redis pour héberger un cache clé-valeur dans cette solution. Ce cache est partagé entre tous les pods et est utilisé pour les plug-ins d’optimisation des performances WordPress.
  • Key Vault stocke et contrôle l’accès aux mots de passe, certificats numériques et clés.
  • Le serveur flexible Azure Database pour MySQL qui fournit un service de base de données relationnelle basé sur le moteur de base de données MySQL open source. L’option de déploiement d’un serveur flexible est un service complètement managé. Elle est conçue pour assurer le contrôle granulaire et la flexibilité des fonctions de gestion de bases de données et des paramètres de configuration. Avec ce scénario, Azure Database pour MySQL stocke les données WordPress.

Autres solutions

  • Au lieu d’utiliser le service géré Azure Cache pour Redis, vous pouvez utiliser un pod auto-hébergé au sein d’un cluster AKS comme cache.
  • Au lieu d’utiliser une solution de stockage managée comme Azure NetApp Files, vous pouvez utiliser une solution auto-hébergée comme le stockage Rook-Ceph. Pour plus d’informations, consultez comment Utiliser Rook Ceph sur Azure Kubernetes Service.

Détails du scénario

Cet exemple de scénario convient pour les installations volumineuses et gourmandes en stockage de WordPress. Ce modèle de déploiement peut être mis à l’échelle pour répondre aux pics de trafic vers le site.

Cas d’usage potentiels

  • Les blogs à trafic élevé qui utilisent WordPress comme système de gestion de contenu
  • Sites web d’entreprise ou de e-commerce qui utilisent WordPress

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Tenez compte des recommandations suivantes lorsque vous déployez la solution :

  • La solution utilise des pods dans AKS et un équilibreur de charge pour distribuer le trafic d’entrée. Cette approche offre une haute disponibilité même en cas de défaillance d’un pod.
  • Cette solution prend en charge plusieurs régions, la réplication des données et la mise à l’échelle automatique. Les composants distribuent le trafic vers les pods. Les sondes d’intégrité sont utilisées pour que le trafic soit distribué uniquement aux pods sains.
  • Tous les composants réseau sont pris en charge par Azure Front Door. De cette façon, les ressources réseau et l’application sont résilientes aux problèmes qui autrement perturberaient le trafic et affecteraient l’accès de l’utilisateur final.
  • Azure Front Door est un service global qui prend en charge les groupes de machines virtuelles identiques déployés dans une autre région.
  • Lorsque vous utilisez Azure Front Door pour mettre en cache toutes les réponses, vous bénéficiez d’un petit avantage de disponibilité. Plus précisément, lorsque l’origine ne répond pas, vous pouvez toujours accéder au contenu. Toutefois, la mise en cache ne fournit pas de solution de disponibilité complète.
  • Pour augmenter la disponibilité, répliquez le stockage Azure NetApp Files entre les régions jumelées. Pour plus d’informations, consultez Réplication inter-régions avec Azure NetApp Files.
  • Pour augmenter la disponibilité Azure Database pour MySQL, suivez les options de haute disponibilité qui répondent à vos besoins.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Tenez compte des meilleures pratiques suivantes lorsque vous déployez la solution :

  • Utilisez Web Application Firewall sur Azure Front Door pour protéger le trafic de réseau virtuel qui transite dans la couche front-end de l’application. Pour plus d’informations, consultez Azure Web Application Firewall sur Azure Front Door.
  • N’autorisez pas le trafic Internet sortant à transiter depuis la couche de base de données.
  • N’autorisez pas l’accès public au stockage privé et désactivez l’accès public aux ressources. Utilisez des points de terminaison privés pour Azure Database pour MySQL, Azure Cache pour Redis, Key Vault et Azure Container Registry. Pour plus d’informations, consultez Azure Private Link.

Pour plus d’informations sur la sécurité WordPress, consultez la rubrique Conseils d’ordre général concernant la sécurité et les performances WordPress et la Documentation sur la sécurité Azure.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Tenez compte des considérations de coût suivantes lorsque vous déployez la solution :

  • Attentes en termes de trafic (Go/mois). Le volume de trafic est le facteur qui affecte le plus votre coût. La quantité de trafic que vous recevez détermine le nombre de nœuds AKS dont vous avez besoin et le prix du transfert de données sortantes. De plus, le volume de trafic est directement corrélé à la quantité de données fournie par le réseau de distribution de contenu, avec lequel les coûts de transfert de données sortant sont moindres.
  • Quantité de données hébergées. Il est important de tenir compte de la quantité de données que vous hébergez, car le prix d’Azure NetApp Files est basé sur la capacité réservée. Pour optimiser les coûts, réservez la capacité minimale dont vous avez besoin pour vos données.
  • Pourcentage d’écriture. Tenez compte de la quantité de nouvelles données que vous écrivez sur votre site web et du coût de leur stockage. Pour les déploiements multi-régions, la quantité de nouvelles données que vous écrivez sur votre site web est corrélée à la quantité de données mises en miroir dans vos régions.
  • Contenu statique ou contenu dynamique. Surveillez les performances et la capacité de stockage de votre base de données afin de déterminer si une référence SKU moins chère peut prendre en charge votre site. La base de données stocke le contenu dynamique et le réseau de distribution de contenu met en cache le contenu statique.
  • Optimisation du cluster AKS. Pour optimiser les coûts de votre cluster AKS, suivez des conseils généraux pour AKS, tels que des conseils sur la taille de machine virtuelle et les réservations Azure. Pour plus d’informations, consultez Optimisation du coût AKS.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Ce scénario utilise des pods dans AKS pour héberger le front-end. Avec des groupes identiques, le nombre d’instances de machine virtuelle qui s’exécutent au niveau de la couche d’application de front-end peut être automatiquement mis à l’échelle selon la demande du client. Elles peuvent également être mises à l’échelle en fonction d’une planification définie. Pour plus d'informations, consultez Options de mise à l’échelle pour les applications dans Azure Kubernetes Service (AKS).

Important

Pour de meilleures performances, il est essentiel de monter un volume persistant qui utilise le protocole NFS version 4.1. L’exemple YAML suivant montre comment configurer un PersistentVolume objet à cet effet. Notez la valeur du champ mountOptions.

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

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

  • Adrian Calinescu | Architecte de solution cloud senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Documentation du produit :

Modules de formation Microsoft :