Cet article concerne la version open source de Magento, une plateforme d’e-commerce écrite en PHP. Cet article ne concerne pas Adobe Commerce. Cet exemple de scénario montre le déploiement de Magento sur Azure Kubernetes Service (AKS) et décrit les meilleures pratiques courantes pour l’hébergement de Magento sur Azure.
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
- Azure Kubernetes Service (AKS) déploie le cluster Kubernetes de Varnish, Magento, Redis et Elasticsearch dans différents pods.
- AKS crée un réseau virtuel pour déployer les nœuds d’agent. Créez le réseau virtuel à l’avance pour mettre en place une configuration de sous-réseau, un lien privé et une restriction de sortie.
- Varnish s’installe devant les serveurs HTTP pour fonctionner comme un cache de pages entières.
- Azure Database pour MySQL stocke les données de transaction, par exemple, les commandes et les catalogues. La version 8.0 est recommandée.
- Azure Files Premium, Azure NetApp Files ou un système de stockage NAS équivalent stockent les fichiers médias, par exemple, les images de produits. Magento a besoin d’un système de fichiers compatible avec Kubernetes et capable de monter un volume en mode ReadWriteMany, par exemple, Azure Files Premium ou Azure NetApp Files. Options de stockage pour les applications dans Azure Kubernetes Service (AKS). Il est vivement recommandé de tester le débit des opérations d’entrée/sortie par seconde (IOPS) et de choisir les options qui vous conviennent.
- Un réseau de distribution de contenu (CDN) fournit du contenu statique comme CSS ou JavaScript et des images. Le fait de passer par un réseau CDN pour traiter le contenu permet de réduire le temps de réponse du réseau entre les utilisateurs et le centre de données. Un réseau CDN peut supprimer une bonne partie de la charge du périphérique NAS en mettant en cache et en traitant le contenu statique.
- Redis stocke les données de session. Il est recommandé d’héberger Redis sur des conteneurs pour des raisons de performances.
- AKS utilise une identité Microsoft Entra ID pour créer et gérer d’autres ressources Azure comme les équilibreurs de charge Azure, l’authentification utilisateur, le contrôle d’accès en fonction du rôle et l’identité managée.
- Azure Container Registry stocke les images Docker privées, qui sont déployées sur le cluster AKS. Vous pouvez utiliser d’autres registres de conteneurs, comme Docker Hub. L’installation par défaut de Magento écrit des secrets dans l’image.
- Azure Monitor collecte et stocke les métriques et journaux, notamment les métriques de plateforme du service Azure et les données de télémétrie applicative. Azure Monitor s’intègre à AKS pour collecter les métriques relatives aux contrôleurs, aux nœuds et aux conteneurs ainsi que les journaux des conteneurs et des nœuds principaux.
Components
- Azure Kubernetes Service (AKS) : mettre à l’échelle des conteneurs sur un service Kubernetes managé.
- Azure Réseau virtuel : réseaux virtuels dans le cloud.
- Azure Database pour MySQL : service MySQL dans le cloud, économique et facile à configurer, à utiliser et à mettre à l’échelle.
- Azure Files : partages de fichiers dans le cloud. Cette solution utilise le niveau Premium.
- Azure NetApp Files : partages de fichiers Azure de qualité professionnelle, avec NetApp.
- Réseau de distribution de contenu Azure : réseau de distribution de contenu rapide, fiable et mondial.
- Microsoft Entra ID : gestion multicloud des identités et des accès.
- Azure Container Registry : un registre d’images Docker et OCI (Open Container Initiative), avec prise en charge de tous les artefacts OCI.
- Azure Monitor : observabilité de bout en bout pour vos applications, votre infrastructure et votre réseau.
Détails du scénario
Pour plus d’informations sur Magento, consultez Vue d’ensemble de l’installation locale.
Cas d’usage potentiels
Cette solution est optimisée pour le secteur de la vente au détail.
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.
Sécurité
Voici quelques considérations relatives à la sécurité pour ce scénario :
Configurez un lien privé pour MySQL afin que le trafic entre les clients et MySQL ne soit pas exposé à l’Internet public. Pour plus d’informations, consultez Qu’est-ce qu’Azure Private Link ?.
Vous pouvez ajouter l’entrée Azure Application Gateway pour prendre en charge la terminaison SSL (Secure Socket Layer).
Vous pouvez également activer Azure Web Application Firewall avec Application Gateway pour protéger le trafic entrant dans l’application web hébergée dans votre cluster AKS.
Contrôle d’accès en fonction du rôle
Kubernetes et Azure disposent de mécanismes de contrôle d’accès en fonction du rôle (RBAC) .
Le mécanisme RBAC Azure contrôle l’accès aux ressources Azure, y compris la possibilité de créer des ressources. Le contrôle RBAC Azure peut affecter des autorisations à des utilisateurs, à des groupes ou à des principaux de service, c’est-à-dire des identités de sécurité utilisées par les applications.
Kubernetes RBAC contrôle les autorisations sur l’API Kubernetes. Par exemple, la création et le listage des pods sont des actions que le contrôle RBAC Kubernetes peut autoriser aux utilisateurs.
AKS intègre les mécanismes RBAC d’Azure et de Kubernetes. Pour affecter des autorisations AKS aux utilisateurs, créez des rôles et des liaisons de rôles :
Un rôle consiste en un ensemble d’autorisations qui s’appliquent au sein d’un espace de noms. Les autorisations sont définies par des verbes (par exemple, obtenir, mettre à jour, créer ou supprimer) appliqués à des ressources comme des pods ou des déploiements.
Une liaison de rôle permet d’assigner des rôles à des utilisateurs ou à des groupes.
Un objet ClusterRole permet de définir un rôle qui s’applique à l’ensemble du cluster AKS, tous espaces de noms confondus. Pour assigner un ClusterRole à des utilisateurs ou à des groupes, créez un objet ClusterRoleBinding.
Sinon, vous pouvez utiliser Azure RBAC pour l’autorisation Kubernetes, qui permet une gestion unifiée et un contrôle d’accès aux ressources Azure, AKS et Kubernetes.
Quand vous créez le cluster AKS, vous pouvez le configurer afin d’utiliser Microsoft Entra ID pour l’authentification utilisateur.
Si vous souhaitez obtenir plus d’informations sur la configuration de l’intégration Microsoft Entra, voir Intégration Microsoft Entra gérée par AKS.
Pour obtenir plus d’informations sur le contrôle de l’accès aux ressources de cluster en utilisant le contrôle d’accès en fonction du rôle (RBAC) Kubernetes et Microsoft Entra, consultez Utiliser le contrôle d’accès en fonction du rôle Kubernetes avec Microsoft Entra ID.
Extensibilité
Il existe plusieurs façons d’optimiser la scalabilité de ce scénario :
Fichiers multimédias et statiques
Approvisionnez correctement Azure Files, Azure NetApp Files ou un autre système NAS (Network-Attached Storage). Magento peut stocker des milliers de fichiers multimédias, par exemple, des images de produits. Veillez à approvisionner les produits NAS avec suffisamment d’opérations d’entrée/sortie par seconde (IOPS) pour gérer la demande.
Réduisez la taille du contenu statique, comme HTML, CSS et JavaScript. La minimisation peut permettre de réduire les coûts de bande passante et d’offrir aux utilisateurs une expérience plus dynamique.
Connexion de base de données
Activez la connexion permanente à la base de données MySQL afin que Magento continue à réutiliser la connexion existante au lieu d’en créer une nouvelle pour chaque demande. Pour cela, ajoutez la ligne suivante à la section
db
du fichier Magento env.php :'persistent' => '1'
Si MySQL consomme trop de CPU, réduisez l’utilisation en désactivant le nombre de produits de la navigation superposée dans la configuration de Magento :
magento config:set -vvv catalog/layered_navigation/display_product_count 0
Mise en cache
Configurez OPcache pour la mise en cache et l’optimisation du code PHP.
Veillez à ce que les directives suivantes soient définies dans php.ini et que les marques de commentaire associées soient supprimées :
opcache.enable=1
opcache.save_comments=1
opcache.validate_timestamps=0
Équilibrez la charge du cache Varnish en exécutant plusieurs instances sur des pods pour qu’il soit scalable.
Journalisation
Limitez la journalisation des accès pour éviter des problèmes de performances et empêcher l’exposition de données sensibles, par exemple, les adresses IP clientes.
Utilisez la commande Varnish suivante pour limiter au niveau erreur la journalisation :
varnishd -s malloc,1G -a :80 -f /etc/varnish/magento.vcl && varnishlog -q "RespStatus >= 400 or BerespStatus >= 400"
Si vous utilisez le serveur web Apache pour l’entrée, limitez au niveau erreur la journalisation Apache en ajoutant la ligne suivante à l’entrée Magento
VirtualHost
dans la configuration du serveur Apache :CustomLog /dev/null common
Désactivez les journaux d’accès PHP-FPM en commentant le paramètre
access.log
dans toutes les configurations PHP-FPM.
Disponibilité
Il existe différents moyens d’optimiser la disponibilité de ce scénario :
Sondes d’intégrité
Kubernetes définit deux types de sondes d’intégrité :
- La probe readiness indique à Kubernetes si le pod est prêt à accepter les demandes.
- La probe liveness indique à Kubernetes si un pod doit être supprimé et une nouvelle instance démarrée.
Personnalisez les sondes d’intégrité Kubernetes et utilisez-les pour déterminer si un pod est en bon état d’intégrité.
Zones de disponibilité
Les zones de disponibilité constituent des emplacements physiques uniques au sein de régions Azure, qui contribuent à protéger les applications et les données contre les échecs des centres de données. Chaque zone se compose d’un ou de plusieurs centres de données. Les applications situées dans les zones peuvent rester disponibles même en cas de défaillance physique dans un centre de données.
Les clusters AKS peuvent être déployés sur plusieurs zones de disponibilité, afin de fournir un niveau de disponibilité plus élevé et de se protéger contre les défaillances matérielles et les événements de maintenance planifiée. Si les pools de nœuds de cluster sont définis de façon à s’étendre sur plusieurs zones, les nœuds peuvent continuer à fonctionner même si une zone tombe en panne. Pour plus d’informations sur le déploiement d’AKS dans les Zones de disponibilité, consultez Création d’un cluster AKS qui utilise les zones de disponibilité.
Contraintes de ressources
La contention de ressources est susceptible d’affecter la disponibilité du service. Définissez des contraintes de ressources de conteneurs pour éviter qu’un seul conteneur ne surcharge les ressources de mémoire et de CPU de cluster. Vous pouvez utiliser les diagnostics AKS pour identifier des problèmes dans le cluster.
Utilisez la limite de ressources pour restreindre la quantité totale de ressources autorisées pour un conteneur et ainsi éviter qu’un conteneur donné ne puisse en priver d’autres.
DevOps
Voici quelques considérations opérationnelles pour ce scénario :
Dans ce scénario, MySQL n’expose pas de point de terminaison public. Si le serveur de builds stocke les paramètres de configuration dans la base de données MySQL principale, veillez à déployer ce serveur dans le sous-réseau de réseau virtuel auquel MySQL se connecte via le point de terminaison de service.
Utilisez Azure Container Registry ou un autre registre de conteneurs comme Docker Hub pour stocker les images Docker privées déployées sur le cluster. AKS peut s’authentifier auprès d’Azure Container Registry en tirant parti de son identité Microsoft Entra.
Surveillance
Azure Monitor fournit des métriques clés pour tous les services Azure, y compris les métriques de conteneur issues d’AKS. Créez un tableau de bord pour toutes les afficher au même endroit.
En plus d’utiliser Azure Monitor pour conteneurs, vous pouvez désormais utiliser le service managé pour Prometheus afin de collecter et d’analyser des métriques à grande échelle via une solution de monitoring compatible avec Prometheus.
Vous pouvez également utiliser Azure Managed Grafana (ou Grafana autogéré) pour visualiser les métriques Prometheus. Lorsque vous utilisez Azure Managed Grafana, la connexion de votre espace de travail Azure Monitor à l’espace de travail Azure Managed Grafana permet à Grafana d’utiliser les données de l’espace de travail Azure Monitor dans un tableau de bord Grafana. Vous avez ensuite accès à plusieurs tableaux de bord prédéfinis qui utilisent des métriques Prometheus. Vous pouvez également créer des tableaux de bord personnalisés.
Tests de performances
Utilisez Magento Performance Toolkit pour tester les performances. Ce kit de ressources s’appuie sur Apache JMeter pour simuler le comportement des clients, par exemple, la connexion, l’exploration des produits et la validation de l’achat.
Il est également conseillé d’utiliser le Test de charge Azure, un service de test de charge complètement managé qui permet de générer une charge à grande échelle. Avec le Test de charge Azure, vous pouvez créer rapidement un test de charge pour votre application web à l’aide d’une URL. Sinon, pour avoir plus de scénarios de test de charge plus avancés, vous pouvez créer un test de charge en réutilisant un script de test Apache JMeter existant.
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.
Planifiez la capacité en fonction des tests de performances.
Utiliser la calculatrice de prix Azure pour estimer les coûts.
Retrouvez d’autres considérations dans la section Principes d’optimisation des coûts de Microsoft Azure Well-Architected Framework.