Gestão global de bonecos vs local

8

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

Tenho várias implantações quase exatamente iguais (exceto os IPs do servidor), cujo gerenciamento estou procurando converter para o Puppet.

Eu tenho 2 opções:

Faça com que cada implantação hospede seu próprio PuppetMaster para fornecer configurações locais e sincronize de alguma forma o PuppetMasters (talvez com o fantoche 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 nesse ambiente.

Obrigado.

puppet

— SyRenity
fonte

7

Não há nada de errado com qualquer uma das abordagens que você propõe. Temos três mestres de marionetes, todos localizados em um único local, e servindo nós em todo o mundo - os separamos com base no fato de o nó de marionete de conexão estar em dev / test / prod. Outras pessoas preferem administrar um mestre de marionetes por região geográfica. Outras pessoas têm muitos mestres de marionetes, alguns gerenciando apenas um nó!

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

Com o seu conteúdo em um VCS, você pode implantar os manifestos / módulos necessários nos respectivos puppetmasters e mantê-los sincronizados facilmente. A convenção parece ser para pessoas que têm um repositório / módulo git / svn por módulo fantoche, embora não exista nada que impeça você de colocar a árvore inteira sob um repositório / módulo.

Minhas perguntas para você seriam:

Quantos nós existem em cada implantação? Se você está falando de mais de 50 anos, vale a pena ter um mestre de marionetes local, com certeza.
As implantações têm terceiros que as utilizam além da sua empresa? O puppetmaster precisa ter uma segurança muito alta - considere as chaves da porta de todos os seus sistemas e conterá informações muito sensíveis.
Da mesma forma, para os PMs baseados na implantação, você os hospedaria em seu próprio servidor / VM ou uma máquina existente precisaria receber a tarefa? Eu recomendo que o servidor puppetmaster tenha esse papel sozinho, por segurança.
Como você espera que o EC2 forneça maior disponibilidade? Pelo meu entendimento, as instâncias do EC2 não são HA, embora seja possível executar mais de 2 puppetmasters por trás do serviço de balanceador de carga da AWS.
As implantações são muito diferentes? Deseja alterá-los em diferentes momentos do dia? Vários puppetmasters oferecem um nível de controle mais preciso.

— Mike Pountney
fonte

11

Oi. Falando em torno de 10 a 20 nós no máximo em cada implantação, as implantações são em todo o mundo. Não há terceiros permitidos nas implantações. Na verdade, estou interessado em concentrar todos os dados relacionados ao Puppet em uma máquina dedicada, para que o PM seja hospedado na instância do EC2. Eu provavelmente usarei Heartbeat + DRBD para o HA. As implantações são basicamente os mesmos dispositivos, pois os IPs do servidor são diferentes. Obrigado novamente.

— precisa saber é o seguinte

Parece muito que um cluster de puppetmaster no EC2 provavelmente fará o truque para você. Apenas certifique-se de usar o Git ou Subversion para armazenar seus manifestos com segurança :)

— Mike Pountney

2

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

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

— John Arundel
fonte

Se você não possui um mestre de marionetes, perde o suporte aos dados armazenados, que é um dos recursos mais poderosos do Puppet. Pense na coleta de informações entre máquinas incorporada às atualizações; por exemplo, você pode informações automaticamente a cobrar sobre a execução de serviços em todas (boneco de gestão) hospedeiros para gerar firewall em regras, regras de roteamento, monitoramento configurações, backups baseados em puxar etc.

— David Gardner

Sim, esse é um argumento justo. Certamente, existem vantagens em executar um sistema completo baseado no Puppetmaster, e geralmente eu faço. Eu posso ver situações em que um sistema leve, baseado em VCS como esse seria útil.

— John Arundel

Se você está optando pela configuração sem master, você pode fazer isso e configurar o servidor puppetmaster para receber inventário apenas dos facters - ele não precisa estar muito disponível.

— timurb 19/11/11

0

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

http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff

Quando queremos sincronizar, marcamos uma versão e atualizamos o nodes.pp para o mestre de marionetes.

Saudações

Dave

— user1238985
fonte