Como usar ambientes de marionetes no Linux para atualizar com segurança um agente

Objetivo

Crie e use ambientes de marionetes para testar a nova configuração antes de atualizar um sistema de produção ao vivo.

Sistema operacional e versões de software

• Sistema operacional: Qualquer principal distribuição Linux e.g. Ubuntu, Debian, Centos
• Programas: Puppet e Puppet-Mestre

Requisitos

Acesso privilegiado ao servidor mestre de bonecos e ao nó do cliente Puppet.

Convenções

• # - requer que os comandos Linux sejam executados com privilégios root diretamente como usuário root ou por uso de sudo comando
• $ - dados os comandos do Linux a serem executados como um usuário não privilegiado regular

Introdução

A maioria das instalações de fantoches começa a vida como um servidor mestre executando uma única filial. O mestre contém todos os manifestos e outras configurações para todos os agentes de marionetes que são sincronizados. Este é um bom lugar para começar, mas chegará rapidamente a um momento em que uma atualização precisa de empurrar que tenha o potencial de quebrar um servidor de produção. Esperando o melhor não é a melhor maneira de prosseguir.

O Puppet fornece as ferramentas para separar ramos inteiros de configuração. Estes são chamados ambientes. Um ambiente de fantoches é uma maneira de fornecer um grupo isolado de nós de agentes com sua própria configuração dedicada. Cada ambiente contém uma árvore de configuração de bonecos inteira e pode ser considerada como um servidor mestre de marionetes separado.

Como os ambientes de boneco são usados?

O cenário típico para ambientes e é o que estamos explorando neste guia é criar um ambiente de teste, juntamente com o ambiente de produção, onde a nova configuração de bonecos é criada.

Uma maneira de testar a nova configuração no ambiente de teste é atualizando uma cópia de um servidor de produção, como um instantâneo da VM. Quaisquer problemas serão observados na máquina de teste e a configuração de bonecos modificada para corrigir isso. No entanto, nem sempre é possível ter um servidor de teste para verificar as alterações no ambiente de teste.

Outro método e o que exploraremos aqui é executar o agente de fantoches manualmente no servidor de produção, mas usar várias opções que farão com que o agente fantoche sincronize com o ambiente de teste, mas apenas mostre o que teria acontecido sem fazer mudanças reais. Isso destacará quaisquer erros que teriam ocorrido em uma atualização completa sem realmente causar tempo de inatividade.

Criando ambientes de fantoche

Neste guia, criaremos uma instância de fantoche muito simples com um mestre de marionetes e um nó do agente de marionetes. O servidor mestre do boneco será configurado para ter dois ambientes; testes e desenvolvimento.

Este guia pressupõe que você tenha um servidor mestre de bonecos e um nó agente de fantoches capazes de se conectar ao mestre de bonecos.

Vamos criar dois ambientes no mestre de bonecos e, nesses ambientes.

O local padrão para as mudanças de configuração do boneco, dependendo de qual distribuição você está usando. No Ubuntu 18.04LTS, a versão que será usada neste guia, o local está em /etc/boneco. Outras distribuições (e a documentação oficial) podem colocá -la em /etc/PuppetLabs/. No entanto, uma vez que você estiver no diretório principal de configuração de bonecos, todos os subdiretos são os mesmos para todas as distribuições.

Instruções

Crie os diretórios do ambiente

Os ambientes e sua configuração existem todos sob o /etc/boneco/código/ diretório. No Ubuntu 18.04 Este diretório está vazio na instalação, então precisaremos primeiro criar os dois diretórios de ambiente de nível superior com os dois comandos a seguir:

# mkdir -p/etc/fantoche/code/ambientes/teste # mkdir -p/etc/fantoche/code/ambientes/desenvolvimento 

Qualquer novo nó do agente se conectará automaticamente ao desenvolvimento ambiente, a menos que o ambiente A variável é definida como uma alternativa no [agente] seção do fantoche.conf arquivo no nó do agente.

