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

Question

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

Por favor, note que esta questão pode pertencer a muitas situações, não é específico para o Minecraft.

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

Primeiro, alguns arquivos que os administradores precisariam editar são alterados pelo servidor no tempo de execução . Eu estou supondo que isso iria confundir git se eu fiz o próprio diretório do servidor no repositório. Usando a solução de check-out pós-recebimento, isso seria menos problemático se eu estivesse correto (ainda estou aprendendo git).

Eu também precisaria que as alterações feitas pelo servidor fossem inseridas no repositório, para que os administradores possam buscar essas alterações em seus repositórios locais. Já vi soluções usando o inotifywait , mas todas parecem ser responsáveis por alterações em arquivos únicos. Meu servidor tem 50-80 arquivos de configuração que eu precisaria rastrear e autocommitar quando o tempo de execução do servidor os altera. Qual seria a melhor maneira de lidar com isso?

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

Originalmente postei isso no StackOverflow, mas me disseram que era mais adequado para isso aqui.

    

Answer 1

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

inotifywait funcionará feliz com vários arquivos e pode recursivamente definir watchpoints em diretórios. Por exemplo, posso executar:

inotifywait -m -r -e close_write /etc

E obtenha o seguinte log após editar /etc/passwd e /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 trabalhar isso em um script que, em cada evento close_write , enviaria o arquivo para o repositório local e enviaria as alterações para um servidor remoto.

Observe também que o incron é uma ótima ferramenta para automatizar esse tipo de inotificação fluxo de trabalho baseado em software (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 durante a 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, perda aparente , pelo menos, você pode obviamente preservar alterações conflitantes em dois ramos distintos do repositório, mas o servidor só consegue ver um ramo).

Eu não acho que qualquer parte deste problema ou solução seja particular para git. Você vai encontrar esses problemas com qualquer tipo de manutenção compartilhada distribuída, assincronamente e sincronizada de arquivos.

    

Answer 2

O que eu fiz em situações semelhantes é tornar a configuração ao vivo um repositório (eu uso Bazaar), e escrevi um cronjob para automaticamente confirmar quaisquer mudanças. Ter a configuração ativa de um repositório VCS não deve ser um problema - a única diferença é o diretório .git , que deve ser ignorado na maioria dos casos. O intervalo do cronjob seria a granularidade com que você está feliz. Cada hora tem sido boa o suficiente para as minhas situações, mas pode ser a cada 5 minutos, ou até 1 minuto, se necessário.

    

Answer 3

Several tutorials exist on using git to manage websites. The most common solutions seems to be using the post-receive hook to run a checkout operation to the web directory.

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

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

First, some files admins would need to edit are changed by the server at runtime.

Não tem problema.

I also would need changes made by the server to be pushed into the repo, so admins can fetch those changes down to their local repos.

Por padrão, etckeeper é executado diariamente como uma tarefa agendada:

/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 quiser entrar no repo remoto, edite o arquivo acima como abaixo:

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

Se o intervalo diário ou minucioso não for suficiente, o Watcher pode confirmar seus arquivos de configuração imediatamente após a alteração:

/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

Tente.