TOC

Infrastructure SaltStack: Création d’états Salt pour les serveurs Web Nginx

introduction

SaltStack, ou Salt, est un puissant système d’exécution à distance et de gestion de la configuration qui permet de gérer facilement l’infrastructure de manière structurée et reproductible. Dans cette série, nous présenterons une méthode de gestion de vos environnements de développement, de transfert et de production à partir d’un déploiement de Salt. Nous utiliserons le système d’état de Salt pour écrire et appliquer des actions répétables. Cela nous permettra de détruire n’importe lequel de nos environnements, en sachant que nous pourrons facilement les remettre en ligne dans un état identique ultérieurement.

Dans notre https://www.digitalocean.com/community/tutorials/saltstack-infrastructure-configuring-salt-cloud-to-spin-up-digitalocean-ources (guide précédent), nous avons étendu les capacités de notre serveur maître Salt en configurant le fournisseur DigitalOcean pour + salt-cloud +. Nous avons créé les fichiers nécessaires pour nous permettre d’activer de nouveaux serveurs pour chacun de nos environnements. Dans cet article, nous allons commencer à plonger dans la gestion de la configuration en créant des fichiers d’état Salt pour Nginx. Nginx sera utilisé sur nos nœuds de serveurs Web dans les trois environnements afin de traiter les demandes Web.

Créer le fichier d’état principal de Nginx

Salt gère la gestion de la configuration via son système d’état. Dans le cas le plus simple, ceux-ci sont contrôlés par des fichiers situés à la racine du serveur de fichiers de Salt (que nous avons configurés sous la forme + / srv / salt +). Pour démarrer notre configuration Nginx, nous allons créer un répertoire à cet emplacement spécifique au logiciel que nous configurons:

sudo mkdir /srv/salt/nginx

Les fichiers d’état ont un suffixe + .sls +. Un fichier + init.sls + dans un répertoire sert de fichier de configuration principal pour cet état ou cette formule Salt. Nous nous référons au nom du répertoire parent pour exécuter la fonctionnalité contenue dans le fichier + init.sls + associé.

Dans cet esprit, créez et ouvrez un fichier + init.sls + dans ce répertoire pour commencer:

sudo nano /srv/salt/nginx/init.sls

Le paquet Nginx et les états de service

Nous allons commencer par créer un état utilisant l’identifiant + nginx +. Cela servira de nom unique pour cet état particulier dans le système d’état de Salt. Puisque nous n’inclurons pas l’attribut «name» pour nos modules d’état, il servira également de cible à installer (pour la fonction + pkg.installed +) et de service en cours d’exécution (pour le service `+ .running + `fonction).

Nous souhaitons que Nginx se recharge automatiquement dans certaines conditions: lors de la mise à jour du package, de la modification du fichier de configuration principal ou de la modification du fichier de blocage du serveur par défaut. Nous pouvons dire à Salt de redémarrer le service Nginx lorsque ces conditions se produisent en utilisant + watch +:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Les clés + pkg: + et + file: + situées sous la touche + watch: + représentent les modules d’état associés aux ressources à surveiller. La ressource + pkg + est prise en charge dans la première partie de cette même définition. Nous devrons créer les états pour faire correspondre les ressources + file à la prochaine.

Les états du fichier de configuration Nginx

Nous pouvons commencer avec le fichier + / etc / nginx / nginx.conf +. Nous aimerions en faire un fichier géré. En termes de Salt, cela signifie simplement que nous allons définir le contenu du fichier sur le serveur maître et le télécharger sur chaque séide qui en a besoin. Nous allons définir des autorisations et des propriétés plutôt typiques sur le fichier. La source fait référence à un emplacement du serveur de fichiers Salt (notre fichier actuel se trouve également dans cette structure). Nous allons créer ce chemin et archiver momentanément:

/srv/salt/nginx/init.sls

nginx:
 pkg:
   - installed
 service.running:
   - watch:
     - pkg: nginx
     - file: /etc/nginx/nginx.conf
     - file: /etc/nginx/sites-available/default

