1. O documento discute a implementação de uma nova estrutura para gerenciamento de configurações usando Puppet, incluindo a separação de ambientes de desenvolvimento e produção e a organização de módulos, roles e profiles.
2. Será adotado um fluxo de trabalho com branches no Git para desenvolvimento e testes antes de implantação na produção.
3. Próximos passos incluem integrar o processo com Jenkins, implantar a estrutura proposta e estratégias de migração do Puppet legado.
2. Gerenciamento de Configurações - Puppet
Objetivos:
● Atualização da ferramenta;
● Separação dos ambientes de homolog/dev de production;
● Adequação ao padrão de mercado;
● Utilização de módulos prontos via puppetforge;
● Poucos módulos “homemade”;
● Testes automatizados nos módulos;
● Separação de dados de recursos (manifests);
● Exportação de dados para analise via puppetdb;
● Criação de pipeline para entrega em produção via jenkins.
3. Gerenciamento de Configurações - Puppet
homolog/dev production
(FS) environments =>
common/modules
development/modules
development/hostsgroup
Homolog/...
Production/...
Resources e Data juntos!!!!
SVN trunk!!!!
12. Gerenciamento de Configurações - Puppet
/etc/puppetlabs/code/environments:
$branch = production
hieradata/*.yaml
manifests/
modules/profile
modules/role
/etc/puppetlabs/code/modules/{puppetforge sources}
Role => função de negócio
Profile => regra de implantação
Modulos => classes
Hiera => data
Role e Profile são módulos do
puppet para organizar as
classes.
Nova organização do puppet:
13. Gerenciamento de Configurações - Puppet
hieradata/puppet_role/servername.yaml
- - -
puppetmaster: puppet.localdomain
classes:
include role::webserver
class role::webserver {
include profile::apache
include profile::php
include profile::certificados
}
class profile::apache {
apache::vhost { 'first.example.com':
port => '80',
docroot => '/var/www/first',
}
}
15. Gerenciamento de Configurações - Puppet
Workflow proposto:
● Branch environment.git;
● Faz todas as alterações necessárias;
● Executa o commit e push;
● Executa o deploy no puppet server;
● Testa no servidor com “environment=$branch”;
● Valida se tudo esta ok;
● Executa o merge deste $branch em $production;
● Realiza o deploy no puppet server.
17. Gerenciamento de Configurações - Puppet
Próximos passos:
● Testar a integração com o jenkins e criação de jobs;
● Implatantação da estrutura em produção;
● POC de estratégias de migração do puppet legado, 2.7 para o novo 4.2;
● Importar as primeiras classes (Puppetfile);
● Criar os primeiros profiles e roles;
● Criar workflow de entrega em produção;
Este é um ambiente legado que tinhamos na empresa, usando o svn como controle de versão e utilizando a funçao de fileserver do puppet.
Problemas como resources e data nos manifests do puppet e todos no trunk do SVN.
Aqui temos um exemplo de utilização do puppet neste ambiente legado, onde os sysadmins fazem o commit diretamente no ambiente e sem nenhum teste (apenas alguns hooks do svn), os manifests já se encontravam em produção. Mesmo com a estrutura modular do puppet, podiamos ter algum módulo com problema quebrando o catalogo tanto de servidores de desenvolvimento como servidores de produção.
Portanto, “relaxa”! Tudo irá bem. Será?
A não ser que algo quebre e coloque tudo a perder...
Nova versão do puppet e separação do ambiente de desenvolvimento de produção. Dando mais liberdade para os sysadmins atuarem sem terem receio de “quebrar” algo em produção.Nesta nova implantação, usaremos módulos do puppet forge e os dinamyc environments (com os branchs do git)
Adicionaremos o puppet-db para expandir a visibilidade além de suas outras funcionalidades, como “exported resources”.
Esta é a cara do puppet DB.
Um exemplo de informação que o puppet DB trás com um simples GET.
Outro exemplo de puppetdb.
Visualização da estrutura de diretórios do puppet e como será a função de alguns diretórios dentro do puppet. Uma recomendação é a utilização dos módulos profile e role para organização de seus manifests e aplicação das classes importadas do puppet forge.
A utilização do hiera como “guardião” da data, da informação referente aos manifests, como um IP do servidor de monitoração por exemplo.
Aqui alguns exemplos de profile, role e hiera data.
Utilizando o hiera como node classifier.
Este seria o diagrama do workflow propopsto, iniciando sempre com as alterações do sysadmin no repositório do git e fazendo o push para o git que inicia todo o processo com um hook que chama o jenkins para validar suas alterações, como check de manifests, check de templates e etc, para caso de sucesso nos testes, ele aplica no servidor do puppet. Após isso, o sysadmin teste usando a tag “--environment testing” ao executar o puppet nos servidores. Assim que suas alterações estiverem ok, ele realiza o merge deste código em produção. Assim suas alterações seriam visualizadas por todo o parque de computadores.
Detalhamento do workflow proposto.
E tudo será bem mais incrível. Ou pelo menos mais estruturado e fácil. Um pouco de controle sobre o gerenciador de confirgurações é sempre bem vinda.
Notas sobre os próximos passos a serem feitos, ou que precisam ser validados.