TOC

Infrastructure SaltStack: Création des états Salt pour les serveurs de base de données MySQL

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 le last guide de cette série, nous avons défini HAProxy comme équilibreur de charge dans devant nos serveurs Web. Dans ce guide, nous allons changer notre objectif pour créer des états qui installeront et géreront nos serveurs de base de données MySQL dans chacun de nos environnements. Cet article couvrira l’installation et la configuration de base de MySQL. Dans un prochain guide, nous aborderons la tâche plus complexe de la configuration de la réplication.

Obtenir des informations sur l’invite MySQL avec debconf-utils

Le processus de création de nos états MySQL sera un peu plus compliqué que nos exemples précédents avec Nginx et MySQL. Contrairement aux deux autres étapes de l’installation, l’installation de MySQL implique généralement de répondre à un ensemble d’invites pour définir le mot de passe racine de MySQL.

Avant de commencer avec notre fichier d’état, nous devrions faire une installation test de MySQL sur l’un de nos séides. Nous pouvons ensuite utiliser le paquetage + debconf-utils + pour obtenir des informations sur les invites à remplir.

Si votre environnement intermédiaire n’est pas encore disponible, vous pouvez utiliser le fichier de carte de l’environnement intermédiaire que nous avons créé précédemment pour créer l’environnement:

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

Une fois vos serveurs de base de données opérationnels et disponibles, choisissez l’un de vos serveurs de base de données pour installer MySQL afin que nous puissions obtenir les informations pertinentes à partir de l’installation:

sudo salt stage-db1 pkg.install mysql-server

Afin d’interroger facilement les bases de données + debconf + pour les informations d’invite dont nous avons besoin, nous devons également installer le paquetage + debconf-utils + sur la base de données minion:

sudo salt stage-db1 pkg.install debconf-utils

La fonctionnalité + debconf + dans Salt sera disponible maintenant que ce paquet est installé. Nous pouvons utiliser la fonction de module d’exécution + debconf.get_selections + pour obtenir toutes les informations sur les invites à partir de la base de données minion. Nous devrions diriger ceci dans + less + parce que cela retournera all des informations provenant des paquets installés sur cet hôte:

sudo salt stage-db1 debconf.get_selections | less

Dans la sortie, recherchez la section impliquant MySQL. Ça devrait ressembler a quelque chose comme ca:

Output. . .

mysql-server-5.5:
   |_


   |_


   |_
     - mysql-server-5.5/really_downgrade
     - boolean
     - false
   |_
     - mysql-server-5.5/start_on_boot
     - boolean
     - true

. . .

Les deux premières entrées contiennent les noms de champs dont nous avons besoin (+ mysql-server / motdepasse_racine + et + mysql-server / mot_passe_racine +). La deuxième ligne de ces entrées spécifie le type de champ, que nous devrons spécifier dans notre fichier d’état.

Une fois que vous avez copié ces informations à partir de la sortie + debconf +, nous devrions également aller de l’avant et récupérer le fichier + / etc / mysql / my.cnf +. Nous en aurons besoin plus tard pour configurer nos états MySQL:

sudo salt stage-db1 cp.push /etc/mysql/my.cnf

Après avoir repoussé le fichier + / etc / mysql / my.cnf vers le maître Salt, nous pouvons supprimer la ressource afin d’avoir une table rase sur laquelle tester plus tard dans le guide:

sudo salt-cloud -d stage-db1

Une fois le serveur supprimé, vous pouvez le recréer en arrière-plan en tapant ce qui suit. Le + sm + dans cette instance est le nom de notre serveur maître Salt, qui possède les informations d’identification du cloud appropriées:

sudo salt --async  cloud.profile stage-db stage-db1

Pendant la reconstruction de votre serveur de base de données, nous pouvons commencer à créer le fichier d’état MySQL.

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

Nous allons commencer par créer un répertoire pour notre état MySQL dans le répertoire + / srv / salt +:

sudo mkdir -p /srv/salt/mysql

Dans ce répertoire, nous pouvons créer et ouvrir un fichier + init.sls + pour stocker notre fichier d’état MySQL principal:

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

Nous devrons nous assurer que le paquetage + debconf-utils + est installé sur le serveur afin de pouvoir définir facilement les valeurs dont nous avons besoin. Nous pouvons le faire avec le module d’état + package.installed:

/srv/salt/mysql/init.sls

