¿Cuáles son algunas buenas maneras de hacer esto? ¿Es posible hacerlo limpiamente?Apache e IIS uno al lado del otro (ambos escuchando el puerto 80) en windows2003
Lo ideal sería utilizar cabeceras de los paquetes para decidir qué servidor debe atender las peticiones. Sin embargo, si hay una manera más fácil/mejor hágamelo saber.
Es imposible que ambos servidores escuchen en el mismo puerto en la misma dirección IP: dado que un solo socket solo se puede abrir con un único proceso, solo el primer servidor configurado para una determinada combinación de IP/puerto se vinculará correctamente y el segundo fallará.
Usted por lo tanto necesitan una solución para lograr lo que quiere. Lo más probable es que ejecute Apache en su combinación principal de IP/puerto y haga que enrute las solicitudes de IIS (que debe configurarse para una IP y/o puerto diferente) usando mod_rewrite.
Tenga en cuenta que la IP y el puerto IIS alternativo que se ejecuta deben ser accesibles a los clientes que se conectan a su servidor: si solo tiene una dirección IP disponible, debe elegir un puerto IIS que no sea generalmente bloqueado por cortafuegos (8080 podría ser una buena opción, o 443, a pesar de que se está ejecutando HTTP normal y no SSL)
PS Además, tenga en cuenta que necesita modificar la configuración predeterminada de IIS utilizando httpcfg antes de permitir que otros servidores se ejecuten en el puerto 80 en cualquier dirección IP en el mismo servidor: consulte la respuesta de Micky McQuade para el procedimiento para hacerlo ...
Encontré el siguiente enlace que sugería tener dos direcciones IP separadas para que ambos pudieran escuchar en el puerto 80: (Editar: El enlace ya no funciona: www.prismix.com/blog/2006/06/running_apache_and_iis_6_toget.cfm)
Hubo una advertencia de que había que hacer un cambio en IIS debido a la agrupación de sockets. Aquí están las instrucciones basadas en el enlace de arriba:
Esto es exactamente correcto; Tuve que hacer esto hace un par de meses para resolver exactamente el mismo problema. Si se aceptan dos direcciones IP, esta es una solución muy fácil y sólida. –
fyi, para Windows 2008 hay un artículo diferente que explica cómo hacerlo. http://weblogs.asp.net/steveschofield/archive/2007/07/06/iis7-post-44-iis7-and-apache-on-the-same-machine.aspx –
Gracias, me ayudó, pero 'net stop/y' también detuvo la cola de impresión, por lo que' net start spooler' se requiere más tarde. – Alexey
Usted tendrá que utilizar diferentes direcciones IP. El servidor, ya sea Apache o IIS, captura el tráfico en función de la IP y el puerto, lo que sea que estén obligados a escuchar. Una vez que comienza a escuchar, usa los encabezados, como el nombre del servidor para filtrar y determinar a qué sitio se accede. No puede hacerlo simplemente cambiando el nombre del servidor en la solicitud
wow. Realmente escribo demasiado despacio, cuando escribo algo, 5 personas dan la misma respuesta. – stephenbayer
Jaja, ¿bien dónde irían todos? –
Bien dos direcciones diferentes IP (recomendado) o como un servidor web es inversa proxy a la otra (que está escuchando en un puerto <> 80).
Por ejemplo: Apache escucha en el puerto 80, IIS en el puerto 8080. Cada petición HTTP Apache va a primero (por supuesto). A continuación, puede decidir reenviar cada solicitud a un dominio particular (nombrado virtual) o a cada solicitud que contenga un directorio particular (por ejemplo, http://www.example.com/winapp/) al IIS.
La ventaja de este concepto es que solo tiene un servidor escuchando al público en lugar de dos, usted es más flexible que con dos servidores distintos.
Inconvenientes: algunos webapps están diseñados y son un verdadero dolor en el culo para integrarse en una infraestructura de proxy inverso. Una aplicación de Internet IIS en funcionamiento depende de un Apache que funcione, por lo que tenemos algunas interdependencias.
De mi investigación estaba considerando un escenario de proxy inverso. ¿Puedes explicar cómo configuraste esto? ¿Usaste Apache mod_Proxy? Mis dos aplicaciones no dependen la una de la otra, lo cual es una ventaja. ¿Hay todavía algunos problemas de los que debería tener cuidado? –
Necesita al menos mod_proxy y mod_proxy_http, que son parte de la distribución (aunque no siempre se crean automáticamente). A continuación, puede mirar aquí: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
más simple de configuración en un contexto host virtual es:
ProxyPass /winapp http://127.0.0.1:8080/somedir/
ProxyPassReverse /winapp http://127.0.0.1:8080/somedir/
(Dependiendo de su aplicación web, la configuración real podría ser más sofisticados.) que redirige de forma transparente todas las solicitudes en el camino winapp/al servidor de Windows y transfiere la salida resultante al cliente.
Atención: Tenga cuidado de los enlaces en las páginas entregadas: no se vuelven a escribir, por lo que puede ahorrar muchísima molestia si se utiliza generalmente en los enlaces relativos a su aplicación, como
<a href=../pics/mypic.jpg">
en lugar de la habitual pesadilla integración de todos los eslabones ser absoluto:
<a href="http://myinternalhostname/somedir/crappydesign.jpg">
Este último es MALO casi cada vez SOLA!
Para reescribir enlaces en páginas hay mod_proxy_html (¡no confundir con mod_proxy_http!) Pero esa es otra historia y otra cruel.
Por favor, combine esto en su otra respuesta :) –
Para las personas con solamente una dirección IP y múltiples sitios en un servidor, puede configurar IIS para escuchar en un puerto distinto 80, por ejemplo 8080 estableciendo el puerto TCP en las propiedades de cada uno de sus sitios (incluido el predeterminado).
En Apache, habilite mod_proxy y mod_proxy_http, luego agregue un VirtualHost catch-all (después de todos los demás) para que las solicitudes Apache no administren explícitamente el "reenvío" en IIS.
<VirtualHost *:80>
ServerName foo.bar
ServerAlias *
ProxyPreserveHost On
ProxyPass/http://127.0.0.1:8080/
</VirtualHost>
Ahora puede hacer que Apache sirva algunos sitios y que IIS sirva a otros, sin que exista una diferencia visible para el usuario.
Editar: sus sitios IIS no deben incluir su número de puerto en ninguna URL dentro de sus respuestas, incluidos los encabezados.
Veo que esta es una publicación bastante antigua, pero encontré esto buscando una respuesta para este problema. Después de leer algunas de las respuestas parecen muy largas, así que después de 5 minutos logré resolver el problema de la siguiente manera:
httpd.conf para Apache deje el puerto de escucha como 80 y 'Nombre del servidor' como FQDN/IP: 80.
Ahora, para IIS, vaya a Servicios administrativos> Administrador de IIS> 'Sitios' en el menú desplegable de navegación de la izquierda> en la ventana derecha, seleccione la línea superior (sitio web predeterminado) y enlaces a la derecha.
Ahora seleccione http> edit y cambie a 81 e ingrese su IP local para el servidor/pc y en el dominio ingrese su FQDN (www.domain.com) o cierre de IP externo.
Reinicie ambos servidores para garantizar que sus puertos estén abiertos tanto en el enrutador como en el firewall, hecho.
Esto suena largo aliento, pero literalmente tomó 5 minutos de juego. funciona perfectamente.
Sistema: Windows 8, 8 IIS, Apache 2.2
Creo que @thedeeno estaba tratando de evitar los problemas asociados con la utilización de un puerto no predeterminado. – Walf
Instalación de Windows 10 que tenía este problema: Apache (IPv4) y el servicio de cola (IPv6) escuchando el mismo puerto 80.
resolví editar el archivo httpd.conf de Apache cambiando la línea
Escuchar 80
a
Escuchar 127.0.0.1:80
Eso no es del todo cierto. P.ej. para HTTP Windows admite el uso compartido de puertos basado en URL, lo que permite que múltiples procesos utilicen la misma dirección IP y el mismo puerto.
¿Puedes explicar cómo harías que Apache enrutara la solicitud? Además, ¿hay alguna razón por la cual Apache debería ser el servidor primario o es simplemente una preferencia? –
La razón para hacer que Apache sea el principal es el hecho de que tiene mod_rewrite. (Existen soluciones similares para IIS, pero no tan flexibles). Para que Apache envíe la solicitud, deberá definir una carpeta (que puede ser una raíz de host virtual) con reglas de reescritura en .htaccess o httpd. conf – mdb
Para futuros lectores, 'mod_rewrite' no es una buena solución a este problema porque solo maneja la URL, mientras que un proxy apropiado maneja todo lo demás. – Walf