Infrastructure SaltStack: Installation de Salt Master

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 cet article, nous présenterons les différents environnements que nous allons créer et installerons le démon Salt Master sur notre serveur principal afin de commencer. C’est le système principal qui hébergera nos instructions de configuration, contrôlera nos nœuds d’infrastructure et gérera nos exigences.

Pour compléter ce guide, vous aurez besoin d’un serveur vierge Ubuntu 14.04. Ce serveur devra avoir activé la mise en réseau privée.

Sur ce serveur, vous devez avoir un compte non-root configuré avec les privilèges + sudo +. Vous pouvez apprendre à configurer un compte de ce type dans notre Ubuntu 14.04 guide de configuration initiale du serveur.

Un article ultérieur de cette série utilisera la commande + salt-cloud + pour activer des serveurs d’infrastructure utilisant le cloud DigitalOcean. Vous pouvez utiliser d’autres fournisseurs de cloud, si vous le souhaitez, ou même des instances virtuelles utilisant un logiciel tel que vagrant. Cependant, cela sort du cadre de ce guide et vous devrez faire vos propres recherches dans ces domaines.

Les serveurs sur lesquels nous tournons `` salt-cloud + `représenteront nos trois environnements que nous souhaitons maintenir pour le développement d’applications. Étant donné que notre serveur maître Salt conservera la configuration de chacun des serveurs dont nous avons besoin, nous pourrons les désactiver lorsque nous ne les utiliserons pas. Par exemple, si votre équipe de développement a arrêté le travail pendant les vacances, vous pouvez réduire vos environnements non productifs. Lorsque vous revenez de votre séjour, vous pouvez facilement les reconstruire et redéployer votre application sur cette nouvelle infrastructure.

Nous allons décomposer notre exemple d’infrastructure en développement, en staging et en production.

Notre infrastructure de développement sera notre plus modeste. Il contiendra simplement un serveur Web unique et un serveur de base de données associé. Le découplage de la base de données et du serveur Web suffira à garantir que notre application est conçue pour les données distantes.

L’environnement de transfert sera plus robuste. La plupart des conseils que vous trouverez recommandent de configurer votre environnement de transfert de manière à être aussi semblable que possible à votre environnement de production prévu. Dans cet esprit, notre environnement de transfert comprendra deux serveurs Web afin de répartir la charge de trafic. Nous allons répartir le trafic entre ces deux serveurs à l’aide d’un équilibreur de charge. Du côté de la base de données, nous allons faire tourner deux serveurs de base de données. Nous allons configurer une réplication maître-maître entre ces deux serveurs afin que ceux-ci puissent accepter les demandes d’écriture. La réplication maître à maître présente certains inconvénients, mais elle nous permet d’être un peu paresseux dans la conception de nos applications (tout serveur de base de données peut recevoir des écritures) et de nous permettre de démontrer un scénario de gestion de configuration assez complexe.

Comme nous l’avons indiqué précédemment, l’environnement de production sera très similaire à l’environnement de transfert. La seule différence dans notre conception sera un équilibreur de charge supplémentaire pour assurer une haute disponibilité et un basculement. Si vous le souhaitez, vous pouvez également utiliser des serveurs de plus grande capacité pour votre charge de production. Cela est souvent nécessaire pour gérer correctement les exigences de trafic, même si cela rend plus difficile l’évaluation de la charge dans l’environnement de transfert.

N’oubliez pas que lors de la création des configurations pour les environnements énumérés ci-dessus, elles ne doivent pas toutes être exécutées en même temps. Cela est particulièrement vrai lors des tests. Tout au long de cette série, vous n’auriez probablement que quelques serveurs actifs à la fois. Cela est souhaitable du point de vue des coûts, mais détruire et élever nos environnements selon les besoins garantit également que le démarrage de notre environnement est robuste et reproductible.

Maintenant que vous connaissez la disposition générale des environnements que nous allons configurer, notre maître Salt peut être opérationnel.

Commencez par vous connecter au serveur que vous avez l’intention de configurer en tant que maître Salt en tant qu’utilisateur non root avec les privilèges + sudo +.

Il existe de nombreuses https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-salt-master-and-minion-servers-on-ubuntu-14-04] installer le démon maître Salt sur un serveur. Des PPA sont disponibles pour Ubuntu, mais ils peuvent souvent être obsolètes. La meilleure approche pour planifier et gérer un logiciel de gestion de la configuration consiste à cibler une version spécifique. Cela vous permettra de mettre à jour vos systèmes (après des tests approfondis) de manière planifiée et structurée au lieu de vous fier à tout ce qui est disponible dans un référentiel au moment de l’installation.

Pour ce guide, nous viserons la version Salt, v2015.8.0, la dernière version stable au moment de la rédaction de cet article. Si vous choisissez une version ou une méthode d’installation différente, sachez que les processus décrits dans ce guide risquent de ne pas fonctionner comme prévu.

Le moyen le plus simple d’installer une version spécifique consiste à utiliser le script d’amorçage de SaltStack. Téléchargez le dernier script d’amorçage dans votre répertoire personnel en tapant:

N’hésitez pas à consulter le contenu du script téléchargé jusqu’à ce que vous soyez à l’aise avec les opérations qu’il effectuera.

Lorsque vous êtes prêt à installer le maître Salt, vous pouvez exécuter le script avec le shell + sh +. Nous allons lui passer l’indicateur + -P + pour indiquer que nous autorisons les installations de dépendances avec + pip +, le gestionnaire de paquets Python. Nous devrons également inclure l’indicateur + -M + pour indiquer que nous souhaitons installer le démon maître. Terminez la commande en incluant + git v2015.8.0 +, qui indique au script de récupérer la balise de version spécifiée à partir du SaltStack GitHub et de l’utiliser pour l’installation:

Le script installera toutes les dépendances nécessaires, tirera la version spécifiée du référentiel + git + et installera les démons Salt master et minion, ainsi que certains utilitaires Salt connexes.

L’installation devrait être plutôt simple. Ensuite, nous pouvons commencer à configurer notre maître de sel.

La première chose à faire est de modifier le fichier de configuration principal de Salt. Ouvrez-le maintenant avec les privilèges + sudo +:

Le fichier de configuration est assez long et bien commenté. Vous devez uniquement supprimer les commentaires et définir les options lorsque vous souhaitez vous écarter des valeurs par défaut. Nous avons seulement besoin de faire quelques modifications pour commencer.

Tout d’abord, recherchez l’option + file_recv + dans le fichier. L’activation de cette option permet aux sbires de sel d’envoyer des fichiers au maître de sel. Ceci est extrêmement utile lors de la création d’états pour obtenir les fichiers de configuration que vous souhaitez modifier. Toutefois, cela comporte certains risques. Nous l’activerons pour la durée de ce guide. Vous pouvez le désactiver par la suite si vous souhaitez:

/ etc / salt / master

Ensuite, nous devrons définir le dictionnaire + file_roots +. Le maître Salt comprend un serveur de fichiers qu’il utilise pour stocker et servir des fichiers pour toute l’infrastructure. Cela inclut les fichiers d’état de gestion de la configuration eux-mêmes, ainsi que tous les fichiers sous-jacents gérés par notre système. Ce dictionnaire YAML définit la racine du serveur de fichiers, qui sera situé à + ​​/ srv / salt +. Nous devons spécifier qu’il se trouve dans l’environnement «de base», l’environnement par défaut obligatoire pour tous les déploiements Salt:

/ etc / salt / master

Note

Le dernier élément dont nous avons besoin pour l’instant est le dictionnaire + pillar_roots +. Le système de pilier est utilisé pour stocker des données de configuration pouvant être restreintes à certains nœuds. Cela nous permet de personnaliser le comportement et d’éviter que des données sensibles ne soient vues par des composants d’infrastructure non associés aux données. Ce format reflète le + fichier_roots + exactement. L’emplacement de nos données de pilier sera à + ​​/ srv / pillar +:

/ etc / salt / master

Enregistrez et fermez le fichier lorsque vous avez terminé.

Nous pouvons aller de l’avant et créer les répertoires référencés dans le fichier de configuration en tapant:

Nous voulons également configurer notre serveur maître Salt pour accepter les commandes Salt. Nous pouvons le faire en configurant le démon minion sur notre serveur. Ouvrez le fichier pour commencer:

Le seul élément que nous devons modifier ici est l’emplacement du serveur maître. Puisque les deux démons fonctionnent sur le même hôte, nous pouvons définir l’adresse sur l’interface de bouclage local:

/ etc / salt / minion

Enregistrez et fermez le fichier lorsque vous avez terminé.

Maintenant que la configuration du maître de sel et du sbire est en place, redémarrez les services pour prendre en compte nos modifications:

Avant que le maître Salt puisse communiquer de manière sécurisée avec un séide (même sur le même serveur), il doit accepter la clé de celui-ci. Ceci est une fonctionnalité de sécurité. Vous pouvez voir toutes les clés acceptées et en attente en tapant:

Si vos démons ont été configurés correctement et ont été redémarrés, vous devriez voir une clé pour votre serveur maître Salt dans la section «Clés non acceptées». Dans notre cas, notre maître de sel est hébergé sur une machine appelée «sm»:

Vous pouvez accepter cette clé en transmettant l’ID de serveur du serveur (+ sm + dans ce cas` +) à la commande + salt-key + avec l’indicateur +` -a`:

Si vous revérifiez, votre clé aura été déplacée dans la section «Clés acceptées»:

Vous pouvez vérifier que votre serveur maître Salt répond maintenant aux commandes Salt en tapant:

Vous devriez obtenir une réponse qui ressemble à ceci:

Votre serveur maître Salt est maintenant opérationnel.

Dans ce guide, nous avons commencé à gérer notre infrastructure en exécutant la configuration initiale de notre serveur maître Salt. C’est le serveur central de notre conception de gestion qui sera utilisé à la fois comme centre de contrôle et comme référentiel de données de configuration.

Dans le next guide de cette série, nous allons configurer notre serveur maître Salt avec nos identifiants d’API DigitalOcean. Nous allons créer une configuration de fournisseur nous permettant de nous connecter à notre compte DigitalOcean à l’aide de la commande + salt-cloud + `et de créer et gérer des ressources cloud. Nous allons créer les profils pour nos machines d’infrastructure afin de pouvoir définir les propriétés de chacun de nos serveurs.