debconf-utils:
 pkg.installed

Une fois le paquetage + debconf-utils + installé, nous pouvons pré-ensemencer les réponses aux invites à l’aide du module d’état + debconf.set +. Nous allons utiliser l’attribut + name + pour spécifier le nom du paquet pour lequel nous souhaitons définir des invites. Ensuite, nous créons une structure + data + qui contient le dictionnaire des informations pouvant être utilisé pour remplir les invites.

La structure + data + utilise essentiellement les informations sur les invites que nous avons interrogées depuis notre installation de test MySQL. Nous connaissons les noms de champs et les types de données à utiliser pour ces champs. Pour spécifier le mot de passe réel, nous allons extraire du système Salt pillar avec la fonction de module d’exécution + pillar.get +.

Nous définirons le mot de passe dans le système de pilier un peu plus tard. Cela nous permettra de garder vos données de mot de passe séparément de notre configuration.

Note

/srv/salt/mysql/init.sls

debconf-utils:
 pkg.installed

mysql_setup:
 debconf.set:
   - name: mysql-server
   - data:
       'mysql-server/root_password': {'type': 'password', 'value': '{{ salt['pillar.get']('mysql:root_pw', '') }}' }
       'mysql-server/root_password_again': {'type': 'password', 'value': '{{ salt['pillar.get']('mysql:root_pw', '') }}' }
   - require:
     - pkg: debconf-utils

Afin d’interagir réellement avec MySQL, les bibliothèques Python appropriées doivent être disponibles sur les serveurs de base de données. Nous pouvons installer le paquetage + python-mysqldb pour nous assurer d’avoir accès aux fonctionnalités MySQL de Salt. Ensuite, nous pouvons installer en toute sécurité le logiciel serveur MySQL. Nous allons utiliser + require + pour nous assurer que les bibliothèques + debconf + et Python sont disponibles.

Après l’installation, nous pouvons ajouter un état de service pour nous assurer que le service est en cours d’exécution. Ceci surveillera les changements dans le paquet du serveur MySQL. Il observera également le fichier de configuration MySQL de base et rechargera le service si des modifications sont détectées:

/srv/salt/mysql/init.sls

debconf-utils:
 pkg.installed

mysql_setup:
 debconf.set:
   - name: mysql-server
   - data:
       'mysql-server/root_password': {'type': 'password', 'value': '{{ salt['pillar.get']('mysql:root_pw', '') }}' }
       'mysql-server/root_password_again': {'type': 'password', 'value': '{{ salt['pillar.get']('mysql:root_pw', '') }}' }
   - require:
     - pkg: debconf-utils

Nous aurons besoin de gérer quelques fichiers avec MySQL. Le fichier le plus évident que nous devons gérer est le fichier + / etc / mysql / my.cnf que nous avons mentionné ci-dessus. Nous devrons apporter des modifications en fonction des informations variables. Ce fichier devra donc être un modèle Jinja.

Les autres fichiers que nous devons gérer concernent la gestion des systèmes MySQL par Salt. Afin de gérer les bases de données, le séide sel doit avoir des informations sur la façon de se connecter au SGBDR. Premièrement, nous pouvons créer un fichier simple dans le répertoire + / etc / salt / minion.d +. Ceci listera simplement le fichier où nos détails de connexion peuvent être trouvés. Le fichier avec les détails de connexion à la base de données est l’autre fichier que nous devrons gérer. Le fichier de connexion à la base de données devra être un modèle:

/srv/salt/mysql/init.sls

. . .

mysql:
 service.running:
   - watch:
     - pkg: mysql-server
     - file: /etc/mysql/my.cnf

Enfin, nous devons inclure un état + service.restart + qui rechargera le processus + salt-minion + lui-même. Cela est nécessaire pour que notre serviteur récupère le fichier + / etc / salt / minion.d / mysql.conf +. Nous voulons que le fichier + salt-minion + soit redémarré uniquement lorsque le fichier + / etc / salt / minion.d / mysql.conf + a été modifié. Nous pouvons utiliser un requis + watch + pour accomplir cela:

/srv/salt/mysql/init.sls

. . .

/etc/mysql/salt.cnf:
 file.managed:
   - source: salt://mysql/files/etc/mysql/salt.cnf.jinja
   - template: jinja
   - user: root
   - group: root
   - mode: 640
   - require:
     - service: mysql

