Déployer Fault Tolerant, chargez des applications Web équilibrées sur Alibaba Cloud –

Cet article a été publié à l'origine le Alibaba Cloud . Nous vous remercions de soutenir les partenaires qui rendent SitePoint possible.

La haute disponibilité (HA), la tolérance aux pannes (FT) et l'adaptation horizontale (HSF) sont tout aussi importantes pour les fonctionnalités des applications Web. Les applications Web existantes ou nouvelles doivent être conçues et provisionnées avec une telle architecture sous-jacente. Heureusement, vous pouvez déployer facilement et rapidement l'architecture mentionnée ci-dessus dans l'ère du Cloud aujourd'hui (par rapport à l'ère des machines bare-metal sur site)!

Cependant, cette flexibilité s'accompagne d'une mise en garde: comment choisissez-vous le bon fournisseur de cloud? Nous avons l'embarras du choix et il peut être très difficile (et trépidant!) En évaluant et en choisissant le bon.

Ce poste est destiné à discuter et fournir une procédure pas à pas sur le déploiement d'applications web sur Alibaba Cloud à partir de zéro, y compris HA, FT et HSF. Tout au long de ce post, je présenterai brièvement plusieurs services et outils fournis dans Alibaba Cloud. Oui, brièvement! Si vous souhaitez en savoir plus sur des services ou des outils particuliers, veuillez visiter le Centre de documentation . En outre, ce post mettra en évidence les préoccupations et les considérations lors du déploiement de ces services.

WordPress est utilisé comme l'application web de démonstration qui serait déployée sur Alibaba Cloud dans ce post. Le même principe de déploiement s'applique à de nombreuses autres applications Web. Ce message n'est pas destiné à discuter sur la configuration de WordPress du tout. Il ne doit pas (et ne peut pas) servir de référence pour la configuration de WordPress. Il y a des tonnes et des tonnes de bonnes ressources là-bas concernant les meilleures pratiques sur WordPress administratif.

1. Architecture de haut niveau

Comme beaucoup d'autres applications web, l'application web de démonstration se compose d'une couche application (WordPress) et d'une couche base de données (MySQL).

But : -on application web (WordPress)!

Afin d'atteindre un tel objectif "simple", l'application web de démonstration doit être déployée avec les exigences minimales suivantes:

1. Un seul site principal.
2. Un minimum de deux instances WordPress physiquement séparées sur chaque site à des fins de redondance et d'équilibrage de charge.
3. Génération automatique de l'autre instance WordPress lorsque l'instance existante s'arrête ou connaît un échec.
4. L'instance de base de données (MySQL) doit également fonctionner en mode redondance. Il doit automatiquement basculer vers l'instance de secours active si nécessaire.
5. Espace de données centralisé. Les ressources partagées doivent être accessibles et disponibles pour toutes les instances WordPress en cours d'exécution. Par exemple, un document téléchargé par un utilisateur via WordPress doit être synchronisé sur toutes les instances WordPress en cours d'exécution.

Heureusement, Alibaba Cloud fournit une liste de services et d'outils pour que nous puissions répondre à ces exigences. Dans ce post spécifiquement, nous utiliserons Cloud DNS (DNS) Auto Scaling Group (ASG) Serveur Balancer Loader (SLB) Elastic Compute Service (19459005), Système de base de données relationnelle (RDS) Service de stockage d'objets (OSS) et OSSFS (Object Storage File System) pour atteindre notre objectif. Le diagramme d'architecture de haut niveau pour le déployé WordPress serait comme suit:

2. Procédures de déploiement

Nous présenterons brièvement les composants illustrés à la figure 1.0 avant de plonger dans chaque configuration individuelle. Comme indiqué précédemment, vous devrez vous référer à d'autres sources telles que Alibaba Cloud documentation en ligne pour une explication détaillée. Le tableau suivant résume la description et l'utilisation de ces composants selon notre contexte de déploiement:

Tableau 1: Composants Cloud dans les déploiements de démonstration

Le flux de travail ci-dessous décrit les étapes générales du déploiement d'une application Web sur Alibaba Cloud .

2.1. Identifier la région de service

Il est important de décider de la région où une application doit être déployée. Les considérations générales doivent inclure ce qui suit:

1. Cost : La mère de toutes les considérations. Oui, le coût peut varier selon la région.
2. Disponibilité dans la région ? Il n'est pas rare que certaines régions fournissent des services supplémentaires qui ne sont pas disponibles dans une autre région – vous devez tester pour les découvrir!
3. Position géographique principale des utilisateurs . C'est certainement mieux pour l'expérience utilisateur si l'application est physiquement plus proche du client, ce qui entraîne une latence plus courte.
4. Règles et règlements . Est-il légal que l'application soit hébergée dans la région sélectionnée?
5. Nombre de Disponibilité Zonez . Occasionnellement, nous devons améliorer la disponibilité des applications en déployant des applications redondantes dans une zone différente. Comme je suis basé en Asie du Sud-Est, je me pencherai sur les centres de données de Singapour et de Kuala Lumpur. Au moment d'écrire ces lignes, "Asia Pacific SE 3 (Kuala Lumpur)" n'a qu'une seule zone alors que "Asia Pacific SE 1 (Singapour)" a deux zones.

Après examen, nous avons décidé "Asia Pacific SE 1 (Singapour)" sera la région principale pour notre déploiement de démonstration. »

2.2. Plan pour la configuration du réseau

I. VPC

Nous devons prendre en compte le nombre de nœuds potentiellement actifs dans le déploiement. Chaque nœud en cours d'exécution est soumis à une IP privée, et nous ne voulons plus manquer d'adresses IP privées pour les nœuds dans le futur!

Il existe trois types de blocs CIDR autorisés par Alibaba Cloud pour un VPC: 10.0. 0,0 / 8, 172.16.0.0/12, 192.168.0.0/16. Selon la documentation de Alibaba Cloud le premier et le dernier trois IP du bloc CIDR seraient réservés par l'utilisation du système, et donc le nombre maximum d'IP privées pour chaque bloc CIDR est:

• 10.0.0.0/8 = 16777212 (16777216 – 4)
• 172.16.0.0/12 1048572 (1048576 – 4)
• 192.168.0.0/16 = 65532 (65536 – 4)

Vous pouvez également vous demander pourquoi nous ne venons pas utiliser le plus grand bloc CIDR autorisé pour éviter de potentiellement manquer d'IP privée à l'avenir? Ce qui suit pourrait vous aider à reconsidérer cette pensée:

1. Le bloc CIDR plus grand peut augmenter la complexité lorsqu'il est confronté à une configuration IP, comme la création de sous-réseau, la configuration de route, le groupe de sécurité configuration, et etc.
2. Si ce qui précède n'est pas un show-stopper valide pour vous, considérez ceci: " VPC peering (interconnect) " avec d'autres VPC ne permet pas le chevauchement du bloc CIDR. En d'autres termes, il n'est pas possible de pair avec d'autres VPC une fois que vous utilisez 10.0.0.0/8 comme bloc CIDR!

Après examen, nous utiliserons "192.168.0.0/16" pour notre déploiement de démonstration car il n'y aura que quelques nœuds en cours d'exécution dans le VPC.

II. Sous-réseau

Dans Alibaba Cloud, VSwitch peut être utilisé pour segmenter davantage le bloc VPC CIDR en un sous-réseau avec un bloc CIDR plus petit. La considération générale pour la segmentation des sous-réseaux comprend ce qui suit:

1. Groupement logique des instances en fonction des fonctionnalités. Par exemple. grouper l'application dans un groupe et RDS dans un autre groupe pour faciliter la maintenabilité. Par exemple, désactiver un groupe d'instances en supprimant VSwitch attaché au groupe.
2. Simplifier la configuration du profil de groupe de sécurité . Les règles de sécurité basées sur le niveau de bloc CIDR du sous-réseau plutôt que sur l'IP de l'instance sont plus propres.
3. Activer Auto-scaling et Server Load Balancer surveillance et actions sur un sous-réseau spécifique. Redondance sur les ressources . Il est possible de basculer de manière transparente vers un sous-réseau différent basé dans une zone différente lorsque la zone du sous-réseau existant rencontre une défaillance.

Après examen, nous regroupons WordPress dans un sous-réseau (192.168.1.0/24) et l'instance RDS dans un autre sous-réseau (192.168.2.0/24).

2.3. Configurer le pare-feu (groupe de sécurité)

L'accès au réseau au niveau de l'instance peut être limité via le groupe de sécurité dans Alibaba Cloud. La configuration de la règle de groupe de sécurité peut être très granulaire, jusqu'au niveau IP par protocole, par port et par client. Par conséquent, pour éviter un accès non autorisé à l'instance, nous devons considérer ce qui suit:

1. Respectez toujours la pratique du moindre privilège . Restreindre l'accès au client requis seulement.
2. Intranet et / ou connectivité Internet . Vous pouvez utiliser le groupe de sécurité pour créer un «sous-réseau privé» (pas d'utilisation Internet) en autorisant uniquement l'accès à l'intranet entrant. En outre, une passerelle NAT pourrait être utilisée pour permettre à l'instance du réseau privé d'accéder aux services Internet sortants.

Puisque nous utilisons WordPress sur des instances Linux, nous autoriserions au moins une règle entrante pour le port 80 (HTTP) et 22 (SSH) dans le groupe de sécurité. En outre, tout le trafic sortant serait autorisé puisqu'il n'y a pas d'exigence spécifique à ce sujet.

2.4. Configurez la couche d'application

Cela pourrait être la décision la plus délicate et la plus incertaine que nous ayons à faire lors du déploiement d'applications Web. Comme indiqué précédemment, ce post ne traite pas des exigences de capacité d'une application et, par conséquent, le choix d'un type d'instance approprié est hors de portée de ce post. Quoi qu'il en soit, les considérations suivantes peuvent aider à décider d'un type d'instance:

1. Commencez toujours avec le modèle Pay-As-You-Go si vous n'avez aucune idée de la performance du type d'instance ni de la capacité réelle exigence. Ce modèle de tarification vous permet d'expérimenter librement différents types d'instance sans période de verrouillage.
2. Vous devez comprendre la nature de la contrainte de l'application à venir . L'application est-elle liée à l'UC ou liée à l'IO? Vous devez répondre à cette question afin de déterminer le type d'instance approprié avec le meilleur rapport coût-efficacité
3. Déployer avec une instance à un seul échelon autant que possible. Si l'exigence de capacité d'une application peut être satisfaite avec une instance X d'une famille d'instances de type Y, il est préférable de déployer l'application avec deux instances à un seul pas (par exemple X / 2) du même type de famille pour la même quantité de charge de travail. Cela augmentera la disponibilité de l'application. Par exemple, nous pouvons toujours traiter 50% de la charge de travail si l'instance X / 2 tombe en panne par rapport à 100% de temps d'arrêt si l'instance X est en panne. Bien entendu, cette approche est sujette à la conception et à l'utilisation de l'application.
4. Décidez d'autres paramètres d'utilisation p. type de réseau, bande passante réseau, image du système d'exploitation, etc. en conséquence.

Comme il s'agit d'un déploiement de démonstration sans utilisation de production réelle, nous optons pour la configuration d'instance ECS la plus basse (moins chère) . Par exemple: Général Type n1: 1-core, 1 Go, Ubuntu 16.04 OS, Ultra Cloud Disk 40 Go et bande passante 1 Mo.

2.5. Configurer la couche de base de données

En règle générale, nous devons choisir entre l'utilisation d'instances de base de données autogérées (installation automatique de DB à l'instance ECS) comme pour les solutions locales, ou l'utilisation de services DB RDS entièrement gérés. comme ApsaraDB . Encore une fois, il est hors de portée de ce poste en comparant ou en comparant les deux variantes de services de base de données. Ces instructions peuvent vous aider à choisir les variantes de base de données en général:

1. Avez-vous des ressources disponibles pour gérer et exploiter les instances de base de données? Les tâches de gestion et opérationnelles peuvent inclure la sauvegarde de fichiers de données, le patch OS / DB, le contrôle d'accès sur la machine hôte, etc. Si la réponse est non, alors une base de données RDS entièrement gérée est préférable.
2. instance de base de données? Si votre base de données est petite et que la charge de travail est minime et peut coexister avec l'application (par exemple dans l'environnement de développement), la variante autogérée est peut-être préférable pour des raisons de rentabilité.
3. Avez-vous besoin d'accès? hôte pour l'instance de base de données? Par exemple, si vous devez effectuer une configuration OS / DB spécifique pour optimiser les performances, la variante auto-gérée doit être utilisée
4. Le service de base de données entièrement géré fournit-il le type de BD requis? Si non, alors la réponse est simple, optez pour une variante de base de données autogérée.
5. Si vous êtes préoccupé par le possible verrouillage du fournisseur de cloud, vous pouvez éviter la variante entièrement gérée comme RDS implémentations pourraient être spécifiques au fournisseur de cloud.

Comme il n'y a pas de main-d'œuvre pour maintenir la base de données de démo ni aucune configuration de base de données, nous allons déployer la base de données de démonstration avec ApsaraDB RDS – MySQL. De plus, cette variante nous permet de créer facilement une base de données de redondance (en veille active) (en un clic!).

2.6. Identifier le stockage centralisé

Éventuellement, plusieurs applications WordPress simultanées peuvent s'exécuter physiquement sur des instances ECS physiquement distinctes. Chaque instance peut générer et stocker certains fichiers / images / médias résultant des opérations des utilisateurs. De toute évidence, les objets générés par une instance doivent être synchronisés entre toutes les instances d'application en cours d'exécution. L'une des approches pour réaliser cette synchronisation est le stockage centralisé. Les objets générés doivent être synchronisés avec le stockage centralisé et suivis par la synchronisation entre les objets centralisés et les autres instances en cours d'exécution. De plus, le stockage centralisé doit toujours être disponible et toute défaillance d'une instance ne devrait pas avoir d'incidence sur la disponibilité et la durabilité du stockage centralisé.

Alibaba Cloud fournit quelques services entièrement gérés pouvant servir de stockage centralisé:

1. Service de stockage d'objets pour objets: Idéal comme stockage d'objets centralisé grâce à la haute disponibilité garantie (99,9%), à l'évolutivité et à nature gérée. Spécifiquement à ce déploiement de démonstration, chaque instance WordPress en cours doit être synchronisée avec un compartiment dédié du Service de stockage d'objets. En utilisant un tel mécanisme de synchronisation, toutes les instances WordPress en cours auraient un ensemble identique d'objets créés
2. ApsaraDB Redis pour l'état de l'application: L'état de partage (par exemple valeur partagée, paramètre) entre instances est possible via ApsaraDB Redis entièrement géré. .

Un compartiment dédié dans Object Storage Service serait créé et utilisé pour stocker les objets créés à la suite des opérations de l'utilisateur. Toutes les instances WordPress en cours doivent être synchronisées avec le compartiment correspondant à la liste des objets créés.

2.7. Plan pour HA, FT et HSF

Pour réaliser HA, FT et HSF dans Alibaba Cloud, une application web doit être fondamentalement conçue comme apatride et évolutive horizontalement. L'état ou les données de toute application dépendante doivent être découplés de l'application Web et migrés vers le stockage centralisé, comme indiqué dans la section précédente.

Les services listés ci-dessous pourraient être employés pour déployer une application web HA, FT et HSF:

1. Cloud DNS : Il est possible de configurer des types d'enregistrements 'A' pour des instances hébergées dans différents les régions. C'est vraiment utile pendant les scénarios de basculement où un enregistrement «A» d'une instance de secours peut être activé en un clic, ce qui entraîne un détournement du trafic réseau vers l'instance de secours.
2. Auto Scaling : Il peut être utilisé pour les instances d'auto-spawn dans une zone souhaitée lorsque les instances en cours d'exécution tombent en panne ou deviennent malsaines.
3. Server Load Balancer : Ce service fournit une vérification de l'état des instances configurées et signale leur état au service Auto Scaling pour une action ultérieure. En outre, ce service équilibrerait également la charge de travail entre les instances en cours d'exécution.
4. ApsaraDB RDS : RDS MySQL fournit la fonctionnalité de disponibilité multizones en un simple clic. Cela va vraiment faciliter les efforts nécessaires pour fournir HA et FT pour la base de données.

Le déploiement de démo utilise DNS pour acheminer le trafic vers les instances WordPress, Auto Scaling pour assurer un minimum de deux instances en cours dans chaque région, et Server Load Balancer pour fournir un contrôle de santé ainsi que pour charger équilibrer la charge de travail. Dernier point, mais non des moindres, la fonction de disponibilité multi-zone de RDS MySQL permet de fournir HA et FT pour la base de données.

2.8. Test et exécution

Pour tester le comportement HA et FT, nous pouvons arrêter manuellement ECS en cours d'exécution et observer les déclenchements d'action par le service de mise à l'échelle automatique. Si la mise à l'échelle automatique a été correctement configurée, une nouvelle instance sera générée automatiquement. En outre, nous pouvons également désactiver manuellement l'instance de base de données RDS pour observer le basculement de redondance multi-zone. La meilleure chose est que ces actions sont automatiquement traitées par les services respectifs sans aucune intervention manuelle. Montré ci-dessous est notre déployé WordPress :

3. Améliorations possibles

Les suggestions suivantes pourraient être utiles pour améliorer encore la résilience, les performances et la disponibilité d'une application Web déployée:

1. Extensibilité automatique / entrée en fonction de la charge de travail de l'instance. Par exemple, générer une nouvelle instance lorsque CPU / mémoire dépasse un certain seuil sur une période définie
2. Utiliser le CDN pour mettre en cache et distribuer du contenu afin de minimiser la latence géographique et réduire le trafic vers l'instance d'application. De plus, le CDN sert également de couche de défense pour les attaques DDoS sur les instances d'application.
3. Décharger la charge de travail 'read' de la base en créant une réplique en lecture.
4. Planifier une zone de récupération après sinistre et créer une stratégie de basculement.
5. Paramétrez la surveillance du cloud, activez l'alerte et activez au moins le journal détaillé pour les métriques et les incidents critiques tels que la défaillance d'une instance, l'espace disque plein, la mise à l'échelle automatique déclenchée, etc.

4. Annexe (Exemple de configuration)

Les étapes de configuration suivantes sont basées sur le résultat décrit dans la section "Procédures de déploiement". Vous auriez besoin d'un compte Cloud Alibaba pour exécuter la configuration suivante. Si vous n'en avez pas encore, vous pouvez vous inscrire (avec 300 $ US de crédit gratuit au moment de la rédaction de ce document) avec ce lien .

1. VPC et configuration du réseau (identification de la région de service et planification de la configuration réseau)

1. Connexion à la console Alibaba Cloud
2. Créer "VPC". Allez dans "Produit" et cliquez sur "Virtual Private Cloud" sous "Networking". Sélectionnez la région sous "Asie Pacifique SE 1". Une fois arrivé à la page d'aperçu VPC, cliquez sur "VPC" sur l'onglet latéral, puis cliquez sur le bouton "Créer un VPC".
   • Nom: VPC-Main
   • CIDR range: 192.168.0.0/16
3. Créer un "sous-réseau". Un sous-réseau pour l'instance WordPress et un sous-réseau pour RDS.
   • Premier sous-réseau (Passez à "Etape suivante" à l'étape 2 pour "Créer VSwitch"):
     • VPC: VPC récemment créé (par exemple, VPC-principal)
     • Nom: Public-Subnet1
     • Zone: Zone A
     • CIDR: 192.168.1.0/24
   • Deuxième sous-réseau (Cliquez sur 'Créer plus' pour créer le deuxième commutateur):
     • VPC: VPC récemment créé (par exemple, VPC-principal)
     • Nom: Public-Subnet2
     • Zone: Zone A
     • CIDR: 192.168.2.0/24

2. Configuration du groupe de sécurité (Configurer le pare-feu)

1. Créer "Groupe de sécurité". Allez dans "Product" et cliquez sur "Elastic Computing Service". Une fois arrivé à la page d'aperçu ECS, cliquez sur "Groupe de sécurité" sur l'onglet latéral, puis cliquez sur le bouton "Créer un groupe de sécurité".
   • Nom: Tout nom. Par exemple. SG-SSH-HTTP
   • Type de réseau: VPC
   • VPC: VPC-Main
   • Cliquez sur "Définir la règle immédiatement"
2. Ajouter une règle. Cliquez sur "Ajouter des règles de groupe de sécurité"
   • Première règle (SSH pour tout client entrant)
     • Direction de la règle: entrante
     • Autorisation: Autoriser
     • Type de protocole: SSH
     • Objet d'autorisation: 0.0.0.0/0
   • Deuxième règle (HTTP pour tout client entrant)
     • Direction de la règle: entrante
     • Autorisation: Autoriser
     • Type de protocole: HTTP
     • Objet d'autorisation: 0.0.0.0/0
   • Troisième règle (Tout protocole pour toute cible sortante)
     • Direction de la règle: sortante
     • Politique d'autorisation: Autoriser
     • Type de protocole: Tous
     • Objet d'autorisation: 0.0.0.0/0

3. Configuration ECS (Configurer la couche d'application – Partie 1)

1. Créer une "paire de clés". Allez dans "Product" et cliquez sur "Elastic Computing Service". Une fois sur la page de présentation ECS, cliquez sur «Key Pairs» dans l'onglet latéral, puis cliquez sur «Create Key Pair».
   • Nom: ECS-Lab
   • Type: Création automatique d'une paire de clés
   • Un fichier de paires de clés nommé "ECS-Lab.pem" doit être téléchargé automatiquement. Ce fichier sera utilisé comme clé d'authentification lors de la connexion à l'instance ECS.
2. Créez une instance ECS pour votre installation WordPress. Allez dans "Product" et cliquez sur "Elastic Computing Service". Une fois sur la page de présentation ECS, cliquez sur "Instances" dans l'onglet latéral, puis cliquez sur le bouton "Créer une instance".
   • Modèle de prix: Pay-As-You-Go
   • Région et Zone: Asia Pacific SE 1 (Singapour), Asie et Pacifique SE 1 Zone A
   • Type d'Instance: Général Type Type n1 – 1 noyau 1GB
   • Type de réseau: Sélectionnez le 'VPC' (VPC-Main), VSwitch (Public-Subnet1) et Security Group (SG-SSH-HTTP) créés en conséquence
   • Système d'exploitation: Ubuntu 16.04
   • Paramètre de sécurité: Attacher une paire de clés , sélectionnez la paire de clés générée à partir de l'étape 6 (ECS-Lab)
   • Nom de l'instance: ECS-Lab-WP
   • Cliquez sur "Acheter maintenant" et procédez en conséquence
3. SSH dans l'instance ECS achetée avec la paire de clés générée à l'étape 3.1. Reportez-vous à ce lien pour savoir comment utiliser SSH dans l'instance ECS. Allez dans "Product" et cliquez sur "Elastic Computing Service". Une fois arrivé sur la page de présentation ECS, cliquez sur "Instances" dans l'onglet latéral. L'adresse IP Internet est dans la colonne "Adresse IP".

SSH dans l'instance ECS et exécutez les commandes suivantes pour installer les logiciels et les packages nécessaires pour WordPress. Veuillez vous assurer que toutes les commandes sont exécutées avec succès.

 apt-get update
apt-get installer apache2 libapache2-mod-php php php-mcrypt php-mysql mysql-client-core-5.7 -y
cd / var / www / html
mv index.html index.html.bk
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
cp -r wordpress / * / var / www / html /
rm -rf wordpress latest.tar.gz
chown -R www-données: www-data / var / www / html
chmod -R 755 / var / www / html / wp-content
service apache2 redémarre

4. Configuration ApsaraDB RDS (Configuration de la couche de base de données)

1. Créer ApsaraDB RDS – MySQL. Allez dans "Produit" et cliquez sur "ApsaraDB for RDS". Une fois posé sur la page RDS, cliquez sur "Créer des instances".
   • Méthode de facturation: Pay-As-You-Go
   • Région et zone: Singapour, Zone multiple (Zone A + Zone B)
   • Moteur de base de données: MySQL
   • Type d'instance: 1 Core 1GB (rds. mysql.t1.small)
   • Type de réseau: "VPC", et sélectionnez VPC (VPC-Main) et VSwitch (Public-Subnet2) en conséquence
   • Cliquez sur "Acheter maintenant" et procédez en conséquence
2. Configurez l'instance RDS. Allez dans "Product" et cliquez sur "ApsaraDB for RDS" (cela peut prendre un peu de temps avant que le "RDS" acheté apparaisse sur la page). Une fois que le RDS acheté est opérationnel, cliquez sur "Gérer" sur le RDS.
3. Créez une liste blanche. Cliquez sur "Sécurité" sur l'onglet latéral. Sous l'onglet "Whitelist Setting", cliquez sur "+ Ajouter un groupe Whitelist".
   • Nom du groupe: rds_ecs_whitelist
   • Whitelist: 192.168.1.0/24
   • Cliquez sur "OK"
4. Créer la base de données "wordpress". Cliquez sur "Bases de données" sur l'onglet latéral suivi de "Créer une base de données".
   • Nom de la base de données: wordpress
   • Caractères supportés: utf8
   • Cliquez sur OK
5. Créer un compte utilisateur. Cliquez sur "Comptes" sur l'onglet latéral suivi de "Créer un compte".
   • Compte de base de données: wordpress_user
   • Bases de données autorisées: sélectionnez la base de données créée (wordpress)
   • Mot de passe & Mot de passe: WordPress123 (entrez votre propre mot de passe plus sécurisé ici)
6. Cliquez sur "OK" pour créer le compte.

5. Configuration WordPress (Configurer la couche application – Partie 2)

1. Naviguez jusqu'à l'adresse IP Internet ECS (créée à l'étape 3.2) en utilisant votre navigateur Web.
2. Remplissez les détails de connexion MySQL, tels que "Database Name", "Username" , "Mot de passe" tel que défini à l'étape 4.2. L'hôte de la base de données est l'adresse intranet de l'instance RDS créée en 4.1. Vous pouvez obtenir l'adresse intranet en accédant à la console d'Alibaba Cloud sur "Product" et en cliquant sur "ApsaraDB for RDS". Une fois arrivé sur la page RDS, cliquez sur l'instance RDS créée et copiez la valeur "Intranet Address"
3. Cliquez sur "Run on Installation" et continuez la configuration WordPress jusqu'à la fin. Hourra! A ce jour, votre première instance WordPress devrait être installée et en cours d'exécution à Alibaba Cloud !

6. Synchroniser le stockage de données dépendant (identifier le stockage centralisé)

1. Le dossier utilisé par WordPress pour stocker les fichiers téléchargés par l'utilisateur doit être synchronisé avec le stockage centralisé.
2. Créer un compartiment OSS . Allez dans "Product" et cliquez sur "Object Storage Service" sous "Storage & CDN". Une fois que vous avez atterri sur la page Object Storage, cliquez sur "Create Bucket" sur le RDS.
   • Nom du compartiment: lab-wp-XXX (utilisant votre propre nom de compartiment)
   • Région: Asia Pacific SE 1 (Singapour)
   • Classe de stockage: Standard
   • ACL: Private [19659011] Cliquez sur OK
3. Accordez l'accès au compartiment créé à l'étape 14. Allez dans "Product" et cliquez sur "Resource Access Management" sous "Monitor and Management". Une fois que vous avez atterri sur la page RAM, cliquez sur "Utilisateur" suivi de "Créer un utilisateur".
   • Nom d'utilisateur: oss-user
   • Cliquez OK
4. Autorise l'utilisateur créé avec l'accès OSS . Allez dans "Product" et cliquez sur "Resource Access Management" sous "Monitor and Management". Une fois que vous avez atterri sur la page RAM, cliquez sur le bouton "Autoriser" pour l'utilisateur nouvellement créé.
   • Sélectionnez et ajoutez "AliyunOSSFullAccess"
   • Cliquez sur OK
5. Générer "Clé d'accès utilisateur". Allez dans "Product" et cliquez sur "Resource Access Management" sous "Monitor and Management". Une fois que vous avez atterri sur la page RAM, cliquez sur "Gérer" pour l'utilisateur nouvellement créé.
6. Allez dans la section "User Access Key" et cliquez sur "Create Access Key".
7. Cliquez sur "Save Access Key Information "pour sauvegarder la clé d'accès générée et le secret de clé d'accès.
8. Installer l'outil" ossfs ". SSH dans l'instance de WordPress ECS lancée
9. Installez 'ossfs' selon les directives de ce lien

 cd Cet outil est utilisé pour synchroniser le dossier dépendant de WordPress avec le seau OSS créé à l'étape 6.2.
wget https://github.com/aliyun/ossfs/releases/download/v1.80.3/ossfs_1.80.3_ubuntu16.04_amd64.deb
sudo apt-get mise à jour
sudo apt-get installe gdebi-core -y
sudo gdebi ossfs_1.80.3_ubuntu16.04_amd64.deb

10. Créez le répertoire de téléchargement de WordPress:

 mkdir -p / var / www / html / wp-content / uploads
chown -R www-data: www-données / var / www / html / wp-content / uploads

11. Configurez les informations d'identification avec le nom et la clé du compartiment créés en conséquence aux étapes 6.2 et 6.5

 chmod 640 / etc / passwd-ossfs

12. Montez le compartiment OSS lab-wp-XXX dans le dossier dépendant de WordPress et activez le montage automatique lors du démarrage de l'instance.
13. Ajoutez la commande suivante dans / etc / fstab pour monter lab-wp-XXX lors du démarrage du système. Attention à l'utilisation de la zone correcte. Par exemple. " http://oss-ap-southeast-1.aliyuncs.com "

echo "ossfs # lab-wp-XXX / var / www / html / wp-content / télécharge le fusible _netdev, url = http: //oss-ap-southeast-1.aliyuncs.com,allow_other, 0 0 ">> / etc / fstab

14. Exécutez l'opération de montage: mount -a
15. Pour évitez que le compartiment OSS monté soit analysé par Linux (ce qui entraîne des coûts inutiles), ajoutez les détails suivants dans "/etc/updatedb.conf":
    • Add “/var/www/html/wp-content/uploads” to PRUNEPATHS
    • Add “fuse.ossfs” into PRUNEFS

7. High Availability, Fault Tolerance, and Load Balance Configuration

1. Create the Load Balancer. On the ECS overview page, click “Load Balancer” on the side tab. On the Load Balancer page, click “Create Server Load Balancer”.
   • Region: Singapore
   • Zone: Multi-zone
   • Primary Zone: Zone A
   • Backup Zone: Zone B
   • Instance Type: Internet
   • Quantity: 1
2. Configure load balancer. On the ECS overview page, click “Load Balancer” on the side tab. Once the Load Balancer page is loaded, click “Manage” on the purchased load balancer at Step 7.1.
3. Click “Listener” and then click the “Add Listener” button.
   • Front-end Protocol: HTTP, port 80
   • Back-end Protocol: HTTP, port 80
   • Scheduling: Weighted Round
   • Click “Show Advance” and enable persistence session
   • Timeout Duration: 300
4. Click “Next” to configure the health check.
   • Domain Name: Leave Blank
   • Health Check Port: 80
   • Health Check Path: /index.php
   • Normal Status Code: enable http_2xx and http_3xx
   • Click “Confirm” to provision Load Balancer
5. Update the Load Balancer internet IP address in WordPress. This is important as the running WordPress instance has been auto-configured with the running ECS IP. We need to change the IP to point to the Load Balancer’s IP, as WordPress might be running by any ECS instance behind the load balancer. If you have a domain name, you might want to update to the domain name instead.
   • Browse to WordPress using the browser. Go to the “Settings” URL e.g. “http:///wp-admin/options-general.php” and then change the “WordPress Address (URL)” & “Site Address (URL)” to the Load Balancer’s internet IP accordingly.
6. Stop the ECS instance. Go to “Product” and click on “Elastic Computing Service”. Once landed on the ECS overview page, click “Instances” on the side tab, followed by “More” and then “Stop”.
7. Create a Custom Image. Once ECS has stopped, click on “More” then “Create Custom Image”.
   • Image Name: IMG-WP
   • Image Description: Image for WordPress
8. Restart ECS once the ‘custom image’ creation at Step 22 has completed (you may check the creation status under the “Snapshot” section). Go to “Product” and click on “Elastic Computing Service”. Once landed on the ECS overview page, click “Instances” on the side tab, followed by “More” and then “Start”.
9. Once ECS is up and running, create an Auto Scaling Group. Go to “Product” and click on “Auto Scaling” under “Elastic Computing”. Once landed on the “Auto Scaling” page, click on “Create Scaling Group”.
   • Scaling Group Name: ASG-WS
   • Maximum Number: 2
   • Minimum Number: 2
   • Default Cool-down Time: 300
   • Network Type: VPC and select the VPC (VPC-Main) and VSwitch (Public-Subnet1)
   • Server Load Balancer: Select the load balance created at step 7.1. You may need to click “Load more data” to show the load balancer.
   • Configure the ECS source and ‘User Defined Image’ accordingly.
   • Click the “Submit” button.
10. Create a “Scaling Configuration”. Click on “Create Scaling Configuration”.
    • Source ECS: Select the one that got restarted at Step 7.8.
    • Configuration Name: ASG_ECS_WP
    • Security Group: Select the one created at Step 2.1
    • User Defined Image: Select the one created at Step 7.7.
    • Click “Next”, followed by “OK” and “Enable” the Auto Scaling Group.
    • Retrieve the Load Balancer Public IP. Go to “Product” and click on “Elastic Computing Service”. Once landed on the ECS overview page, click “Load Balancer” on the side tab. The Public IP is under the “IP Address” column.
11. The health check carried out by the Load Balancer might take a while to complete. You may visit the WordPress application by using the Load Balancer’s public IP once the Load Balance status is shown as “normal”.

Congratulations! You’ve now successfully deployed a high availability, fault tolerant, and load balanced WordPress server in a single region!

If you would like to buy a domain name, go to “Domain” under “Domain & Websites” and proceed for purchasing.

If you would like to associate your domain name with the deployed WordPress, go to “Alibaba Cloud DNS” under “Domain & Websites” and add at least ‘A’ records for the ‘Server Load Balance’ public IP.