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