Gerenciamento de configuração para 'único servidor, múltiplos administradores'

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 idéia é que esse servidor seja deixado sozinho a maior parte do tempo, com pessoas adicionando ou alterando coisas uma vez na lua azul. Isso torna crucial que tudo o que está configurado e em execução no servidor seja bem documentado e claro, pois as pessoas que não administram o sistema frequentemente perdem a visão geral (sem falar nos detalhes). Além disso, com o tempo, a composição do grupo de pessoas que administrará este servidor será alterada (à medida que as pessoas saem e ingressam no 'comitê').

Começamos com uma instalação limpa, adicionando funções no ansible sempre que desejamos configurar algo (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Talvez devido à nossa inexperiência, é claro que nunca somos capazes de digitar um conjunto de tarefas ansíveis 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 configurávamos primeiro qualquer serviço que desejássemos executar no servidor e depois convertíamos em tarefas ansíveis. Você pode ver para onde isso está indo. As pessoas esquecem de testar a tarefa ou têm medo de fazê-lo, ou pior: esquecemos ou deixamos de acrescentar coisas ao ansible.

Hoje, temos muito pouca confiança de que a configuração ansible realmente reflita 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 possíveis sem correr o risco de quebrar as coisas.
• Ele adiciona trabalho extra para descobrir primeiro a configuração desejada e depois descobrir como traduzir isso em tarefas possíveis.
• (Idealmente), não o usamos com freqüência suficiente para criar familiaridade e rotina.

Uma consideração importante aqui é que, para o que quer que acabemos fazendo, deve ser fácil para os iniciantes aprender as cordas sem muita prática.

Existe uma alternativa viável que ainda fornece algumas garantias e verificações (comparáveis ​​à mesclagem de arquivos Ansible para alguns master) que "configuram as coisas e anotam o que você fez" não fornecem?

EDIT: Nós consideramos nos comprometer /etccom o git. Existe uma maneira razoável de proteger segredos (chaves privadas, etc) dessa maneira, mas ainda assim temos o repositório de configuração disponível fora do servidor?

Basta girar uma VM de teste / preparo que você pode usar para validar suas alterações. Seu método atual de executar as alterações manualmente primeiro é irremediavelmente quebrado e fadado ao fracasso. Você e sua equipe precisam se comprometer a usar o CM corretamente e parte disso é ter um sistema de teste disponível. Mesmo apenas uma VM vagabunda local seria suficiente.

Isso não apenas ajudará no teste de novas alterações, mas também servirá como uma base de testes para os novos funcionários (ou funcionários mais antigos que não usam o sistema há algum tempo) para se familiarizarem com sua configuração ansível.

Em relação a manter / etc / no git: não, não faça isso. Esse diretório é apenas uma pequena parte do que o ansible está mudando, e ter o git no local só incentivará as pessoas a fazer alterações locais.

Mantenha seus playbooks ansible no git. Considere restringir as permissões para que somente você possa aplicar alterações ansíveis ao servidor ativo. Outros podem enviar solicitações pull com suas alterações, que você pode revisar e mesclar no master, se apropriado.

Talvez devido à nossa inexperiência, é claro que nunca somos capazes de digitar um conjunto de tarefas ansíveis 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 configurávamos primeiro qualquer serviço que desejássemos executar no servidor e depois convertíamos em tarefas ansíveis.

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

Um dos principais objetivos de design da Ansible é ser idempotente , o que significa que executar o seu manual várias vezes não deve mudar nada (a menos que você tenha alterado as peças). Assim, quando estou configurando um novo software, minhas etapas 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ê acha que não escreverá a coisa correta da primeira vez no Ansible, escreva assim mesmo e faça a iteração até que esteja certo, como qualquer outro código. Isso reduz bastante a chance de esquecer de Ansiblize algumas alterações que você fez, pois todas as alterações feitas já estavam no Ansible em algum momento do processo de desenvolvimento.

O Ansible tem um tempo de aceleração antes de você exceder o seu nível anterior de produtividade, mas, uma vez feito isso, é fácil garantir o estado do sistema. Suas práticas parecem estar fora de sincronia com seus objetivos finais. Você pode ser produtivo com um conjunto de ferramentas CM, mantendo práticas sólidas de engenharia, mas leva tempo para estruturá-lo corretamente. Você está essencialmente negociando com eficiência e facilidade de implementação, para estabilidade e escalabilidade corporativa. Da mesma maneira que um programador profissional experiente não escreve hacks feios, as consequências sempre superam os benefícios.

Para iniciantes, você pode ter muitos cozinheiros, sem propriedade clara, se assim for, esperar uma tragédia dos comuns. Cada prioridade comercial supera as preocupações de engenharia do sistema todas as vezes, a menos que seja amplamente desativada e o que resta permaneça refletindo diretamente no engenheiro responsável.

Um conjunto de ferramentas do CM não pode ser projetado por administradores, é isso 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 onerosa de aplicaçã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 de 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 hackers, então você precisa tornar a tarefa estruturada o suficiente para que um trabalho de hackers seja suportável.

Portanto, é necessário configurar as coisas para o sucesso, projetar soluções para pontos de administração desnecessária. Troque a complexidade dos sistemas de baixo nível por coisas que um administrador pode 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ções, obviamente porque a implementação depende de qual caminho é menos perturbador para o seu estado atual.

1. Mova qualquer trabalho do sistema relacionado ao fluxo de trabalho relacionado a negócios para uma desagregação dedicada.

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 as melhores práticas possíveis, manuais representando objetos NÃO funções ou papéis. Cada sistema deve ser descrito em uma peça.