MongoDB
 sql >> Database >  >> NoSQL >> MongoDB

Una guida alla distribuzione e alla manutenzione di MongoDB utilizzando Puppet:parte 2

Nel blog precedente, ti abbiamo mostrato come configurare la nostra macchina con il Puppet e quindi installare e configurare MongoDB. Dato che configureremo un certo numero di nodi o meglio macchine, abbiamo bisogno di un burattinaio. Nel nostro caso, però, creeremo un repository git in cui inseriremo i nostri manifesti e li applicheremo alle nostre macchine.

Per creare un repository git locale, seleziona prima il percorso che desideri utilizzare, ad esempio /opt/. Quindi crea il repository git eseguendo  $sudo mkdir repository. Ottieni l'autorizzazione dell'utente root per modificare il contenuto di questa directory eseguendo il comando  $sudo chown vagrant:vagrant repository. Per inizializzare questa directory come repository git dopo aver emesso il comando $ cd repository, esegui $ git init --bare --shared se accedi a questa directory dovresti ora vedere qualcosa di simile

[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

Questa è la struttura di base di un repository git e le opzioni --bare e --share ci consentiranno di eseguire il push e il pull di file dalla directory.

Dobbiamo impostare un sistema che consenta la comunicazione tra le macchine coinvolte e questo server master remoto. Il sistema in questo caso verrà chiamato demone. Il demone accetterà richieste da host remoti per eseguire il pull o il push di file in questo repository. Per farlo, emetti il ​​comando $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

Tuttavia la buona pratica sarà quella di creare un file da cui eseguirlo in background. Dobbiamo quindi impostare il servizio eseguendo il comando sudo vim /etc/systemd/system/gitd. servizio. Nel nuovo file popolalo con questi contenuti

[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

Salvare il file ed uscire premendo quindi digitare :x e premere . Per avviare il server eseguire il comando $ systemctl start gitd. Per l'autenticazione utilizzare la password che abbiamo impostato in questo caso vagabondo. Dovresti presentarti qualcosa del genere 

[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

Ora, se eseguiamo $ git clone git://198.168.1.100/repository (ricordati di cambiare l'indirizzo IP con l'IP di rete della tua macchina) nella directory principale, otterrai una cartella di repository appena creata . Ricordati di configurare le tue credenziali decommentando l'email e la password nel file di configurazione. Esegui $ git config --global --edit per accedere a questo file.

Questo repository fungerà da server centrale per tutti i manifest e le variabili.

Impostazione dell'ambiente

Ora dobbiamo configurare l'ambiente da cui configureremo i nodi. Per prima cosa, passa alla directory vagrant e clona il repository che abbiamo appena creato con lo stesso comando di cui sopra.

 Rimuovi la directory manifest nella cartella vagrant eseguendo $rm -r manifest/.

Crea una nuova cartella di produzione con $ mkdir production e clona lo stesso repository che abbiamo creato sopra con $ git clone git://198.168.1.100/repository . (non dimenticare il punto alla fine)

 Copia e incolla il contenuto dell'ambiente di produzione di puppetlabs in questa cartella di produzione emettendo cp -pr /etc/puppetlabs/code/environments/production/* . La tua directory di produzione dovrebbe ora assomigliare a questa

[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

Dobbiamo inviare queste modifiche al repository principale, quindi eseguiamo 

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

Per verificare se la configurazione di git funziona, possiamo eliminare il contenuto nella directory /etc/puppetlabs/code/environments/production/ eseguendo $ sudo rm -r * in questa directory e quindi tirare i file dal repository principale come utente root, ad esempio $ git clone git://198.168.1.100/repository . (non dimenticare il punto alla fine). In questo caso vengono estratte solo le directory con contenuto, quindi potresti perdere le cartelle manifest e moduli. Queste operazioni possono essere eseguite su tutte le macchine coinvolte, sia il burattino principale che la macchina client. Quindi le nostre attività estrarranno le modifiche dal server principale e applicheranno le modifiche utilizzando i manifesti.

Manifest di esecuzione

Questo è lo script che scriveremo per aiutarci a estrarre le modifiche e applicarle automaticamente agli altri nostri nodi. Non solo devi utilizzare l'ambiente di produzione, puoi aggiungere il maggior numero possibile di ambienti e poi dettare il pupazzo da cui cercare. Nella directory root  production/manifests creeremo il manifest di esecuzione come puppet_exec.pp e lo compileremo con i seguenti contenuti

 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'

}

Il file è una risorsa che è stata descritta per eseguire i manifesti del pupazzo. Aggiungi un percorso appropriato per il file che stiamo creando e popolalo con i comandi che devono essere emessi quando verrà eseguito.

I comandi vengono eseguiti sistematicamente, ovvero prima navighiamo nell'ambiente di produzione, estraiamo le modifiche al repository e quindi le applichiamo alla macchina.

Forniamo la directory manifests a ciascun nodo da cui può selezionare il manifest indirizzato ad esso per l'applicazione.

Viene impostata anche una durata per l'esecuzione del file di esecuzione. In questo caso per ogni ora, eseguire il file 4 volte.

Per applicarlo alla nostra macchina attuale, $ cd /vagrant/production. Aggiungi tutto a git eseguendo $ git add * quindi $ git commit -m "aggiungi le configurazioni cron" e infine $ git push. Ora vai a $ cd /etc/puppetlabs/code/environments/production/ e $ sudo git pull

Ora se controlliamo la cartella manifest in questa directory, dovresti vedere il puppet_exec.pp creato come abbiamo appena definito.

Ora, se eseguiamo $ sudo puppet apply manifests/ e controlliamo se i file exec-puppet sono stati creati $ cat /usr/local/bin/exec-puppet

Il contenuto di questo file dovrebbe essere 

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

A questo punto abbiamo visto come possiamo eseguire il pull e il push delle modifiche alla nostra macchina master che dovrebbero essere applicate a tutti gli altri nodi. Se eseguiamo $ sudo crontab -l, alcuni avvisi importanti vengono evidenziati sul file exec-puppet creato.

# 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

Configurazione delle macchine

Diciamo che il nostro file Vagrant assomiglia a

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

In questo caso abbiamo la macchina dei pupazzi dove abbiamo fatto le nostre configurazioni e poi la macchina del db. Ora dobbiamo automatizzare la macchina in modo tale che ogni volta che la macchina db viene avviata, ha il puppet già installato e il file cron già disponibile per estrarre i manifesti e applicarli di conseguenza. Dovrai ristrutturare il contenuto della macchina db in modo che sia il seguente

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

Fino a questa fase, la struttura della directory dei pupazzi dovrebbe essere simile a questa

Se ora esegui la macchina db con il comando $ vagrant up db, alcune delle risorse verranno installate e il lo script che abbiamo appena definito può essere trovato nella directory production/manifests. Si consiglia comunque di utilizzare il burattinaio che è vincolato a soli 10 nodi per la versione gratuita altrimenti sarà necessario sottoscrivere un piano. Puppet Master offre più funzionalità e distribuisce manifest a più nodi, report log e maggiore controllo sui nodi.

Modulo pupazzo Mongodb

Questo modulo viene utilizzato nell'installazione di MongoDB, gestendo l'installazione del server mongod, la configurazione del demone mongod e la gestione dell'impostazione di Ops Manager oltre al demone MongoDB-mms.

Conclusione

Nel prossimo blog ti mostreremo come distribuire un MongoDB Replica Set e Shard usando Puppet.