O Puppet ou Chef é adequado para gerenciar configurações muito básicas do servidor em um ambiente multi-tenant?

9

Relaciona-se a ambientes com vários inquilinos, como uma pequena empresa de hospedagem.

O Puppet (ou similar) é uma tecnologia adequada para cuidar de mudanças básicas, mas críticas? Por exemplo:

  • Atualizando resolvedores de DNS (resolv.conf)
  • Definição de chaves SSH
  • Atualizando a configuração do NTP
  • Configurando o snmpd
  • Implantando scripts de monitoramento, como extensões SNMP Perl ou scripts Nagios

Minhas preocupações estão relacionadas à segurança e à invasão:

  1. Não quero que nenhum servidor consiga ver nenhuma configuração que não deva
  2. Estou preocupado que um mestre de marionetes esteja vulnerável a ataques de um servidor comprometido
  3. Eu não quero que o Puppet faça alterações que não deveria, ou reverta qualquer alteração manual feita no servidor.

Eu deveria deixar isso de lado dizendo que nunca usei o Puppet na produção, só tive uma rápida brincadeira em um laboratório de teste, então é possível que eu esteja pensando errado no caminho!

    
por SimonJGreen 13.05.2013 / 23:25

6 respostas

6

Tente Ansible (ansible.cc). Pode ser que seja para você. Não há agente em execução nos seus clientes. Está crescendo muito rápido.

Outra alternativa muito boa é o Salt Stack.

Ansible e Salt são fáceis de entender, você pode usá-los como uma ferramenta de linha de comando, se quiser, como shell distribuído.

    
por 19.05.2013 / 11:48
9

Sim, isso é certamente possível. Decidir se você deve fazer isso ou não é com você embora.

Em relação às suas dúvidas:

1) justo o suficiente. O tráfego é baseado em SSL, portanto, o gerenciamento de certificados é importante. Também não confie em nenhum "fato" que o cliente forneça relacionado à sua identidade, pois eles podem ser alterados pelo cliente. Você deseja confiar no certificado SSL do cliente para fornecer a autenticação de quem é o servidor. Para ser honesto, se você estiver usando coisas como hiera corretamente e evitando enormes nomes de host baseados em if-blocks em seu código (o que você realmente deveria), você ficará bem.

2) Não deveria ser, supondo que você mantenha o patch. Corretamente configurado, há apenas um pequeno vetor para o mestre de fantoches ser atacado pelos clientes. Dito isso, os efeitos se forem comprometidos são grandes, então tome cuidado para bloqueá-lo.

3) Esse é realmente um problema de teste e implantação. Se você tiver um código de fantoche sólido, ele não estragará seus arquivos. Demora um pouco para conseguir isso ordenado, mas para o básico (como você precisa) não muito tempo.

    
por 13.05.2013 / 23:50
4

Is Puppet (or similar) a suitable technology for taking care of basic but critical mass changes?

Sim, pode ser usado dessa maneira. Eu uso isso para suportar sistemas de clientes externos.

I don't want any server to be able to see any config it shouldn't

Se você estiver usando o fantoche, não deverá ativar o autosign então. Autosign permite que os hosts solicitem automaticamente um certificado. Sua configuração e permissões serão quase certamente ligadas diretamente ao CN no certificado. Você não quer que um computador aleatório fique on-line e seja capaz de afirmar que ele é, na verdade, o sistema com todo o material secreto de alta segurança.

Se você é realmente paranóico, pode ajustar as configurações do servidor de arquivos de fantoches para criar compartilhamentos que somente alguns sistemas podem acessar. O acesso ao servidor de arquivos é baseado nos certificados.

I don't want Puppet to make any changes which it shouldn't, or revert any manual changes done on the server.

Existem algumas abordagens diferentes para permitir mudanças locais.

Um método que eu uso com frequência está abaixo. Basicamente, se você passar uma lista para um source , o fantoche tentará cada item na lista. Então, adiciono o primeiro item da lista para apontar para um arquivo local.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Outra opção seria fazer uso de links simbólicos. Se alguém quiser usar a versão de fantoches, eles irão ligar simbolicamente à versão de fantoches de um arquivo. Se eles quiserem manter sua configuração localmente, eles não criarão um link simbólico.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

A outra possibilidade é usar o augeas para fazer alterações no nível da linha, em vez de alterar arquivos inteiros. Seja muito conservador sobre o que você muda.

    
por 14.05.2013 / 01:12
1

3 > Não há desfazer automático no Puppet ou em qualquer dessas ferramentas. Você tem que escrever código explícito para desfazer. Além disso, você pode pesquisar o recurso Ambientes do boneco, ter um laboratório de testes em que um novo código é testado (pode ser VMs) e usar a revisão de código.

    
por 14.05.2013 / 00:19
1

I don't want Puppet to make any changes which it shouldn't, or revert any manual changes done on the server.

Para arquivos de configuração que são criados usando o tipo de arquivo Puppets, isso pode ser feito configurando:

replace => false,

Eu uso isso para gerar alguns arquivos de configuração na primeira vez que um aplicativo é implantado em um servidor, mas qualquer edição nesse arquivo de configuração não será sobrescrita pelo Puppet.

No entanto, isso vai contra a filosofia do Puppet de ser um script de implantação idempotente.

Pode ser melhor se você puder, ter arquivos separados editáveis pelo administrador que não sejam gerenciados pelo fantoche e que sejam incluídos nos arquivos gerenciados pelo fantoche.

    
por 14.05.2013 / 00:32
0

O Puppet funciona melhor para muitos servidores com configuração idêntica. Por exemplo. você escreve toda a configuração de um servidor da Web compartilhado fornecido pela sua empresa e, em seguida, cria N instâncias desse servidor. Depois disso, fazer alterações em todas as instâncias de uma só vez (por exemplo, você descobre que precisa alterar AllowOverride para todos os hosts virtuais do Apache) será muito fácil. Você também poderá armazenar todas as informações de configuração em um único local e tê-las sob controle de versão. No caso perfeito, você será capaz de lidar com uma falha de hardware jogando fora o host quebrado, substituindo-o por um novo, configurando o mesmo nome de host e assinando o certificado necessário. Tudo o mais poderia ser feito por Puppet.

Mas se você não tiver quase nenhum compartilhamento de configuração entre dois hosts, usar o fantoche pode ser menos produtivo do que fazer a configuração manualmente. Também administrar metade da configuração do servidor com o fantoche e a outra metade manualmente pode não fazer muito sentido.

Resumo : Se você pode criar uma configuração uniforme e estruturada para os hosts que você vai gerenciar, o Puppet é seu melhor amigo, mas se você tiver que lidar com cada serviço (host, virtual host, banco de dados) especialmente Puppet não irá adicionar muito valor.

    
por 14.05.2013 / 22:08

Tags