Gerenciamento de configuração para 'um único servidor vários administradores'

Question

Nós configuramos um servidor que está executando a infraestrutura para uma pequena associação. Até agora, tentamos gerenciar a configuração com o Ansible, mas isso não foi um grande sucesso. Talvez estejamos fazendo errado.

Em princípio, a ideia é que este servidor seja deixado sozinho a maior parte do tempo, com pessoas adicionando ou alterando coisas uma vez em uma lua azul. Isso torna crucial que o que estiver configurado e em execução no servidor esteja bem documentado e claro, já que as pessoas que não administram o sistema frequentemente perderão a visão geral (quanto mais lembrar os detalhes). Além disso, ao longo do tempo, a composição do grupo de pessoas que administrará este servidor será alterada (conforme as pessoas saírem e ingressarem no 'comitê').

Nós começamos com uma instalação limpa, adicionando funções em ansible sempre que queríamos configurar algo (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Talvez devido à nossa inexperiência, é claro que nunca poderemos digitar um conjunto de tarefas ansiosas exatamente da maneira que precisamos, de uma só vez, também porque a configuração é um processo de tentativa e erro. Isso significa que, na prática, normalmente, primeiro configuramos qualquer serviço que desejamos executar no servidor e, em seguida, traduzimos para tarefas orientáveis. Você pode ver onde isso está indo. As pessoas esquecem de então testar a tarefa, ou têm medo de fazer isso com o risco de quebrar as coisas, ou pior: esquecemos ou deixamos de acrescentar coisas ao ansible.

Hoje, temos muito pouca confiança de que a configuração ansiosa realmente reflete o que está configurado no servidor.

Atualmente vejo três problemas principais:

• É difícil (leia-se: não temos uma boa maneira de testar) tarefas ansiosas sem o risco de quebrar as coisas.
• Adiciona trabalho extra para descobrir primeiro a configuração desejada e, em seguida, descobrir como traduzi-la para tarefas ansiosas.
• (Idealmente), não usamos com frequência suficiente para criar familiaridade e rotina.

Uma consideração importante aqui é que, seja o que for que acabemos fazendo, deve ser fácil para os recém-chegados aprenderem as cordas sem muita prática.

Existe uma alternativa viável que ainda fornece algumas garantias e verificações (comparáveis à fusão de arquivos Ansible com algum master ) que "configure as coisas e anote o que você fez" não fornece?

EDIT: Nós consideramos cometer /etc para git. Existe uma maneira razoável de proteger segredos (chaves privadas, etc) dessa forma, mas ainda tem o repositório de configuração disponível fora do servidor de alguma forma?

    

Answer 1

Basta criar uma VM de teste / teste que você possa usar para validar suas alterações. Seu método atual de realizar mudanças manualmente primeiro é irremediavelmente quebrado e condenado ao fracasso. Você e sua equipe precisam se comprometer a usar o CM adequadamente e parte disso é ter um sistema de teste disponível. Mesmo apenas uma VM vagante local seria suficiente.

Isso não apenas ajudará no teste de novas alterações, mas também servirá como uma plataforma de teste para novos funcionários (ou funcionários mais antigos que não usaram o sistema por algum tempo) para se familiarizarem com sua configuração ansiável.

Em relação a manter o / etc / in git: não, não faça isso. Esse diretório é apenas uma pequena parte do que o ansible está mudando, e ter um lugar só vai encorajar as pessoas a fazer mudanças locais.

Mantenha seus ansiosos playbooks no git. Considere restringir permissões de modo que apenas você possa aplicar alterações ansiosas ao servidor ativo. Outros podem enviar pedidos pull com suas alterações, que você pode rever e mesclar no mestre, se for o caso.

    

Answer 2

Perhaps due to our inexperience, we're of course never able to type out a set of ansible tasks exactly the way we need it to be in one go, also because configuration is a bit of a trial and error process. That means that in practice, we would typically first configure whatever service we wanted to run on the server, and then translate to ansible tasks.

Embora existam outros problemas (como não ter um ambiente de teste), você pode ter uma grande melhoria ao não fazer isso .

Um dos principais objetivos de design do Ansible deve ser idempotent , o que significa que rodar o seu playbook várias vezes não deve mudar nada (a menos que você tenha mudado as jogadas). Assim, quando estou configurando um novo software, meus passos são:

1. Faça alterações nas tarefas Ansible.
2. Execute o manual.
3. Examine o sistema e, se não estiver correto, retorne à etapa 1.
4. Confirme minhas alterações.

Se você não acha que escreverá a coisa correta na primeira vez em Ansible, escreva de qualquer maneira e itere nela até que esteja certo, como qualquer outro código. Isso reduz bastante a chance de esquecer Ansiblize de algumas alterações feitas, já que todas as alterações feitas já estavam no Ansible em algum momento durante o processo de desenvolvimento.

    

Answer 3

O Ansible tem um tempo de aceleração antes de exceder o nível anterior de produtividade, mas, quando você o faz, o estado do sistema é fácil de assegurar. Suas práticas parecem estar fora de sincronia com suas metas finais. Você pode ser produtivo com um conjunto de ferramentas CM, mantendo práticas de engenharia sólidas, mas leva tempo para estruturá-lo corretamente. Você está essencialmente trocando eficiência e facilidade de implementação, por estabilidade e escalabilidade empresarial. Da mesma forma que um programador profissional experiente não escreve hacks feios, as conseqüências sempre superam os benefícios.

Para começar, você pode ter muitos cozinheiros, sem propriedade clara, se assim esperar uma tragédia dos comuns. Cada prioridade de negócios superará as preocupações de engenharia do sistema a cada vez, a menos que seja amplamente desativada e o que resta da esquerda reflita diretamente no engenheiro responsável.

Um conjunto de ferramentas CM não é capaz de ser projetado por administradores, é o que acabei de perceber. Eles podem reutilizar o trabalho existente ou POSSIVELMENTE estender-se a uma base sólida, mas, mesmo assim, isso exigiria uma quantidade pesada de imposição de práticas. O que um engenheiro pode fazer, simplesmente NÃO é o que um administrador pode fazer. Muitos conceitos no Ansible são quase os mesmos que em uma base de código, você pode ensinar um python Admin e esperar resultados competentes? Não, certamente não, eu esperaria um trabalho de hack, então você precisa fazer a tarefa estruturada o suficiente para que um trabalho de hacker seja suportável.

Portanto, você precisa definir as coisas para o sucesso, criar soluções para pontos de administração desnecessária. Negocie a complexidade dos sistemas de baixo nível para coisas que um administrador poderia realmente fazer com sucesso. Um conjunto de ferramentas CM não salvará você de incompatibilidades de arquitetura ou design.

Portanto, a ordem está sujeita a modificação, obviamente porque a implementação depende de qual caminho é menos perturbador para seu estado atual.

1. Mova qualquer trabalho do sistema relacionado ao fluxo de trabalho relacionado a negócios para um rundeck dedicado.

2. Divida as tarefas na caixa, você pode ter duas ou mais caixas em uma agora.

3. Reimplemente seu CM de uma maneira mais estruturada e siga práticas mais seguras, manuais que representam objetos ou funções NÃO. Cada sistema deve ser descrito em uma peça.