Use r10k com repositórios de módulo separados

Question

Eu tenho uma configuração funcional do Puppet com o Master e o Agent. Agora estou tentando usar o r10k para gerenciar o código do Puppet. Meu objetivo é que, em cada git push de um código, o código do Puppet abaixo de /etc/puppetlabs/code/environments no Puppet Master seja atualizado automaticamente.

Embora isso pareça funcionar para um repositório de controle monolítico contendo todos os módulos, não estou conseguindo que ele funcione se os módulos personalizados estiverem em repositórios Git separados.

Minha configuração é a seguinte:

configuração do r10k em /etc/puppetlabs/r10k/r10k.yaml :

sources:
  operations:
    remote: '/srv/git/puppet.git'
    basedir: '/etc/puppetlabs/code/environments'

Repositório de controle central /srv/git/puppet.git contendo as ramificações production e testing , cada uma com:

• A manifests/site.pp com configurações de nó, por exemplo %código%
• A node default { contain mymodule } com referências de módulo externo

O Puppetfile para Puppetfile se pareceria com, por exemplo,

mod 'mymodule',
  :git => 'file:///srv/git/mymodule.git',
  :ref => 'HEAD'

enquanto que para testing seria parecido com, por exemplo.

mod 'mymodule',
  :git => 'file:///srv/git/mymodule.git',
  :ref => 'stable'

(Até que isso funcione, eu só tenho o branch production e referência a production .)

Outro repositório Git para cada módulo personalizado , por exemplo HEAD

Git Hooks para executar o r10k sempre que /srv/git/mymodule.git for executado:

• git push

  com conteúdo /srv/git/puppet.git/hooks/post-receive

• r10k deploy environment -pv

  com conteúdo /srv/git/mymodule.git/hooks/post-receive

Os ganchos são executados, já que em r10k deploy module mymodule -v eu recebo saída como

remote: INFO     -> Deploying environment /etc/puppetlabs/code/environments/production
remote: INFO     -> Environment production is now at 991830eb1561cddd7970be4152748168df52ef79
remote: INFO     -> Deploying Puppetfile content /etc/puppetlabs/code/environments/production/modules/mymodule

e

remote: INFO     -> Deploying module /etc/puppetlabs/code/environments/production/modules/mymodule

Meu problema é que - apesar desta saída - as mudanças enviadas para o repositório do módulo não são refletidas pelos arquivos abaixo de git push .

Editar

Elaborar um pouco sobre o fluxo de trabalho pretendido:

• Meu repo de controle tem duas ramificações, /etc/puppetlabs/code/environments e production , enquanto o repositório de módulos tem apenas uma ramificação testing . Eu pensei que seria mais fácil assim, especialmente para evitar problemas de mesclagem. Mas considerando que nas fusões do Git pode ser restrito ao avanço rápido, e o r10k tem suporte ativo para o rastreamento de ramificações, meu fluxo de trabalho pode ser mais fácil usando os branches master e production para os repositórios do módulo também. Eu então trabalhava (desenvolvia) em testing e só mudava para testing para executar algo como production .
• Meu primeiro pensamento foi criar uma tag do Git git merge --ff-only testing para o repositório de módulos que eu movo para o commit atual de vez em quando, ou seja, permanecendo na ramificação stable o tempo todo sem qualquer fusão feita. Mas uma mesclagem de avanço rápido entre ramificações também pode salvar-me de conflitos de mesclagem, portanto provavelmente não há motivos para evitar ramificações. Também posso obter o mesmo fluxo de trabalho tanto no repositório de controle quanto no repositório de módulos.
• Estou apenas começando a aprender sobre Puppet com duas máquinas virtuais, um mestre Puppet e um agente. Vou adicionar outro agente de VM e, em seguida, aponte um para o ambiente master e o outro para production , para que eu possa verificar meu fluxo de trabalho ao criar uma configuração de Marionete utilizável para os agentes. Por enquanto, vou simplesmente definir o ambiente em cada agente testing .
• Mais tarde, usarei caixas Linux reais e mapeará um agente para puppet.conf e todos os outros para testing . O mestre estará em outra caixa e será configurado manualmente.

Answer 1

De acordo com sua pergunta e os comentários:

