TOC

Comment utiliser les fichiers de carte Salt Cloud pour déployer des serveurs d’applications et un proxy inverse Nginx

introduction

Votre application est écrite et vous devez maintenant la déployer. Vous pouvez créer un environnement de production et configurer votre application sur une machine virtuelle, mais comment la redimensionner lorsqu’elle devient populaire? Comment déployez-vous de nouvelles versions? Qu’en est-il de l’équilibrage de charge? Et surtout, comment pouvez-vous être certain que la configuration est correcte? Nous pouvons automatiser tout cela pour gagner beaucoup de temps.

Dans ce didacticiel, nous allons vous montrer comment définir votre application dans un fichier de carte Salt Cloud, notamment en utilisant des grains de sel personnalisés pour attribuer des rôles à vos serveurs et pour configurer de manière dynamique un proxy inverse.

À la fin de ce didacticiel, vous aurez deux serveurs d’applications de base, un proxy inverse Nginx avec une configuration construite de manière dynamique et la possibilité de redimensionner votre application en quelques minutes.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

  • Une gouttelette CentOS 7 de 1 Go. Toutes les commandes de ce didacticiel seront exécutées en tant que root. Vous n’avez donc pas besoin de créer un utilisateur sudo non root.

  • Une clé SSH sur le droplet pour l’utilisateur * root * (c’est-à-dire une nouvelle paire de clés créée sur le Droplet). Ajoutez cette clé SSH dans le panneau de configuration de DigitalOcean pour pouvoir vous connecter à d’autres droplets DigitalOcean à partir du droplet maître. Vous pouvez utiliser le tutoriel Comment utiliser les clés SSH avec des gouttelettes DigitalOcean pour obtenir des instructions. + Notez le nom que vous avez attribué à la clé dans le panneau de commande de DigitalOcean. Dans ce tutoriel, nous utilisons le nom. Vous devez également noter l’emplacement de la clé privée. par défaut, c’est + / root / .ssh / id_rsa +.

  • Un jeton d’accès personnel, que vous pouvez créer en suivant les instructions de cette étape à l’adresse https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate -a-personal-access-token [Comment utiliser l’API v2 de DigitalOcean]. Assurez-vous de définir la portée pour lire et écrire.

Étape 1 - Installation de Salt and Salt Cloud

Pour commencer, Salt Cloud doit être installé et configuré sur votre serveur. Pour ce tutoriel, nous allons simplement utiliser le script Salt Bootstrap.

Commencez par graver le script bootstrap de Salt pour installer Salt.

wget -O install_salt.sh https://bootstrap.saltstack.com

Exécutez le script d’amorçage Salt. Nous utilisons l’indicateur + -M + pour installer également + salt-master +.

sh install_salt.sh -M

Bien que la base de code de Salt Cloud ait été fusionnée dans le projet principal de Salt, elle est toujours emballée séparément pour CentOS. Heureusement, le script + install_salt + a configuré le dépôt pour nous, nous pouvons donc simplement installer + salt-cloud + avec yum:

yum install salt-cloud

Nous pouvons maintenant vérifier la version de Salt Cloud pour confirmer la réussite de l’installation:

salt-cloud --version

Vous devriez voir la sortie comme ceci:

nuage de sel –version de sortie

salt-cloud 2015.5.3 (Lithium)

Notez que Salt est sur un cycle de lancement glissant, votre version peut donc différer légèrement de la version précédente.

Étape 2 - Configuration de Salt Cloud

Dans cette section, nous allons configurer Salt Cloud pour qu’il se connecte à DigitalOcean et définisse certains profils pour nos droplets.

Configuration du fichier de fournisseur DigitalOcean

Dans Salt Cloud, fournisseurs de fichiers vous permettent de définir l’emplacement de création des nouvelles machines virtuelles. Les fournisseurs sont définis dans le répertoire + / etc / salt / cloud.providers.d +

Créez et ouvrez un fichier de fournisseur DigitalOcean en utilisant + nano + ou votre éditeur de texte préféré.

nano /etc/salt/cloud.providers.d/digital_ocean.conf

Insérez le texte ci-dessous en remplaçant les variables par les vôtres, à savoir l’IP du serveur et le jeton d’accès, ainsi que le nom et le fichier de la clé SSH, si vous les avez personnalisés.

