MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Ein Leitfaden für die Bereitstellung und Wartung von MongoDB mit Puppet:Teil 2

Im vorherigen Blog haben wir Ihnen gezeigt, wie Sie unsere Maschine mit Puppet einrichten und dann MongoDB installieren und konfigurieren. Da wir eine Reihe von Knoten bzw. Maschinen konfigurieren werden, brauchen wir einen Puppenspieler. In unserem Fall erstellen wir jedoch ein Git-Repository, in das wir unsere Manifeste pushen und auf unsere Maschinen anwenden.

Um ein lokales Git-Repository zu erstellen, wählen Sie zuerst den Pfad aus, den Sie verwenden möchten, z. B. /opt/. Erstellen Sie dann ein Git-Repository, indem Sie $sudo mkdir repository ausführen. Holen Sie sich die Root-Benutzerberechtigung, um den Inhalt dieses Verzeichnisses zu ändern, indem Sie den Befehl  $sudo chown vagrant:vagrant repository ausgeben. Um dieses Verzeichnis als Git-Repository zu initialisieren, nachdem Sie den Befehl $ cd repository ausgegeben haben, führen Sie $ git init --bare --shared aus. Wenn Sie zu diesem Verzeichnis navigieren, sollten Sie jetzt so etwas wie

sehen 
[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

Dies ist die Grundstruktur eines Git-Repositorys und die Optionen --bare und --share ermöglichen es uns, Dateien aus dem Verzeichnis zu pushen und zu pullen.

Wir müssen ein System einrichten, das die Kommunikation zwischen den beteiligten Maschinen und diesem Remote-Master-Server ermöglicht. Das System wird in diesem Fall als Daemon bezeichnet. Der Daemon akzeptiert Anfragen von Remote-Hosts, um Dateien entweder in dieses Repository zu ziehen oder zu verschieben. Führen Sie dazu den Befehl $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

aus

Es empfiehlt sich jedoch, eine Datei zu erstellen, von der aus wir dies im Hintergrund ausführen können. Wir müssen daher den Dienst einrichten, indem wir den Befehl sudo vim /etc/systemd/system/gitd ausführen. Service. Füllen Sie die neue Datei mit diesen Inhalten auf

[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

Speichern Sie die Datei und verlassen Sie sie, indem Sie drücken, geben Sie dann :x ein und drücken Sie . Führen Sie zum Starten des Servers den Befehl $ systemctl start gitd aus. Verwenden Sie für die Authentifizierung das von uns in diesem Fall festgelegte Passwort vagrant. Ihnen sollte so etwas angezeigt werden 

[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

Wenn wir nun $ git clone git://198.168.1.100/repository (denken Sie daran, die IP-Adresse mit der Netzwerk-IP Ihres Rechners zu ändern) im Root-Verzeichnis ausführen, erhalten Sie einen neu erstellten Repository-Ordner . Denken Sie daran, Ihre Anmeldeinformationen zu konfigurieren, indem Sie die E-Mail-Adresse und das Passwort in der Konfigurationsdatei auskommentieren. Führen Sie $ git config --global --edit aus, um auf diese Datei zuzugreifen.

Dieses Repository fungiert als unser zentraler Server für alle Manifeste und Variablen.

Umgebung einrichten

Wir müssen jetzt die Umgebung einrichten, von der aus wir die Knoten konfigurieren werden. Wechseln Sie zunächst in das Vagrant-Verzeichnis und klonen Sie das gerade erstellte Repository mit demselben Befehl wie oben.

 Entfernen Sie das Manifestverzeichnis im Vagrant-Ordner, indem Sie $rm -r manifest/ ausführen.

Erstellen Sie einen neuen Produktionsordner mit $ mkdir production und klonen Sie dasselbe Repository, das wir oben erstellt haben, mit $ git clone git://198.168.1.100/repository . (den Punkt am Ende nicht vergessen)

 Kopieren Sie den Inhalt der puppetlabs-Produktionsumgebung und fügen Sie ihn in diesen Produktionsordner ein, indem Sie cp -pr /etc/puppetlabs/code/environments/production/* ausgeben. Ihr Produktionsverzeichnis sollte nun so aussehen

[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

Wir müssen diese Änderungen in das Root-Repository übertragen, damit wir 

ausführen können 
$ git add * && git commit -m "adding production default files" && git push

Um zu testen, ob die Git-Konfiguration funktioniert, können wir den Inhalt im Verzeichnis /etc/puppetlabs/code/environments/production/ löschen, indem wir $ sudo rm -r * in diesem Verzeichnis ausführen und dann pullen die Dateien aus dem Master-Repository als Root-Benutzer, dh $ git clone git://198.168.1.100/repository . (den Punkt am Ende nicht vergessen). In diesem Fall werden nur Verzeichnisse mit Inhalten abgerufen, sodass Sie möglicherweise die Ordner „Manifeste“ und „Module“ übersehen. Diese Vorgänge können auf allen beteiligten Computern ausgeführt werden, entweder Master-Puppe oder Client-Computer. Unsere Aufgaben werden also darin bestehen, die Änderungen vom Hauptserver abzurufen und die Änderungen mithilfe der Manifeste anzuwenden.

Ausführungsmanifest

Dies ist das Skript, das wir schreiben werden, um uns dabei zu helfen, Änderungen zu ziehen und sie automatisch auf unsere anderen Knoten anzuwenden. Sie müssen nicht nur die Produktionsumgebung verwenden, Sie können so viele Umgebungen wie möglich hinzufügen und dann Puppet diktieren, in der gesucht werden soll. Im Stammverzeichnis  production/manifests erstellen wir das Ausführungsmanifest als puppet_exec.pp und füllen es mit den folgenden Inhalten

 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'

}

Datei ist eine Ressource, die beschrieben wurde, um die Puppet-Manifeste auszuführen. Fügen Sie einen geeigneten Pfad für die Datei hinzu, die wir erstellen, und füllen Sie sie mit den Befehlen, die ausgegeben werden sollen, wenn sie ausgeführt wird.

Die Befehle werden systematisch ausgeführt, das heißt, wir navigieren zuerst zur Produktionsumgebung, ziehen die Repository-Änderungen und wenden sie dann auf die Maschine an.

Wir liefern das Manifest-Verzeichnis an jeden Knoten, aus dem er das an ihn gerichtete Manifest zur Anwendung auswählen kann.

Eine Dauer, über die die Ausführungsdatei ausgeführt werden soll, wird ebenfalls festgelegt. Führen Sie in diesem Fall die Datei jede Stunde viermal aus.

Um dies auf unsere aktuelle Maschine anzuwenden, $ cd /vagrant/production. Fügen Sie alles zu git hinzu, indem Sie $ git add *, dann $ git commit -m „add the cron configurations“ und schließlich $ git push ausführen. Navigieren Sie nun zu $ ​​cd /etc/puppetlabs/code/environments/production/ und $ sudo git pull

Wenn wir nun den Manifest-Ordner in diesem Verzeichnis überprüfen, sollten Sie die puppet_exec.pp sehen, die so erstellt wurde, wie wir sie gerade definiert hatten.

Wenn wir jetzt $ sudo puppet apply manifests/ ausführen und überprüfen, ob die Dateien exec-puppet erstellt wurden $ cat /usr/local/bin/exec-puppet

Der Inhalt dieser Datei sollte 

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

An diesem Punkt haben wir gesehen, wie wir Änderungen per Pull und Push auf unseren Master-Rechner übertragen können, die auf alle anderen Knoten angewendet werden sollten. Wenn wir $ sudo crontab -l ausführen, werden einige wichtige Warnungen in der erstellten exec-puppet-Datei hervorgehoben.

# 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

Maschinen konfigurieren

Nehmen wir an, unsere Vagrant-Datei sieht so aus

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 diesem Fall haben wir die Puppet-Maschine, auf der wir unsere Konfigurationen vorgenommen haben, und dann die DB-Maschine. Jetzt automatisieren wir die Maschine so, dass jedes Mal, wenn die db-Maschine gestartet wird, Puppet bereits installiert und die Cron-Datei bereits verfügbar ist, um die Manifeste abzurufen und sie entsprechend anzuwenden. Sie müssen den Inhalt der db-Maschine wie folgt neu strukturieren

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

Bis zu diesem Stadium sollte die Struktur Ihres Puppet-Verzeichnisses ungefähr so ​​aussehen

Wenn Sie jetzt die db-Maschine mit dem Befehl $ vagrant up db ausführen, werden einige der Ressourcen installiert und die Das gerade definierte Skript befindet sich im Verzeichnis production/manifests. Es ist jedoch ratsam, den Puppet Master zu verwenden, der für die kostenlose Version auf nur 10 Knoten beschränkt ist, andernfalls müssen Sie einen Plan abonnieren. Puppet Master bietet mehr Funktionen und verteilt Manifeste an mehrere Knoten, meldet Protokolle und mehr Kontrolle über die Knoten.

Mongodb-Marionettenmodul

Dieses Modul wird bei der Installation von MongoDB, der Verwaltung der Installation des Mongod-Servers, der Konfiguration des Mongod-Daemons und der Verwaltung des Ops Manager-Setups neben dem MongoDB-mms-Daemon verwendet.

Schlussfolgerung

Im nächsten Blog zeigen wir Ihnen, wie Sie ein MongoDB Replica Set und Shards mit Puppet bereitstellen.