Uma das soluções aceitas para esse problema é usar um sistema de gerenciamento de configuração. Alguns exemplos são fantoche , chef e pilha de sal .
Esses sistemas permitem que você defina exatamente o que um servidor (ou, em alguns casos, uma pilha de aplicativos) se parece. Usando essas ferramentas, você define o estado de um servidor, incluindo sua configuração.
Aqui está um exemplo de uma configuração muito básica do Apache usando o Puppet com o módulo puppetlabs/apache :
class { 'apache': }
apache::vhost { 'first.example.com':
port => '80',
docroot => '/var/www/first',
}
Esse código simples de fantoches garante o seguinte:
- O Apache está instalado no servidor
- O servidor está em execução e escutando na porta 80
- Contém um vhost com o docroot
/var/www/first
Você pode aplicar esse manifesto a muitos servidores em um cluster. Existem muitas razões para o movimento em direção a esse tipo de configuração, copiando manualmente os arquivos de configuração. Ele trata a configuração e a infraestrutura do seu servidor de uma maneira muito semelhante a como você trata o código.
- As configurações desses sistemas geralmente são armazenadas no controle de versão. Isso permite que você visualize facilmente alterações, reversão, etc.
- Seus estados de servidor podem ser testados em unidade e testados para aceitação
- Os módulos compartilhados funcionam como bibliotecas de código - você não precisa reinventar a roda
- Seus servidores são provisionados de maneira repetível (e mais confiável)