diff options
author | Silvio Rhatto <rhatto@riseup.net> | 2015-03-20 11:26:16 -0300 |
---|---|---|
committer | Silvio Rhatto <rhatto@riseup.net> | 2015-03-20 11:26:16 -0300 |
commit | 99eb59e02948c77c27d68e31cc7765ddd547c3be (patch) | |
tree | 9593fdf6dd3280e2da575bbe4af9b57dec03cfbe /puppet | |
parent | 9f76b1c27dfd27985675a131c0f19820c8c40c0b (diff) | |
download | padrao-99eb59e02948c77c27d68e31cc7765ddd547c3be.tar.gz padrao-99eb59e02948c77c27d68e31cc7765ddd547c3be.tar.bz2 |
Sobre novos puppetmasters
Diffstat (limited to 'puppet')
-rw-r--r-- | puppet/master.mdwn | 74 |
1 files changed, 74 insertions, 0 deletions
diff --git a/puppet/master.mdwn b/puppet/master.mdwn new file mode 100644 index 0000000..1a44775 --- /dev/null +++ b/puppet/master.mdwn @@ -0,0 +1,74 @@ +Configurando um master +====================== + +Procedimento para configurar um novo master e eventualmente assumi-lo como o +master principal da rede. + +Deploy do nodo +-------------- + +* Assumiremos `$old` como o hostname do master antigo. +* Nós usaremos o master `$old` para configurar o master `$node`. +* Assim, siga as [instruções para adicionar um nodo](/nodo), levando em conta: + * Inicialmente, a configuração do nodo com `nodo::role::master::main: false`. + * Se o nodo for assumir o papel de um master principal, use `nodo::role::master::main: true` + após a aplicação do primeiro catálogo. + +Mudança de porta +---------------- + +Em alguns casos -- dependendo de onde o novo master for hospedado --, pode ser necessário +usar uma porta fora do padrão para o `puppetmaster`. + +No caso de mudança de portas do puppetmaster, comunicar essa mudança aos nodos +via `puppet::daemon::port` e aguardar aplicação de catálogo de todos os nodos. + +Mudança do DNS +-------------- + +Esta etapa consiste em fazer a atualização do DNS, para que os nodos acessando `puppet.$domain` +caiam direto no novo master. Use a seguinte configuração na interface de atualização de DNS, +substituindo `$node.$domain` pelo domínio do novo master (o ponto final é importante): + + admin 3600 IN CNAME $node.$domain. + munin 3600 IN CNAME $node.$domain. + nagios 3600 IN CNAME $node.$domain. + puppet 3600 IN CNAME $node.$domain. + +As próximas etapas podem ser executadas enquanto o DNS é propagado. + +Importação da chave de backups +------------------------------ + +Para importar a chave privada do nodo `$old` no nodo `$node`, use + + admin@box$ HOST=$old hydra $hydra import-key $node + +Restore dos backups +------------------- + +Assumindo que o backup criptografado já esteja disponível em `$node:/var/backups/remote/$old.$domain`: + + root@master$ hydractl backup-restore-master $old + +Após o restore, o nodo deverá estar pronto para assumir o papel de master. + +Atualize seu ~/.ssh/config +-------------------------- + +Exemplo de configuração pessoal, substituindo as variáveis de acordo: + + Host admin.$domain + HostName $node.$domain + Port $porta + +Assim, independentemente qual seja o nodo master atual, ele sempre estará acessível pelo alias `admin.$domain`, +evitando mudanças desnecessárias e tediosas em referências de inúmeros repositórios. + +Possíveis problemas +------------------- + +As seguintes mensagens de erro podem aparecer no novo master depois de sua ativação: + +* "You cannot collect without storeconfigs being set": o problema tende a desaparecer conforme os exported resources forem sendo definidos. +* [Collected resources with a puppet master fail on Ruby 1.9.x](http://projects.puppetlabs.com/issues/10963): basta aplicar o patch manualmente. |