Nous souhaitons également contrôler le contenu du fichier + / etc / nginx / sites-available / default +. Ceci définit le bloc serveur qui contrôle la manière dont notre contenu sera servi. Le bloc d’état est assez similaire au dernier. La principale différence est que ce fichier sera un modèle Jinja.

Les modèles Jinja permettent à Salt de personnaliser une partie du contenu du fichier avec des détails spécifiques à chacun des minions où il sera placé. Cela signifie que nous pouvons extraire des informations de chaque hôte et construire une version personnalisée et adaptée du fichier pour chacun de nos serveurs Web. Nous indiquons que ce fichier utilisera Jinja avec l’option + template +. Nous allons également utiliser le suffixe + .jinja + sur le fichier source afin de pouvoir dire immédiatement que ce fichier est un modèle:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/nginx.conf:
 file.managed:
   - source: salt://nginx/files/etc/nginx/nginx.conf
   - user: root
   - group: root
   - mode: 640

Notre fichier de bloc de serveur par défaut est censé être placé dans le répertoire + sites-available sur les hôtes minion. Cependant, nous devons toujours lier le fichier au répertoire + sites-enabled + pour l’activer. Nous pouvons le faire avec la fonction + file.symlink +. Nous avons juste besoin de fournir l’emplacement du fichier d’origine en tant que + cible. Nous devons également «exiger» ce fichier pour que cet état ne soit exécuté qu’une fois l’état précédent terminé:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-available/default:
 file.managed:
   - source: salt://nginx/files/etc/nginx/sites-available/default.jinja
   - template: jinja
   - user: root
   - group: root
   - mode: 640

L’état du contenu de notre site par défaut

Nous avons écrit nos états d’installation et de configuration Nginx. Maintenant, nous avons juste besoin de créer un état pour notre fichier + index.html qui sera le contenu réel de notre site.

Cet état utilise exactement le même format que notre précédent modèle. Les seules différences sont l’identifiant, la source et le mode de permission sur ce fichier:

/srv/salt/nginx/init.sls

. . .

/etc/nginx/sites-enabled/default:
 file.symlink:
   - target: /etc/nginx/sites-available/default
   - require:
     - file: /etc/nginx/sites-available/default

Lorsque vous avez terminé, enregistrez et fermez ce fichier. Nous en avons terminé avec les informations d’état Nginx pour le moment.

Installer Nginx et transférer les fichiers d’origine sur Salt Master

Nous avons créé notre fichier d’état principal Nginx Salt. Cependant, certains des états dans lesquels nous avons créé font référence sur le serveur de fichiers de Salt Master à des fichiers qui n’existent pas encore.

Puisque nos fichiers seront en grande partie identiques aux fichiers par défaut installés par le paquet Nginx d’Ubuntu, le moyen le plus simple de commencer consiste à utiliser les fichiers de ce paquet. Les serveurs Web de l’un de nos environnements constituent un emplacement idéal pour installer Nginx afin que nous puissions récupérer les fichiers nécessaires.

Si vous ne possédez pas déjà un de vos environnements filées, sélectionnez l’un de vos fichiers de carte de l’environnement à déployer. Nous allons utiliser l’environnement «stage» de cette série car c’est le plus petit environnement qui regroupe tous les types de serveurs dont nous aurons besoin.

sudo salt-cloud -P -m /etc/salt/cloud.maps.d/stage-environment.map

Une fois vos serveurs opérationnels, choisissez l’un de vos serveurs Web sur lequel vous souhaitez installer Nginx. Nous allons juste utiliser le module d’exécution + pkg + pour l’instant, car nos états ne sont pas encore complètement fonctionnels:

sudo salt stage-www1 pkg.install nginx

Lors de la configuration de notre configuration maître Salt, nous avons activé l’option + file_recv +. Cela nous permet de demander aux serviteurs de transmettre certains fichiers au maître. Nous pouvons utiliser ceci pour récupérer les versions par défaut des fichiers que nous allons gérer:

sudo salt stage-www1 cp.push /etc/nginx/nginx.conf
sudo salt stage-www1 cp.push /etc/nginx/sites-available/default
sudo salt stage-www1 cp.push /usr/share/nginx/html/index.html

