Como posso controlar a versão dos arquivos de configuração do servidor que são alterados no tempo de execução do aplicativo, usando git ou outro VCS?

Question

Estou executando um servidor Minecraft (craftbukkit) e tenho vários outros administradores que desejam acesso para modificar os arquivos de configuração do servidor. É importante que eu acompanhe todas as alterações, então, naturalmente, o git parece ser uma boa escolha.

Observe que esta pergunta pode se referir a muitas situações,não é específico do Minecraft.

Existem vários tutoriais sobre como usar o git para gerenciar sites. As soluções mais comuns parecem estar usando ogancho pós-recebimentopara executar uma operação de checkout no diretório da web. No entanto, na minha situação, isso levanta alguns problemas.

Primeiro, alguns arquivos que os administradores precisariam editarsão alterados pelo servidor em tempo de execução. Presumo que isso confundiria o git se eu colocasse o próprio diretório do servidor no repositório. Usando a solução de checkout pós-recebimento, isso seria menos problemático, se eu estiver correto (ainda estou aprendendo git).

Eu também precisaria que as alterações feitas pelo servidor fossem enviadas para o repositório, para que os administradores possam buscar essas alterações em seus repositórios locais. Já vi soluções usandoinotifywaitmas tudo isso parece explicar apenas alterações em um único arquivo. Meu servidor tem de 50 a 80 arquivos de configuração que eu precisaria rastrear e confirmar automaticamente quando o tempo de execução do servidor os alterar. Qual seria a melhor maneira de lidar com isso?

Observe que usar git não é um requisito. Eu simplesmente gosto do que usei até agora. Se houver uma ferramenta melhor para o trabalho, estou aberto a utilizá-la, desde que seja de fácil utilização. Observe que meus administradores de servidor não são programadores, nem usuários avançados do Linux, portanto, a facilidade de uso ajuda.

Postei isso originalmente no StackOverflow, mas me disseram que era mais adequado para aqui.

Answer 1

Esta não é uma resposta completa, mas espero que alguns pensamentos úteis:

inotifywaitfuncionará perfeitamente com vários arquivos e poderá definir pontos de controle recursivamente em diretórios. Por exemplo, posso executar:

inotifywait -m -r -e close_write /etc

E obtenha o seguinte log após a edição /etc/passwde /etc/postfix/main.cf:

/etc/ CLOSE_WRITE,CLOSE .passwd.swpx
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/ CLOSE_WRITE,CLOSE 4913
/etc/ CLOSE_WRITE,CLOSE passwd
/etc/ CLOSE_WRITE,CLOSE .passwd.swp
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swx
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp
/etc/postfix/ CLOSE_WRITE,CLOSE 4913
/etc/postfix/ CLOSE_WRITE,CLOSE main.cf
/etc/postfix/ CLOSE_WRITE,CLOSE .main.cf.swp

Você poderia facilmente transformar isso em um script que, a cada close_writeevento, enviaria o arquivo para o repositório local e enviaria as alterações para um servidor remoto.

Observe também queíncroné uma ferramenta bacana para automatizar esse tipo de fluxo de trabalho baseado em inotify (mas não mudaria substancialmente a natureza da solução).

Você terá dificuldades se seus administradores editarem os mesmos arquivos que são atualizados pelo servidor em tempo de execução. Isso sugere que você terá que configurar algum tipo de resolução automática de conflitos no servidor, o que invariavelmente resultará na perda de algumas informações (bem,aparenteperda, pelo menos, você pode obviamente preservar alterações conflitantes em duas ramificações distintas do repositório, mas o servidor só consegue ver uma ramificação).

Não acho que nenhuma parte deste problema ou solução seja específica do git. Você encontrará esses problemas com qualquer tipo de manutenção compartilhada de arquivos distribuída e sincronizada de forma assíncrona.

Answer 2

O que fiz em situações semelhantes foi transformar a configuração ao vivo em um repositório (costumo usar o Bazaar) e escrevi um cronjob para confirmar automaticamente quaisquer alterações. Ter a configuração ao vivo de um repositório VCS não deve ser um problema - a única diferença é o .gitdiretório, que deve ser ignorado na maioria dos casos. O intervalo do cronjob seria qualquer granularidade com a qual você estiver satisfeito. Cada hora tem sido boa o suficiente para minhas situações, mas pode ser a cada 5 minutos, ou até 1 minuto, se necessário.

Answer 3

Existem vários tutoriais sobre como usar o git para gerenciar sites. As soluções mais comuns parecem estar usando ogancho pós-recebimentopara executar uma operação de checkout no diretório da web.

Para os arquivos de configuração, dê uma olhada emetckeeper:

Name       : etckeeper
Arch       : noarch
Version    : 0.63
Release    : 1.el5
Size       : 36 k
Repo       : epel
Summary    : Store /etc in a SCM system (git, mercurial, bzr or darcs)
URL        : http://kitenet.net/~joey/code/etckeeper/
License    : GPLv2+
Description: The etckeeper program is a tool to let /etc be stored in a git,
           : mercurial, bzr or darcs repository. It hooks into yum to automatically
           : commit changes made to /etc during package upgrades. It tracks file
           : metadata that version control systems do not normally support, but that
           : is important for /etc, such as the permissions of /etc/shadow. It's
           : quite modular and configurable, while also being simple to use if you
           : understand the basics of working with version control.
           : 
           : The default backend is git, if want to use a another backend please
           : install the appropriate tool (mercurial, darcs or bzr).
           : To use bzr as backend, please also install the etckeeper-bzr package.
           : 
           : To start using the package please read /usr/share/doc/etckeeper-0.63/README

Primeiro, alguns arquivos que os administradores precisariam editarsão alterados pelo servidor em tempo de execução.

Sem problemas.

Eu também precisaria que as alterações feitas pelo servidor fossem enviadas para o repositório, para que os administradores possam buscar essas alterações em seus repositórios locais.

Por padrão, etckeeperé executado diariamente como um cron job:

/etc/cron.daily/etckeeper

#!/bin/sh
set -e
if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
    . /etc/etckeeper/etckeeper.conf
    if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
        # avoid autocommit if an install run is in progress
        lockfile=/var/cache/etckeeper/packagelist.pre-install
        if [ -e "$pe" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
            rm -f "$lockfile" # stale
        fi
        if [ ! -e "$lockfile" ]; then
            AVOID_SPECIAL_FILE_WARNING=1
            export AVOID_SPECIAL_FILE_WARNING
            if etckeeper unclean; then
                etckeeper commit "daily autocommit" >/dev/null
            fi
        fi
    fi
fi

Se você também deseja enviar para o repositório remoto, edite o arquivo acima conforme abaixo:

        if etckeeper unclean; then
            etckeeper commit "daily autocommit" >/dev/null
            cd /etc && git push origin master
        fi

Se o intervalo diário ou mesmo minuto a minuto não for suficiente,Observadorpode enviar seus arquivos de configuração imediatamente após alterar:

/etc/watcher.ini

[DEFAULT]
logfile=/tmp/watcher.log
pidfile=/tmp/watcher.pid
[job1]
watch=/etc
events=create,delete,write_close
recursive=true
autoadd=true
command=cd /etc && etckeeper commit "daily autocommit" >/dev/null && git push origin master

De uma chance.