Quando fantoche, chef ou ansible são soluções mais simples que o gerenciador de pacotes?

Question

Sou novo nas ferramentas de implantação e configuração acima. Eu tenho necessidade típica de instalar e atualizar em uma máquina de destino um servidor web personalizado e configurado, talvez proxy reverso, banco de dados, tempo de execução necessário para idiomas interpretados e tal.

Minha distribuição já tem um gerenciador de pacotes que funciona. Eu posso criar e distribuir meus próprios pacotes contendo software pré-configurado e instalá-los / atualizá-los em ssh.

Onde devo esperar que esta solução seja insuficiente e opte por ferramentas mencionadas?

    

Answer 1

Um gerenciador de pacotes não substitui o gerenciamento de configurações. Um sistema de gerenciamento de configuração pode manipular interações com o gerenciador de pacotes nativo. No que diz respeito a configurações de assados em pacotes, isso seria suficiente apenas se a) todos os servidores tivessem configurações idênticas eb) Nenhum dado externo fosse necessário para suas configurações.

Vamos analisar uma infraestrutura básica. Você tem um aplicativo da Web interno, mas também usa um servidor da web para executar o software de rastreamento de tickets (digamos, Redmine). Seu aplicativo da web interno é escrito em PHP, mas o Redmine é um aplicativo ruby. Esses dois aplicativos da Web diferentes teriam configurações diferentes do apache. Se você estiver assando configurações em pacotes, isso exigiria que você construísse dois pacotes apache que conflitem entre si, por exemplo, apache-internal e apache-redmine. É fácil ver como isso pode se tornar incontrolável muito rapidamente.

Vamos ver como isso ficaria em um manifesto de marionetes:

# internal PHP application
class { apache: }
# uses your OS package manager to install PHP
class {'::apache::mod::php':
  package_name => "php54-php",
  path         => "${::apache::params::lib_path}/libphp54-php5.so",
}

# redmine
class { apache: }
# uses your OS package manager to install mod_passenger
class { apache::mod::passenger: }
apache::vhost { $::fqdn:
  docroot     => '/path/to/directory',
  directories => [
    { path              => '/path/to/directory',
      passenger_enabled => 'on',
    },
  ],
}   

Outro exemplo básico é ter diferentes ambientes em sua infraestrutura. Algo que você não pode fazer com configurações estáticas em um gerenciador de pacotes é um arquivo de configuração de modelo. Se você tiver um ambiente de desenvolvimento e produção, os modelos permitem que você escreva configurações que instruam seus aplicativos a se conectarem à fonte de dados correta (por exemplo, um banco de dados) ou a um ambiente específico.

Por fim, quem adicionará seus repos personalizados e instalará os pacotes corretos em cada host? Esta é uma manutenção mais desnecessária que é resolvida pelo gerenciamento de configuração.

    

Answer 2

Eu concordo com Jordanm, um exemplo prático de como eu uso fantoche dentro da minha empresa é que temos repositórios yum locais, já que toda a nossa infraestrutura é baseada em Centos. Ao criar novos servidores do zero, posso escolher um manifesto pré-configurado para construir o servidor contra, por exemplo, Pode ser uma pilha de lâmpadas para que os fantoches instalem todos os RPMs necessários para garantir que todas as aplicações corretas estejam presentes. Mas também removerá qualquer serviço de sistema que eu não queira, altere configurações, implemente regras de iptable, instale contas de usuários de administradores, configure regras de proxy e assim por diante. Qualquer alteração de sistema que eu faça eu faço através de fantoches, então nunca esqueço de fazê-los novamente.

Como você pode ver o fantoche é usado para mais do que apenas gerenciamento de pacotes, ele pode construir um servidor inteiro sem interação do usuário. Pense se o seu hardware morre por quanto tempo e quanto esforço seria necessário para construir uma nova réplica.

Espero que isso ajude