Peu importe si vous exécutez un petit blog, une application volumineuse ou une API; vous ne voulez jamais qu’il soit hors ligne.
Un point de défaillance unique est une partie de votre infrastructure qui entraînera des temps d’arrêt en cas d’échec. Un exemple serait d’utiliser un serveur pour héberger votre serveur Web et votre base de données. Les pannes sont souvent causées par ces points uniques de défaillance et nous voulons concevoir notre infrastructure pour éviter ces situations.
Une infrastructure hautement disponible n’a pas de point de défaillance unique. Généralement, cela signifie que votre infrastructure est divisée par service et que chaque service est exécuté sur plusieurs serveurs. Si un serveur tombe en panne, d’autres serveurs sont disponibles pour traiter les demandes. Une configuration hautement disponible est non seulement importante pour la redondance, mais il sera également plus rapide et plus rentable de faire évoluer votre infrastructure.
Imaginez un service Web hébergeant vos fichiers. Imaginez maintenant qu’il tourne sur trois serveurs indépendants. Nous avons quelques problèmes immédiats. Comment les utilisateurs auront-ils accès à ces serveurs? Nous pourrions ajouter des enregistrements DNS pour chacun des serveurs indépendants. Les utilisateurs seraient malheureusement routés vers des serveurs de manière aléatoire et pourraient être envoyés à un serveur hors ligne.
Nous pouvons éviter ces pièges en ajoutant un équilibreur de charge à notre infrastructure. L’équilibreur de charge effectuera des contrôles d’intégrité sur chacun des serveurs dont il dispose dans sa configuration. Si un serveur est hors ligne, l’équilibreur de charge n’enverra aucune demande d’utilisateur. Un équilibreur de charge augmente les performances en routant plus efficacement les utilisateurs vers le meilleur serveur disponible.
La seule préoccupation supplémentaire que nous aurions en effectuant cet ajout est de nous assurer que l’équilibreur de charge lui-même ne constitue pas un point de défaillance unique. Nous y avons pensé et avons deux solutions complètes hautement disponibles au niveau de la couche d’équilibreur de charge et des serveurs principaux.
Notre configuration
Dans ce chapitre, nous allons examiner deux manières de déployer une solution à charge équilibrée avec quelques serveurs Web. À la fin de cette section (chapitres 4 à 6), nous aurons plusieurs équilibreurs de charge configurés devant les services Web et de base de données, garantissant ainsi l’absence de points de défaillance uniques.
Il existe différentes manières de configurer l’équilibrage de charge. Nous allons passer par deux exemples de configuration, les deux servant un service Web Nginx sur le backend.
La première solution utilise DigitalOcean Load Balancers, qui est un service hautement disponible qui gère automatiquement la reprise en cas de basculement. Ils incluent également la possibilité de diriger le trafic vers des gouttelettes en se basant sur tags au lieu d’une liste manuelle, ce qui simplifie votre redimensionnement.
La seconde solution est une solution d’équilibrage de charge plus personnalisée avec HAProxy et DigitalOcean Floating IPs, qui sont des adresses IP statiques pouvant être attribuées et réaffectées dans un région automatiquement à l’aide du Panneau de configuration ou de l’API. Vous pouvez les utiliser pour rediriger le trafic vers un équilibreur de charge en attente en cas d’échec du principal.
Parce que c’est la première fois que nous utilisons Terraform et Ansible dans ce livre, nous allons parcourir cette section un peu manuellement pour vous donner une expérience de la création manuelle de vos propres projets. À mesure que nous passerons à des configurations plus complexes dans le chapitre suivant, nous automatiserons la majeure partie de la configuration.
Utilisation de l’équilibreur de charge DigitalOcean
Configuration de l’équilibreur de charge DigitalOcean
Sur le contrôleur Droplet, accédez à le répertoire de ce chapitre dans notre référentiel.
cd /root/navigators-guide/example-code/02-scale/ch04/digitalocean_loadbalancerDans ce répertoire, vous trouverez a `+ terraform.tfvars.sample + `fichier. Cet exemple de fichier comprend des commentaires et des notes pour vous aider à trouver les informations dont vous avez besoin. Sans les commentaires, le fichier ressemble à ceci:
do_token = ""
project = "DO-LB"
region = "sfo2"
image_slug = "debian-9-x64"
keys = ""
private_key_path = ""
ssh_fingerprint = ""
public_key = ""Cela va créer un équilibreur de charge DigitalOcean avec quelques gouttelettes exécutant Nginx. Chaque serveur Web affichera un simple message de bienvenue avec le nom d’hôte individuel de Droplet.
Remplissez les variables en suivant les instructions dans les commentaires, puis renommez le fichier + terraform.tfvars +.
mv terraform.tfvars.sample terraform.tfvarsCette configuration ne nécessite pas de certificat TLS, mais vous pouvez en ajouter un à DigitalOcean Load Balancer. La fonction DigitalOcean Load Balancer est également intégrée à Let’s Encrypt, qui fournit des certificats sans frais. Lets Encrypt requiert un nom de domaine enregistré et ajouté à votre compte DigitalOcean.
Ensuite, préparez et exécutez le déploiement de Terraform. Commencez par analyser les fichiers de plan et les modules en utilisant + terraform init +. Vous pouvez éventuellement exécuter + terraform plan + pour voir ce qui se passera lorsque vous exécuterez le script réel. Lorsque vous êtes prêt, exécutez + terraform apply + pour exécuter les demandes de création via l’API DigitalOcean.
terraform init
terraform applyVous devrez confirmer l’exécution en entrant + yes + et vous serez averti lorsque l’application est terminée.
À ce stade, vous pouvez visiter l’adresse IP publique de votre équilibreur de charge (que vous pouvez obtenir avec terraform show +) dans votre navigateur pour voir le contenu de vos serveurs Web à titre d’exemple.
Terraform peut également supprimer votre cluster automatiquement avec l’option + destroy +. Vous pouvez utiliser ce flux de travail pour effectuer des tests rapides, mais sachez que toutes les données enregistrées dans le cluster seront supprimées. * L’option + destroy + supprimera votre cluster. * C’est le moyen le plus rapide de nettoyer le travail effectué dans ce chapitre. Vous pouvez réexécuter + apply + pour générer un nouveau cluster.
Avant de supprimer cet exemple de cluster, testons qu’il est réellement hautement disponible, comme nous l’attendions.
Test de la disponibilité du cluster
Pour tester la disponibilité des serveurs Web principaux, nous pouvons mettre un serveur hors ligne tout en demandant en permanence des connexions à Load Balancer. Si les connexions continuent à établir, nous saurons que le service est resté en ligne malgré une défaillance du serveur. (Nous ne pouvons pas tester le basculement de Load Balancer lui-même car il s’exécute en tant que service, ce qui signifie que vous n’avez pas ou n’avez pas besoin d’un accès direct à ses composants individuels.)
Exécutez la commande suivante dans un terminal, qui se connectera à Load Balancer une fois par seconde.
while true; do curl -k load_balancer_ip; sleep 1; doneVous verrez une sortie continue comme ceci:
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!Essayez d’éteindre l’une des gouttelettes principales. Lorsque Droplet est hors ligne, vous devriez toujours voir le test renvoyer des réponses valides du backend de votre autre Load Balancer. Vous remarquerez que le Droplet que vous avez désactivé ne répond plus. Si vous le rallumez, vous verrez qu’il sera automatiquement ajouté à la rotation une fois qu’il aura passé les vérifications configurées de Load Balancer.
_ (Si vous avez besoin d’aide pour arrêter le test en cours, vous pouvez quitter la boucle avec une commande au clavier + CTRL-C +) _
Mise à l’échelle du cluster
La configuration initiale du cluster utilise 3 droplets dorsaux. Le paramètre pour le nombre de gouttelettes dorsales est défini dans la déclaration de variable par défaut du fichier variables.tf. Nous pouvons remplacer en ajoutant une ligne à + terraform.tfvars + avec la variable + node_count + définie sur 5. Une fois la ligne ajoutée, vous devrez réappliquer le plan Terraform.
terraform applyTerraform brille vraiment ici. Il gère la logique pour modifier le nombre de gouttelettes en fonction de cette variable. Il crée ou détruit donc automatiquement les gouttelettes lorsque la variable + node_count + augmente ou diminue.
Dans le terminal exécutant + curl + sur votre Load Balancer, examinez le résultat. Une fois que les nouvelles Droplets sont mises en service, vous les verrez commencer à répondre automatiquement.
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!
Welcome to DO-LB-backend-02!
Welcome to DO-LB-backend-03!
Welcome to DO-LB-backend-04!
Welcome to DO-LB-backend-05!
Welcome to DO-LB-backend-01!Avant de continuer, vous voudrez détruire ce projet de test. Terraform conserve l’état actuel du plan dans le répertoire de travail en cours. Lorsque vous détruisez les ressources via Terraform, l’état est automatiquement effacé.
terraform destroyUtilisation de HAProxy et d’une adresse IP flottante DigitalOcean
Le déploiement d’une solution personnalisée d’équilibrage de la charge peut constituer le bon choix. Certaines options ne sont pas prises en charge par DigitalOcean Load Balancer pour le moment. Par exemple, l’hébergement de plusieurs sites ou applications en tant que backends, de plusieurs certificats TLS, de la prise en charge du protocole proxy ou de l’optimisation de paramètres TCP spécifiques.
Cet exemple utilise des équilibreurs de charge HAProxy v1.8 en cluster utilisant une adresse IP flottante DigitalOcean pour le basculement.
Configurer HAProxy
Sur le contrôleur Droplet, accédez à le répertoire de ce chapitre dans notre référentiel.
cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancerDans ce répertoire, vous trouverez a `+ terraform.tfvars.sample + `fichier. Cet exemple de fichier comprend des commentaires et des notes pour vous aider à trouver les informations dont vous avez besoin. Sans les commentaires, le fichier ressemble à ceci:
do_token = ""
project = "HAPROXY-LB"
region = "sfo2"
image_slug = "debian-9-x64"
keys = ""
private_key_path = ""
ssh_fingerprint = ""
public_key = ""Remplissez les variables en suivant les instructions dans les commentaires, puis renommez le fichier + terraform.tfvars +.
mv terraform.tfvars.sample terraform.tfvarsEnsuite, préparez et exécutez le déploiement de Terraform. Commencez par analyser les fichiers de plan et les modules en utilisant + terraform init +. Vous pouvez éventuellement exécuter + terraform plan + pour voir ce qui se passera lorsque vous exécuterez le script réel. Lorsque vous êtes prêt, exécutez + terraform apply + pour exécuter les demandes de création via l’API DigitalOcean.
terraform init
terraform applyVous devrez confirmer l’exécution en entrant + yes + et vous serez averti lorsque l’application est terminée.
Si vous exécutez + terraform show + maintenant, vous pouvez voir les ressources que vous avez déployées. Chaque ensemble de ressources (c.-à-d. Droplets) est placé dans un nom de groupe en fonction du nom de la ressource dans le fichier de configuration Terraform. Dans cet exemple, la ressource + haproxy.tf + file ' déclaration détermine ces groupes.
Les trois groupes sont + load_balancer + pour HAProxy, + web_node + pour Nginx et + fip + pour l’IP flottante. Vous pouvez jeter un coup d’oeil avec + terraform-inventory -inventory + pour obtenir un inventaire Ansible au format INI, ou générer du JSON avec l’option + -list.
À ce stade, les gouttelettes dont vous avez besoin sont créées et en cours d’exécution, mais elles doivent encore être configurées.
Configuration des gouttelettes avec Ansible
Nous allons automatiser la configuration des gouttelettes en utilisant Ansible. Nous avons un livre de base Ansible qui est préconfiguré pour télécharger quelques rôles Ansible. Vous trouverez ces rôles Ansible dans la liste suivante: le fichier + Requirements.yml + . Vous n’avez pas besoin de les installer un par un; vous pouvez télécharger les rôles requis avec Ansible Galaxy.
Cette commande place les rôles dans le répertoire + roles +.
ansible-galaxy install -r requirements.ymlVous devez définir quelques variables supplémentaires pour ce rôle. Nous allons revenir au répertoire _ / root / navigators-guide / example-code / 02-scale / ch04 / haproxyloadbalancer / groupvars / load_balancer / . Si vous affichez le fichier * vars.yml * existant, vous verrez que «+ do_token » et ` ha_auth_key ` sont affectés aux valeurs de ` vault_do_token ` et ` vault_ha_auth_key `, respectivement. Nous allons créer un fichier secondaire nommé * vault.yml * et initialiser les variables ` vault +`.
Vous aurez besoin de deux choses avant de définir les variables. Un jeton d’API DigitalOcean qui sera utilisé pour gérer l’affectation d’adresse IP flottante pour les scénarios de basculement, et un hachage SHA-1 qui sera utilisé pour authentifier les membres du cluster. Nous avons un outil pour vous aider à créer cela.
cd /root/navigators-guide/example-code/02-scale/ch04/haproxy_loadbalancer/
./gen_auth_keyUne fois cette clé auth créée, continuez et créez le fichier groupvars / load_balancer / vault.yml