Criando dois sites simples.PP se manifesta

O site.pp O arquivo é o manifesto principal de onde o agente fantoche começa a construir um catálogo do estado da máquina desejado. Vamos criar dois muito simples site.pp arquivos nos dois ambientes que criam o mesmo arquivo no nó do agente. A única diferença é que eles colocam texto diferente no arquivo.

O primeiro site.pp O arquivo será o ambiente de produção em:

/etc/boneco/código/ambientes/desenvolvimento/manifestos/site.pp

Este arquivo deve ter o seguinte conteúdo:

arquivo '/tmp/exemplo.txt ': garantir => presente, modo => "0644", content => "do ambiente de desenvolvimento \ n", 

Use seu editor de texto favorito para criar e preencher este arquivo.

Este manifesto garante que um arquivo esteja presente em /tmp/exemplo.TXT e contém o texto "do ambiente de desenvolvimento" (o "\ n" adiciona uma nova linha no final do arquivo, que é uma boa prática e impede o Puppet que mostra uma mensagem de aviso quando não estiver presente).

O segundo manifesto estará no ambiente de teste em:

/etc/fantoche/code/ambientes/teste/manifestos/site.pp

Este arquivo contém o seguinte:

arquivo '/tmp/exemplo.txt ': garantir => presente, modo => "0644", content => "do ambiente de teste \ n", 

Isso é quase idêntico ao arquivo no ambiente de desenvolvimento, com a única diferença que o texto no arquivo indica que ele veio do ambiente de teste.

Avaliando novas configurações de fantoches do ambiente de teste

O nó do agente, por padrão, apenas sincroniza o ambiente de desenvolvimento. Primeiro, instruiremos manualmente o agente de marionetes a sincronizar com o servidor mestre de bonecos e criar e aplicar o site.pp que criamos no ambiente de desenvolvimento.

Isso é feito com o seguinte comando:

# agente de marionetes -ambiente = produção -teste 

O --teste Opção faz com que o agente fantoche execute um catálogo executado em primeiro plano com o registro detalhado. Quaisquer atualizações ou alterações serão aplicadas ao nó.

O --Ambiente = Produção Existe a opção para deixar claro que estamos sincronizando com o ambiente de produção. Geralmente, isso seria configurado na configuração principal do agente de bonecos e não precisaria ser incluído no comando.

Quando o comando acima é executado, obtemos a seguinte saída:

 Informações: Usando o ambiente configurado 'Produção' Informações: Recuperando o PluginFacts Info: Recuperando o plug-in Informações: Recuperação de locais Informações: Carregando fatos Informações: CACHING CACHING para digital-2.Informações líquidas: Aplicação da versão de configuração '1527680694' aviso:/estágio [main]/main/arquivo [/tmp/exemplo.txt]/verifique: conteúdo definido como 'md5 59f9ce1d4aad5fd155db7ccc2478a93b' aviso: catálogo aplicado em 0.02 segundos 

Esta saída indica que o arquivo /tmp/exemplo.TXT não estava presente, então o agente de marionetes o criou como instruído no site.pp manifesto. As execuções subsequentes não terão o Perceber: linhas como o /tmp/exemplo.TXT O arquivo existe com o conteúdo correto.

Agora que o estado do nó do agente concorda com o manifesto do ambiente de desenvolvimento, podemos testar o que aconteceria se aplicarmos o manifesto alternativo do ambiente de teste.

Para testar e não comprometer a nova configuração, precisamos executar o seguinte comando:

# agente de marionetes -ambiente = teste - -teste -Noop 

Como você pode ver o --ambiente a opção foi alterada para testes e incluímos a opção adicional --Noop. Esta opção faz com que o agente execute uma corrida a seco. Isso significa que o agente de bonecos não fará nenhuma alteração real no nó do agente, mas produzirá toda a saída como se tivesse.

