Discussion :

[eséguin]

Par curiosité

Je vois pas mal d'architectures de production dans lesquelles chaque service possède sa propre instance apache (chaque service possédant sa conf apache intégrale, ses dossiers de logs et ses données).

Hormis le fait d'avoir quelque chose d'un peu plus propre et normalisé qu'une multitude de conf de virtualhost et des dossiers dans tous les coins : Quels sont les avantages de ce genre d'archi en termes de stabilité et d'exploitation des apaches ?

Merci d'avance

Manu

[_Mac_]

Comprends pas tout : ton premier paragraphe parle d'avoir des fichiers httpd.conf (en gros) distincts par site, alors que ton second paragraphe parle de virtual hosts ce qui sous-entend qu'on a un seul httpd.conf avec dedans plusieurs blocs <VirtualHost> (présents dans différents fichiers éventuellement, mais au final 1 seul httpd.conf commun à tous les sites). De quel(s) cas de figure veux-tu parler ?

[eséguin]

On rembobine et on recommence

On a n sites web à monter sur une machine.
On a une install d'apache.

solution 1) on fait un httpd.conf par site et on démarre chaque site dans une instance apache indépendante (ex : apache2 -f /path/http.conf).

solution 2) on garde un seul httpd.conf et on définit tout les sites via des virtualhost dans cette conf (type commande a2ensite/a2dissite sur ubuntu dans mon souvenir)

=> Je me demandais quel était l'avantage d'une solution par rapport à l'autre.

Exemple de questions que je me pose :

Dans la solution 2, si un vhost bagotte, l'instance apache risque-t-elle de planter complètement et donc d'entrainer dans sa chute les autres vhost ? Si oui la solution 1 présente un avantage certain.

Dans la solution 1, il me semble qu'on est obligé de faire tourner les instances apache sur des ports différents. Il est donc nécessaire de rajouter un autre apache pour forwarder les requêtes vers les différentes instances. Cette apache "passe-plat" est donc assez critique (en cas de chute plus d'accès à l'ensemble des sites). Peut on faire autrement ?

En termes de ressources (ram/cpu) : solution 1 = solution 2 ? ou l'une des solutions est-elle clairement plus gourmande en termes de ressources ?

A priori les solutions 1 et 2 m'ont l'air équivalentes en termes de gestions des fichiers des logs. Vrai ?

etc ...

Pour faire court : Pourquoi, et dans quel cas, choisir une solution plutôt que l'autre ?

Merci pour toutes pistes de réponse

[_Mac_]

Dans la solution 1, il me semble qu'on est obligé de faire tourner les instances apache sur des ports différents.

Tout à fait. C'est peut-être le problème principal de cette solution. En revanche, là où la solution 1 est mieux positionnée est quand tu te retrouves avec 2 sites qui ont besoin d'une configuration Apache bien différente, parce que charge très différentes, modules différents, etc. Autre avantage de la 2 : s'il faut patcher Apache ou le reconfigurer, cela se fait indépendamment les uns des autres. Dans l'absolu, c'est peut-être la solution des VH qui est la mieux.

Il est donc nécessaire de rajouter un autre apache pour forwarder les requêtes vers les différentes instances. Cette apache "passe-plat" est donc assez critique (en cas de chute plus d'accès à l'ensemble des sites). Peut on faire autrement ?

L'autre solution c'est d'avoir autant d'IP différentes que tu as d'Apache.

En termes de ressources (ram/cpu) : solution 1 = solution 2 ? ou l'une des solutions est-elle clairement plus gourmande en termes de ressources ?

Je ne sais pas trop. Je pense que la solution 1 sera quand même plus gourmande.

A priori les solutions 1 et 2 m'ont l'air équivalentes en termes de gestions des fichiers des logs. Vrai ?

Oui car tu peux régler les fichiers de log par VH.