Use o git para vários arquivos de configuração do servidor

Question

Nós migramos muito código-fonte para o git e estamos muito felizes com a nossa solução atual. Gostaríamos de ter nossos arquivos de configuração do servidor com versões no mesmo sistema, mas há algumas coisas que não funcionam da maneira que gostaríamos e espero que alguém possa compartilhar sua experiência aqui.

Esta pergunta é semelhante a Usando o controle de revisão para arquivos de configuração do servidor? , mas temos alguns requisitos especiais que não funcionam com as sugestões sobre essa questão.

A configuração atual usa o subversion para arquivos de configuração. O repositório correspondente é parecido com isto

 / # root of repository
 +--www.domain.com/     # configuration for www
 |  \--etc/
 |     \--apache2/
 +--dev.domain.com/     # configuration for dev
 |  +--etc/
 |  \--opt/
 |     \--app1/         
 |         \--conf/     # configuration for app1 on dev
 \--staging.domain.com/ # configuration for staging

Com o subversion, isso funcionaria muito bem, porque é possível apenas fazer o checkout de um subdiretório de um repositório. Além disso, você pode usar svn: externals para apontar para uma estrutura comum para várias configurações diferentes. Nós só tivemos que lidar com os arquivos .svn em todos os diretórios versionados. O Git, por outro lado, não tem svn: externals e checkouts em parpar sempre exigem que o caminho da raiz até o diretório real seja o mesmo.

Ao discutir a migração para o git, tentei escrever os Requirements principais para a versão de configuração do servidor:

• queremos apenas um único repositório
• deve ser possível enviar alterações facilmente ao controle remoto central
• changesets devem conter o autor real

Existe uma maneira legal de ter toda a configuração em um repositório e ter apenas um sub-caminho como cópia de trabalho? Atualmente estou considerando duas abordagens, mas queria fazer essa pergunta aqui primeiro

1. Se o repositório .git estiver em um local fixo, por exemplo em algum lugar em / var , poderíamos vincular ao sub-caminho do diretório de trabalho "target". O problema principal: Eu não saberia de uma maneira de "vincular" de / etc para outro diretório, a fim de importar apenas o conteúdo, exceto os arquivos individuais de links simbólicos
2. Eu encontrei outra alternativa em essa pergunta SO , sugerindo ter várias ramificações em um repositório. Isso certamente aumentaria a complexidade, mas eu poderia nos ver tentando dessa maneira.

Usar o git em uma única máquina para o gerenciamento de arquivos de configuração funciona bem, mas acredito que deve haver alguém que esteja usando da maneira que gostaríamos de usá-lo.

Obrigado ... Kariem

    

Answer 1

Eu usei algo assim antes; foi assim que funcionou.

Configuração de Repo

1. Crie um repositório git, "etc_files".
2. Crie uma ramificação para cada tipo de máquina, por exemplo, "servidor / www", "servidor / dev" etc.
   • git suporta barras nos nomes das ramificações. Isso me ajuda a manter os galhos diretos na minha cabeça.
   • Se você tiver poucas máquinas suficientes, poderá ter uma filial para cada máquina individual.
3. Crie uma filial para cada parte da infraestrutura compartilhada, por exemplo "módulos / apache", "módulos / cups", etc.
   • Essas ramificações são para armazenar arquivos que são os mesmos entre todas as máquinas, como /etc/resolv.conf . Estes seriam os arquivos que você mantém em repositórios "svn: externals" agora.

Construindo uma nova máquina

1. Em uma nova máquina, clone o repositório git e confira a ramificação desse tipo de máquina.
   • Eu faço deste um clone somente leitura para evitar que as pessoas cometam alterações de máquinas de produção sem testes.
2. Configure um cron job para automaticamente git pull do repositório todos os dias.

Mudando de galhos de máquinas

Alterar o código em uma única ramificação da máquina é simples; apenas git checkout o ramo apropriado em seu ambiente de desenvolvimento, faça as alterações e envie-as de volta ao repositório central. Todas as máquinas nessa ramificação receberão as alterações automaticamente na próxima vez em que a tarefa do cron for executada.

Alterando ramificações de módulos

Alterar o código para um ramo de módulo é apenas um pouco mais complicado, pois envolve duas etapas:

1. git checkout o ramo do módulo apropriado
2. Faça suas alterações e confirme-as no servidor centralizado.
3. git checkout de cada ramificação de máquina que usa essa ramificação do módulo e, em seguida, mescla a ramificação do módulo nela. O git irá descobrir que você mesclou esse ramo antes e só notará as mudanças que aconteceram desde o último pai comum.

Este método tem benefícios e desvantagens. Uma vantagem é que eu posso fazer uma alteração em uma ramificação do módulo e aplicá-la às ramificações da máquina que precisam dela, o que permite que as ramificações da máquina não permaneçam na versão mais antiga até que estejam prontas. A desvantagem, então, é que você precisa se lembrar de mesclar sua ramificação de módulo em cada ramificação de máquina que possa estar usando-a. Eu uso um script que atravessa a árvore de commit e automaticamente faz essa mesclagem para mim, mas ainda pode ser uma dor.

Como alternativa, versões mais recentes do git oferecem suporte a algo chamado " submódulos ":

Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.

Isso permitiria que você construísse algo um pouco como as árvores "svn: externals", que você poderia atualizar da mesma maneira como faz agora.

    

Answer 2

Bit de um nub aqui, mas Parece que um gancho de postagem pode fazer o trabalho

Repo mestre é armazenado em / var / master
o gancho clona para / var / localclone
copia os detalhes específicos do host
Você precisaria configurar o gancho .git / post-receive localmente em cada servidor (com configurações apropriadas)

Também parece que você quer algo mais como fantoche ou chef do que git para este isso permitiria que você executasse o git para gerenciar centralmente as configurações e os módulos e fazer com que o puppet \ chef gerencie a implantação e a verificação para você

    

Answer 3

aqui está um trabalho rápido que eu pensei em 1. Tenha um repositório central em dizer /var/repo
2. Coloque arquivos que são globais para todos os domínios nesse diretório.
3. Criar filiais para cada subdomínio /var/repo/subdomain1 , /var/repo/subdomain2 etc.
4. Crie um post hook onde qualquer push para o branch é mesclado com o master.

Portanto, quando você alterar a configuração de /var/repo/subdomain2 , ele será mesclado imediatamente com o mestre, para que você possa fazer o repo por completo e ter todos os arquivos de configuração. Quando você quiser extrair configurações individuais de subdomínio, basta puxar a ramificação apropriada.

Como você coloca seus arquivos de configuração em /var/repo/* é uma questão totalmente diferente (cron tabs, eu consigo pensar)

~ $