Estou procurando a melhor maneira (para meus propósitos e situação) de versionar arquivos de configuração do sistema e gerenciar a implantação (propriedade e modo) entre apenas duas máquinas (ativas e de backup, ambas devem ser consideradas como 'produção'). Eu gostaria de poder usar este sistema para duplicar e gerenciar automaticamente (mas seletivamente) configurações relevantes e especificadas na máquina de backup (uma instância EC2).
Atualmente, essas máquinas são principalmente servidores web e SMTP (não armazenamos caixas de correio de usuários), mas nosso projeto está crescendo e quem sabe quais serão os requisitos futuros. Por exemplo, existe a possibilidade de implementarmos rádio e chat baseado na web em algum momento no futuro.
Prefiro gerenciar o servidor de maneira convencional (ou seja, entrar e fazer alterações no servidor ativo conforme necessário) e depois armazenar essas alterações (uma vez resolvidas) no sistema de gerenciamento. (Ok, para ser honesto, devo dizerorganicamente: não quero perder a flexibilidade de fazer as coisas conforme as necessidades e as situações exigem.) Acho esta abordagem, em vez da implantação de configuração que foi ajustada e testada em outro lugar, mais previsível e com potencial para menos surpresas (fora do possibilidade de estragar a configuração em um sistema ativo, isto é!)
Percebo que, filosoficamente falando, isso é de trás para frente e provavelmente faria o contrário se tivesse os recursos (infraestrutura de teste e, mais importante, mão de obra). Do jeito que está, tenho que me contentar com o que tenho. Gosto bastante de estrutura, mas o excesso de infraestrutura ganha vida própria e, em algum momento, seu valor se perde.
Fiz alguns trabalhos de casa e revisei algumas opções, mas nenhuma delas parece realmente fazer o que eu quero, então estou tentado a lançar minha própria solução. O objetivo desta pergunta é ver o que não pensei e verificar a sanidade antes de latir na árvore errada.
Opções
Sistemas de metaconfiguração declarativa como Puppet,entre outros, são provavelmente boas escolhas onde muitos servidores estão envolvidos com pouca ou nenhuma diferenciação entre eles, e especialmente quando está claro antecipadamente como deve ser a configuração. Não acho que seria sensato empregar tal ferramenta sem preparar a infraestrutura.
Também é um pouco pesado e excessivamente complicado. Eu sou o único administrador, faço isso no meu tempo livre e, se algo acontecer comigo, tudo o que eu deixar para trás precisa ser razoavelmente sensato para o sortudo que vier atrás de mim.
etckeeper pode servir, mas até onde eu vi, ele realmente não se presta ao gerenciamento de nada além de /etc. ou seja, não seria adequado para armazenar scripts personalizados que, por tradição, residem em /usr/local/bin. Além disso, o etckeeper provavelmente gerenciatodosde /etc, onde acho que prefiro criar versões apenas de coisas específicas (por exemplo, postfix, apache, fail2ban, ssh e possivelmente munin).
Um simples repositório git ou svn certamente não funcionaria, pois embora o git rastreie as permissões, ele não rastreia a propriedade, e o svn também não rastreia.
O svn mantém um
.svnsubdiretório em cada diretório rastreado, enquanto.gitexiste apenas no diretório raiz da cópia de trabalho. Existem vantagens e desvantagens em ambos os casos. A presença de um.svndiretório em um determinado local pode ser aceitável em alguns lugares (por exemplo, /etc/apache2/sites-enabled), mas perturbar scripts/ferramentas com morte cerebral em outros lugares. (Tenho certeza de que li algo há algum tempo: será que o cron estava bem com um.svndiretório em /etc/cron.d, mas o depmod não estava com /lib/modules?)Por outro lado, com um
.gitin/, o git consideratudoum candidato para rastreamento, até mesmo (presumivelmente) outros repositórios git!
Solução personalizada
Aqui está o que proponho fazer: um repositório subversion armazenado na máquina primária (digamos /usr/local/sc-repo) e um script de gerenciamento escrito emPysvnque implementa o seguinte:
add (mas, por padrão, não recursivamente), que armazena o modo e a propriedade do arquivo como propriedades personalizadas. Além disso, gosto
$Id$de tags em meus arquivos de configuração, então isso garantirásvn:keywordsque estejam configurados corretamente.comprometer-se
atualização, que aplica propriedade e modo após a gravação do arquivo
reverter, idem
permissões, como diff, mas para propriedade e modo, com sinalizador de correção para corrigir, se necessário.
A máquina de backup acessará o repositório via ssh e realizará uma operação de atualização todas as noites. (Ele também fará outras coisas, como restaurar o SQL do site e os sistemas de arquivos de aplicativos do repositório de backup da máquina principal (S3), e provavelmente terei que escrever algum hackery que procure por novos pacotes adicionados na máquina principal e os adicione no máquina de backup - mas tudo isso está fora do escopo desta questão.)
Por que subversão?
eu sei, gosto e soumuitomais familiarizado com o svn do que com o git. Sim, provavelmente sou um dinossauro.
Pysvn é fácil e já o usei antes.
svn suporta propriedades customizadas versionadas, onde o git parece não
isso não é desenvolvimento distribuído: repositórios distribuídos complicam as coisas sem trazer benefícios. A disponibilidade do repositório remoto é irrelevante, porque os commits da máquina remota serão raros.
Ficarei grato pelo seu feedback. Pensei nisso o máximo que pude, mas devo ter perdido alguma coisa.
Responder1
Não reinvente a roda. As ferramentas existem para fazer o que você precisa. Você pode querer olharbcfg2, especialmente porque você parece estar particularmente focado em arquivos de configuração. Pense também nos serviços. Onde o repositório central precisa estar em relação ao servidor de produção?
Talvez uma opção intermediária pudesse ser uma modificação cuidadosa da saída doProjetoferramenta. Eu uso o Blueprint para fazer engenharia reversa de sistemas existentes. A saída de uma execução do Blueprint pode criar um script de shell, um Módulo Puppet ou um Chef Cookbook... Depois de ter uma configuração verificada no servidor de produção, você pode usar esta ferramenta para capturar o estado do sistema e, em seguida, marcar e versionar o resultado. Leratravés dos exemplose informe se isso parece adequado ao seu caso de uso.
Responder2
Sistemas de metaconfiguração declarativos como o Puppet, entre outros, são provavelmente boas escolhas onde muitos servidores estão envolvidos com pouca ou nenhuma diferenciação entre eles, e especialmente quando está claro antecipadamente como deve ser a configuração. Não acho que seria sensato empregar tal ferramenta sem preparar a infraestrutura.
Eu uso o Puppet (mas sim, Chef, Ansible, Salt e outros existem) mesmo para configurações de máquina única. Ainda não tive uma situação em que alguém tenha deixado claro com antecedência como deveria ser a configuração da máquina (sem dúvida, muitos não ficaram claros depois do tempo como deveria ser a configuração, mas esse é um problema completamente diferente)
Quanto à "infraestrutura de teste", isso éVagabundoeCaixa Virtual(ou alguma outra tecnologia de virtualização de apoio) - execute-o em sua máquina de desenvolvimento para gastar zero. Eu não faço nenhum desenvolvimento de manifesto do Puppet sem ele. Também testes automatizados comTravis CI
Também é um pouco pesado e excessivamente complicado. Eu sou o único administrador, faço isso no meu tempo livre e, se algo acontecer comigo, tudo o que eu deixar para trás precisa ser razoavelmente sensato para o sortudo que vier atrás de mim.
Parece inconsistente dizer isso e depois descrever como você está planejando uma solução desenvolvida internamente em vez das existentes, com bastante documentação, exemplos, "bibliotecas" existentes e desenvolvimento ativo.