Ces fichiers devraient maintenant être disponibles sur le maître. Le chemin d’accès à ces fichiers est créé dans le répertoire + / var / cache / salt / master / minion // des fichiers dans. Dans notre cas, l’ID de séide serait + stage-www1 +. Nous pouvons copier les répertoires situés sous cet emplacement, qui représente les chemins de fichiers du séide, dans notre répertoire d’état Salt en tapant:

sudo cp -r /var/cache/salt/master/minions/stage-www1/files /srv/salt/nginx

Si vous examinez le contenu de votre répertoire state, vous verrez un nouveau répertoire appelé «fichiers». Sous ce répertoire, les répertoires pertinents du système de fichiers du séide et les trois fichiers que nous avons copiés sont disponibles:

find /srv/salt/nginx -printf "%P\n"
Outputfiles
files/usr
files/usr/share
files/usr/share/nginx
files/usr/share/nginx/html
files/usr/share/nginx/html/index.html
files/etc
files/etc/nginx
files/etc/nginx/sites-available
files/etc/nginx/sites-available/default
files/etc/nginx/nginx.conf
init.sls

C’est ici que tous nos fichiers gérés seront conservés. Cela correspond à l’emplacement «source» que nous avons défini dans notre fichier d’état Nginx.

Puisque nous avons maintenant tous les fichiers dont nous avons besoin extraits du séide où Nginx a été installé, nous pouvons le détruire et le reconstruire. Cela garantira que nos fichiers d’état pourront être testés ultérieurement sur un serveur vierge. Détruisez le sbire Nginx:

sudo salt-cloud -d stage-www1

Après avoir attendu le traitement de l’événement, nous pouvons reconstruire le séide.

Nous utilisons généralement le fichier map pour cela, mais comme nous ne reconstruisons qu’un seul serveur, il est préférable d’utiliser directement le profil stage + web +. Nous pouvons ensuite utiliser la fonction d’exécution + cloud.profile + Salt au lieu de + salt-cloud +, ce qui nous permet d’ajouter l’indicateur + - async +. En gros, cela nous permet de reconstruire notre serveur + stage-www1 + en arrière-plan pendant que nous continuons à travailler. Nous devrons cibler notre maître Salt dans cette commande puisqu’il s’agit du serveur avec les profils de cloud dont nous avons besoin:

sudo salt --async  cloud.profile stage-web stage-www1

Pendant que notre noeud + stage-www1 + est en train de reconstruire en arrière-plan, nous pouvons continuer.

Configurez le fichier /etc/nginx/nginx.conf

Examinons d’abord le fichier de configuration principal de Nginx, qui sera placé dans le dossier + / etc / nginx / nginx.conf + sur nos sbires. Nous pouvons trouver ce chemin sous le répertoire + files in sans le répertoire d’état Nginx:

cd /srv/salt/nginx/files/etc/nginx

En fait, nous n’allons pas modifier ce fichier pour le moment, mais nous pouvons nous rendre service et sauvegarder l’original maintenant:

sudo cp nginx.conf nginx.conf.orig

Cela nous donnera un bon point de référence pour les personnalisations que nous pourrions effectuer à l’avenir. Nous pouvons rapidement voir les modifications que nous avons apportées en tapant:

diff nginx.conf nginx.conf.orig

Si, à l’avenir, nous devions personnaliser la configuration de Nginx dans nos divers environnements (par exemple, nous pourrions vouloir faire correspondre le worker_processus + au nombre de processeurs sur nos serveurs de production), nous pourrions vouloir passer à en utilisant un fichier modèle. Nous n’avons pas besoin de cela pour le moment, donc, en tant que fichier non-template, nos modifications seront codées en dur.

Comme nous l’avons dit plus tôt, nous n’avons pas besoin de modifications pour le moment. Allons-nous en.

Configurez le modèle / etc / nginx / sites-available / default

Voyons maintenant notre modèle de bloc de serveur par défaut. Nous pouvons trouver l’original dans ce répertoire:

cd /srv/salt/nginx/files/etc/nginx/sites-available

Encore une fois, nous devrions copier l’original dans un emplacement de sauvegarde au cas où nous en aurions besoin plus tard:

