arquivos conf.d Nginx via fantoche

2

Estou tentando determinar onde traçar a linha entre o que acontece no fantoche e o que faz parte de um 'aplicativo'. Um lugar em que estou um pouco perplexo são os arquivos nginx conf.d .

No apache, eu teria esses arquivos marcados como .htaccess e, portanto, parte do aplicativo. No entanto, no nginx não há arquivos .htaccess; eles devem ir no diretório conf.d e o servidor deve ser devolvido.

É justo, mas quando se trata de empacotar o aplicativo e implantar a configuração do servidor com o fantoche, acho que a linha entre a configuração do servidor e o aplicativo está bastante desfocada aqui.

Se eu colocar os arquivos no pacote do aplicativo (estamos usando o RPM), então eu tenho a configuração do servidor no aplicativo. No entanto, se eu colocar os arquivos no fantoche e o autor do aplicativo desejar fazer uma alteração (adicionar outro / local, ou reescrever etc.), então eu tenho que atualizar o fantoche e agora a próxima versão do aplicativo depende de um lançamento de marionete .

Parece um problema de galinha e ovo para mim. Onde é o local mais apropriado para colocar esses arquivos conf.d, RPM de bonecos ou aplicativos?

    
por quickshiftin 30.09.2013 / 18:55

2 respostas

2

Acho que a resposta certa aqui será direcionada por considerações comerciais, e não técnicas.

Em geral, meu conselho é: Se os desenvolvedores mantiverem esse arquivo como parte do aplicativo, eles deverão empacotá-lo e enviá-lo como parte do aplicativo. Mas eles também têm que ter responsabilidade se suas mudanças quebrarem a produção.

Se você mantiver este arquivo, ou se eles não forem responsáveis se eles quebrarem a produção, então você deve manter o arquivo e colocá-lo no fantoche.

    
por 30.09.2013 / 19:39
0

However, in nginx there are no .htaccess files;

correto

they must go in the conf.d directory and the server bounced.

não está correto; eles podem ir onde quiserem, basta incluir os arquivos ou diretórios inteiros assim :

You can include any configuration files for what ever purpose you want. include vhosts/*.conf;

Fair enough, but when it comes to packaging the application and deploying server configuration with puppet I find the line between server configuration and application land rather blurry here

muito pelo contrário é verdade, por causa de um conceito diferente: com o .htaccess você mistura o aplicativo com a configuração do servidor, enquanto no nginx-land um geralmente permite que o aplicativo manipule os pedidos. O nginx é muito mais comum como proxy reverso na frente do servidor de aplicativos que serve URLs no estilo REST do que como um gateway para coisas como typo3 com um htuuge .htaccess para fazer urls amigáveis em vez de /index.php?id=23&project=23&page=13&lang=fr

de volta à sua pergunta: o que michael disse, mais (levemente OT): usamos o tecido para alterações imediatas / interativas (o intervalo de execução do fantoche é definido para 15 minutos), porque queremos ter

  1. um processo de implantação e uma ação ativa para essas alterações, ou seja: alguém DEVE pressionar um botão
  2. a possibilidade de ver, detectar e recuperar imediatamente, por exemplo, quando uma configuração falha
  3. envia alterações de configuração geralmente para um servidor standy para testes primeiro e, se funcionar, atualize os servidores ativos.

mas YMMV.

    
por 30.09.2013 / 23:59