Lorsque vous avez terminé d’ajouter les détails ci-dessus, enregistrez et fermez le fichier.

Créer les piliers pour MySQL

Dans notre état MySQL, nous avons utilisé la fonction de module d’exécution + pillar.get + pour renseigner le mot de passe racine de MySQL avec une valeur issue du système de pilier. Nous devons mettre en place ce pilier afin que l’État puisse extraire les données nécessaires à la construction des informations d’identification de la base de données.

Le système de piliers est parfait pour ce type de cas d’utilisation car il vous permet d’affecter des données à certains hôtes. Les hôtes ne correspondant pas n’auront pas accès aux données sensibles. Jusqu’à présent, notre état n’a besoin que du mot de passe root. Nous avons spécifié l’emplacement dans le système de piliers comme + mysql: root_pw +. Nous allons maintenant configurer cette clé.

Création d’un fichier de base pour le système Pillar

Avant de créer les fichiers de piliers MySQL dont nous avons besoin, nous devons créer un fichier «top» de piliers. Le fichier supérieur est utilisé pour faire correspondre les sbires de sel avec les données de pilier. Les sbires de sel ne pourront pas accéder aux données de pilier dont ils ne correspondent pas dans le fichier principal.

Le répertoire + / srv / pillar + devrait avoir été créé lors du guide d’installation. Nous pouvons créer un fichier + top.sls + dans ce répertoire pour commencer:

cd /srv/pillar
sudo nano top.sls

A l’intérieur, nous devons spécifier l’environnement + base (nous n’utilisons pas la conception Salt des environnements de cette série en raison de la complexité et de certains comportements non documentés. Tous nos serveurs fonctionnent dans l’environnement + base + et utilisent des grains pour la désignation environnementale). Nous allons utiliser la correspondance des composés pour faire correspondre les nœuds. Nous allons associer le rôle de serveur et l’environnement de serveur pour déterminer les piliers à affecter à chaque hôte.

Les piliers utilisent la notation par points pour désigner les fichiers dans un répertoire. Par exemple, la racine du système de piliers est + / srv / pillar +. Pour assigner le pilier + mysql.sls situé dans le répertoire` + dev + , nous utilisons + dev.mysql`.

La tâche dont nous aurons besoin pour ce guide ressemble à ceci:

/srv/pillar/top.sls

base:
 'G@env:dev and G@role:dbserver':
   - match: compound
   - dev.mysql

 'G@env:stage and G@role:dbserver':
   - match: compound
   - stage.mysql

 'G@env:prod and G@role:dbserver':
   - match: compound
   - prod.mysql

Enregistrez et fermez le fichier lorsque vous avez terminé.

Création des piliers spécifiques à l’environnement

Ci-dessus, nous avons affecté des piliers aux serveurs en fonction de leur rôle et de leur environnement. Cela nous permet de spécifier différentes informations de connexion et d’informations d’identification pour différents environnements.

Commencez par créer les répertoires mentionnés dans le fichier supérieur du pilier:

sudo mkdir /srv/pillar/{prod,stage,dev}

Ensuite, nous devrions créer un fichier + mysql.sql dans chacun de ces répertoires. Nous pouvons commencer avec le fichier + / srv / salt / stage / mysql.sls +, car nous utilisons actuellement l’environnement de transfert pour tester:

sudo nano /srv/pillar/stage/mysql.sls

Le fichier d’état que nous avons créé veut extraire le mot de passe root MySQL du système de pilier à l’aide de la clé + mysql: root_pw +. C’est en fait une clé imbriquée, ce qui signifie que + root_pw + est un enfant de la clé + mysql +. Dans cet esprit, nous pouvons choisir un mot de passe pour notre utilisateur root MySQL et le définir dans le fichier comme suit:

/srv/pillar/stage/mysql.sls

mysql:
 root_pw:

Choisissez le mot de passe que vous souhaitez utiliser. Lorsque vous avez terminé, enregistrez et fermez le fichier. C’est tout ce dont nous avons besoin pour l’instant.

Créez un fichier similaire dans votre pilier de développement:

sudo nano /srv/pillar/dev/mysql.sls

/srv/pillar/dev/mysql.sls

mysql:
 root_pw:

Faites de même pour le pilier de votre environnement de production:

sudo nano /srv/pillar/prod/mysql.sls

/srv/pillar/prod/mysql.sls

mysql:
 root_pw:

