From: Rich Bowen Date: Mon, 13 Mar 2017 13:33:39 +0000 (+0000) Subject: rebuild X-Git-Tag: 2.5.0-alpha~562 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5008e67191db75fad4bf3e9a98ca2f24d53c7c0b;p=apache rebuild git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1786683 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/reverse_proxy.html.es b/docs/manual/howto/reverse_proxy.html.es index dde23b3ac3..e6427f3012 100644 --- a/docs/manual/howto/reverse_proxy.html.es +++ b/docs/manual/howto/reverse_proxy.html.es @@ -1,313 +1,317 @@ - - - - + + + + -Guía de Proxy Inverso - Servidor HTTP Apache Versión 2.5 - - - - - - -
-

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versión 2.5 del Servidor HTTP Apache

-
-
<-
-
-Apache > Servidor HTTP > Documentación > Versión 2.5 > How-To / Tutoriales

Guía de Proxy Inverso

-
-

Idiomas disponibles:  en  | - es 

-
- -

Además de ser un servidor web "básico", y proveer contenido estático y - dinámico a los usuarios finales, Apache HTTPD (al igual que la mayoría de - servidores http) puede también actuar como proxy inverso, también conocido - como "servidor de paso" o gateway. -

- -

En tales escenarios, el propio httpd no genera contenido o aloja datos, - en su lugar el contenido se obtiene de uno o varios servidores backend, que - normalmente no tienen conexión directa con redes externas. Cuando httpd - recibe una petición de un cliente, se hace proxy de esta petición - a uno de estos servidores backend, que gestiona la petición, genera el - contenido y entonces envía este contenido de vuelta a httpd, que - entonces genera la respuesta HTTP definitiva que se envía de vuelta al cliente. -

- -

Existen muchas razones para usar esta implementación, pero generalmente - las razones típicas se deben a seguridad, alta disponibilidad, balanceo - de carga, y centralización de autenticación/autorización. Es crítico en - estas implementaciones que la arquitectura y el diseño de la infraestructura - de los backend (esos servidores que son los que acaban gestionando las peticiones) - estén aislados y protegidos del exterior; en cuanto al cliente se refiere, - el proxy inverso és la única fuente de todo el contenido.

- -

Ejemplo de implementación típica:

-

reverse-proxy-arch

- -
- -
top
-
-

Proxy Inverso

- -
Módulos RelacionadosDirectivas Relacionadas
-
top
-
-

Proxy inverso sencillo

- - -

- La directiva ProxyPass - especifica el mapeo de peticiones entrantes al servidor backend (o un cluster - de servidores conocido como grupo de Balanceo). El ejemplo - más sencillo hace proxy de todas las solicitudes ("/") a un solo backend: -

- - 
ProxyPass "/"  "http://www.example.com/"
- - -

- Para asegurarse de ello y que las cabeceras Location: - generadas en el backend se modifican para apuntar al proxy inverso, - en lugar del propio backend, la directiva - ProxyPassReverse suele ser necesaria a menudo: -

- - 
ProxyPass "/"  "http://www.example.com/"
-ProxyPassReverse "/"  "http://www.example.com/"
- - -

Sólo se hará proxy de ciertas URIs, como se muestra en este ejemplo:

- - 
ProxyPass "/images/"  "http://www.example.com/"
-ProxyPassReverse "/images/"  "http://www.example.com/"
- - -

En este ejemplo, se hará proxy al backend especificado, - de cualquier solicitud que comience con la ruta /images/, si - no se gestionarán localmente. -

-
top
-
-

Clusters y Balanceadores

- - -