/etc/salt/cloud.providers.d/digital_ocean.conf

### /etc/salt/cloud.providers.d/digital_ocean.conf ###
######################################################
do:
 provider: digital_ocean
 minion:
   master:

 # DigitalOcean Access Token
 personal_access_token:

 # This is the name of your SSH key in your Digital Ocean account
 # as it appears in the control panel.
 ssh_key_name:

 # This is the path on disk to the private key for your Digital Ocean account
 ssh_key_file:

Vous devez verrouiller les autorisations sur votre fichier de clé SSH. Sinon, SSH refusera de l’utiliser. En supposant que votre emplacement se trouve à l’emplacement par défaut, + / root / .ssh / id_rsa +, vous pouvez le faire avec:

chmod 600 /root/.ssh/id_rsa

Configuration des profils pour les serveurs déployables

Dans Salt Cloud, profiles sont des descriptions individuelles de machines virtuelles liées à un fournisseur (par exemple, “Une machine virtuelle Ubuntu de 512 Mo sur DigitalOcean”). Ceux-ci sont définis dans le répertoire + / etc / salt / cloud.profiles.d +.

Créez et ouvrez un fichier de profil.

nano /etc/salt/cloud.profiles.d/digital_ocean.conf

Collez le texte suivant dans le fichier. Aucune modification n’est nécessaire:

/etc/salt/cloud.profiles.d/digital_ocean.conf

### /etc/salt/cloud.profiles.d/digital_ocean.conf ###
#####################################################

ubuntu_512MB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 512MB
 location: nyc3
 private_networking: True

ubuntu_1GB_ny3:
 provider: do
 image: ubuntu-14-04-x64
 size: 1GB
 location: nyc3
 private_networking: True

Enregistrez et fermez le fichier. Ce fichier définit deux profils:

  • Une machine virtuelle Ubuntu 14.04 avec 512 Mo de mémoire, déployée dans la région 3 de New York.

  • Une machine virtuelle Ubuntu 14.04 avec 1 Go de mémoire, déployée dans la région 3 de New York.

Si vous souhaitez utiliser une image autre que Ubuntu 14.04, vous pouvez utiliser Salt Cloud pour répertorier tous les noms d’images disponibles sur DigitalOcean à l’aide de la commande suivante:

salt-cloud --list-images do

Cela affichera toutes les images DigitalOcean standard, ainsi que les images personnalisées que vous avez enregistrées sur votre compte avec l’outil de capture instantanée. Vous pouvez remplacer le nom d’image ou la région que nous avons utilisés dans le fichier de fournisseur par un nom d’image différent de cette liste. Si vous le faites, veillez à utiliser le champ de cette sortie dans les paramètres du fichier de profil.

Testez votre configuration avec une requête rapide.

salt-cloud -Q

Vous devriez voir quelque chose comme ce qui suit.

Exemple de sortie de nuage de sel -Q

[INFO    ] salt-cloud starting
do:
   ----------
   digital_ocean:
       ----------
       centos-salt:
           ----------
           id:
               2806501
           image_id:
               6372108
           public_ips:
               192.241.247.229
           size_id:
               63
           state:
               active

Cela signifie que Salt Cloud communique avec votre compte DigitalOcean et que deux profils de base sont configurés.

Troisième étape - Écrire un fichier de carte simple

Un fichier de carte est un fichier YAML qui répertorie les profils et le nombre de serveurs que vous souhaitez créer. Nous commencerons par un simple fichier de carte, puis nous en construirons dans la section suivante.

En utilisant les profils ci-dessus, supposons que vous souhaitiez deux serveurs d’applications de 1 Go, dirigés par un seul proxy inverse de 512 Mo. Nous allons créer un fichier de carte nommé + / etc / salt / cloud.maps.d / do-app-with-rproxy.map + et définir l’application.

Tout d’abord, créez le fichier:

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Insérer le texte suivant. Aucune modification n’est nécessaire:

/etc/salt/cloud.maps.d/do-app-with-rproxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ####
######################################################
ubuntu_512MB_ny3:
 - nginx-rproxy

ubuntu_1GB_ny3:
 - appserver-01
 - appserver-02

C’est ça! C’est à peu près aussi simple qu’un fichier de carte. Allez-y et déployez ces serveurs avec:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Une fois la commande terminée, confirmez le succès avec un ping rapide:

