Puppet
NOTA: A curva aprendizado do Puppet é maior do que outras tecnologias com o mesmo potencial . Neste caso, a comunidade Fedora está migrando de Puppet para Ansible. Consulte a documentação migrated.
Introdução
Puppet é um sistema de gerenciamento de configurações atualmente avaliado pela Fedora para sua infraestrutura. Esta página descreve sua implementação e, embora seja específica para o Fedora, é uma configuração padrão e deve ser aplicável à maioria dos ambientes.
Veja também o SOP
Arquivos Importantes / Localizações
Puppet Master (server):
- /etc/puppet - Informações básicas de configuração do Puppet
- /etc/puppet/manifests - Mapeamento de configuração do node
- /etc/puppet/manifests/filetypes/* - Várias definições de tipo de arquivo
- /etc/puppet/manifests/nodes/* - Lista de servidores e quais classes[1] usam
- /etc/puppet/manifests/server-groups - Serviços de mapas com um tipo de servidor
- /etc/puppet/manifests/service-types - Contém cada serviço e o que é necessário para esse serviço
- /etc/puppet/manifests/site.pp - Contém o arquivo de configuração 'root' que inclui outros arquivos de configuração
- /var/lib/puppet/ - Arquivos Puppet
- /var/lib/puppet/config - Arquivos de configuração para nodes atuais (eg httpd.conf)
- /etc/lib/puppet/bucket - Backup de arquivos de configuração sobrepostos
Puppet client
- /etc/puppet - Informações básicas de configuração
- /etc/sysconfig/puppet - Definições de inicialização do Puppet
Puppet CVS
- /cvs/puppet - puppet cvs
- /cvs/private - Private information (keys, passwords, etc)
[1] No Puppet, as classes são semelhantes aos templates. Isto é, uma classe pode conter outra classe. Em nosso caso, por exemplo, vamos tomar um account system (sistema de contas). Nos servidores proxy, exigimos uma seção de configuração para ProxyPass/accounts/ para os servidores de aplicativos. Esse account system está em uma classe que herda propriedades da classe http. A classe http exige que o httpd seja instalado e o tipo de arquivo de configuração que estamos usando, no caso o apacheconfig, exige que o httpd seja reiniciado sempre que um arquivo de configuração for implantado. Esta classe de sistema de contas é, por sua vez, colocada na classe proxy. Em seguida, proxy1 e o proxy2 usam a classe "proxy", que contém a classe account, que contém a classe httpd. Dê uma olhada nos arquivos de configuração para ver isso em ação.
Configuração do Node
O node neste contexto refere-se a um servidor que desejamos gerenciar com o Puppet e não o servidor masterdo Puppet. Para os propósitos deste exemplo, usaremos um novo servidor "proxy3".
- Construa o proxy3
- Instale o ruby
- Instale o facter e o puppet a partir do EPEL
- Modifique o /etc/sysconfig/puppet: PUPPET_SERVER=puppet
- chkconfig puppet on
- /etc/init.d/puppet start
Isso fará com que o Puppet seja iniciado e entre em contato com puppet1 para obter uma lista de arquivos. Isso também enviará uma solicitação de certificado para o servidor. Neste momento, não são alterados os arquivos de configuração. Isso ocorre porque o puppet1 tem que dar acesso ao proxy 3.
Para permitir que o servidor faça logon para puppet1 e execute puppetca:
proxy3.fedora.phx.redhat.com Signed: proxy3.fedora.phx.redhat.com
Agora loggue no puppet1 e adicione o proxy3 em /etc/puppet/manifests/nodes/proxy3.fedora.phx.redhat.com.pp
Feito isso, a comunicação entre o node e o servidor estará pronta.
Server Side
O server side os things já está configurado. Consulte os Files/Locations Importantes acima para obter mais detalhes sobre onde estão os arquivos de configuração. Na nossa configuração, mudamos de um modelo de gerenciamento centrado no servidor para um modelo centrado no serviço. Isso foi feito para facilitar o gerenciamento. Por exemplo, o Fedora Account System contém algumas demandas em vários servidores. No sistema de configuração anterior, vários arquivos de vários grupos de servidores e a relação entre eles não eram claros. Nesta nova configuração, temos um arquivo no diretório de grupos de serviços que contém as configurações de proxy, configurações de aplicativos e configurações de db.
Adding a file
There's a few steps to actually adding a file to puppet.
- Check out the current configuration
- Add configuation file
- Add the manifest config (tell puppet where your file should end up and what type of file it is)
- commit the files
- Run "make install" in the config directory and "make install" in the manifests directory.
- Verify new file on the client
Adding new files is easy, stick them in /var/lib/puppet/config/ somewhere that makes sense, for example all the web files are in ./web/ Once that is done you need to add your file to /etc/puppet/manifests/service-groups/. In this example we'll be discussing nagios (not yet implemented but will be soon).
class nagios {
package { nagios:
}
nagiosfile { '/etc/nagios/':
source => "nagios/",
ensure => directory,
recurse => true
service { nagios:
ensure => true,
subscribe => [ package["nagios"]
}
}
class nagios-proxy inherits httpd {
apachefile { "/etc/httpd/conf.d/admin.fedoraproject.org/nagios.conf":
source => "web/nagios-proxy.conf"
}
}
There are 3 classes here. The first one defines a generic nagios class. It's used to make sure that anything that inherits it requires nagios to be installed and so it restarts nagios when a config file is changed. Next is the nagios-proxy file which inherits httpd (defined in a different config file). By inheriting httpd we're saying that wherever the nagios-proxy files get installed, that box will also need to have http. By specifying apachefile, we're telling puppet to restart httpd if the config has changed. We do the same thing with "nagiosfile" which is defined in /etc/puppet/manifests/filetypes. An example would be:
define nagiosfile(owner = root, group = nagios, mode = 664, source,
backup = main, recurse = false, ensure = file) {
file { $name:
mode => $mode,
owner => $owner,
group => $group,
backup => $backup,
recurse => $recurse,
notify => service[nagios] ,
ensure => $ensure,
source => "puppet://$server/config/$source"
}
}
The notify=>service[nagios] means that whenever a configfile of type "nagiosfile" is deployed, the service nagios is restarted.
From this point on you can specify which nodes include which classes. The proxy servers would include "nagios-proxy" where the actual nagios server would include "nagios".
To check if your changes are syntatically correct you can restart puppet master with:
service puppetmaster restart
The client checks in every half hour. If you want to immediately check your changes just run:
/etc/init.d/puppet restart; tail -f /var/log/messages