- Aunque los ejemplos de más arriba son útiles, tienen la deficiencia en la - que si el backend se cae, o recibe mucha carga, hacer proxy de esas solicitudes - no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un - grupo de servidores backend que puedan gestionar esas peticiones y que el proxy - inverso pueda balancear la carga y aplicar la tolerancia a fallos entre los backend. - A veces a este grupo se le llama cluster, pero el término para Apache httpd - es balanceador. Se puede definir un balanceador usando las directivas - <Proxy> and - BalancerMember como se muestra - a continuación: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- El esquema balancer:// es lo que le dice a httpd que estamos - generando un grupo de balanceo, con el nombre myset. Incluye 2 - servidores backend, que httpd llama BalancerMember. En este caso, - se hará proxy inverso de cualquier petición para /images/ - hacia uno de los dos backend. - La directiva ProxySet especifica que - el Balanceador myset usa un algoritmo que balancea basado en los - bytes de entrada/salida (I/O). -

- -

Información adicional

-

- También se refiere a los Miembros del Balanceador BalancerMember - como workers (trabajadores). -

-
- -
top
-
-

Configuración de Balanceador y BalancerMember

- - -

- Puede ajustar numerosos parámetros de los balanceadores - y los workers definiéndolos a través de la directiva - ProxyPass. Por ejemplo, - asumiendo que quisiéramos que http://www3.example.com:8080 gestionara - 3 veces más tráfico con un "timeout" de 1 segundo, ajustaríamos la configuración como sigue: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -
top
-
-

Tolerancia a fallos

- - -

- Puede también ajustar varios escenarios de tolerancia a fallos, detallando - qué workers, e incluso balanceadores, deberían usarse en tales casos. - Por ejemplo, la siguiente configuración implementa dos casos de tolerancia - a fallos: En el primero, sólo se envía tráfico a - http://hstandby.example.com:8080 si todos los demás workers en - el balanceador myset no están disponibles. Si ese worker tampoco está - disponible, sólo entonces los workers de http://bkup1.example.com:8080 - y http://bkup2.example.com:8080 serán incluidos en la rotación: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    BalancerMember http://hstandby.example.com:8080 status=+H
-    BalancerMember http://bkup1.example.com:8080 lbset=1
-    BalancerMember http://bkup2.example.com:8080 lbset=1
-    ProxySet lbmethod=byrequests
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- La "magia" de ésta configuración de tolerancia a fallos es configurar - http://hstandby.example.com:8080 con la marca de estado - +H, que lo pone en modo hot standby (en reserva), - y hacen que los dos servidores bkup# sean parte del set nº 1 del - balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, los "hot standby" (si existen) se usan primero cuando todos los workers estándar activos no están disponibles; los set de balanceo con números inferiores se usan siempre primero. -

- -
top
-
-

Gestor del Balanceador

- - -

- Una de las características más útiles y única del proxy inverso de Apache - httpd es la aplicación embebida balancer-manager (gestor de balanceo). - wSimilar a mod_status, balancer-manager muestra - la configuración actual que está funcionando, el estado de los balanceadores - activados y workers que están en uso en ese momento. Aun así, no sólo muestra - estos parámetros, también permite reconfiguración dinámica, en tiempo real, de - prácticamente todos ellos, incluido añadir nuevos BalancerMember (workers) - a un balanceo existente. Para activar esta prestación, se tiene que añadir lo siguiente a la configuración: -

- - 
<Location "/balancer-manager">
-    SetHandler balancer-manager
-    Require host localhost
-</Location>
- - -

Atención

-

No active el balancer-manager hasta que haya securizado su servidor. En particular, - asegúrese de que el acceso a ésta URL (la de configuración del balanceador) - esté altamente restringido.

-
- -

