MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Guide de déploiement et de maintenance de MongoDB à l'aide de Puppet :2e partie

Dans le blog précédent, nous vous avons montré comment configurer notre machine avec le Puppet puis installer et configurer MongoDB. Puisque nous allons configurer un certain nombre de nœuds ou plutôt de machines, nous avons besoin d'un marionnettiste. Dans notre cas cependant, nous allons créer un dépôt git dans lequel nous pousserons nos manifestes et les appliquerons à nos machines.

Pour créer un référentiel git local, sélectionnez d'abord le chemin que vous souhaitez utiliser, c'est-à-dire /opt/. Créez ensuite le référentiel git en exécutant le référentiel $sudo mkdir. Obtenez l'autorisation de l'utilisateur racine pour modifier le contenu de ce répertoire en exécutant la commande $sudo chown vagrant:vagrant repository. Pour initialiser ce répertoire en tant que référentiel git après avoir lancé la commande $ cd repository, exécutez $ git init --bare --shared si vous accédez à ce répertoire, vous devriez maintenant voir quelque chose comme

[email protected]:/vagrant/repository$ ls -l

total 12

-rw-rw-r-- 1 vagrant vagrant  23 Jul 15 07:46 HEAD

drwxr-xr-x 1 vagrant vagrant  64 Jul 15 07:46 branches

-rw-rw-r-- 1 vagrant vagrant 145 Jul 15 07:46 config

-rw-rw-r-- 1 vagrant vagrant  73 Jul 15 07:46 description

drwxr-xr-x 1 vagrant vagrant 352 Jul 15 07:46 hooks

drwxr-xr-x 1 vagrant vagrant  96 Jul 15 07:46 info

drwxr-xr-x 1 vagrant vagrant 128 Jul 15 07:46 objects

drwxr-xr-x 1 vagrant vagrant 128 Jul 15 07:46 refs

-rw-r--r-- 1 vagrant vagrant   0 Jul 1 15:58 test.pp

C'est la structure de base d'un dépôt git et les options --bare et --share nous permettront de pousser et d'extraire des fichiers du répertoire.

Nous devons mettre en place un système qui permettra la communication entre les machines impliquées et ce serveur maître distant. Dans ce cas, le système sera appelé un démon. Le démon acceptera les demandes des hôtes distants pour extraire ou envoyer des fichiers vers ce référentiel. Pour ce faire, lancez la commande $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

Cependant, la bonne pratique consistera à créer un fichier à partir duquel nous pourrons l'exécuter en arrière-plan. Nous devons donc définir le service en lançant la commande sudo vim /etc/systemd/system/gitd. un service. Dans le nouveau fichier remplissez-le avec ces contenus

[Unit]

Description=Git Repo Server Daemon

[Service]

ExecStart=/usr/bin/git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

[Install]

WantedBy=getty.target

DefaultInstance=ttyl

Enregistrez le fichier et quittez en appuyant sur <Échap> puis tapez :x et appuyez sur . Pour démarrer le serveur, exécutez la commande $ systemctl start gitd. Pour l'authentification, utilisez le mot de passe que nous avons défini dans ce cas vagabond. Vous devriez être présenté avec quelque chose comme ça 

[email protected]:/opt/repository$ systemctl start gitd

==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===

Authentication is required to start 'gitd.service'.

Authenticating as: vagrant,,, (vagrant)

Password: 

==== AUTHENTICATION COMPLETE ===

To check if the service is running $ ps -ef | grep git and you will get: 

[email protected]:/opt/repository$ ps -ef | grep git

root      1726 1  0 07:48 ?     00:00:00 /usr/bin/git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

root      1728 1726  0 07:48 ?     00:00:00 git-daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

vagrant   1731 1700  0 07:48 pts/0    00:00:00 grep --color=auto git

Maintenant, si nous exécutons $ git clone git://198.168.1.100/repository (n'oubliez pas de changer l'adresse IP avec l'adresse IP du réseau de votre machine) dans le répertoire racine, vous obtiendrez un dossier de référentiel nouvellement créé . Pensez à configurer vos identifiants en décommentant l'email et le mot de passe dans le fichier de configuration. Exécutez $ git config --global --edit pour accéder à ce fichier.