salt '*' test.ping

Vous devriez voir ce qui suit:

[label salt '*' test.ping
appserver-01:
   True
appserver-02:
   True
nginx-rproxy:
   True

Une fois que vous avez créé les ordinateurs virtuels dans votre fichier de carte, leur suppression est aussi simple:

salt-cloud -d -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Veillez cependant à utiliser cette commande avec prudence! Il supprimera all les machines virtuelles spécifiées dans ce fichier de carte.

Quatrième étape - Écrire un fichier de carte plus réaliste

Ce fichier de carte a bien fonctionné, mais même un script shell peut créer un ensemble de machines virtuelles. Ce dont nous avons besoin, c’est de définir l’empreinte de notre application. Revenons à notre fichier de carte et ajoutons quelques éléments supplémentaires. ouvrez le fichier de carte à nouveau.

nano /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Supprimez le contenu précédent du fichier et placez-le ci-dessous. Aucune modification n’est nécessaire:

/etc/salt/cloud.maps.d/do-app-with-rproxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
 - appserver-01:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver
 - appserver-02:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: appserver

Maintenant, nous allons quelque part! Cela semble beaucoup, mais nous n’avons ajouté que deux choses. Examinons les deux ajouts: la section + mine_functions + et la section + grains +.

Nous avons demandé à Salt Cloud de modifier la configuration de Salt Minion pour ces machines virtuelles et d’ajouter des grains personnalisés. Plus précisément, les grains attribuent le rôle + rproxy + à la machine virtuelle de proxy inverse, ainsi que le rôle + appserver + aux serveurs d’applications. Cela sera utile lorsque nous aurons besoin de configurer dynamiquement le proxy inverse.

Le + mine_functions + sera également ajouté à la configuration de Salt Minion. Il demande au Minion d’envoyer l’adresse IP trouvée sur * eth0 * au Salt Master afin qu’elle soit stockée dans le fichier Salt mine. Cela signifie que Salt Master connaîtra automatiquement l’adresse IP du nouveau droplet créé sans que nous ayons à le configurer. Nous allons utiliser cela dans la prochaine partie.

Cinquième étape - Définition du proxy inverse

Nous avons maintenant devant nous une tâche commune: installer le serveur Web de proxy inverse et le configurer. Pour ce tutoriel, nous utiliserons Nginx en tant que proxy inverse.

Écrire l’état de sel de Nginx

Il est temps de nous salir les mains et d’écrire quelques états de sel. Commencez par définir l’emplacement par défaut de l’arbre d’état Salt:

mkdir /srv/salt

Naviguez dans ce répertoire et créez un autre répertoire uniquement pour nginx:

cd /srv/salt
mkdir /srv/salt/nginx

Allez dans ce répertoire et, en utilisant votre éditeur favori, créez un nouveau fichier nommé + rproxy.sls +:

cd /srv/salt/nginx
nano /srv/salt/nginx/rproxy.sls

Placez ce qui suit dans ce fichier. Aucune modification n’est nécessaire:

/srv/salt/nginx/rproxy.sls

### /srv/salt/nginx/rproxy.sls ###
##################################

### Install Nginx and configure it as a reverse proxy, pulling the IPs of
### the app servers from the Salt Mine.

nginx-rproxy:
 # Install Nginx
 pkg:
   - installed
   - name: nginx
 # Place a customized Nginx config file
 file:
   - managed
   - source: salt://nginx/files/awesome-app.conf.jin
   - name: /etc/nginx/conf.d/awesome-app.conf
   - template: jinja
   - require:
     - pkg: nginx-rproxy
 # Ensure Nginx is always running.
 # Restart Nginx if the config file changes.
 service:
   - running
   - enable: True
   - name: nginx
   - require:
     - pkg: nginx-rproxy
   - watch:
     - file: nginx-rproxy
 # Restart Nginx for the initial installation.
 cmd:
   - run
   - name: service nginx restart
   - require:
     - file: nginx-rproxy

Cet état fait ce qui suit:

  • Installe Nginx.

  • Place notre fichier de configuration personnalisé dans + / etc / nginx / conf.d / awesome-app.conf +.

  • Assure que Nginx est en cours d’exécution.

Notre état Salt installe simplement Nginx et supprime un fichier de configuration; le contenu vraiment intéressant est dans la config.

Écriture du fichier de configuration du proxy inverse Nginx

Faisons un autre répertoire pour notre fichier de configuration:

mkdir /srv/salt/nginx/files
cd /srv/salt/nginx/files

Et ouvrez le fichier de configuration:

nano /srv/salt/nginx/files/awesome-app.conf.jin

Mettez ce qui suit dans le fichier de configuration. Aucune modification n’est nécessaire, à moins que vous n’utilisiez * pas * le réseau privé; dans ce cas, modifiez le «+ 1 » en « 0 +» comme indiqué en ligne:

/srv/salt/nginx/files/awesome-app.conf.jin

### /srv/salt/nginx/files/awesome-app.conf.jin ###
##################################################

### Configuration file for Nginx to act as a
### reverse proxy for an app farm.

# Define the app servers that we're in front of.
upstream awesome-app {
   {% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}
   server {{ addrs[0] }}:1337;
   {% endfor %}
}

# Forward all port 80 http traffic to our app farm, defined above as 'awesome-app'.
server {
   listen       80;
   server_name  {{ salt['network.ip_addrs']()[] }};  #
                                                      #     DigitalOcean's private networking.

   access_log  /var/log/nginx/awesome-app.access.log;
   error_log  /var/log/nginx/awesome-app.error.log;

   ## forward request to awesome-app ##
   location / {
    proxy_pass  http://awesome-app;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Nous utilisons l’extension + .jin + pour nous dire que le fichier contient Jinja templating. Les modèles Jinja nous permettent de mettre une petite quantité de logique dans nos fichiers texte afin de générer dynamiquement les détails de la configuration.

Ce fichier de configuration indique à Nginx de prendre tout le trafic HTTP du port 80 et de le transférer à notre batterie d’applications. Il comporte deux parties: une amont (notre batterie d’applications) et la configuration permettant d’agir en tant que proxy entre l’utilisateur et notre batterie d’applications.

Parlons de l’amont. Un flux amont normal, sans modèle, spécifie une collection d’adresses IP. Cependant, nous ne savons pas quelles seront les adresses IP de nos sbires tant qu’elles n’existeront pas, et nous ne modifierons pas les fichiers de configuration manuellement. (Sinon, il n’y aurait aucune raison d’utiliser Salt!)

Vous vous souvenez des lignes + mine_function + dans notre fichier map? Les sbires donnent leurs adresses IP au Salt Master pour les stocker pour une telle occasion. Regardons la ligne Jinja un peu plus près:

Extrait de Jinja

{% for server, addrs in salt['mine.get']('roles:appserver', 'network.ip_addrs', expr_form='grain').items() %}

Ceci est une boucle for dans Jinja, exécutant une fonction Salt arbitraire. Dans ce cas, il exécute http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.mine.html#salt.modules.mine.get [+ mine.get +]. Les paramètres sont:

  • + roles: appserver + - Cela signifie de n’obtenir que les détails des minions qui ont le rôle "appserver".

  • + network.ip_addrs + - Ce sont les données que nous voulons sortir de la mine. Nous l’avons également spécifié dans notre fichier de carte.

  • + expr_form = 'grain' + - Ceci indique à Salt que nous ciblons nos sbires en fonction de leurs grains. Pour plus d’informations sur l’appariement par grain, consultez doc de la documentation sur le ciblage Saltstack.

Suite à cette boucle, la variable + {{addrs}} + contient une liste d’adresses IP (même s’il ne s’agit que d’une adresse). Comme il s’agit d’une liste, nous devons récupérer le premier élément avec + [0] +.

C’est en amont. Quant au nom du serveur:

server_name  {{ salt['network.ip_addrs']()[0] }};

C’est le même truc que l’appel de la mine de sel (appelez une fonction de sel dans Jinja). C’est plus simple. Il appelle http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#salt.modules.network.ip_addrs [+ network.ip_addrs +] et prend le premier élément. de la liste retournée. Cela nous évite également de devoir modifier manuellement notre fichier.

Sixième étape - Définir la ferme d’applications

Un proxy inverse ne veut pas dire grand-chose s’il n’ya pas d’application derrière. Faisons une petite application Node.js qui ne rapporte que l’adresse IP du serveur sur lequel il se trouve (pour que nous puissions confirmer que nous atteignons les deux ordinateurs).

Créez un nouveau répertoire nommé + awesome-app + et déplacez-vous là.

mkdir -p /srv/salt/awesome-app
cd /srv/salt/awesome-app

Créez un nouveau fichier d’état d’application appelé + app.sls +.

nano /srv/salt/awesome-app/app.sls

Placez ce qui suit dans le fichier. Aucune modification n’est nécessaire:

/srv/salt/awesome-app/app.sls

### /srv/salt/awesome-app/app.sls ###
#####################################

### Install Nodejs and start a simple
### web application that reports the server IP.

install-app:
 # Install prerequisites
 pkg:
   - installed
   - names:
     - node
     - npm
     - nodejs-legacy  # workaround for Debian systems
 # Place our Node code
 file:
   - managed
   - source: salt://awesome-app/files/app.js
   - name: /root/app.js
 # Install the package called 'forever'
 cmd:
   - run
   - name: npm install forever -g
   - require:
     - pkg: install-app

run-app:
 # Use 'forever' to start the server
 cmd:
   - run
   - name: forever start app.js
   - cwd: /root

Ce fichier d’état effectue les opérations suivantes:

  • Installez les packages + nodejs,` + npm` et + nodejs-legacy.

  • Ajoute le fichier JavaScript qui sera notre application simple.

  • Utilise NPM pour installer https://www.npmjs.org/package/forever [+ Forever +].

  • Lance l’application.

Maintenant, créez le (petit) code d’application:

mkdir /srv/salt/awesome-app/files
cd /srv/salt/awesome-app/files

Créez le fichier:

nano /srv/salt/awesome-app/files/app.js

Placez ce qui suit dedans. Aucune modification n’est nécessaire:

/srv/salt/awesome-app/files/app.js

/* /srv/salt/awesome-app/files/app.js

  A simple Node.js web application that
  reports the server's IP.
  Shamefully stolen from StackOverflow:
  http://stackoverflow.com/questions/10750303/how-can-i-get-the-local-ip-address-in-node-js
*/

var os = require('os');
var http = require('http');

http.createServer(function (req, res) {
 var interfaces = os.networkInterfaces();
 var addresses = [];
 for (k in interfaces) {
     for (k2 in interfaces[k]) {
         var address = interfaces[k][k2];
         if (address.family == 'IPv4' && !address.internal) {
             addresses.push(address.address)
         }
     }
 }

 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end(JSON.stringify(addresses));
}).listen(1337, '0.0.0.0');
console.log('Server listening on port 1337');

C’est un simple serveur Node.js qui fait une chose: accepter les requêtes HTTP sur le port 1337 et répondre avec les adresses IP du serveur.

À ce stade, vous devriez avoir une structure de fichier qui ressemble à ceci:

Structure de fichier

/srv/salt
        ├── awesome-app
        │   ├── app.sls
        │   └── files
        │       └── app.js
        └── nginx
            ├── rproxy.sls
            └── files
                └── awesome-app.conf.jin

Étape 7 - Déploiement de l’application

Il ne reste plus qu’à déployer l’application.

Déployer les serveurs avec Salt Cloud

Exécutez la même commande de déploiement que précédemment, qui utilisera désormais toutes les configurations que nous avons définies.

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map

Attendez que Salt Cloud soit terminé; cela va prendre du temps. Une fois qu’il est renvoyé, confirmez le déploiement réussi en envoyant une requête ping aux serveurs d’applications:

salt -G 'roles:appserver' test.ping

Tu devrais voir:

Sortie ping du serveur d’applications

appserver-02:
   True
appserver-01:
   True

Envoyez une requête ping au proxy inverse:

salt -G 'roles:rproxy' test.ping

Tu devrais voir:

Sortie ping proxy inverse

nginx-rproxy:
   True

Une fois que vous avez vos machines virtuelles, il est temps de leur donner du travail.

Construire l’application

Ensuite, lancez les commandes Salt pour générer automatiquement la batterie d’applications et le proxy inverse.

Construisez la ferme d’applications:

salt -G 'roles:appserver' state.sls awesome-app.app

Il y aura une bonne quantité de sortie, mais cela devrait se terminer comme suit:

Summary
------------
Succeeded: 6 (changed=6)
Failed:    0
------------
Total states run:     6

Construisez le proxy inverse:

salt -G 'roles:rproxy' state.sls nginx.rproxy

Encore une fois, il y aura une bonne quantité de production, se terminant par ce qui suit:

Summary
------------
Succeeded: 4 (changed=4)
Failed:    0
------------
Total states run:     4

Alors qu’est-ce qui vient de se passer ici?

La première commande (celle avec les serveurs d’applications) prend l’état Salt que nous avons écrit précédemment et l’exécute sur les deux serveurs d’applications. Cela a abouti à deux machines avec des configurations identiques exécutant des versions de code identiques.

La deuxième commande (le proxy inverse) a exécuté l’état Salt que nous avons écrit pour Nginx. Il a installé Nginx et le fichier de configuration, en renseignant de manière dynamique les adresses IP de notre ferme d’applications dans le fichier de configuration.

Une fois que Salt est terminé, vous pouvez tester pour confirmer le déploiement réussi. Trouvez l’adresse IP de votre proxy inverse:

salt -G 'roles:rproxy' network.ip_addrs

Vous pouvez récupérer deux adresses IP si vous utilisez un réseau privé sur votre Droplet.

Branchez l’adresse IP publique sur votre navigateur et visitez la page Web! Cliquez sur Actualiser à quelques reprises pour confirmer que Nginx est actuellement le serveur proxy entre les deux serveurs d’applications que vous avez créés. Vous devriez voir les adresses IP changer, ce qui confirme que vous vous connectez effectivement à plusieurs serveurs d’applications.

Si vous obtenez la même adresse IP malgré le rafraîchissement, cela est probablement dû à la mise en cache du navigateur. Vous pouvez essayer d’utiliser + curl + à la place pour montrer que Nginx est mandataire parmi vos serveurs d’applications. Exécutez cette commande plusieurs fois et observez le résultat:

curl http://

Nous pouvons aller plus loin et automatiser complètement le déploiement de l’application via OverState. Cela nous permettrait de créer une seule commande pour indiquer à Salt de créer, par exemple, les serveurs d’applications avant de créer le proxy inverse, garantissant ainsi l’ordre de notre processus de construction.

Étape huit - Mise à l’échelle (facultatif)

Le but de Salt est d’automatiser votre processus de construction; Salt Cloud et les fichiers de cartes ont pour objectif de facilement faire évoluer votre déploiement. Si vous souhaitez ajouter plusieurs serveurs d’applications (par exemple deux autres) à votre déploiement, vous devez mettre à jour votre fichier de carte pour lui donner l’aspect suivant:

/etc/salt/cloud.maps.d/do-app-with-rproxy.map

### /etc/salt/cloud.maps.d/do-app-with-rproxy.map ###
#####################################################
ubuntu_512MB_ny3:
 - nginx-rproxy:
     minion:
       mine_functions:
         network.ip_addrs:
           interface: eth0
       grains:
         roles: rproxy
ubuntu_1GB_ny3:
- appserver-01:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-02:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-03:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver
- appserver-04:
   minion:
     mine_functions:
       network.ip_addrs:
           interface: eth0
     grains:
       roles: appserver

Après avoir effectué cette mise à jour, vous devrez réexécuter la commande et les deux commandes de l’étape 6:

salt-cloud -m /etc/salt/cloud.maps.d/do-app-with-rproxy.map
salt -G 'roles:appserver' state.sls awesome-app.app
salt -G 'roles:rproxy' state.sls nginx.rproxy

La répétition de la séquence Salt ne toucherait pas les serveurs existants, les nouveaux serveurs seraient construits conformément aux spécifications et la configuration de Nginx serait mise à jour pour commencer le routage du trafic vers les nouveaux serveurs d’applications.

Conclusion

Le déploiement d’une application ne faisant que signaler l’adresse IP du serveur n’est pas très utile. Heureusement, cette approche ne se limite pas aux applications Node.js. Salt ne se soucie pas de la langue dans laquelle votre application est écrite.

Si vous souhaitez utiliser ce cadre pour déployer votre propre application, il vous suffit d’automatiser la tâche d’installation de votre application sur un serveur (via un script ou avec des états Salt) et de remplacer notre exemple par votre propre automatisation.

Tout comme Salt automatise les processus sur vos gouttelettes, Salt Cloud automatise les processus sur votre cloud. Prendre plaisir!

Related