- Cuando se accede al proxy inverso en la url - (p.e: http://rproxy.example.com/balancer-manager/, verá una - página similar a la siguiente: -

-

balancer-manager page

- -

- Este formulario permite al administrador ajustar varios parámetros, desactivar - workers, cambiar los métodos de balanceo de carga y añadir nuevos workers. - Por ejemplo, haciendo clic en el balanceador, verá la siguiente página: -

-

balancer-manager page

- -

- Y haciendo clic en el worker, mostrará esta página: -

-

balancer-manager page

- -

- Para hacer que estos cambios sean persistentes en los reinicios del proxy - inverso, asegúrese de que BalancerPersist está activado. -

- -
top
-
-

Comprobaciones de estado dinámicas

- - -

- Antes de que httpd haga proxy de una petición a un worker, puede "comprobar" - si ese worker está disponible mediante el parámetro de configuración ping - para ese worker usando ProxyPass. - A menudo es más útil comprobar el estado de los workers no disponibles, - con un método dinámico. Esto se consigue con el módulo mod_proxy_hcheck. -

- -
top
-
-

Marcas de estado de los Miembros del Balanceador

- - -

- En el balancer-manager el estado actual, o status, de un worker - se muestra y puede ser configurado/reseteado. El significado de estos estados es el siguiente: -

- - - - - - - - - - - -
MarcaCadenaDescripción
 OkEl Worker está disponible
 InitEl Worker ha sido inicializado
DDisEl Worker está - desactivado y no aceptará peticiones; se intentará reutilizar automáticamente.
SStopEl Worker ha sido desactivado por el - administrador; no aceptará peticiones y no se reintentará utilizar automáticamente
IIgnEl Worker está en modo "ignore-errors" (obviar-errores) y estará siempre en modo disponible.
HStbyEl Worker está en modo "hot-standby" y sólo se usará si no hay otros workers disponibles.
EErrEl Worker está en estado de error, - generalmente debido a fallos de comprobación antes de enviar peticiones; no se hará - proxy de peticiones a este worker, pero se reintentará el uso de este worker - dependiendo de la configuración del parámetro retry.
NDrnEl Worker está en modo vaciado y sólo aceptará - sesiones activas previamente destinadas a él mismo y obviará el resto de peticiones.
CHcFlLa comprobación dinámica del estado del Worker - ha fallado y no se usará hasta que pase las comprobaciones de estado posteriores.
-
-
-

Idiomas disponibles:  en  | - es 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+ --> +Guía de Proxy Inverso - Servidor HTTP Apache Versión 2.5 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.5 del Servidor HTTP Apache

+
+
<-
+

Guía de Proxy Inverso

+
+

Idiomas disponibles:  en  | + es 

+
+
Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.
+ +

Además de ser un servidor web "básico", y proveer contenido estático y + dinámico a los usuarios finales, Apache HTTPD (al igual que la mayoría de + servidores http) puede también actuar como proxy inverso, también conocido + como "servidor de paso" o gateway. +

+ +

En tales escenarios, el propio httpd no genera contenido o aloja datos, + en su lugar el contenido se obtiene de uno o varios servidores backend, que + normalmente no tienen conexión directa con redes externas. Cuando httpd + recibe una petición de un cliente, se hace proxy de esta petición + a uno de estos servidores backend, que gestiona la petición, genera el + contenido y entonces envía este contenido de vuelta a httpd, que + entonces genera la respuesta HTTP definitiva que se envía de vuelta al cliente. +

+ +

Existen muchas razones para usar esta implementación, pero generalmente + las razones típicas se deben a seguridad, alta disponibilidad, balanceo + de carga, y centralización de autenticación/autorización. Es crítico en + estas implementaciones que la arquitectura y el diseño de la infraestructura + de los backend (esos servidores que son los que acaban gestionando las peticiones) + estén aislados y protegidos del exterior; en cuanto al cliente se refiere, + el proxy inverso és la única fuente de todo el contenido.

+ +

Ejemplo de implementación típica:

+

reverse-proxy-arch

+ +
+ +
top
+
+

Proxy Inverso

+ +
Módulos RelacionadosDirectivas Relacionadas
+
top
+
+

Proxy inverso sencillo

+ + +

+ La directiva ProxyPass + especifica el mapeo de peticiones entrantes al servidor backend (o un cluster + de servidores conocido como grupo de Balanceo). El ejemplo + más sencillo hace proxy de todas las solicitudes ("/") a un solo backend: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Para asegurarse de ello y que las cabeceras Location: + generadas en el backend se modifican para apuntar al proxy inverso, + en lugar del propio backend, la directiva + ProxyPassReverse suele ser necesaria a menudo: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Sólo se hará proxy de ciertas URIs, como se muestra en este ejemplo:

+ + 
ProxyPass "/images/"  "http://www.example.com/"
+ProxyPassReverse "/images/"  "http://www.example.com/"
+ + +

En este ejemplo, se hará proxy al backend especificado, + de cualquier solicitud que comience con la ruta /images/, si + no se gestionarán localmente. +

+
top
+
+

Clusters y Balanceadores

+ + +

+ Aunque los ejemplos de más arriba son útiles, tienen la deficiencia en la + que si el backend se cae, o recibe mucha carga, hacer proxy de esas solicitudes + no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un + grupo de servidores backend que puedan gestionar esas peticiones y que el proxy + inverso pueda balancear la carga y aplicar la tolerancia a fallos entre los backend. + A veces a este grupo se le llama cluster, pero el término para Apache httpd + es balanceador. Se puede definir un balanceador usando las directivas + <Proxy> and + BalancerMember como se muestra + a continuación: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ El esquema balancer:// es lo que le dice a httpd que estamos + generando un grupo de balanceo, con el nombre myset. Incluye 2 + servidores backend, que httpd llama BalancerMember. En este caso, + se hará proxy inverso de cualquier petición para /images/ + hacia uno de los dos backend. + La directiva ProxySet especifica que + el Balanceador myset usa un algoritmo que balancea basado en los + bytes de entrada/salida (I/O). +

+ +

Información adicional

+

+ También se refiere a los Miembros del Balanceador BalancerMember + como workers (trabajadores). +

+
+ +
top
+
+

Configuración de Balanceador y BalancerMember

+ + +

+ Puede ajustar numerosos parámetros de los balanceadores + y los workers definiéndolos a través de la directiva + ProxyPass. Por ejemplo, + asumiendo que quisiéramos que http://www3.example.com:8080 gestionara + 3 veces más tráfico con un "timeout" de 1 segundo, ajustaríamos la configuración como sigue: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +
top
+
+

Tolerancia a fallos

+ + +

+ Puede también ajustar varios escenarios de tolerancia a fallos, detallando + qué workers, e incluso balanceadores, deberían usarse en tales casos. + Por ejemplo, la siguiente configuración implementa dos casos de tolerancia + a fallos: En el primero, sólo se envía tráfico a + http://hstandby.example.com:8080 si todos los demás workers en + el balanceador myset no están disponibles. Si ese worker tampoco está + disponible, sólo entonces los workers de http://bkup1.example.com:8080 + y http://bkup2.example.com:8080 serán incluidos en la rotación: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ La "magia" de ésta configuración de tolerancia a fallos es configurar + http://hstandby.example.com:8080 con la marca de estado + +H, que lo pone en modo hot standby (en reserva), + y hacen que los dos servidores bkup# sean parte del set nº 1 del + balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, los "hot standby" (si existen) se usan primero cuando todos los workers estándar activos no están disponibles; los set de balanceo con números inferiores se usan siempre primero. +

+ +
top
+
+

Gestor del Balanceador

+ + +

+ Una de las características más útiles y única del proxy inverso de Apache + httpd es la aplicación embebida balancer-manager (gestor de balanceo). + wSimilar a mod_status, balancer-manager muestra + la configuración actual que está funcionando, el estado de los balanceadores + activados y workers que están en uso en ese momento. Aun así, no sólo muestra + estos parámetros, también permite reconfiguración dinámica, en tiempo real, de + prácticamente todos ellos, incluido añadir nuevos BalancerMember (workers) + a un balanceo existente. Para activar esta prestación, se tiene que añadir lo siguiente a la configuración: +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Atención

+

No active el balancer-manager hasta que haya securizado su servidor. En particular, + asegúrese de que el acceso a ésta URL (la de configuración del balanceador) + esté altamente restringido.

+
+ +

+ Cuando se accede al proxy inverso en la url + (p.e: http://rproxy.example.com/balancer-manager/, verá una + página similar a la siguiente: +

+

balancer-manager page

+ +

+ Este formulario permite al administrador ajustar varios parámetros, desactivar + workers, cambiar los métodos de balanceo de carga y añadir nuevos workers. + Por ejemplo, haciendo clic en el balanceador, verá la siguiente página: +

+

balancer-manager page

+ +

+ Y haciendo clic en el worker, mostrará esta página: +

+

balancer-manager page

+ +

+ Para hacer que estos cambios sean persistentes en los reinicios del proxy + inverso, asegúrese de que BalancerPersist está activado. +

+ +
top
+
+

Comprobaciones de estado dinámicas

+ + +

+ Antes de que httpd haga proxy de una petición a un worker, puede "comprobar" + si ese worker está disponible mediante el parámetro de configuración ping + para ese worker usando ProxyPass. + A menudo es más útil comprobar el estado de los workers no disponibles, + con un método dinámico. Esto se consigue con el módulo mod_proxy_hcheck. +

+ +
top
+
+

Marcas de estado de los Miembros del Balanceador

+ + +

+ En el balancer-manager el estado actual, o status, de un worker + se muestra y puede ser configurado/reseteado. El significado de estos estados es el siguiente: +

+ + + + + + + + + + + +
MarcaCadenaDescripción
 OkEl Worker está disponible
 InitEl Worker ha sido inicializado
DDisEl Worker está + desactivado y no aceptará peticiones; se intentará reutilizar automáticamente.
SStopEl Worker ha sido desactivado por el + administrador; no aceptará peticiones y no se reintentará utilizar automáticamente
IIgnEl Worker está en modo "ignore-errors" (obviar-errores) y estará siempre en modo disponible.
HStbyEl Worker está en modo "hot-standby" y sólo se usará si no hay otros workers disponibles.
EErrEl Worker está en estado de error, + generalmente debido a fallos de comprobación antes de enviar peticiones; no se hará + proxy de peticiones a este worker, pero se reintentará el uso de este worker + dependiendo de la configuración del parámetro retry.
NDrnEl Worker está en modo vaciado y sólo aceptará + sesiones activas previamente destinadas a él mismo y obviará el resto de peticiones.
CHcFlLa comprobación dinámica del estado del Worker + ha fallado y no se usará hasta que pase las comprobaciones de estado posteriores.
+
+
+

Idiomas disponibles:  en  | + es 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+//--> \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.en b/docs/manual/howto/ssi.html.en index b1c45647fe..cf7138f4c9 100644 --- a/docs/manual/howto/ssi.html.en +++ b/docs/manual/howto/ssi.html.en @@ -332,9 +332,7 @@ modified?

Executing commands

-

I expect that I'll have an article some time in the coming - months about using SSI with small CGI programs. For now, here's - something else that you can do with the exec +

Here's something else that you can do with the exec function. You can actually have SSI execute a command using the shell (/bin/sh, to be precise - or the DOS shell, if you're on Win32). The following, for example, will give you diff --git a/docs/manual/howto/ssi.html.fr b/docs/manual/howto/ssi.html.fr index 33cbf77629..2088094648 100644 --- a/docs/manual/howto/ssi.html.fr +++ b/docs/manual/howto/ssi.html.fr @@ -30,6 +30,8 @@  ja  |  ko 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

Les SSI permettent d'ajouter du contenu dynamique à des documents HTML préexistants.

diff --git a/docs/manual/howto/ssi.xml.fr b/docs/manual/howto/ssi.xml.fr index 669c9bef4d..6fa2876e2d 100644 --- a/docs/manual/howto/ssi.xml.fr +++ b/docs/manual/howto/ssi.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/ssi.xml.ja b/docs/manual/howto/ssi.xml.ja index 96c71bc00b..5cfe9bd574 100644 --- a/docs/manual/howto/ssi.xml.ja +++ b/docs/manual/howto/ssi.xml.ja @@ -1,7 +1,7 @@ - + +