Gerenciando / especificando scripts específicos do host (* nix)

Question

No momento, estamos usando o Puppet (com os manifestos e arquivos relacionados no SVN) para gerenciar a configuração de nossos hosts * nix. No entanto, eu tenho um pouco de um problema desconcertante.

Muitos de nossos hosts possuem scripts específicos para as tarefas host-cron, scripts de mineração de dados, scripts que geram dinamicamente arquivos de configuração, etc. Estou procurando uma maneira de gerenciar esses scripts, especificamente os versione e permitem uma forma relativamente simples. restaure a solução se um host for recriado, sem alterar o layout existente.

Não consigo encontrar uma solução que "funcione" para o nosso ambiente.

• Temos scripts em locais arbitrários no sistema de arquivos. Especialmente considerando a idade de alguns desses aplicativos, locais em movimento não são uma opção.
• A maioria dos desenvolvedores tem um fluxo de trabalho de edição no local. É improvável que isso possa ser alterado.
• O SVN não tem como desreferenciar os links simbólicos, portanto, não posso criar apenas um diretório com links para os scripts e a versão.
• Os desenvolvedores não têm acesso ao repositório Puppet. Isso precisa funcionar dentro das permissões existentes do sistema de arquivos - ou seja, um usuário só deve ser capaz de modificar os scripts aos quais eles têm acesso, nada mais.

Acho que a maneira mais fácil de explicar o que estou procurando é o que eu queria, mas não existe:

• SVN que lida com links simbólicos (ou seja, crie links simbólicos para todas as configurações em um diretório e, em seguida, trabalhe normalmente e faça com que eles sejam versionados)
• Uma maneira fácil de o SVN gerenciar uma determinada lista de caminhos ou diretórios em um host, mas deixar tudo intocado.

Alguma sugestão?

    

Answer 1

O verdadeiro problema aqui não é um sistema SCM, é que você não tem controle sobre seus usuários fazendo alterações descontroladas em seu ambiente de produção. A menos que você consiga fazer com que os usuários verifiquem as alterações, o controle de configuração não é a abordagem correta. Parece que você realmente precisa de uma boa solução de backup que possa ser usada para restaurar rapidamente uma imagem em funcionamento.

Se você quiser restaurar a "configuração" com o fantoche, em vez de uma solução de backup convencional (que deveria ter de qualquer maneira), talvez queira usar o fpm de Jordan Sissel link . O fpm é realmente destinado a gerar pacotes (rpm, deb, etc.), mas pode gerar um módulo de fantoche com uma lista de arquivos. Você pode executar um cronjob em cada host que gera um módulo de puppet com scripts de hosts e o verifica em svn / git / etc.

    

Answer 2

O FSVS é um cliente do Subversion para o Unix que permite usar qualquer parte do seu sistema de arquivos como uma cópia de trabalho. Ele armazena os dados do SVN em / var, para que não polvilhe seus diretórios com subpastas .svn. Importante, ele armazena os metadados do arquivo Unix nos atributos SVN, de forma transparente.

Você usa muito como você usaria o svn na linha de comando:

cd /home/mydir
fsvs urls svn+ssh://yoursvnrepohost/var/svn/yourrepo/home/mydir
fsvs exclude ./tmp
fsvs commit -m 'initial commit'

(...)

fsvs log
fsvs diff thatconfigfile

Você pode usar qualquer ferramenta SVN para navegar pelo repositório SVN resultante.

Sugiro também adicionar um cronjob diário para fazer um autocommit em /.

Você também precisa excluir muitos arquivos, cache, diretórios temporários e assim por diante, caso contrário, você preencherá seu repositório com lixo eletrônico.

    

Answer 3

Eu recomendaria a atualização do repositório de controle de revisão diretamente no próprio servidor. Eu mantenho a maior parte da minha configuração de produção em um repositório de infraestrutura.

Parece que você está tentando projetar a solução. Não use links simbólicos, faça-os usar o SVN em locais arbitrários.

    

Answer 4

Embora existam SCMs que podem armazenar links, não estou ciente de que nenhum dos sistemas SCM manipule links dessa maneira. Nem eles deveriam IMHO! E se você quisesse trabalhar em dois ramos diferentes ao mesmo tempo e verificasse duas cópias, uma para cada filial? (Isso é bastante comum em minha experiência com projetos de programação.) Eles causariam estragos um no outro se cada um apontasse para os mesmos arquivos em outro lugar no disco.

SCMs geralmente reservam um diretório que lhes pertença. Isso permite que vários repositórios com check-out vivam lado a lado sem interferência e torna claro o limite entre arquivos gerenciados por SCM e não gerenciados por SCM.

Em vez de links, eu criaria uma solução em torno de operações de cópia e implantação explícitas. Para lidar com o seu caso, eu escreveria scripts de sincronização entre os locais implantados de seus scripts e o diretório de origem gerenciado pelo SCM (que chamarei de "repositório"), para que você possa substituir as edições dos scripts em locais. no repo. Eu também trabalharia em um script de implantação simples de executar (baseado em Puppet?) Que copiava do repositório para os locais de destino para teste.

    

Answer 5

Embora eu concorde que provavelmente seria melhor treinar novamente seus desenvolvedores para fazerem as edições deles no Subversion, você poderia gerenciar um truque razoável sem muito esforço.

Eu começaria fazendo um diretório ou repositório (dependendo do que faz mais sentido em seu ambiente) que tem um subdiretório por host que você deseja gerenciar dessa maneira. Abaixo desses diretórios, coloque os arquivos que você deseja gerenciar de forma estruturada. Pessoalmente, eu faria assim:

per_host_confs/
    host1/
        etc/
            cron.d/
                foo
            logrotate.d/
                bar
        var/
            ...

Em seguida, adicione um cronjob (ou adicione uma regra de fantoche) que execute um script que faça check-out do tronco atual do diretório do host apropriado (a variável $ hostname será útil aqui em sua receita de fantoches) para algum diretório temporário. encontre nesse diretório e copie os arquivos relevantes na cópia de trabalho, e então confirme.

A regra de fantoches para reimplantá-lo poderia fazer algo semelhante e usar um cria ou verificar horários de modificação para determinar quando enviar arquivos da cópia de trabalho / repo para o disco local.

    

Answer 6

Você pode fazer os links simbólicos ao contrário? Tenha um diretório gerenciado pelo svn (digamos /usr/local/scripts/ ) e então copie todos os seus scripts para aquele diretório (ou subdiretórios) e coloque um symlink no local antigo. Então, sempre que alguém edita o arquivo, ele realmente edita o arquivo no diretório svn.

Se os links sym não funcionarem dessa maneira, você poderá usar links de hardware.

Depois de fazer isso, você pode tentar encorajar sua equipe a editar os arquivos no novo local e gradualmente padronizar a nova estrutura de diretórios. Como backstop você pode ter um cron job que faz um check-in a cada noite, e envia um e-mail para que você saiba quem não está usando o novo sistema, para que você possa dar um lembrete amigável à pessoa relevante.