Isso nos permite avaliar o que teria acontecido se a nova configuração fosse aplicada ao servidor. Nesse caso, a saída do comando acima se parece:

 Informações: Usando o ambiente configurado 'Teste' Informações: Recuperando o PluginFacts Informações: Recuperando o plug -in Informações: Recuperação de locais Informações: Carregando fatos Informações: Aplicação da versão de configuração '1527683748' AVIS.txt]/content: ---/tmp/exemplo.TXT 2018-05-30 12:19:16.205774048 +0000 +++ /tmp /boneca-fil-File20180530-21610-8ipzur 2018-05-30 12:35:48.740982652 +0000 @@ -1 +1 @@ -From The Development Ambient.txt]/content: current_value 'md5 59f9ce1d4aad5fd155db7ccc2478a93b', deve ser 'md5 abbb8f68df144a567d 62ae6c4a036ed' (noop) a servidor: [não é o stain: [não é o stain: [não é o stain: [mD5 abbb8f68df144a5677d 62ae6c4a036ed '(noop) (não): [não é o stain: [não: hem: stain: [madre -md5 abbb8f68df144a567d 62ae6c4a036ed' (noop) (não -out). desencadeado 'atualização' de 1 aviso de evento: catálogo aplicado em 0.04 segundos 

As linhas mais interessantes aqui são as seguintes:

 -Do ambiente de desenvolvimento +do ambiente de teste 

Estes indicam com o símbolo menos ( -) o que está sendo mudado de e com o símbolo plus ( +) O que está sendo alterado para. Neste exemplo, é o texto no arquivo.

Toda essa saída indica que a nova configuração teria sido aplicada com sucesso e o conteúdo de /tmp/exemplo.TXT teria sido modificado. Se esse é o estado desejado do servidor de produção, as alterações no site.pp O arquivo pode ser feito com segurança no ambiente de produção.

Identificando um erro

A nova configuração de bonecos nem sempre é aplicada sem erro e é por isso que ela sempre deve ser testada antes de ser aplicada a um sistema de produção. Forçaremos um erro nessa situação, cometendo um erro deliberado no teste site.pp arquivo. Vamos tentar definir as permissões do arquivo para 0944 o que não é uma permissão válida e causará um erro.

Agora, quando corremos:

 # agente de marionetes -ambiente = teste - -teste -Noop 

Veremos a seguinte saída:

 Informações: Usando o ambiente configurado 'Teste' Informações: Recuperando o PluginFacts Informações: Recuperando o plug -in Informações: Recuperação de locais Informações: Carregando fatos Erro: Falha ao aplicar o catálogo: Modo de parâmetro falhou no arquivo [/tmp/exemplo.txt]: A especificação do modo de arquivo é inválida: "0944" (arquivo:/etc/Puppetcode/ambientes/testing/manifestos/site.pp, linha: 1) 

A captura de tela a seguir mostra esta saída como seria apresentada na linha de comando:

As cores imediatamente nos informam que teria havido um erro na tentativa de usar a nova configuração de bonecos do ambiente de teste. No entanto, como usamos o --Noop opção nenhum erro foi comprometido com o servidor de produção.

Conclusão

Ao executar sistemas de produção que são gerenciados pelo Puppet, é sempre importante testar qualquer nova configuração antes de ser aplicada. O uso do Ferramentas Puppet fornece para criar ambientes alternativos, onde novas configurações podem ser criadas e avaliadas com segurança em relação aos sistemas de produção, significará menos erros e menos tempo de inatividade.

Tutoriais do Linux relacionados:

• Coisas para instalar no Ubuntu 20.04
• Uma introdução à automação, ferramentas e técnicas do Linux
• Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
• Arquivos de configuração do Linux: os 30 primeiros mais importantes
• Download ao vivo de CD/DVD Linux
• Linux pode obter vírus? Explorando a vulnerabilidade do Linux…
• Download do Linux
• Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
• Como fazer bota dupla kali linux e windows 10
• Como atualizar o Firefox no Linux