Latest revision as of 00:09, 6 March 2018

File:Infrastructure InfrastructureTeamN1.png

In other languages: English (en) português do Brasil (pt-br) [edit]

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.

Adicionando um arquivo

Há alguns passos recomendados para adicionar um arquivo no puppet. Por exemplo:

Confira a configuração atual
Adicione o arquivo de configuração
Adicione a configuração do manifests (diga ao Puppet onde seu arquivo deve terminar e que tipo de arquivo é)
confirme os arquivos
Execute "make install" no diretório de configuração e "make install" no diretório do manifests.
Verifique o novo arquivo no cliente

Adicionar novos arquivos é fácil, basta coloca-los em /var/lib/ puppet/config/ em algum lugar que faça sentido, por exemplo, todos os arquivos da web estão em ./web/ . Uma vez feito isso, você precisará adicionar seu arquivo em /etc/puppet /manifests/service-group . Neste exemplo, estaremos discutindo o nagios (ainda não implementado, mas será em breve).

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"
}
}

Existem aqui 3 classes. A primeira define uma classe genérica do nagios. É usado para certificar-se de que qualquer coisa que seja herdada exigirá que nagios seja instalado e, assim, reiniciará o nagios quando um arquivo de configuração for alterado. Em seguida, o arquivo nagios-proxy herda o httpd (definido em um arquivo de configuração diferente). Ao herdar o httpd, estamos dizendo que, sempre que os arquivos nagios-proxy for instalado, também precisará ter o http. Ao especificar o arquivo apache, estamos dizendo ao Puppet para reiniciar o httpd se a configuração tiver mudado. Fazemos o mesmo com "nagiosfile", que é definido em /etc/puppet/manifests/filetypes. Um exemplo seria:

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] significa que sempre que um configfile do tipo "nagiosfile" for implantado, o serviço nagios será reiniciado.

A partir deste ponto você pode especificar quais os nodes incluem quais classes. Os servidores proxy incluem "nagios-proxy", onde o servidor nagios real incluiria "nagios".

Para verificar se suas alterações estão sintaticamente corretas, você poderá reiniciar o Puppet master com:

service puppetmaster restart

O cliente verifica a cada meia hora. Se você deseja verificar imediatamente as alterações, apenas execute:

/etc/init.d/puppet restart; tail -f /var/log/messages

@@ Line 1: / Line 1: @@
 {{header|infra}}
+{{lang|en|pt-br|page=Puppet}}
 = 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 [[Infrastructure/PuppetToAnsibleMigration | migrated]].
-== Introduction ==
+== Introdução ==
-Puppet is a configuration management system currently being evaluated by Fedora for its infrastructure.  This page describes its implementation and while it is specific to Fedora it is a fairly standard setup and should be applicable to most environments.
+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.
-Also see [[Infrastructure/SOP/Puppet|SOP]]
+Veja também o [[Infrastructure/SOP/Puppet|SOP]]
-== Important Files / Locations ==
+== Arquivos Importantes / Localizações ==
 Puppet Master (server):