My problem is that - despite this output - changes pushed to the module's repository are not reflected by the files below /etc/puppetlabs/code/environments.

r10k não sabe sobre HEAD . HEAD não é determinista, por isso não é possível usá-lo assim.

Se você quiser acompanhar um branch , use algo como:

mod 'mymodule',
  :git => 'file:///srv/git/mymodule.git',
  :ref => 'master'

To keep the setup simple I wanted to avoid branching. Instead I wanted to always use the latest commit of the module repository for testing and use another stable tag for production which I move forward whenever the code is in acceptable shape.

Honestamente, não tenho certeza de como seu fluxo de trabalho se parece:

• Você tem um repositório de controle com dois ramos, master e testing . master é o código de produção estável, enquanto você está usando testing para desenvolvimento?

• Você está enviando um novo código para testing e, assim que atingir um estado com o qual se sente confortável, você está mesclando testing em master ?

• Depois disso, você gostaria de marcar o estado atual em master as stable , que seus agentes devem usar?

• Como é o restante da sua infraestrutura? Quantos agentes estão no lugar? Como você testa seu código, ou seja, como você diz a {one, all} (?) Agentes: "Por favor, use este código saindo deste ambiente"?

• Siga as etapas acima: se você codifica em master e testing , como seus agentes sabem qual ambiente usar?

• Se você pudesse elaborar os pontos acima e me dissesse mais detalhes (e por favor adicione isso à sua pergunta, os comentários podem ser muito limitados para isso), eu posso ajudar e estender esta resposta. / p>

• Enfim, boa sorte! puppet e r10k , especialmente se acoplados a ganchos git, são uma configuração incrível! Usando isso sozinho, é ótimo! :)

Informação adicional:

• Obrigado por elaborar o seu fluxo de trabalho.

• Se você não é tão versátil ainda com o git, e especialmente se você está fazendo muitas ramificações e mesclagens e tem medo de conflitos de mesclagem, certifique-se de ler sobre gase rebase , que faz

  reapply commits on top of another base tip

• Diga que você está na seguinte situação:

  • Você está ramificando master para feature1 .
  • Você faz algum trabalho em file1:3-6 em feature1 .
  • Você está alterando file1:7-10 diretamente em master para corrigir um bug urgente.
  • Você deseja mesclar feature1 de volta em master .
  • Normalmente, nesse momento, você receberia um conflito de mesclagem, porque o mesmo arquivo foi modificado nas duas ramificações.
  • Se você git rebase master em feature1 antes da fusão, isso "puxará" o estado / commit (s) mais recente para feature1 , nesse caso a correção do bug.
  • Agora faça a mesclagem, sem conflitos.
• Eu não me limitaria a apenas uma ramificação nos repositórios do módulo. Como você lida com o teste de novo código lá dentro? Não é apenas o seu repositório de controle que precisa melhorar ao longo do tempo.

• Para tornar isso mais confortável, use outro recurso de r10k :

  # Track control branch and fall-back to master if no matching branch exists
  mod 'mymodule',
    :git => 'file:///srv/git/mymodule.git',
    :branch => :control_branch,
    :default_branch => 'master'
  

• Isso permitirá que você faça o seguinte, por exemplo, em uma situação na qual gostaria de desenvolver um novo recurso em seu módulo:

  • No seu repositório de controle, filial de master a testing .
  • No repositório de módulos, a ramificação de master to testing .
  • Sem alterar seu Puppetfile , seu agente fantoche que usa a ramificação testing de seu repo de controle agora também usa a ramificação testing do repo de seu módulo.
  • Desenvolva até estar satisfeito.
  • No repositório de módulos, mescle testing em master .
  • O novo código que você desenvolveu agora vai para todos os seus agentes fantoches que usam o código de produção, ou seja, a ramificação master do repo de controle.

• Uma última nota, por enquanto: parece que você é a única pessoa que está desenvolvendo o código, então talvez isso não seja tão importante para você, mas apenas para informá-lo:

  • Se duas ramificações são muito limitadas, é bem possível usar um ambiente diferente durante um agente fantoche sem modificar a configuração, mas fornecendo um parâmetro:

    puppet agent -t --environment ${FEATURE_BRANCH}
    

• É tudo por agora que consigo pensar. Espero que isso ajude, novamente, boa sorte e tudo de bom!