Ce référentiel agira comme notre serveur central pour tous les manifestes et variables.

Configuration de l'environnement

Nous devons maintenant mettre en place l'environnement à partir duquel nous allons configurer les nœuds. Tout d'abord, passez au répertoire vagrant et clonez le référentiel que nous venons de créer avec la même commande que ci-dessus.

 Supprimez le répertoire du manifeste dans le dossier vagrant en exécutant $rm -r manifest/.

Créez un nouveau dossier de production avec $ mkdir production et clonez le même référentiel que nous avons créé ci-dessus avec $ git clone git://198.168.1.100/repository . (n'oubliez pas le point à la fin)

 Copiez et collez le contenu de l'environnement de production puppetlabs dans ce dossier de production en exécutant cp -pr /etc/puppetlabs/code/environments/production/* . Votre répertoire de production devrait maintenant ressembler à ceci

[email protected]:/vagrant/production$ ls -l

total 8

drwxr-xr-x 1 vagrant vagrant  64 Apr 26 18:50 data

-rw-r--r-- 1 vagrant vagrant 865 Apr 26 18:50 environment.conf

-rw-r--r-- 1 vagrant vagrant 518 Apr 26 18:50 hiera.yaml

drwxr-xr-x 1 vagrant vagrant  96 Jul 2 10:45 manifests

drwxr-xr-x 1 vagrant vagrant  64 Apr 26 18:50 modules

-rw-r--r-- 1 vagrant vagrant   0 Jul 1 16:13 test.pp

Nous devons transférer ces modifications vers le dépôt racine afin d'exécuter 

$ git add * && git commit -m "adding production default files" && git push

Pour tester si la configuration de git fonctionne, nous pouvons supprimer le contenu du répertoire /etc/puppetlabs/code/environments/production/ en exécutant $ sudo rm -r * dans ce répertoire, puis tirer les fichiers du référentiel maître en tant qu'utilisateur root, c'est-à-dire $ git clone git://198.168.1.100/repository . (n'oubliez pas le point à la fin). Seuls les répertoires avec du contenu sont extraits dans ce cas, vous risquez donc de manquer les dossiers des manifestes et des modules. Ces opérations peuvent être effectuées sur toutes les machines impliquées, qu'il s'agisse de la marionnette principale ou de la machine cliente. Nos tâches consisteront donc à extraire les modifications du serveur principal et à appliquer les modifications à l'aide des manifestes.

Manifeste d'exécution

C'est le script que nous allons écrire pour nous aider à extraire les modifications et à les appliquer automatiquement à nos autres nœuds. Non seulement vous devez utiliser l'environnement de production,  vous pouvez ajouter autant d'environnements que possible, puis dicter à la marionnette à partir de laquelle effectuer la recherche. Dans le répertoire racine production/manifests, nous allons créer le manifeste d'exécution en tant que puppet_exec.pp et le remplir avec le contenu suivant

 file { "This script will be pulling and applying the puppet manifests":

path => '/usr/local/bin/exec-puppet',

content => 'cd /etc/puppetlabs/code/environments/production/ && git pull; /opt/puppetlabs/bin/puppet apply manifests/'

mode => "0755"

}

cron {'exec-puppet':

command => '/usr/local/bin/exec-puppet',

hour => '*',

minute => '*/15'

}

Le fichier est une ressource qui a été décrite pour exécuter les manifestes de marionnettes. Ajoutez un chemin approprié pour le fichier que nous créons et remplissez-le avec les commandes qui doivent être émises lors de son exécution.

Les commandes sont exécutées systématiquement, c'est-à-dire que nous naviguons d'abord vers l'environnement de production, récupérons les modifications du référentiel, puis les appliquons à la machine.

Nous fournissons le répertoire des manifestes à chaque nœud à partir duquel il peut sélectionner le manifeste qui lui est destiné pour application.

Une durée pendant laquelle le fichier d'exécution doit être exécuté est également définie. Dans ce cas, pour chaque heure, exécutez le fichier 4 fois.

