Como testar receita de chef modificada em um único nó?

Question

Eu tenho um servidor chefe gerenciando um punhado de nós. O servidor tem receitas e sacos de dados com vários segredos. Gostaria de fazer alterações em uma das receitas e testá-la em um único nó: não quero que outros nós atualizem e usem a receita modificada.

Soluções que explorei:

Cozinha de teste, etc.

Os testes são bons, mas há alguns detalhes que não posso testar sem as bolsas de dados e outras coisas exclusivas do servidor do chef.

código rsync em / var / chef / cache / cookbooks

E execute chef-client --skip-cookbook-sync

Isso falha porque o código-fonte do meu cookbook não possui um metadata.json e várias outras coisas.

bata a versão do livro de receitas, carregue, edite a lista de execução do nó

É difícil coordenar o trabalho simultâneo entre vários desenvolvedores (especialmente se o teste durar dias ou semanas). Há também vários ambientes fora do meu controle, e não posso presumir que estão todos presos a uma versão específica do livro de receitas que desejo modificar.

renomeia o livro de receitas, faça o upload para o servidor, aplique o papel alternativo ao nó

Esta é a solução que estou usando agora. É tedioso porque mudar o nome do livro de receitas muda os nomes dos recursos que ele define, então eu tenho que editar o livro de receitas um pouco. Manter o conjunto de funções alternativas para usar o livro de receitas renomeado também é um aborrecimento.

    

Answer 1

Eu lidei com isso definindo a versão do livro de receitas para algo como 0.0.1 e bloqueando apenas o ambiente de destino para essa versão - isso evita que todos com um ambiente desbloqueado adotem o novo livro de receitas.

Se você precisar que ele seja realmente um nó específico, você pode criar um livro de receitas fictício que 'depende' do seu livro de receitas 0.0.1 específico e atribuir essa receita como uma entrada de lista de execução adicional para um nó. Contanto que o pino do ambiente permita livros de receitas mais antigos (ou seja, < = x.y.z em vez de = x.y.z), ele forçará esse nó a usar o livro de receitas especial.

Além disso, veja test-kitchen + chef-zero para testar os recursos do servidor dentro da cozinha.

    

Answer 2

Se os seus testes durarem semanas, você pode pensar em aplicar ideias de sucesso do mundo da engenharia de software, como Recurso Alterna . Dessa forma, você pode alternar entre o código antigo / novo usando essas alternâncias implementadas por meio de atributos de função ou tags no Chef.

Como estamos, no entanto, também invertemos o ambiente de nós específicos de tempos em tempos e restringimos produção à versão latest - 1 , atualmente experimento com o seguinte que facilita o uso de vários ambientes com as mesmas configurações (não há garantia de que realmente funciona bem, ainda não tentei isso em produção):

# environments/production.rb

name "production"

env_cookbook_versions = {
  "mysql"               => "<= 6.0.18",
  "extra-constrained"   => "= 1.1.2"
}

env_default_attributes = {}

eval File.read("production_settings.rb")

Este arquivo (que eu carrego por meio de knife environment from file ) contém algumas restrições específicas, que não são válidas para outro ambiente, como pre-production , que não possui um pin de versão para o livro de receitas extra-constrained .

Por fim, o production_settings.rb (as partes comuns entre todos esses ambientes (para mim, estou falando apenas de production e pre-production , não muito mais)) podem ser assim:

# environments/production_common.rb

env_cookbook_versions["foo"] = "= 0.0.1"
cookbook_versions(env_cookbook_versions)

env_default_attributes.merge!({
  "rabbitmq" => {
    "server" => "mq.example.org"
  },
  "base" => {
    "flags" => {
      "production" => true
    }
  }
})
default_attributes(env_default_attributes)

Como você sabe, você precisa ter cuidado ao procurar outros nós no mesmo ambiente. Além disso, não tenho certeza se tudo isso praticamente funciona bem. Você precisa garantir que todos os ambientes, dependendo do production_settings.rb , sejam carregados, uma vez que isso seja alterado. Mas talvez isso te dê algumas ideias.

Entre. em relação à testabilidade sem o Chef-Server: raramente encontro coisas que não posso testar com o test-kitchen. Você sabe que também pode adicionar bolsas de dados e também outras falsas < um href="https://github.com/TYPO3-cookbooks/t3-tinc/tree/master/test/integration/nodes"> nós ao seu livro de receitas para testar o código que usa tais consultas de pesquisa?