Apache et IIS côte à côte (les deux écoutant sur le port 80) sur Windows2003

Question

Quels sont les bons moyens de le faire ? Est-il même possible de le faire proprement ?

Idéalement, j'aimerais utiliser les en-têtes de paquets pour décider quel serveur doit traiter les demandes. Cependant, s'il existe un moyen plus facile/meilleur, faites-le moi savoir.

Answer 1

Il est impossible que les deux serveurs écoutent sur le même port à la même adresse IP : comme une seule socket ne peut être ouverte que par un seul processus, seul le premier serveur configuré pour une certaine combinaison IP/port réussira à se lier, et le second échouera.

Vous aurez donc besoin d'une solution de contournement pour obtenir ce que vous voulez. Le plus simple est probablement d'exécuter Apache sur votre combinaison IP/port primaire, et de faire en sorte qu'il achemine les requêtes pour IIS (qui doit être configuré pour une autre IP et/ou un autre port) en utilisant mod_rewrite .

Gardez à l'esprit que l'IP et le port alternatifs sur lesquels IIS s'exécute doivent être accessibles aux clients qui se connectent à votre serveur : si vous ne disposez que d'une seule adresse IP, veillez à choisir un port IIS qui n'est généralement pas bloqué par les pare-feu (8080 peut être une bonne option, ou 443, même si vous utilisez le protocole HTTP normal et non SSL).

P.S. Veuillez également noter que vous devez modifier la configuration par défaut d'IIS à l'aide de httpcfg avant qu'il n'autorise d'autres serveurs à fonctionner sur le port 80 sur n'importe quelle adresse IP du même serveur : voir la réponse de Micky McQuade pour la procédure à suivre...

Answer 2

J'ai trouvé ce poste qui suggérait d'avoir deux adresses IP distinctes pour que les deux puissent écouter sur le port 80.

Il y avait un avertissement selon lequel vous deviez faire un changement dans IIS à cause de la mise en commun des sockets. Voici les instructions basées sur le lien ci-dessus :

1. Extraire le httpcfg.exe à partir de la zone des outils d'assistance du CD Win2003.
2. Arrêtez tous les services IIS : net stop http /y
3. Faites en sorte que IIS n'écoute que l'adresse IP que j'ai désignée pour IIS : httpcfg set iplisten -i 192.168.1.253
4. Assurez-vous : httpcfg query iplisten (Les IPs listées sont les seules adresses IP sur lesquelles IIS écoutera et aucune autre).
5. Redémarrez les services IIS : net start w3svc
6. Démarrez le service Apache

Answer 3

Pour les personnes ayant seulement une adresse IP y plusieurs sites sur un serveur, vous pouvez configurer IIS pour écouter sur un port autre que 80 par exemple 8080 en définissant le port TCP dans les propriétés de chacun de ses sites (y compris celui par défaut).

Dans Apache, activez mod_proxy y mod_proxy_http puis ajoutez un VirtualHost attrape-tout (après tous les autres) afin que les requêtes qu'Apache ne traite pas explicitement soient "transférées" à IIS.

<VirtualHost *:80>
    ServerName foo.bar
    ServerAlias *
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8080/
</VirtualHost>

Désormais, Apache peut servir certains sites et IIS d'autres, sans différence visible pour l'utilisateur.

Edit : vos sites IIS ne doivent pas inclure leur numéro de port dans les URL de leurs réponses, y compris les en-têtes.

Answer 4

Vous avez besoin d'au moins mod_proxy et mod_proxy_http qui font partie de la distribution (mais ne sont pas toujours compilés automatiquement). Vous pouvez alors regarder ici : http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

La configuration la plus simple dans un contexte de virtualhost est :

ProxyPass         /winapp http://127.0.0.1:8080/somedir/

ProxyPassReverse  /winapp http://127.0.0.1:8080/somedir/

(En fonction de votre application Web, la configuration actuelle peut être plus sophistiquée. ) Cela redirige de manière transparente chaque requête sur le chemin winapp/ vers le serveur Windows et renvoie la sortie résultante au client.

Attention : Faites attention aux liens dans les pages livrées : ils ne sont pas réécrits, donc vous pouvez vous épargner beaucoup de soucis si vous utilisez généralement des liens relatifs dans votre application, comme par exemple

<a href=../pics/mypic.jpg">

au lieu du cauchemar habituel de l'intégration où chaque lien est absolu :

<a href="http://myinternalhostname/somedir/crappydesign.jpg">

CE DERNIER EST MAUVAIS PRESQUE À CHAQUE FOIS !

Pour réécrire les liens dans les pages, il y a le mod_proxy_html (à ne pas confondre avec le mod_proxy_http !) mais c'est une autre histoire, cruelle elle aussi.

Answer 5

Soit deux adresses IP différentes (comme recommandé), soit un serveur web fait du reverse-proxing sur l'autre (qui écoute sur un port <>80).

Par exemple : Apache écoute sur le port 80, IIS sur le port 8080. Chaque requête http va d'abord à Apache (bien sûr). Vous pouvez ensuite décider de transférer toutes les requêtes vers un domaine (virtuel) particulier (nommé) ou toutes les requêtes qui contiennent un répertoire particulier (par ex. http://www.example.com/winapp/ ) à l'IIS.

L'avantage de ce concept est que vous n'avez qu'un seul serveur qui écoute le public au lieu de deux, vous êtes plus flexible qu'avec deux serveurs distincts.

Inconvénients : certaines applications web sont mal conçues et sont très difficiles à intégrer dans une infrastructure de proxy inverse. Une application web IIS qui fonctionne dépend d'un Apache qui fonctionne, nous avons donc des interdépendances.