Pour appliquer ceci à notre machine actuelle, $ cd /vagrant/production. Ajoutez tout à git en lançant $ git add * puis $ git commit -m « add the cron configurations » et enfin $ git push. Naviguez maintenant vers $ cd /etc/puppetlabs/code/environments/production/ et $ sudo git pull

Maintenant, si nous vérifions le dossier manifests dans ce répertoire, vous devriez voir le puppet_exec.pp créé comme nous venons de le définir.

Maintenant, si nous lançons $ sudo puppet apply manifests/ et vérifions si les fichiers exec-puppet ont été créés $ cat /usr/local/bin/exec-puppet

Le contenu de ce fichier doit être 

cd /etc/puppetlabs/code/environments/production/ && git pull; /opt/puppetlabs/bin/puppet apply manifests/

À ce stade, nous avons vu comment nous pouvons extraire et appliquer des modifications à notre machine maître qui doivent être appliquées à tous les autres nœuds. Si nous exécutons $ sudo crontab -l, certains avertissements importants sont mis en évidence sur le fichier exec-puppet créé.

# HEADER: This file was autogenerated at 2019-07-02 11:50:56 +0000 by puppet.

# HEADER: While it can still be managed manually, it is definitely not recommended.

# HEADER: Note particularly that the comments starting with 'Puppet Name' should

# HEADER: not be deleted, as doing so could cause duplicate cron jobs.

# Puppet Name: exec-puppet

*/15 * * * * /usr/local/bin/exec-puppet

Configuration des machines

Disons que notre fichier vagabond ressemble à

Vagrant.configure("2") do |config|

  config.vm.define "puppet" do |puppet|

   puppet.vm.box = "bento/ubuntu-16.04"

   #puppet.vm.hostname = "puppet"

   #puppet.vm.network "private_network", ip: "192.168.1.10"

  end

  config.vm.define "db" do |db|

    db.vm.box = "bento/ubuntu-16.04"

  end

end

Dans ce cas, nous avons la machine marionnette sur laquelle nous avons effectué nos configurations, puis la machine db. Maintenant, nous devons automatiser la machine de sorte que chaque fois que la machine db est démarrée, la marionnette est déjà installée et le fichier cron déjà disponible pour extraire les manifestes et les appliquer en conséquence. Vous devrez restructurer le contenu de la machine db comme suit

config.vm.define "db" do |db|

    db.vm.box = "bento/ubuntu-16.04"

    vm.provision "shell", inline: <<-SHELL

      cd /temp

      wget  https://apt.puppetlabs.com/puppet5-release-xenial.deb

      dpkg -i puppet5-release-xenial.deb

      apt-get update

      apt-get install -y puppet-agent

      apt-get install -y git

      rm -rf /etc/puppetlabs/code/environments/production/*

      cd /etc/puppetlabs/code/environments/production/

      git clone git://198.168.1.100/repository .

      /opt/puppetlabs/bin/puppet apply /etc/puppetlabs/code/environments/production/manifests/puppet_exec.pp

    SHELL

  End

Jusqu'à ce stade, la structure de votre répertoire de marionnettes devrait ressembler à ceci

Si maintenant vous exécutez la machine db avec la commande $ vagrant up db, certaines des ressources seront installées et le Le script que nous venons de définir se trouve dans le répertoire production/manifests. Cependant, il est conseillé d'utiliser le puppet master qui est contraint à seulement 10 nœuds pour la version gratuite sinon vous devrez souscrire à un plan. Puppet Master offre plus de fonctionnalités et distribue des manifestes à plusieurs nœuds, des journaux de rapports et plus de contrôle sur les nœuds.

Module de marionnettes Mongodb

Ce module est utilisé dans l'installation de MongoDB, la gestion de l'installation du serveur mongod, la configuration du démon mongod et la gestion de la configuration d'Ops Manager en plus du démon MongoDB-mms.

Conclusion

Dans le prochain blog, nous vous montrerons comment déployer un ensemble de répliques MongoDB et des fragments à l'aide de Puppet.