sudo cp default default.orig

Nous pouvons alors renommer le fichier pour qu’il ait une extension + .jinja +. Cela nous rappellera visuellement que ce fichier est un modèle et non un fichier utilisable:

sudo mv default default.jinja

Maintenant, nous pouvons ouvrir le fichier modèle pour apporter quelques modifications:

sudo nano default.jinja

Tout en haut du fichier, nous devons commencer à utiliser les fonctionnalités de création de modèles de Jinja. Notre bloc de serveur par défaut doit rendre différents fichiers selon que le serveur Web se trouve ou non derrière un équilibreur de charge.

Lorsque les connexions sont reçues via un équilibreur de charge, nous voulons que notre serveur Web limite son trafic à l’interface privée. Cependant, lorsque nous sommes dans l’environnement de développement, nous n’avons pas d’équilibreur de charge. Nous souhaitons donc servir via l’interface publique. Nous pouvons créer cette distinction avec Jinja.

Nous allons créer une variable appelée + interface + qui devrait contenir l’interface dont nous voulons l’adresse. Nous allons tester si l’environnement du séide est défini sur «dev», auquel cas nous utiliserons l’interface + eth0 +. Sinon, nous le placerons sur + eth1 +, l’interface privée du serveur. Nous utiliserons ensuite la fonction de module d’exécution + grains.get + pour saisir l’adresse associée à l’interface sélectionnée et l’utiliser comme valeur pour la variable + addr +. Nous allons ajouter ceci tout en haut du fichier:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}
# You may add here your
# server {
#       ...
# }

. . .

Ensuite, nous pouvons éditer le serveur + server bloqué plus bas dans le fichier. Nous pouvons utiliser la variable + addr + définie en haut dans les directives + listen + et + nom_serveur +. Nous avons supprimé les parties serveur IPv6 et serveur par défaut pour restreindre l’utilisation de ce bloc:

/srv/salt/nginx/files/etc/nginx/sites-available/default.jinja

{%- set interface = 'eth0' if salt['grains.get']('env') == 'dev' else 'eth1' -%}
{%- set addr = salt['network.interface_ip'](interface) -%}

. . .

server {
   listen :80;

   root /usr/share/nginx/html;
   index index.html index.htm;

   server_name ;

   location / {
       try_files $uri $uri/ =404;
   }
}

Enregistrez et fermez le fichier lorsque vous avez terminé.

Configurez le modèle /usr/share/nginx/html/index.html

Nous pouvons maintenant passer au fichier + index.html. Déplacez-vous sur le répertoire sur le maître de sel qui contient le fichier:

cd /srv/salt/nginx/files/usr/share/nginx/html

À l’intérieur, nous devrons commencer par la même procédure que celle que nous avons utilisée la dernière fois. Nous devrions stocker une copie du fichier d’origine à des fins d’audit et de sauvegarde. Nous devrions ensuite renommer le fichier pour indiquer qu’il s’agira d’un modèle:

sudo cp index.html index.html.orig
sudo mv index.html index.html.jinja

Ouvrez le fichier modèle afin que nous puissions apporter les modifications nécessaires:

sudo nano index.html.jinja

En haut, nous allons définir une autre variable en utilisant Jinja. Nous allons utiliser la fonction de module d’exécution + grains.get + pour récupérer le nom d’hôte du séide. Nous allons le stocker dans la variable + host +:

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>

. . .

Nous utiliserons ensuite cette valeur tout au long du fichier afin de pouvoir facilement identifier le serveur Web qui répond à nos demandes. Changez d’abord la valeur + <title> +:

{% set host = salt['grains.get']('host') -%}
<!DOCTYPE html>
<html>
<head>
<title>Welcome </title>
. . .

Changeons le corps du texte en ceci:

. . .

<body>
<h1>Welcome to nginx!</h1>




</body>
</html>

Enregistrez et fermez le fichier lorsque vous avez terminé.

Test du fichier d’état Nginx

Nous avons maintenant terminé notre configuration Nginx. Nous pouvons tester certains aspects de l’état afin de nous assurer qu’il fonctionne correctement.

