sql >> Base de Datos >  >> NoSQL >> MongoDB

Una guía para la implementación y el mantenimiento de MongoDB mediante Puppet:Parte 2

En el blog anterior, le mostramos cómo configurar nuestra máquina con Puppet y luego instalar y configurar MongoDB. Como vamos a configurar varios nodos o más bien máquinas, necesitamos un titiritero. Sin embargo, en nuestro caso, crearemos un  repositorio de git donde enviaremos nuestros manifiestos y los aplicaremos a nuestras máquinas.

Para crear un repositorio git local, primero seleccione la ruta que desea usar, es decir, /opt/. A continuación, cree el repositorio git ejecutando el repositorio $sudo mkdir. Obtenga permiso de usuario raíz para cambiar el contenido de este directorio emitiendo el comando  $sudo chown vagrant:vagrant repository. Para inicializar este directorio como un repositorio git después de emitir el comando $ cd repository, ejecute $ git init --bare --shared si navega a este directorio, ahora debería ver algo como

[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

Esta es la estructura básica de un repositorio git y las opciones --bare y --share nos permitirán enviar y extraer archivos del directorio.

Necesitamos configurar un sistema que permita la comunicación entre las máquinas involucradas y este servidor maestro remoto. En este caso, el sistema se denominará demonio. El daemon aceptará solicitudes de hosts remotos para extraer o enviar archivos a este repositorio. Para hacerlo, emita el comando $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

Sin embargo, la buena práctica será crear un archivo desde el cual podamos ejecutar esto en segundo plano. Por lo tanto, debemos configurar el servicio emitiendo el comando sudo vim /etc/systemd/system/gitd. Servicio. En el nuevo archivo, rellénelo con estos contenidos

[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

Guarde el archivo y salga presionando , luego escriba :x y presione . Para iniciar el servidor, ejecute el comando $ systemctl start gitd. Para la autenticación use la contraseña que establecimos en este caso vagabundo. Deberías ver algo como esto 

[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

Ahora, si ejecutamos $ git clone git://198.168.1.100/repository (recuerde cambiar la dirección IP con la IP de red de su máquina) en el directorio raíz, obtendrá una carpeta de repositorio recién creada . Recuerde configurar sus credenciales descomentando el correo electrónico y la contraseña en el archivo de configuración. Ejecute $ git config --global --edit para acceder a este archivo.

Este repositorio actuará como nuestro servidor central para todos los manifiestos y variables.

Configuración del entorno

Ahora necesitamos configurar el entorno desde el cual configuraremos los nodos. Primero, cambie al directorio vagabundo y clone el repositorio que acabamos de crear con el mismo comando que arriba.

 Elimine el directorio de manifiesto en la carpeta vagabundeando ejecutando $rm -r manifest/.

Cree una nueva carpeta de producción con $ mkdir production y clone el mismo repositorio que creamos anteriormente con $ git clone git://198.168.1.100/repository . (no olvides el punto al final)

 Copie y pegue el contenido del entorno de producción de puppetlabs en esta carpeta de producción ejecutando cp -pr /etc/puppetlabs/code/environments/production/* . Su directorio de producción ahora debería verse así

[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

Necesitamos enviar estos cambios al repositorio raíz para ejecutar 

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

Para probar si la configuración de git está funcionando, podemos eliminar el contenido en el directorio /etc/puppetlabs/code/environments/production/ ejecutando $ sudo rm -r * en este directorio y luego extraer los archivos del repositorio principal como usuario raíz, es decir, $ git clone git://198.168.1.100/repository. (no olvides el punto al final). En este caso, solo se extraen los directorios con contenido, por lo que es posible que se pierda las carpetas de manifiestos y módulos. Estas operaciones se pueden llevar a cabo en todas las máquinas involucradas, ya sea la marioneta maestra o la máquina cliente. Entonces, nuestras tareas serán extraer los cambios del servidor principal y aplicar los cambios usando los manifiestos.

Manifiesto de ejecución

Este es el script que vamos a escribir para ayudarnos a generar cambios y aplicarlos automáticamente a nuestros otros nodos. No solo tiene que usar el entorno de producción, sino que puede agregar tantos entornos como sea posible y luego dictar una marioneta desde la cual buscar. En el directorio raíz producción/manifiestos, crearemos el manifiesto de ejecución como puppet_exec.pp y lo completaremos con los siguientes contenidos

 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'

}

File es un recurso que se ha descrito para ejecutar los manifiestos de marionetas. Agregue una ruta adecuada para el archivo que estamos creando y complételo con los comandos que se emitirán cuando se ejecute.

Los comandos se ejecutan sistemáticamente, es decir, primero navegamos al entorno de producción, extraemos los cambios del repositorio y luego los aplicamos a la máquina.

Suministramos el directorio de manifiestos a cada nodo desde el cual puede seleccionar el manifiesto dirigido a él para su aplicación.

También se establece una duración durante la cual se ejecutará el archivo de ejecución. En este caso por cada hora, ejecute el archivo 4 veces.

Para aplicar esto a nuestra máquina actual, $ cd /vagrant/production. Agregue todo a git ejecutando $ git add * luego $ git commit -m "agregar las configuraciones cron" y, por último, $ git push. Ahora navegue a $ cd /etc/puppetlabs/code/environments/production/ y $ sudo git pull

Ahora, si revisamos la carpeta de manifiestos en este directorio, debería ver el archivo puppet_exec.pp creado como lo acabamos de definir.

Ahora, si ejecutamos $ sudo puppet apply manifests/ y comprobamos si se han creado los archivos exec-puppet $ cat /usr/local/bin/exec-puppet

El contenido de este archivo debe ser 

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

Hasta este punto, hemos visto cómo podemos extraer y enviar cambios a nuestra máquina maestra que deben aplicarse a todos los demás nodos. Si ejecutamos $ sudo crontab -l, se resaltan algunas advertencias importantes en el archivo exec-puppet creado.

# 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

Configuración de las máquinas

Digamos que nuestro archivo vagabundo se parece 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

En este caso tenemos la máquina de marionetas donde hemos estado haciendo nuestras configuraciones y luego la máquina de base de datos. Ahora vamos a automatizar la máquina de modo que cada vez que se inicie la máquina db, ya tenga la marioneta instalada y el archivo cron ya esté disponible para extraer los manifiestos y aplicarlos en consecuencia. Deberá reestructurar el contenido de la máquina db para que quede de la siguiente manera

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

Hasta esta etapa, la estructura de su directorio de marionetas debería ser algo como esto

Si ahora ejecuta la máquina db con el comando $ vagrant up db, algunos de los recursos se instalarán y el El script que acabamos de definir se puede encontrar en el directorio production/manifests. Sin embargo, es recomendable utilizar el maestro de marionetas, que está limitado a solo 10 nodos para la versión gratuita; de lo contrario, deberá suscribirse a un plan. Puppet master ofrece más funciones y distribuye manifiestos a múltiples nodos, informes de registros y más control sobre los nodos.

Módulo de marionetas de Mongodb

Este módulo se utiliza en la instalación de MongoDB, la gestión de la instalación del servidor mongod, la configuración del demonio mongod y la gestión de la configuración de Ops Manager además del demonio MongoDB-mms.

Conclusión

En el próximo blog, le mostraremos cómo implementar un conjunto de réplicas y fragmentos de MongoDB mediante Puppet.