MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Um guia para implantação e manutenção do MongoDB usando Puppet:Parte 2


No blog anterior, mostramos como configurar nossa máquina com o Puppet e depois instalar e configurar o MongoDB. Como vamos configurar vários nós, ou melhor, máquinas, precisamos de um mestre de marionetes. No nosso caso, porém, criaremos um repositório git onde enviaremos nossos manifestos e os aplicaremos às nossas máquinas.

Para criar um repositório git local, primeiro selecione o caminho que deseja usar, ou seja, /opt/. Em seguida, crie o repositório git executando  $sudo mkdir repository. Obtenha permissão de usuário root para alterar o conteúdo deste diretório emitindo o comando  $sudo chown vagrant:vagrant repository. Para inicializar este diretório como um repositório git depois de emitir o comando $ cd repository , execute $ git init --bare --shared se você navegar para este diretório, agora deve 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 é a estrutura básica de um repositório git e as opções --bare e --share nos permitirão enviar e extrair arquivos do diretório.

Precisamos configurar um sistema que permita a comunicação entre as máquinas envolvidas e este servidor mestre remoto. O sistema neste caso será referido como um daemon. O daemon aceitará solicitações de hosts remotos para extrair ou enviar arquivos para este repositório. Para fazer isso, execute o comando $git daemon --reuseaddr --base-path=/opt/ --export-all --enable=receive-pack

No entanto, a boa prática será criar um arquivo a partir do qual possamos executá-lo em segundo plano. Portanto, precisamos definir o serviço emitindo o comando sudo vim /etc/systemd/system/gitd. serviço. No novo arquivo preencha-o com este conteúdo

[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

Salve o arquivo e saia pressionando , digite :xe pressione . Para iniciar o servidor execute o comando $ systemctl start gitd. Para a autenticação use a senha que definimos neste caso vagrant. Você deve ser presenteado com algo assim

[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

Agora, se executarmos $ git clone git://198.168.1.100/repository (lembre-se de alterar o endereço IP com o IP de rede da sua máquina) no diretório raiz, você obterá uma pasta de repositório recém-criada . Lembre-se de configurar suas credenciais descomentando o e-mail e a senha no arquivo de configuração. Execute $ git config --global --edit para acessar este arquivo.

Este repositório atuará como nosso servidor central para todos os manifestos e variáveis.

Configurando o ambiente

Agora precisamos configurar o ambiente a partir do qual configuraremos os nós. Primeiro, mude para o diretório vagrant e clone o repositório que acabamos de criar com o mesmo comando acima.

 Remova o diretório de manifesto na pasta vagrant executando $rm -r manifest/.

Crie uma nova pasta de produção com $ mkdir production e clone o mesmo repositório que criamos acima com $ git clone git://198.168.1.100/repository . (não esqueça do ponto no final)

 Copie e cole o conteúdo do ambiente de produção puppetlabs nesta pasta de produção emitindo cp -pr /etc/puppetlabs/code/environments/production/* . Seu diretório de produção agora deve ficar assim

[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

Precisamos enviar essas alterações para o repositório raiz para executarmos
$ git add * && git commit -m "adding production default files" && git push

Para testar se a configuração do git está funcionando, podemos deletar o conteúdo no diretório /etc/puppetlabs/code/environments/production/ executando $ sudo rm -r * neste diretório e depois puxar os arquivos do repositório mestre como usuário root, ou seja, $ git clone git://198.168.1.100/repository . (não se esqueça do ponto no final). Somente diretórios com conteúdo são puxados neste caso, então você pode perder as pastas de manifestos e módulos. Essas operações podem ser realizadas em todas as máquinas envolvidas, seja uma marionete mestre ou uma máquina cliente. Portanto, nossas tarefas serão extrair as alterações do servidor principal e aplicar as alterações usando os manifestos.

Manifesto de Execução

Este é o script que vamos escrever para nos ajudar a extrair as alterações e aplicá-las automaticamente em nossos outros nós. Além de usar o ambiente de produção, você pode adicionar o maior número possível de ambientes e ditar a marionete de qual pesquisa. No diretório raiz  production/manifests, criaremos o manifesto de execução como puppet_exec.pp e o preencheremos com o seguinte conteúdo

 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'

}

Arquivo é um recurso que foi descrito para executar os manifestos de marionetes. Adicione um caminho apropriado para o arquivo que estamos criando e preencha-o com os comandos que devem ser emitidos quando ele for executado.

Os comandos são executados sistematicamente, ou seja, primeiro navegamos para o ambiente de produção, extraímos as alterações do repositório e depois as aplicamos na máquina.

Nós fornecemos o diretório de manifestos para cada nó a partir do qual ele pode selecionar o manifesto direcionado a ele para aplicação.

Uma duração na qual o arquivo de execução deve ser executado também é definida. Neste caso, a cada hora, execute o arquivo 4 vezes.

Para aplicar isso à nossa máquina atual, $ cd /vagrant/production. Adicione tudo ao git executando $ git add * então $ git commit -m “adicionar as configurações do cron” e por último $ git push. Agora navegue até $ cd /etc/puppetlabs/code/environments/production/ e $ sudo git pull

Agora, se verificarmos a pasta manifests neste diretório, você verá o puppet_exec.pp criado como acabamos de definir.

Agora, se executarmos $ sudo puppet apply manifests/ e verificar se os arquivos exec-puppet foram criados $ cat /usr/local/bin/exec-puppet

O conteúdo deste arquivo deve ser

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

Neste ponto, vimos como podemos fazer pull e push de alterações em nossa máquina mestre, que devem ser aplicadas a todos os outros nós. Se executarmos $ sudo crontab -l, alguns avisos importantes serão destacados no arquivo exec-puppet criado.

# 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

Configurando as Máquinas

Digamos que nosso arquivo vagrant se pareça com

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

Neste caso temos a máquina de marionetes onde estamos fazendo nossas configurações e depois a máquina de banco de dados. Agora vamos automatizar a máquina de tal forma que sempre que a máquina db for iniciada, ela já tenha o fantoche instalado e o arquivo cron já disponível para puxar os manifestos e aplicá-los de acordo. Você precisará reestruturar o conteúdo da máquina db para ser o seguinte

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

Até este estágio, a estrutura do seu diretório de marionetes deve ser algo assim

Se agora você executar a máquina db com o comando $ vagrant up db, alguns dos recursos serão instalados e o O script que acabamos de definir pode ser encontrado no diretório production/manifests. No entanto, é aconselhável usar o mestre de marionetes, que é restrito a apenas 10 nós para a versão gratuita, caso contrário, você precisará assinar um plano. O Puppet master oferece mais recursos e distribuição de manifestos para vários nós, relatórios de logs e mais controle sobre os nós.

Módulo de Marionetes Mongodb

Este módulo é usado na instalação do MongoDB, gerenciando a instalação do servidor mongod, configuração do daemon mongod e gerenciamento da configuração do Ops Manager além do daemon MongoDB-mms.

Conclusão

No próximo blog, mostraremos como implantar um conjunto de réplicas e fragmentos do MongoDB usando o Puppet.