Gestão global de fantoches locais

Question

Alguém já gerenciou vários sistemas distribuídos geograficamente com o Puppet?

Eu tenho várias implementações quase exatamente iguais (exceto as IP's do servidor), que gerenciamento estou tentando converter em Puppet.

Eu tenho duas opções:

• Ter cada implantação para hospedar seu próprio PuppetMaster para fornecer configurações locais e, em seguida, sincronizar de alguma forma os PuppetMasters (talvez com fantoches novamente)

• Hospede o PuppetMaster no AWS EC2 para alta disponibilidade e forneça configurações para todas as implantações a partir de um único ponto

Alguém já tentou a segunda opção e como funcionou? Estou especialmente interessado no desempenho de alta disponibilidade em tal ambiente.

Obrigado.

    

Answer 1

Não há nada errado com a abordagem que você propõe. Nós temos três maços de marionetes, todos localizados em um único site, e servindo nós em todo o mundo - nós os separamos com base no fato de o nodo de marionete conectado estar em dev / test / prod. Outras pessoas preferem executar um mestre de marionetes por região geográfica. Outras pessoas têm lotes de máscaras de fantoches, algumas gerenciam apenas um nó!

A principal coisa é que é vital que você armazene e gerencie sua árvore de manifestos de puppetmaster em um sistema de controle de versão - trate como qualquer outro código que sua empresa mantenha. Eu recomendo o Git, mas o Subversion também fará o truque se você estiver mais acostumado com isso. O puppetmaster é simplesmente um serviço que serve a sua visão particular do seu VCS, ao invés de ser um banco de dados central em si.

Com o seu conteúdo em um VCS, você pode implantar os manifestos / módulos necessários para os respectivos máscaras de fantoches e mantê-los em sincronia facilmente. A convenção parece ser para folk tem um módulo git / svn repo / module por puppet, embora não haja nada que o impeça de colocar a árvore inteira sob um repo / módulo.

Minhas perguntas para você seriam:

• Quantos nós existem em cada implantação? Se você está falando de mais de 50 anos, então valeria a pena ter um mestre de bonecos local com certeza.
• As implantações têm terceiros que as utilizam além da sua empresa? O mestre de bonecos precisa ter segurança muito alta - considere as chaves da porta de todos os seus sistemas e conterá informações muito confidenciais.
• Da mesma forma, para os PMs baseados em implantação, você os hospedaria em seu próprio servidor / VM ou uma máquina existente precisaria receber a tarefa? Eu recomendo strongmente que o servidor puppetmaster tenha esse papel sozinho, por segurança.
• Como você espera que o EC2 ofereça maior disponibilidade? Pelo que entendi, as instâncias do EC2 não são HA, embora seja possível executar 2 ou mais mestres de bonecos atrás do serviço de balanceador de carga da AWS.
• As implantações são muito diferentes? Você quer mudá-los em diferentes momentos do dia? Múltiplos mestres de fantoches proporcionam um nível mais refinado de controle.

Answer 2

Você também pode usar um sistema sem Puppetmaster usando um VCS distribuído, como o Git, usando o esquema descrito aqui:

link

    

Answer 3

Também temos vários mestres de fantoches, diferentes ambientes que sincronizamos. Para fazer isso, gerenciamos todos os nossos módulos de bonecos e se manifestam em subversão e, em seguida, implantamos os módulos de bonecos nos mestres das marionetes usando manifestos regulares de bonecos e um módulo chamado vcsdeploy que faz o check-out:

link

Quando queremos sincronizar, rotulamos uma versão e atualizamos os nós.pp para o mestre de marionetes.

considera

Dave