Le chapitre précédent a montré comment réduire les temps d’arrêt en ajoutant de la redondance au niveau de la couche frontale Web de votre infrastructure. Si votre service fonctionne avec des fichiers et des données, vous aurez également besoin d’un back-end centralisé, qui devrait être redondant de la même manière pour éviter d’être un point de défaillance unique.
Le client et le serveur peuvent utiliser une solution à charge équilibrée pour répartir le trafic sur plusieurs serveurs. Cette structure offre des avantages uniques sur le back-end, tels que la possibilité de mettre à jour le code de votre application sans interruption, de prendre en charge des tâches telles que les tests A / B, les déploiements Canary et les déploiements bleu / vert. Toutefois, cela ajoute également une certaine complexité à votre infrastructure. Vous devrez prendre en compte des éléments tels que la gestion de la configuration de vos équilibreurs de charge, la gestion de votre application et des serveurs sur lesquels elle s’exécute, et la gestion de la cohérence des éléments tels que les sessions utilisateur, le stockage de fichiers et les bases de données.
Que vous utilisiez DigitalOcean Load Balancers ou un ensemble d’équilibreurs de charge auto-géré, vous devez maintenir la cohérence de sa configuration. La gestion du fichier de configuration à l’aide d’un outil de gestion de la configuration dans une installation d’équilibreur de charge auto-gérée est plus pratique et nécessite un travail supplémentaire considérable, tandis que DigitalOcean Load Balancers est un service géré qui gère automatiquement la redondance de l’équilibreur de charge.
Pour DigitalOcean Load Balancers, les options de configuration sont sélectionnées, mais vous devez tout de même vous assurer que les paramètres sont corrects et cohérents. L’utilisation d’une balise Droplet pour déterminer le backend de Load Balancer est le chemin le plus direct vers le succès, car elle vous permet d’ajouter et de supprimer automatiquement des gouttelettes (plutôt que par une adresse IP individuelle) et signifie que votre configuration peut être gérée uniquement par Terraform sans Ansible.
Si vos exigences en matière d’équilibrage de charge étaient plus complexes, vous avez peut-être choisi d’utiliser votre propre équilibreur de charge (avec HAProxy, comme dans le chapitre précédent, ou un autre logiciel d’équilibrage de charge). Dans ce cas, vous devez déployer un ensemble de plusieurs Droplets d’équilibrage de charge avec une adresse IP flottante DigitalOcean pour garantir la redondance au niveau de la couche d’équilibrage de charge.
Notre configuration
La cohérence des données est la principale complication que vous allez aborder dans la configuration de votre équilibreur de charge. Lorsque votre serveur peut être servi à partir de plusieurs serveurs, vous devez vous assurer que chaque serveur a accès au même jeu de données cohérent ou qu’une session particulière continuera à se connecter à un serveur particulier.
Nous allons en profiter pour démontrer une utilisation plus puissante du logiciel de gestion de la configuration. Dans notre exemple d’hébergement d’un site Web exécutant WordPress, nous devrons prendre des décisions afin de nous assurer que chaque nœud de notre cluster dispose des données appropriées. Les utilisateurs finaux doivent avoir une expérience cohérente, quel que soit le nœud qui traite la demande. Un utilisateur final peut voir des résultats sporadiques si un nœud connaît une publication ou une image de notre site WordPress, mais pas les autres nœuds.
Nous examinerons trois composants connexes au cours de la configuration pour en assurer la cohérence: sessions utilisateur, stockage de fichiers et bases de données.
Comprendre la configuration
En réalité, la configuration du cluster une fois la configuration terminée est un processus relativement court, mais il est essentiel de comprendre la configuration et les décisions qui y sont prises pour pouvoir appliquer ces modèles à votre propre infrastructure. Laissez-le décomposer pièce par pièce.
Configuration de l’équilibreur de charge
Equilibreur de charge DigitalOcean
Comme dans les chapitres précédents, nous utiliserons Terraform pour gérer la configuration de Load Balancer. L’entrée suivante crée un équilibreur de charge et fournit la balise Droplet dorsale, les règles de transmission, le certificat TLS à utiliser et les vérifications de l’intégrité que l’équilibreur de charge utilisera. SSL et d’autres paramètres de sécurité ne sont pas concernés par ce chapitre, mais ils sont décrits en détail au chapitre 13.
Voici le bloc de ressources situé dans le fichier + example-code / 02-scale / ch05 / init_deploy / main.tf +:
...
resource "digitalocean_loadbalancer" "public" {
name = "${var.project}-lb"
region = "${var.region}"
droplet_tag = "${digitalocean_tag.backend_tag.id}"
redirect_http_to_https = true
depends_on = ["digitalocean_tag.backend_tag"]
forwarding_rule {
entry_port = 80
entry_protocol = "http"
target_port = 80
target_protocol = "http"
}
healthcheck {
port = 80
protocol = "http"
path = "/"
check_interval_seconds = 5
response_timeout_seconds = 3
unhealthy_threshold = 2
healthy_threshold = 2
}
}Les équilibreurs de charge étant un service et non une ressource immuable (comme un droplet), une modification des arguments de configuration ne recrée pas l’intégralité de l’équilibreur de charge; il va mettre à jour en place. Pour plus de détails sur les arguments et les attributs de sortie pris en charge, consultez la documentation Terraform.
Nous utilisons un équilibreur de charge DigitalOcean pour gérer l’équilibrage de la charge du trafic Web public sur nos serveurs Web.
HAProxy Cluster
Si vous avez besoin d’une configuration plus complexe, telle que l’accès à des paramètres d’équilibrage de charge de niveau inférieur ou la prise en charge de plusieurs services principaux, vous pouvez configurer votre propre cluster d’équilibreur de charge. Nous allons continuer avec l’exemple HAProxy du chapitre précédent.
Ansible utilise le système de templates Jinja2, qui simplifie le processus de création et de mise à jour de vos fichiers de configuration. Jinja2 prend en charge l’utilisation de variables et de structures de contrôle que vous trouverez dans un langage de programmation, comme les instructions if, les boucles, les opérations mathématiques et la grande bibliothèque de filtres intégrés. Ce résumé ne rend pas justice au système de templates dans Ansible. Nous vous recommandons de consulter la Ansible’s documentation pour plus de détails.
Il existe plusieurs façons de déclencher une mise à jour lorsque votre configuration change. Si la demande sur votre site ne fluctue pas beaucoup ou si vous savez à quel moment les changements se produiront à l’avance, il se peut que vous n’ayez pas besoin ou ne souhaitiez pas configurer une mise à l’échelle entièrement automatisée. À la place, vous pouvez exécuter manuellement votre playbook Ansible ou le configurer pour l’exécuter lorsque vous appliquez une modification à vos scripts de déploiement Terraform dans votre référentiel git.
Une autre option consiste à utiliser Consul pour la découverte de services et à configurer + consul-template sur votre équilibreur de charge pour actualiser automatiquement le fichier de configuration. Cela ajoute des gouttelettes à votre infrastructure globale, mais vous pouvez également utiliser Consul pour d’autres services.
Nous utilisons un cluster HAProxy pour gérer l’équilibrage de charge de notre cluster de bases de données.
Sessions utilisateur
-
Examen des sessions *
_ Lorsqu’un utilisateur visite un site hébergé par un équilibreur de charge, rien ne garantit que sa prochaine requête sera traitée par le même serveur principal. Pour les pages statiques simples, ce ne sera pas un problème, mais si le service a besoin de connaître la session de l’utilisateur (comme s’ils se sont connectés), vous devrez le gérer. Il existe quelques options pour résoudre ce problème qui peuvent être implémentées à différents points de votre pile. _
La méthode que vous choisissez pour gérer les sessions utilisateur dépendra de votre cas d’utilisation. Voici quelques options:
-
Affinité de source IP * dirige toutes les demandes de la même adresse IP vers le même serveur. Ce n’est pas le meilleur choix dans les situations où vos utilisateurs peuvent se connecter derrière un routeur utilisant NAT, car ils auront tous la même adresse IP.
Les options * session d’équilibrage de charge * et * session d’application * sont similaires. Ils configurent tous les deux l’équilibreur de charge pour qu’il consulte les informations d’en-tête IP afin de déterminer le backend auquel envoyer les demandes. Contrairement à la méthode d’affinité source IP, les utilisateurs derrière un NAT seraient identifiés comme des utilisateurs individuels. Vous pouvez ajuster cela davantage en mettant en place un stick-table sur les équilibreurs de charge HAProxy, qui peut être utilisé pour configurer l’identification de l’utilisateur sur la base de plusieurs points de données différents.
-
La réplication du système de fichiers * réplique le chemin d’accès dans votre système de fichiers où les sessions sont stockées, donnant à tous les backends un accès à toutes les sessions. Un aspect important à prendre en compte est la vitesse à laquelle la réplication a lieu. En fonction de la méthode, même un délai modéré entre le nœud principal et le nombre de sessions à répliquer peut être source de problèmes pour les utilisateurs finaux.
L’utilisation d’une * base de données * ou * d’un magasin de données en mémoire * est similaire. Dans les deux cas, vous devez créer votre application de manière à stocker les sessions utilisateur dans une base de données ou dans un cache en mémoire tel que Redis. L’utilisation d’une base de données peut être pratique car votre application sera déjà configurée pour s’y connecter pour d’autres requêtes de données. Pour un site très actif, cela peut alourdir davantage la base de données, mais dans la plupart des cas, la charge supplémentaire est négligeable. L’utilisation d’un cache en mémoire tel que Redis ou Memcached signifie que vous devez créer quelques Droplets supplémentaires, mais il s’agit de solutions très rapides et polyvalentes que vous pouvez également utiliser pour mettre en cache les réponses aux requêtes de base de données afin d’améliorer les performances.
WordPress étant déjà configuré pour utiliser une base de données pendant des sessions, c’est la solution que nous allons utiliser.
Stockage de fichiers
-
_Revue de stockage de fichiers: _ *
_ Les fichiers utilisés par votre application devront être cohérents. tous les serveurs devront avoir accès au même ensemble de ressources. Une bonne solution à ce problème consiste à découpler la fonctionnalité de stockage de vos serveurs d’applications principaux et à utiliser un service distinct pour le stockage de fichiers. Pour les actifs statiques, vous pouvez utiliser une solution de stockage d’objets. DigitalOcean Spaces est un service de stockage d’objets hautement disponible avec redondance intégrée. Nous parlons plus en détail des options de stockage, en particulier des espaces, au chapitre 7. _
Comme les sessions, vous pouvez gérer le stockage de fichiers à l’aide de la réplication de système de fichiers locale entre vos nœuds d’application. Toutefois, cela ajoute un autre service à votre infrastructure, ainsi que des modifications de configuration supplémentaires.
Une solution plus simple consiste à utiliser le stockage d’objets, comme DigitalOcean Spaces, notamment parce que WordPress dispose déjà d’un plug-in DigitalOcean Spaces. La configuration étant réduite à l’installation et à la configuration d’un seul plug-in, c’est la solution que nous allons utiliser dans ce chapitre.
Base de données
-
Revue de base de données *
_ _ Tout comme le stockage de fichiers, votre base de données doit être accessible à toutes les gouttelettes dorsales. La manière dont vous répliquez les insertions et les mises à jour de la base de données sur un cluster est essentielle pour une solution de base de données en cluster fonctionnelle.
En outre, votre base de données doit être hautement disponible, c’est-à-dire qu’elle dispose d’une redondance et d’un basculement automatique. Cela peut être plus compliqué que de simplement le placer derrière un équilibreur de charge car le système devra gérer la cohérence des données, comme ce qui se produit si des mises à jour conflictuelles sont apportées à différents nœuds.
Dans notre exemple, nous utilisons un cluster MariaDB Galera pour gérer ces problèmes. Galera gère la réplication synchrone sur chaque nœud de base de données, chacun agissant en tant que serveur de base de données primaire complet. Cela signifie que vous pouvez lire et écrire sur chacun des nœuds du cluster et que tout est synchronisé. Il existe d’autres moyens de regrouper des bases de données impliquant des formes de réplication principale et secondaire dans lesquelles un nœud spécifique est choisi comme serveur d’écriture principal.
Chaque solution de cluster a ses avantages. Pour notre exercice, Galera nous offre le plus d’avantages, car la cohérence des données est gérée automatiquement et chaque nœud du cluster peut servir de serveur principal. Aucune étape de basculement ou de restauration n’est nécessaire. _ _
WordPress s’appuie sur sa base de données pour presque tout, et un seul serveur de base de données externe est un point de défaillance unique. Il existe quelques options pour les clusters de bases de données, et différentes parties peuvent être combinées et associées en fonction de ce qui fonctionne le mieux dans votre cas.
Dans ce chapitre, nous construirons un cluster Galera fonctionnant sur MariaDB, un fork de MySQL. Cela s’exécutera derrière quelques nœuds HAProxy avec une adresse IP flottante DigitalOcean attachée.
Vous pouvez visiter le dépôt source pour cela ici: https://github.com/DO-Solutions/galera-tf-mod. Il configure le routage TCP vers le cluster, qui comporte trois nœuds par défaut. Si nous utilisions moins de trois nœuds, un nœud Galera Arbitrator serait nécessaire pour éviter les situations de scission du cerveau et maintenir le cluster en état de fonctionnement. Vous pouvez également augmenter le nombre de nœuds en ajoutant la ligne suivante au bloc de code de module dans notre fichier terraform principal example-code / 02-scale / ch05 / init_deploy / main.tf. Notez que vous souhaiterez disposer d’un nombre impair de nœuds pour qu’un cluster puisse disposer de la majorité lors de l’exercice du vote de quorum. Par exemple, si deux nœuds pensent qu’un enregistrement devrait exister et deux autres nœuds, l’enregistrement ne devrait pas exister, un nœud supplémentaire est nécessaire pour pouvoir voter.
module "sippin_db" {
...
db_node_count = "5"
}Configuration du cluster WordPress
Dans notre projet, la configuration du cluster WordPress ne prend que quelques commandes. Nous allons travailler avec + / root / navigators-guide / example-code / 02-scale / ch05 / init_deploy + sur le contrôle Droplet, qui contient l’exemple de code pour ce chapitre.
À partir de ce répertoire, exécutez le script d’initialisation que nous avons fourni. Il vous guidera à travers tous les paramètres et variables que vous devez définir.
./bin/init_configVous pouvez afficher le code du script d’initialisation à l’adresse GitHub. Vous verrez que le script exécute un certain nombre de fonctions. En réalité, il crée automatiquement les fichiers de variable Terraform et Ansible nécessaires et veille à ce qu’aucun problème connu ne se produise. La première chose que fera le script est de demander un jeton valide de l’API DigitalOcean. Après cela, le script créera des clés uniques nécessaires à la création du cluster. L’invite suivante que vous verrez sera de nommer le projet et de sélectionner une région. Si une clé SSH est déjà configurée (comme nous l’avons vu au chapitre 4), le script indiquera à Terraform de l’utiliser. Si une clé SSH n’est pas encore configurée, elle sera automatiquement créée et ajoutée à votre compte DigitalOcean. Enfin, le script vous demandera les mots de passe nécessaires.
Une fois le script terminé, le plan Terraform et le classeur Ansible sont prêts à être exécutés. Cela ressemble beaucoup aux exemples du chapitre 4, mais il y a plus de ressources en cours de création et de configuration.
Si vous deviez tout configurer manuellement, vous auriez besoin des variables entrées pour Terraform dans le fichier * terraform.tvfars *. Ansible a requis des variables dans plusieurs dossiers du dossier * group_vars *.
Le script d’initialisation imprime des instructions sur la façon de continuer avec Terraform avant de quitter, mais nous allons le parcourir ici également.
D’abord, exécuter + terraform plan + créera les éléments suivants dans votre compte DigitalOcean:
-
One Load Balancer, qui donnera accès à votre site WordPress.
-
Trois gouttelettes à utiliser comme nœuds Web WordPress.
-
Trois gouttelettes à utiliser comme nœuds de base de données.
-
Deux nœuds HAProxy Load Balancer pour le cluster de base de données.
-
Une adresse IP flottante pour l’équilibreur de charge de la base de données.
terraform planEnsuite, analysez les fichiers de plan et les modules pour préparer le déploiement de Terraform à l’aide de + init +.
terraform initEnfin, exécutez les demandes de création via l’API DigitalOcean en utilisant + apply +.
terraform applyUne fois que Terraform a fini de créer tous les composants d’infrastructure, utilisez Ansible pour les configurer. Il y a trois rôles Ansible à exécuter: un pour configurer les serveurs de base de données, un pour configurer les équilibreurs de charge de base de données et un pour configurer WordPress sur tous les nœuds Web.
Vous pouvez exécuter les trois rôles avec une seule commande:
ansible-playbook -i /usr/local/bin/terraform-inventory site.ymlUne fois que le livre de lecture est terminé, vous devez terminer la configuration de WordPress.
Visitez l’adresse IP de votre équilibreur de charge dans votre navigateur et suivez les instructions à l’écran pour compléter votre configuration WordPress. Notez que le chapitre 13 explique comment protéger votre installation WordPress avec HTTPS.
Configuration des espaces
Nous utiliserons le plug-in DigitalOcean Spaces Sync afin de synchroniser les fichiers multimédias des serveurs d’applications WordPress vers le stockage d’objets. L’Espace agit comme un emplacement central pour stocker tout support que vous choisissez de télécharger.
Le plug-in DigitalOcean Spaces Sync a été préinstallé dans le livre de lecture Ansible. Pour utiliser ce plugin, vous devez d’abord create un espace à l’aide du Panneau de configuration.
Une fois l’espace créé, create une clé d’accès Spaces sur la page "API" du panneau de configuration. . Lors de la génération de la clé, vous verrez la clé principale avec le secret. Notez-les, car vous en aurez besoin pour configurer le plugin WordPress.
Maintenant, revenant à WordPress, visitez la page Plugins et vous devriez voir le DigitalOcean Spaces Sync déjà installé grâce à notre playbook Ansible. Cliquez sur le lien Activer pour activer ce plugin. Une fois activé, un nouveau lien apparaîtra dans vos paramètres, intitulé «Synchronisation des espaces DigitalOcean».
Sur cette page de paramètres, entrez votre clé Spaces, le secret des espaces, le nom de l’espace (désigné sur cette page par «Conteneur d’espaces») et le point de terminaison. N’oubliez pas que le point de terminaison dépend du centre de données que vous avez choisi pour votre espace: par exemple, NYC3 correspond à «https: //nyc3.digitaloceanspaces.com».
Après avoir vérifié la connexion, ajoutez l’URL complète de votre espace sous «Chemin d’URL complet des fichiers:». Pour un espace dans NYC3, il s’agirait de «https: //space-name.nyc3.digitaloceanspaces.com» (où + nom-espace + est le nom de votre espace). Une fois que cela est entré, il est temps de sauvegarder vos paramètres et de tester le plug-in en téléchargeant un fichier.
Lorsque vous téléchargez un fichier dans l’onglet «Média», vous devriez le voir se synchroniser automatiquement avec votre espace. Vous pouvez le vérifier en consultant la liste des fichiers de l’Espace dans le panneau de configuration de DigitalOcean.
Désormais, par défaut, cette configuration n’utilise pas de CDN. Dans un environnement de production, nous vous recommandons vivement d’utiliser un CDN, car cela vous permettra de servir ces fichiers multimédia rapidement et de manière fiable pour tous les visiteurs.
Si vous ajoutez un CDN ultérieurement, gardez à l’esprit que vous devrez pointer le «chemin d’URL complet des fichiers» sur l’adresse de ce nouveau CDN. Nous travaillons également sur un CDN qui s’intègre à Spaces. Ceci est actuellement en version bêta, mais n’hésitez pas à demander à votre responsable de compte un accès si vous êtes intéressé.
Vérification de la configuration
En accédant à votre adresse IP Load Balancer dans votre navigateur, vous pouvez voir le site WordPress par défaut, semblable à ceci:
image: https: //raw.githubusercontent.com/digitalocean/navigators-guide/master/book/02-scale/ch05-wordpress-screenshot.png [Capture d’écran de l’installation par défaut de WordPress]
Le résultat final est un site WordPress entièrement fonctionnel. Vous pouvez tester en configurant un blog ou en créant des articles. Vous pouvez mettre hors tension deux des serveurs Web, l’un des serveurs HAProxy et l’un des nœuds de base de données. Le site Web doit toujours être entièrement fonctionnel.
Une fois les tests terminés, vous pouvez supprimer tous ces composants d’infrastructure de votre compte DigitalOcean en une seule commande. Cela supprimera le cluster entier pour nettoyer le travail de ce chapitre.
terraform destroyVous pouvez réexécuter + apply + puis réexécuter le playbook Ansible pour régénérer le cluster.
Et après?
Nous avons pris nos exemples de haute disponibilité et appliqué le concept à l’ensemble de la pile d’applications. L’exemple de ce chapitre a été utilisé pour créer un site Web WordPress entièrement redondant et évolutif. Ceci a été réalisé avec des outils de gestion de la configuration. Nous allons explorer un moyen d’automatiser et d’améliorer nos déploiements dans le chapitre suivant. La suite de l’ouvrage couvrira les concepts relatifs au stockage, à la surveillance et à la sécurité, mais surtout leur application à votre entreprise et les points à prendre en compte lors de la planification de votre infrastructure.