Premièrement, nous pouvons utiliser la fonction de module d’exécution + state.show_sls + pour voir comment Salt interprétera notre fichier d’état Nginx. Nous pouvons utiliser notre serveur + stage-www1 + comme cible. Cependant, rien ne s’exécutera sur le serveur à ce stade:

sudo salt stage-www1 state.show_sls nginx

Vous devriez obtenir une sortie qui ressemble à ceci:

Outputstage-www1:
   ----------
   /etc/nginx/nginx.conf:
       ----------
       __env__:
           base
       __sls__:
           nginx
       file:
           |_
             ----------
             source:
                 salt://nginx/files/etc/nginx/nginx.conf
           |_
             ----------
             user:
                 root
           |_
             ----------
             group:
                 root
           |_
             ----------
             mode:
                 640
           - managed
           |_
             ----------
             order:
                 10002

. . .

Il restitue principalement les informations de notre fichier + / srv / salt / nginx / init.sls + avec quelques ajouts intéressants. Vérifiez qu’il n’y a pas d’erreur d’interprétation où Salt ne sait pas lire les commandes. La «commande» de chaque pièce est un autre bon point à vérifier. Cela détermine le moment où chacun des états du fichier sera exécuté. Le premier état aura le numéro d’ordre «10000». Chaque état supplémentaire comptera à partir de là. Notez que le + env + est différent du + env + que nous avons défini en utilisant des grains. Nous n’utilisons pas la conception des environnements de Salt dans ce guide.

Ensuite, nous pouvons faire un essai d’application de notre fichier d’état. Nous pouvons faire cela avec la fonction ` state.apply + `avec l’option + test = True + `. La commande ressemble à ceci:

sudo salt stage-www1 state.apply nginx test=True

Cela vous montrera les modifications qui seront apportées si l’option + test = True + est supprimée. Jetez un coup d’œil pour vous assurer que les modifications ont un sens et que Salt est capable d’interpréter correctement tous vos fichiers. Le champ «Commentaire» est particulièrement important car il peut révéler des problèmes même dans les cas où Salt n’a pas marqué l’état d’échec.

Si le test n’a révélé aucun problème, vous pouvez essayer d’appliquer l’état à tous vos serveurs Web disponibles en tapant:

sudo salt -G 'role:webserver' state.apply nginx

Si vous avez appliqué l’état Nginx à vos serveurs Web de transfert ou de production, vous souhaiterez obtenir leurs adresses IP internes. Les pages ne seront pas disponibles sur l’interface publique:

sudo salt-call mine.get 'role:webserver' internal_ip expr_form=grain
Outputlocal:
   ----------
   stage-www1:

   stage-www2:

Si, par contre, vous avez démarré votre serveur Web de développement et appliqué l’état Nginx, vous souhaiterez récupérer l’adresse externe car:

sudo salt-call mine.get 'role:webserver' external_ip expr_form=grain

Vous pouvez tester vos serveurs en utilisant + curl:

curl

Vous devriez voir la page + index.html que nous avons modifiée:

Output<!DOCTYPE html>
<html>
<head>
<title>Welcome from </title>
<style>
   body {
       width: 35em;
       margin: 0 auto;
       font-family: Tahoma, Verdana, Arial, sans-serif;
   }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>Hello!  This is being served from:</p>

<h2></h2>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Comme vous pouvez le constater, le nom d’hôte du sbire a été placé dans le fichier lors du rendu de la Jinja. Notre état Nginx est maintenant terminé.

Conclusion

Vous devriez maintenant avoir un état Nginx entièrement fonctionnel. Cela vous permettra de transformer rapidement et facilement toute machine contrôlée par Salt en un serveur Web répondant à vos spécifications. Nous allons utiliser cela dans le cadre de notre stratégie de gestion d’infrastructure plus large pour construire facilement les serveurs Web dans nos environnements.

Dans le next guide, nous allons progresser et créer l’état des équilibreurs de charge. cela dirigera le trafic devant nos serveurs Web. Nous allons utiliser certaines des techniques utilisées dans ce guide pour rendre nos équilibreurs de charge flexibles.

Related