Que soluções de gerenciamento de configuração existem em um ambiente sem rede?

Question

Meus servidores existem em um ambiente sem conectividade de rede externa (isso é um requisito), portanto, quando implantar atualizações, todos os pacotes, binários, arquivos de configuração, etc. devem ser incluídos na mídia entregue. E é claro que eu quero algum tipo de gerenciamento de configuração para poder dizer o que foi e o que não foi instalado.

Então, eu queria saber se as pessoas tinham experiência com chef, fantoche ou outra ferramenta de gerenciamento de configuração para lidar com esse tipo de ambiente. Na pior das hipóteses, implementei minhas atualizações como um RPM.

EDITAR:

Minha configuração tem servidores Linux e Windows.

    

Answer 1

Eu pessoalmente usei o Puppet e o cfEngine são ambos bons instrumentos para esse tipo de tarefa e eu acredito que eles sejam atualmente os maiores jogadores no campo. O Puppet requer um pouco mais de cuidado quando você começa a escalá-lo, mas tem uma sintaxe melhor, o cfEngine escala bem, mas pode levar um pouco mais de tempo para aprender o vodu. Se a conectividade de rede externa não incluir outros servidores que você puder controlar, ambos poderão armazenar em cache seu catálogo / configuração, caso não consigam acessar um servidor mestre, seja seu próprio servidor mestre ou executem apenas sob demanda, ambos devem lidar com o requisito de não rede. Se estiver tudo certo para eles alcançarem um servidor gerenciado internamente, isso definitivamente não é um problema.

Um cara com quem trabalho jura pelo bcfg2, mas eu não fiz nenhum trabalho com ele. No momento, estamos usando o Puppet no meu local de trabalho, por qualquer coisa que valha a pena.

Cada um tem seus pontos strongs e fracos e sua escolha deve depender em grande parte de quaisquer outros requisitos que você possa ter. Você pode dar uma olhada aqui para ver um resumo básico das opções mais comuns e mais obscuras que você tem.

    

Answer 2

Suponho que você tenha uma grande quantidade de servidores em execução em um ambiente off-line por motivos de segurança (esses motivos se tornam cada vez mais comuns). Tendo encontrado uma situação muito semelhante a mim mesmo. A verdadeira resposta para a pergunta depende do aspecto da sua arquitetura.

Todos os jogadores habituais (Chef, Puppet, CF-Engine, Salt, Annsible) irão trabalhar num ambiente offline, no entanto certas coisas que funcionam normalmente não vão entrar no seu caminho (ex. a forja não vai funcionar). No entanto, dependendo de quais versões do software você está usando há soluções alternativas. Para o Puppet (se você usa v3), sugiro usar o r10k para ajudar a atenuar o problema (acredito que a v4 tenha incluído).

O que @ David disse para o fantoche também é muito bom conselho. Agora importa o que você está usando Eu sugiro o seguinte que eu encontrei tornará sua vida muito mais fácil: -

• Tente evitar dados de codificação rígidos na configuração (ou seja, se você estiver usando hiera),
• Faça o máximo de dev em um ambiente de rede que puder (assim, você não precisa se preocupar com problemas de dependência quando estiver desenvolvendo
• Se você pode usar o modo cliente-servidor para a maioria dos sistemas, os modos de execução locais criam alguma complexidade adicional que é um problema se você não puder evitá-lo.
• (Chef / Puppet) Se você tem um servidor de repositório local, veja se você pode configurá-lo para servir os cookbooks / módulos no lugar de uma conexão com a internet (como você faria com o Maven)

Da perspectiva do Windows (supondo que você esteja usando uma versão recente) dê uma olhada no Windows DSC + Powershell, pois pelo menos o Chef e o Puppet têm livros de receitas / módulos que podem interagir com ele para configurar componentes do Windows (e qualquer outra coisa que você puder fazer com o Powershell).

Se ajudar a ver minha resposta para minha própria pergunta aqui , como este foi um dos "outros" fatores decisivos.

Em geral, você avaliará cada ferramenta de acordo com suas próprias necessidades, mas na maioria dos casos, descobri que parece haver algumas soluções da comunidade para qualquer um dos problemas que diminuem qualquer problema que você possa ter.

    

Answer 3

Eu tenho jogado com o Puppet desconectado recentemente para ambientes remotos onde não posso ter um servidor mestre. Em particular, este artigo foi útil para mim e provavelmente vale a pena procurá-lo se você decidir ir a rota Puppet.

Você pode configurar uma estrutura Puppet normal em / etc / puppet e depois executar o puppet manualmente. Até agora eu não descobri como seria bom o registro e o relatório sem um mestre.

Este foi meu melhor amigo durante o desenvolvimento / teste:

puppet -d -v --modulepath=/etc/puppet/modules /etc/puppet/manifests/site.pp

    

Answer 4

O Salt permite que você forneça locais alternativos para seus pacotes.

mypkgs:
  pkg.installed:
    - sources:
      - foo: salt://rpms/foo.rpm
      - bar: http://somesite.org/bar.rpm
      - baz: ftp://someothersite.org/baz.rpm
      - qux: /minion/path/to/qux.rpm

Neste exemplo, esses pacotes serão instalados a partir do local indicado:

• foo será instalado a partir do rpm no servidor de arquivos Salt
A barra
• será instalada a partir de um local http
• o baz será instalado a partir de um local de ftp
O
• qux será instalado a partir do sistema de arquivos local