Choisissez des mots de passe différents pour chacun de ces environnements.

Nous reviendrons sur ces piliers plus tard car nous avons besoin de plus de données qui ne font pas partie de la configuration elle-même. Pour l’instant, enregistrez et fermez tous les fichiers ouverts.

Créez le modèle /etc/mysql/my.cnf.jinja

Nous avons précédemment créé notre fichier d’état MySQL de base, mais nous n’avons jamais créé les fichiers gérés pour l’installation.

Lorsque nous avons effectué l’installation test de + mysql-server + sur notre serveur + stage-db1 +, nous avons poussé le fichier + / etc / mysql / my.cnf + vers le maître. Cela devrait toujours être disponible dans notre cache maître Salt. Nous pouvons copier l’intégralité de la structure de répertoire menant à ce fichier de cache dans notre répertoire + / srv / salt / mysql + en tapant:

sudo cp -r /var/cache/salt/master/minions/stage-db1/files /srv/salt/mysql

Accédez au répertoire contenant le fichier + mycnf + copié dans le répertoire d’état MySQL:

cd /srv/salt/mysql/files/etc/mysql

Copiez le fichier tel qu’il existe actuellement dans un suffixe + .orig + afin que nous puissions annuler les modifications si nécessaire:

sudo cp my.cnf my.cnf.orig

Ensuite, renommez le fichier + my.cnf + pour lui donner un suffixe + .jinja +. Cela nous indiquera d’un coup d’œil que ce fichier est un modèle, pas un fichier pouvant être déposé sur un hôte sans rendu:

sudo mv my.cnf my.cnf.jinja

Ouvrez le fichier de modèle Jinja pour commencer avec les modifications nécessaires:

sudo nano my.cnf.jinja

Toutes les modifications que nous souhaitons créer concernent maintenant l’autorisation des connexions MySQL à distance. Dans l’état actuel des choses, MySQL est lié à l’interface de bouclage local. Nous voulons configurer cela pour écouter sur l’adresse réseau privée du nœud.

Pour ce faire, recherchez la ligne + bind-address dans la section` + [mysqld] + . Nous allons utiliser la fonction de module d’exécution `+ network.interface_ip + pour obtenir l’adresse attribuée à l’interface + eth1 + du séide.

/srv/salt/mysql/files/etc/mysql/my.cnf.jinja

. . .

[mysqld]

. . .

bind-address            =

Nous devons également désactiver la résolution de noms DNS pour nos serveurs. En ajoutant l’option + skip-name-resol +, MySQL n’échouera pas s’il ne peut pas terminer la résolution d’un nom et l’inverse du nom:

/srv/salt/mysql/files/etc/mysql/my.cnf.jinja

. . .

[mysqld]

. . .

bind-address            = {{ salt['network.interface_ip']('eth1') }}

Enregistrez et fermez le fichier lorsque vous avez terminé.

Créez le fichier /etc/salt/minion.d/mysql.conf

Ensuite, nous devons créer le fichier géré utilisé pour modifier la configuration du sbire en sachant comment se connecter à la base de données MySQL. Au lieu de conserver la configuration dans le fichier + / etc / salt / minion + lui-même, nous allons placer un nouveau fichier dans le répertoire + / etc / salt / minion.d + pour indiquer au séide où trouver les informations de connexion.

Commencez par créer la structure de répertoires nécessaire dans le répertoire + / srv / salt / mysql / files:

sudo mkdir -p /srv/salt/mysql/files/etc/salt/minion.d

Nous pouvons créer un fichier dans ce répertoire appelé + mysql.conf +:

sudo nano /srv/salt/mysql/files/etc/salt/minion.d/mysql.conf

À l’intérieur, il suffit de définir une option: l’emplacement du fichier d’informations de connexion. Dans notre cas, nous allons en faire un fichier + / etc / mysql / salt.cnf +:

/srv/salt/mysql/files/etc/salt/minion.d/mysql.conf

mysql.default_file: '/etc/mysql/salt.cnf'

Enregistrez et fermez le fichier lorsque vous avez terminé.

Créez le fichier de modèle /etc/mysql/salt.cnf

Maintenant, nous devons créer le fichier mentionné dans notre configuration de serviteur. Ce sera un fichier modèle car nous devons récupérer certains détails de la connexion à partir du système de pilier. Nous placerons ce fichier dans le répertoire + / srv / salt / mysql / files / etc / mysql:

