Testando mudanças de configuração do apache

4

Qual é a melhor maneira de reconfigurar um servidor apache que hospeda um site de produção?

O fluxo de trabalho básico que uso é o seguinte:

  1. Crie um servidor de teste que seja o mais semelhante possível à produção
  2. Reconfigure o servidor de teste para que ele funcione da maneira que eu quero
  3. Espere até tarde da noite para que o tráfego esteja baixo
  4. Aplicar as alterações que fiz no servidor de teste para o servidor de produção
  5. Reinicie o apache, com os dedos cruzados que funciona
  6. Se algo der errado, retroceda e reinicie

Como o Apache precisa de coisas como endereços IP codificados em sua configuração, é impossível (realmente não direto) copiar os arquivos de configuração exatamente de um servidor de teste para a produção. Portanto, há sempre uma chance de as coisas darem errado quando aplicadas na produção. O que me deixa completamente louco é que

Um único erro de digitação em qualquer arquivo de configuração do Apache elimina todos os sites hospedados nesse servidor!

Como as pessoas lidam com isso em grandes servidores de produção complexos? Parece que tem que haver uma maneira de verificar o que uma configuração fará, ou pelo menos se for válida, sem correr o risco de derrubar o site ao vivo. Sugestões?

    
por Leopd 17.05.2011 / 21:24

2 respostas

8

Você pode usar a opção -t com httpd para testar a configuração sem cometer sua instância do Apache em execução para usá-la. Se houver algum erro, ele fornecerá um status de saída diferente de 0.

Além disso, se você estiver em um ambiente semelhante ao Linux que usa scripts init, /etc/init.d/httpd (ou às vezes /etc/init.d/apache2 ) geralmente suportará um argumento 'teste', ou seja, /etc/init.d/httpd test , que verificará sua configuração e dizer se é bom ou não.

Quando você tiver uma boa configuração, poderá sinalizar ao Apache para recarregar o arquivo de configuração sem reiniciá-lo - /etc/init.d/httpd reload normalmente. (Se você não estiver em um sistema com scripts init, acredito que seja o sinal USER1.) A menos que você esteja fazendo alterações no nível de remoção de vhosts existentes ou alterando quem pode acessar quais recursos, isso não deve ter nenhum impacto sobre os atuais conexões.

No Windows, a opção -t também está disponível ( httpd.exe -t ), mas acredito que seja necessário um reinício para carregar a nova configuração.

Para o seu ambiente de testes, você pode considerar uma VM em uma rede privada isolada, com um IP embutido em código para corresponder ao servidor de produção. Dessa forma, você pode combinar mais de perto com seu ambiente de produção e não precisa se preocupar em esquecer de alterar um endereço IP ao mover a configuração para produção. Você pode configurar uma segunda VM na mesma rede privada com um navegador da Web para testar a funcionalidade também.

    
por 17.05.2011 / 21:37
1

Trate sua configuração como código: use uma ferramenta de gerenciamento de configuração como Puppet para gerenciar e implantar a configuração do apache.

Um fluxo de trabalho geral:

Escreva (ou baixe) um módulo Puppet para gerenciar o Apache, ou seja, os arquivos Package, Service e config. Configure seu servidor puppetmaster para suportar dois ou três ambientes, por exemplo, desenvolvimento, teste e produção, e adicione seus servidores ao seu respectivo ambiente.

Crie um modelo a partir da sua configuração atual do Apache, onde os valores que diferem entre o ambiente de desenvolvimento, teste e produção e entre os servidores são substituídos por variáveis. Dependendo do ambiente para o qual o Puppet está enviando a configuração, as variáveis serão substituídas pelos valores que você definir. O Puppet foi projetado para verificar regularmente se os servidores de destino (nós) estão no estado desejado e, caso contrário, coloca a configuração no local correto e recarrega o Apache.

Então, como você move seu código de teste para produção? Use o software de controle de versão para gerenciar seus módulos Puppet. A maioria das pessoas usa ramificações que correspondem aos ambientes e envia novas versões das configurações de ramificação para filial. O Puppet verá então que o servidor não corresponde à nova configuração e a atualizará.

Isso pode soar um pouco confuso se você nunca pensou em configuração dessa maneira, mas você já está no meio do caminho, com seu servidor de teste e fluxo de trabalho. Você poderia começar apenas com o gerenciamento do Apache, ou até mesmo com algo menos crítico, e, finalmente, gerenciar toda a configuração do seu servidor com o Puppet. Puppet pode até se tornar sua documentação. Uma vez que todo o seu servidor é gerenciado pelo Puppet, reinstalá-lo ou construir outro servidor torna-se um pedaço de bolo, uma questão de minutos.

    
por 17.05.2011 / 23:15