-* /etc/puppet - Basic puppet configuration information
+* /etc/puppet - Informações básicas de configuração do Puppet
-* /etc/puppet/manifests - node config mappings
+* /etc/puppet/manifests - Mapeamento de configuração do node
-* /etc/puppet/manifests/filetypes/* - Various filetype definitions
+* /etc/puppet/manifests/filetypes/* - Várias definições de tipo de arquivo
-* /etc/puppet/manifests/nodes/* - Server lists and what classes[1]  they use
+* /etc/puppet/manifests/nodes/* - Lista de servidores e quais classes[1] usam
-* /etc/puppet/manifests/server-groups - Maps services with a server type
+* /etc/puppet/manifests/server-groups - Serviços de mapas com um tipo de servidor
-* /etc/puppet/manifests/service-types - Contains each service and whats required for that service
+* /etc/puppet/manifests/service-types - Contém cada serviço e o que é necessário para esse serviço
-* /etc/puppet/manifests/site.pp - Contains the 'root' config file which includes other config files
+* /etc/puppet/manifests/site.pp - Contém o arquivo de configuração 'root' que inclui outros arquivos de configuração
-* /var/lib/puppet/ - Puppet files
+* /var/lib/puppet/ - Arquivos Puppet
-* /var/lib/puppet/config - Config files for our actual nodes (eg httpd.conf)
+* /var/lib/puppet/config - Arquivos de configuração para nodes atuais (eg httpd.conf)
-* /etc/lib/puppet/bucket - Backup of overwritten config files
+* /etc/lib/puppet/bucket - Backup de arquivos de configuração sobrepostos
 Puppet client
-* /etc/puppet - Basic configuration information
+* /etc/puppet - Informações básicas de configuração
-* /etc/sysconfig/puppet - Puppet startup definitions
+* /etc/sysconfig/puppet - Definições de inicialização do Puppet
 Puppet CVS
@@ Line 29: / Line 31: @@
 * /cvs/private - Private information (keys, passwords, etc)
-[1]  In puppet classes are similar to templates.  A class can contain another class.  In our case, for example, we'll take the account system.  On the proxy servers we require a config section to ProxyPass /accounts/ to the app servers.  This account system is in a class which inherits properties from the http class.  The http class requires that httpd be installed and the config file type we're using, apacheconfig, requires httpd to be restarted whenever a config file is deployed.  This account system class is, in turn, placed in the proxy class.  Then proxy1 and proxy2 use the "proxy" class, which contains the account class, which contains the httpd class.  Take a look at the config files to see this in action.
+[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.
-== Node Setup ==
+== Configuração do Node ==
-Node in this context refers to a server we wish to manage with puppet not the puppet master server.  For the purposes of this example we'll use a new server "proxy3".
+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".
-# Build proxy3
+# Construa o proxy3
-# Install ruby
+# Instale o ruby
-# Install facter and puppet from EPEL
+# Instale o facter e o puppet a partir do EPEL
-# Alter /etc/sysconfig/puppet: PUPPET_SERVER=puppet
+# Modifique o /etc/sysconfig/puppet: PUPPET_SERVER=puppet
 # chkconfig puppet on
 # /etc/init.d/puppet start
-This will cause puppet to start up and contact puppet1 for a list of files.  This will also send a certificate request to the server.  At this point in time NO CONFIG FILES ARE CHANGED.  This is because puppet1 has to give access to proxy 3.
+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.
-To allow the server log in to puppet1 and run puppetca:
+Para permitir que o servidor faça logon para puppet1 e execute puppetca:
 <pre>
 proxy3.fedora.phx.redhat.com
@@ Line 49: / Line 51: @@
 </pre>
-Next log in to puppet1 and add proxy3 to /etc/puppet/manifests/nodes/proxy3.fedora.phx.redhat.com.pp
+Agora loggue  no puppet1 e adicione o proxy3 em /etc/puppet/manifests/nodes/proxy3.fedora.phx.redhat.com.pp
-Once this is done communcation between the node and the server should be ready.
+Feito isso, a comunicação entre o node e o servidor estará pronta.
 == Server Side ==
-The server side of things is already configured.  Please see the Important Files / Locations above for more details about where configuration files are.  In our setup we have changed from a server centric management model to a service centric model.  This was done for ease of management.  For example, the Fedora Account System contains a few needs on multiple servers.  It has proxy pass on the front servers, applications on the app server and a database to poll.  In the previous configuration system this ment multiple files in multiple server groups and the relationship between them was unclear.  In this new setup we have one file in the service-groups directory which contains the proxy configs, app configs and db configs.
+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 ==
+== Adicionando um arquivo ==
-There's a few steps to actually adding a file to puppet.
-# Check out the current configuration
+Há alguns passos recomendados para adicionar um arquivo no puppet. Por exemplo:
-# 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).
+# Confira a configuração atual
+# Adicione o arquivo de configuração
+# Adicione a configuração do manifests (diga ao Puppet onde seu arquivo deve terminar e que tipo de arquivo é)
+# confirme os arquivos
+# Execute "make install" no diretório de configuração e "make install" no diretório do manifests.
+# Verifique o novo arquivo no cliente
+Adicionar novos arquivos é fácil, basta coloca-los em /var/lib/ puppet/config/ em algum lugar que faça sentido, por exemplo, todos os arquivos da web estão em ./web/ . Uma vez feito isso, você precisará adicionar seu arquivo em  /etc/puppet /manifests/service-group . Neste exemplo, estaremos discutindo o nagios (ainda não implementado, mas será em breve).
 <pre>
@@ Line 77: / Line 80: @@
 ensure => directory,
 recurse => true
 service { nagios:
@@ Line 92: / Line 94: @@
 </pre>
-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:
+Existem aqui 3 classes. A primeira define uma classe genérica do nagios. É usado para certificar-se de que qualquer coisa que seja herdada exigirá que nagios seja instalado e, assim, reiniciará o nagios quando um arquivo de configuração for alterado. Em seguida, o arquivo nagios-proxy herda o httpd (definido em um arquivo de configuração diferente). Ao herdar o httpd, estamos dizendo que, sempre que os arquivos nagios-proxy for instalado, também precisará ter o http. Ao especificar o arquivo apache, estamos dizendo ao Puppet para reiniciar o httpd se a configuração tiver mudado. Fazemos o mesmo com "nagiosfile", que é definido em /etc/puppet/manifests/filetypes. Um exemplo seria:
 <pre>
@@ Line 110: / Line 112: @@
 </pre>
-The notify=>service[nagios]  means that whenever a configfile of type "nagiosfile" is deployed, the service nagios is restarted.
+The notify=>service[nagios]  significa que sempre que um configfile do tipo "nagiosfile" for implantado, o serviço nagios será reiniciado.
-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".
+A partir deste ponto você pode especificar quais os nodes incluem quais classes. Os servidores proxy incluem "nagios-proxy", onde o servidor nagios real incluiria "nagios".
-To check if your changes are syntatically correct you can restart puppet master with:
+Para verificar se suas alterações estão sintaticamente corretas, você poderá reiniciar o Puppet master com:
 <pre>
@@ Line 120: / Line 122: @@
 </pre>
-The client checks in every half hour.  If you want to immediately check your changes just run:
+O cliente verifica a cada meia hora. Se você deseja verificar imediatamente as alterações, apenas execute:
 <pre>
@@ Line 127: / Line 129: @@
 [[Category:Infrastructure]]
+[[Category:Brazilian translations]]

Search

Infrastructure/Puppet: Difference between revisions