sudo nano /srv/salt/mysql/files/etc/mysql/salt.cnf.jinja

À l’intérieur, nous devons ouvrir une section + [client] + pour spécifier le type d’informations que nous définissons. Sous cet en-tête, nous pouvons indiquer au client de se connecter à la machine locale avec l’utilisateur racine MySQL sur un socket Unix situé sur + / var / run / mysqld / mysqld.sock +. Ce sont toutes les valeurs MySQL par défaut:

/srv/salt/mysql/files/etc/mysql/salt.cnf.jinja

[client]
host                = localhost
user                = root
socket              = /var/run/mysqld/mysqld.sock

La seule chose que nous devons ajouter maintenant est le mot de passe. Encore une fois, nous allons tirer cela directement du système de pilier de la même manière que nous l’avions fait dans la section + debconf + de notre fichier d’état MySQL. Cela ressemblera à ceci:

/srv/salt/mysql/files/etc/mysql/salt.cnf.jinja

[client]
host                = localhost
user                = root
socket              = /var/run/mysqld/mysqld.sock

Enregistrez et fermez le fichier lorsque vous avez terminé.

Test d’installation et de vérification de l’intégrité

Maintenant que l’état d’installation de base et les fichiers de support sont configurés, nous devons tester notre configuration rapidement pour nous assurer qu’elle fonctionne correctement.

Nous allons commencer par passer par notre processus de test typique. Utilisez la fonction de module d’exécution + state.show_sls + pour vous assurer qu’elle peut restituer votre fichier d’état:

sudo salt stage-db1 state.show_sls mysql

Parcourez la sortie pour vous assurer que Salt n’a aucun problème à analyser votre fichier + / srv / salt / mysql / init.sls +.

Ensuite, faites un essai sur ordinateur de l’application state en ajoutant + test = True + à la fin de la fonction du module d’exécution + state.apply +:

sudo salt stage-db1 state.apply mysql test=True

  • Cette commande devrait échouer *. Certaines fonctions d’état de notre fichier n’étant disponibles qu’après l’installation de paquetages spécifiques, il est probable qu’un échec survienne au cours de l’exécution à sec. Lors de l’exécution réelle, l’ordre des états garantira que les packages prérequis sont installés _avant que les états qui les utilisent soient appelés.

Tous les commentaires relatifs aux états défaillants doivent indiquer qu’une ou plusieurs conditions requises ont échoué, à l’exception de l’état + mysql_setup +, qui devrait échouer en raison de l’absence de + debconf.set + (ceci est juste un autre échec préalable ). Utilisez la sortie ici pour vous assurer qu’aucune autre erreur non liée n’est apparue.

Après avoir exécuté le test, nous pouvons appliquer l’état en tapant:

sudo salt stage-db1 state.apply mysql

Cela devrait aboutir à une exécution réussie de l’état.

Nous devons vérifier que Salt est capable de se connecter et d’interroger la base de données MySQL. Assurez-vous que vous pouvez répertorier les bases de données par défaut en tapant:

sudo salt stage-db1 mysql.db_list

Vous devriez obtenir une liste qui ressemble à ceci:

Outputstage-db1:
   - information_schema
   - mysql
   - performance_schema

Cela indique que Salt a pu se connecter à l’instance MySQL en utilisant les informations spécifiées dans le fichier + / etc / mysql / salt.cnf +.

Maintenant que nous avons vérifié que notre base MySQL fonctionne correctement, nous pouvons supprimer le serveur + stage-db1 +:

sudo salt-cloud -d stage-db1

Recréez le serveur en arrière-plan afin de pouvoir le tester ultérieurement. Encore une fois, + sm + est le nom de notre serveur maître Salt dans cet exemple:

sudo salt --async  cloud.profile stage-db stage-db1

Notre configuration de base de MySQL est maintenant terminée.

Conclusion

Vous devriez maintenant avoir des états qui installeront MySQL sur vos sbires. Ils lanceront également le processus + salt-minion + sur chacun de ces serveurs afin que Salt puisse se connecter et gérer les bases de données impliquées.

Alors que nos états actuels installent MySQL et configurent nos serviteurs pour contrôler les systèmes de base de données, nos bases de données sont actuellement complètement séparées. Dans un prochain guide, nous aborderons la réplication de base de données MySQL afin que nos données soient cohérentes dans chacune de nos bases de données dans chaque environnement.

Related