En entradas anteriores se ha visto el modo de instalar un servidor de red Nginx y un contenedor de red Tomcat. También se ha comentado que el segundo solía ir conectado al primero (o a un servidor de red Apache), y que otra función de Nginx era crear proxys inversos con diferentes finalidades.
Pero, ¿qué es un proxy inverso?, pues nada menos que un tipo de servidor proxy que recupera recursos en nombre de un cliente desde uno o más servidores. Estos recursos son entonces devueltos al cliente como si se originaran en el propio servidor de red. Por lo tanto, el proxy inverso es un intermediario para que sus servidores asociados sean contactados por cualquier cliente.
Para ejemplificar esta explicación se ha empleado el servidor Debian 9 Stretch como sistema operativo base, el Nginx 1.14 como servidor de proxy inverso, y el contenedor de red Tomcat 8.
location / {
proxy_buffering off;
proxy_store off;
proxy_request_buffering off;
proxy_redirect off;
proxy_connect_timeout 7200;
proxy_send_timeout 7200;
proxy_read_timeout 7200;
proxy_pass http://<dirección IP:puerto de Tomcat>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port <puerto al que se redirigirá>;
proxy_hide_header Strict-Transport-Security;
proxy_set_header Host $http_host;
}
El ingrediente estrella en esta configuración es el uso del módulo "proxy_pass" incluido en el Core de Nginx, y es la directiva que nos permite pasar la petición que nos llega hacia otro destino, en este caso, el servidor web donde se aloja nuestra supuesta aplicación. El resto de los módulos son opcionales, pero, para crear el proxy inverso, debe estar siempre el antes mencionado. De este modo el archivo "default" queda como se puede ver en la siguiente imagen.
Tras guardar y salir de la edición del archivo, se creará su respectivo enlace simbólico (si no lo tiene ya), se reiniciará Nginx [comando systemctl restart nginx (anteponiendo sudo si no se es administrador)], y se editará el archivo "server.xml" de Tomcat, donde se escribirán las siguientes líneas tal y como muestra la imagen (variando los parámetros obvios).
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="200" minSpareThreads="100"/>
<Connector executor="tomcatThreadPool"
port="<puerto de Tomcat>" protocol="HTTP/1.1"
redirectPort="8443"
connectionTimeout="300000"
address="<IP de Tomcat>"
maxPostSize="838860800"
connectionUploadTimeout="36000000"
disableUploadTimeout="false"
URIEncoding="UTF-8"
useBodyEncodingForURI="true"
acceptorThreadCount="2"
acceptCount="500" />
Como puede verse, el puerto de la aplicación será "8085", y su dirección IP será "192.168.0.11". Tras guardar y salir del fichero recién modificado, se reiniciará Tomcat [comando systemctl restart tomcat (anteponiendo sudo si no se es administrador)].
Puede probarse el resultado de la redirección escribiendo la IP y el puerto de Tomcat en la barra de direcciones de un navegador de red y comprobando que se ve la pantalla de inicio de este contenedor de red.
En primer lugar, debe recordarse que en el directorio de Tomcat existen dos carpetas donde se pueden guardar las aplicaciones: "webapps", para desplegarlas automáticamente mediante archivos JAR (".war"), o bien "srv", donde se pueden desplegar manualmente.
Bien, un archivo JAR es un tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java. Aquel que tiene la extensión ".war", llamado "Archivo de Aplicación de Red ("Web Application Archive", en inglés)", contiene páginas jsp, html, javascript, servlets y otros ficheros necesarios para el despliegue de estas aplicaciones en contenedores de red.
En segundo lugar, los siguientes pasos se deben realizar después de haber configurado correctamente el Nginx para añadir un dominio (en este ejemplo se utilizará el dominio agregado durante la explicación sobre la instalación y configuración de este servidor de red, "svelb1.net").
1. Despliegue automático de archivos de aplicación de red
Es el método más rápido de desplegar una aplicación de red en Tomcat, pero tiene el inconveniente de que el usuario pierde el control sobre ciertos aspectos de la configuración, puesto que el propio programa configura todo a su manera según las directrices predeterminadas del propio archivo.
Primeramente, hay que detener el contenedor web [comando systemctl stop tomcat (anteponiendo sudo si no se es administrador)], y copiar el archivo ".war" en el directorio "webapps", que se aloja dentro del directorio donde se encuentre instalado Tomcat [comando cp <archivo.war> <ruta de Tomcat>/webapps (anteponiendo sudo si no se es administrador)].
Si es necesario, se añaden roles y usuarios a la aplicación editando el archivo "tomcat-users.xml", alojado en el directorio "conf" del Tomcat. Para ello, se debe descomentar el último bloque de dicho archivo (o escribir uno nuevo igual pero descomentado), y escribir los datos necesarios en los campos apropiados (los que se ven entre los símbolos "<...>" en la imagen).
Seguidamente, se inicia el contenedor de red mediante el comando systemctl start tomcat (anteponiendo sudo si no se es administrador).
Si, por algún motivo, la aplicación no está funcionando tras este proceso, se puede detener nuevamente el Tomcat, borrar el archivo y la carpeta creada por él de "webapps", lanzarlo mediante el comando jar cvf \<archivo.war> * y copiar la carpeta posterior en dicho directorio; las opciones utilizadas con el comando son: "c" (crear archivo), "v" (generar salida detallada) y "f" (especificar nombre del archivo de almacenamiento), el "*" hace referencia a la inclusión de todos los archivos y carpetas que contiene la carpeta actual. Finalmente, se inicia Tomcat.
2. Despliegue manual de la aplicación
Este se puede hacer desde un archivo de aplicación de red, o bien utilizando directamente el directorio donde se aloja la aplicación. Ambos métodos son iguales excepto en que el archivo debe descomprimirse antes de introducirlo en el contenedor de red.
Por lo tanto, el primer paso es crear un directorio llamado "ROOT" [comando mkdir -p ROOT (anteponiendo sudo si no se es administrador)], y descomprimir el archivo de aplicación de red (descargado, por ejemplo del siguiente enlace, o creado) en el directorio recién creado mediante el comando unzip <archivo.war> -d ROOT (anteponiendo sudo si no se es administrador) (en el ejempo, el archivo se llama "sample.war").
Acto seguido, se detiene el Tomcat, se creará un directorio con nombre significativo (en este ejemplo será "svelb1.net") dentro del directorio "srv" de este programa [comando mkdir -p svelb1.net (anteponiendo sudo si no se es administrador)]. Luego, se copia el directorio "ROOT" con la aplicación dentro en el interior del directorio recién creado y, si es necesario, se cambia todo de propietario para que este sea el usuario "tomcat" [comando chown -R tomcat:tomcat ROOT (anteponiendo sudo si no se es administrador)].
Finalmente, se crea el directorio virtual donde se podrá ver el resultado posteriormente. Dicho directorio se crea editando el archivo "server.xml" (dentro del directorio "conf" del Tomcat), y añadiendo en él una directiva "<Host>" con las siguientes líneas:
<Host name="<nombre del dominio>" appBase="/opt/<directorio de Tomcat>/srv/<directorio de aplicación>" unpackWARs="false" autoDeploy="false"
debug="0" xmlnamespaceaware="false" xmlvalidation="false">
<Context path="/" docBase="/opt/<directorio de tomcat>/srv/<directorio de aplicación>/ROOT" debug="0" />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="<nombre significativo>_logs_access_log" suffix=".log" pattern='%h | %t | "%r" | %s | %b | %T | %S | %u ' />
</Host>
La siguiente imagen ejemplifica el empleo de las líneas que se acaban de mostrar (el nombre del dominio es "svelb1.net", lo que se utiliza como nombre representativo en las secciones adecuadas).
Este bloque de comandos debe ir situado dentro de la directiva "<Engine>", que, a su vez, está dentro de la directiva "<Service>", que se encuentra en el interior de la directiva "<server>".
Naturalmente, si se desea que en el navegador de red se pueda acceder a la aplicación por el nombre de dominio, hay que añadir la línea correspondiente en el archivo "hosts" del directorio "etc" del equipo donde se encuentre instalado el Tomcat (en el ejemplo, el dominio "svelb1.net" se encuentra unido a la dirección IP "192.168.0.11").
Por último, se inicia el contenedor de red (y, si hace falta, se reinicia el Nginx antes) para que los cambios tengan efecto, con el comando antes mencionado para tal circunstancia.
Independientemente del método a utilizar para desplegar la aplicación en Tomcat, puede comprobarse el resultado accediendo a su dirección IP y su puerto, o bien a su nombre de dominio, escribiendo unos u otro en la barra de direcciones de dicho navegador.
Espero que esta entrada haya sido del gusto del lector. En caso afirmativo, aguardo que la comente y/o la comparta, por favor.
Pero, ¿qué es un proxy inverso?, pues nada menos que un tipo de servidor proxy que recupera recursos en nombre de un cliente desde uno o más servidores. Estos recursos son entonces devueltos al cliente como si se originaran en el propio servidor de red. Por lo tanto, el proxy inverso es un intermediario para que sus servidores asociados sean contactados por cualquier cliente.
Para ejemplificar esta explicación se ha empleado el servidor Debian 9 Stretch como sistema operativo base, el Nginx 1.14 como servidor de proxy inverso, y el contenedor de red Tomcat 8.
CONFIGURACIÓN DEL PROXY INVERSO
Con el servidor Nginx y el contenedor de red Tomcat instalados y bien configurados, se comienza editando un archivo de configuración en "sites-available" dentro del directorio del primero (en este ejemplo, se editará el archivo "default", que es más rápido, pero se puede crear cualquier otro dentro de esa misma carpeta). En dicho archivo, se deben comentar las líneas "root" e "index" (poniendo una "#" al principio de cada una de ellas), y escribir la siguiente directiva "<location>" dentro de la directiva "<server>":location / {
proxy_buffering off;
proxy_store off;
proxy_request_buffering off;
proxy_redirect off;
proxy_connect_timeout 7200;
proxy_send_timeout 7200;
proxy_read_timeout 7200;
proxy_pass http://<dirección IP:puerto de Tomcat>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port <puerto al que se redirigirá>;
proxy_hide_header Strict-Transport-Security;
proxy_set_header Host $http_host;
}
El ingrediente estrella en esta configuración es el uso del módulo "proxy_pass" incluido en el Core de Nginx, y es la directiva que nos permite pasar la petición que nos llega hacia otro destino, en este caso, el servidor web donde se aloja nuestra supuesta aplicación. El resto de los módulos son opcionales, pero, para crear el proxy inverso, debe estar siempre el antes mencionado. De este modo el archivo "default" queda como se puede ver en la siguiente imagen.
Tras guardar y salir de la edición del archivo, se creará su respectivo enlace simbólico (si no lo tiene ya), se reiniciará Nginx [comando systemctl restart nginx (anteponiendo sudo si no se es administrador)], y se editará el archivo "server.xml" de Tomcat, donde se escribirán las siguientes líneas tal y como muestra la imagen (variando los parámetros obvios).
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="200" minSpareThreads="100"/>
<Connector executor="tomcatThreadPool"
port="<puerto de Tomcat>" protocol="HTTP/1.1"
redirectPort="8443"
connectionTimeout="300000"
address="<IP de Tomcat>"
maxPostSize="838860800"
connectionUploadTimeout="36000000"
disableUploadTimeout="false"
URIEncoding="UTF-8"
useBodyEncodingForURI="true"
acceptorThreadCount="2"
acceptCount="500" />
Como puede verse, el puerto de la aplicación será "8085", y su dirección IP será "192.168.0.11". Tras guardar y salir del fichero recién modificado, se reiniciará Tomcat [comando systemctl restart tomcat (anteponiendo sudo si no se es administrador)].
Puede probarse el resultado de la redirección escribiendo la IP y el puerto de Tomcat en la barra de direcciones de un navegador de red y comprobando que se ve la pantalla de inicio de este contenedor de red.
INSTALACIÓN DE APLICACIÓN EN TOMCAT
Ahora que se sabe que funciona el proxy inverso entre Nginx y Tomcat, se explicará cómo instalar una aplicación, que será servida a través del proxy inverso del primero, en este último.En primer lugar, debe recordarse que en el directorio de Tomcat existen dos carpetas donde se pueden guardar las aplicaciones: "webapps", para desplegarlas automáticamente mediante archivos JAR (".war"), o bien "srv", donde se pueden desplegar manualmente.
Bien, un archivo JAR es un tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java. Aquel que tiene la extensión ".war", llamado "Archivo de Aplicación de Red ("Web Application Archive", en inglés)", contiene páginas jsp, html, javascript, servlets y otros ficheros necesarios para el despliegue de estas aplicaciones en contenedores de red.
En segundo lugar, los siguientes pasos se deben realizar después de haber configurado correctamente el Nginx para añadir un dominio (en este ejemplo se utilizará el dominio agregado durante la explicación sobre la instalación y configuración de este servidor de red, "svelb1.net").
1. Despliegue automático de archivos de aplicación de red
Es el método más rápido de desplegar una aplicación de red en Tomcat, pero tiene el inconveniente de que el usuario pierde el control sobre ciertos aspectos de la configuración, puesto que el propio programa configura todo a su manera según las directrices predeterminadas del propio archivo.
Primeramente, hay que detener el contenedor web [comando systemctl stop tomcat (anteponiendo sudo si no se es administrador)], y copiar el archivo ".war" en el directorio "webapps", que se aloja dentro del directorio donde se encuentre instalado Tomcat [comando cp <archivo.war> <ruta de Tomcat>/webapps (anteponiendo sudo si no se es administrador)].
Si es necesario, se añaden roles y usuarios a la aplicación editando el archivo "tomcat-users.xml", alojado en el directorio "conf" del Tomcat. Para ello, se debe descomentar el último bloque de dicho archivo (o escribir uno nuevo igual pero descomentado), y escribir los datos necesarios en los campos apropiados (los que se ven entre los símbolos "<...>" en la imagen).
Seguidamente, se inicia el contenedor de red mediante el comando systemctl start tomcat (anteponiendo sudo si no se es administrador).
Si, por algún motivo, la aplicación no está funcionando tras este proceso, se puede detener nuevamente el Tomcat, borrar el archivo y la carpeta creada por él de "webapps", lanzarlo mediante el comando jar cvf \<archivo.war> * y copiar la carpeta posterior en dicho directorio; las opciones utilizadas con el comando son: "c" (crear archivo), "v" (generar salida detallada) y "f" (especificar nombre del archivo de almacenamiento), el "*" hace referencia a la inclusión de todos los archivos y carpetas que contiene la carpeta actual. Finalmente, se inicia Tomcat.
2. Despliegue manual de la aplicación
Este se puede hacer desde un archivo de aplicación de red, o bien utilizando directamente el directorio donde se aloja la aplicación. Ambos métodos son iguales excepto en que el archivo debe descomprimirse antes de introducirlo en el contenedor de red.
Por lo tanto, el primer paso es crear un directorio llamado "ROOT" [comando mkdir -p ROOT (anteponiendo sudo si no se es administrador)], y descomprimir el archivo de aplicación de red (descargado, por ejemplo del siguiente enlace, o creado) en el directorio recién creado mediante el comando unzip <archivo.war> -d ROOT (anteponiendo sudo si no se es administrador) (en el ejempo, el archivo se llama "sample.war").
Acto seguido, se detiene el Tomcat, se creará un directorio con nombre significativo (en este ejemplo será "svelb1.net") dentro del directorio "srv" de este programa [comando mkdir -p svelb1.net (anteponiendo sudo si no se es administrador)]. Luego, se copia el directorio "ROOT" con la aplicación dentro en el interior del directorio recién creado y, si es necesario, se cambia todo de propietario para que este sea el usuario "tomcat" [comando chown -R tomcat:tomcat ROOT (anteponiendo sudo si no se es administrador)].
Finalmente, se crea el directorio virtual donde se podrá ver el resultado posteriormente. Dicho directorio se crea editando el archivo "server.xml" (dentro del directorio "conf" del Tomcat), y añadiendo en él una directiva "<Host>" con las siguientes líneas:
<Host name="<nombre del dominio>" appBase="/opt/<directorio de Tomcat>/srv/<directorio de aplicación>" unpackWARs="false" autoDeploy="false"
debug="0" xmlnamespaceaware="false" xmlvalidation="false">
<Context path="/" docBase="/opt/<directorio de tomcat>/srv/<directorio de aplicación>/ROOT" debug="0" />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="<nombre significativo>_logs_access_log" suffix=".log" pattern='%h | %t | "%r" | %s | %b | %T | %S | %u ' />
</Host>
La siguiente imagen ejemplifica el empleo de las líneas que se acaban de mostrar (el nombre del dominio es "svelb1.net", lo que se utiliza como nombre representativo en las secciones adecuadas).
Este bloque de comandos debe ir situado dentro de la directiva "<Engine>", que, a su vez, está dentro de la directiva "<Service>", que se encuentra en el interior de la directiva "<server>".
Naturalmente, si se desea que en el navegador de red se pueda acceder a la aplicación por el nombre de dominio, hay que añadir la línea correspondiente en el archivo "hosts" del directorio "etc" del equipo donde se encuentre instalado el Tomcat (en el ejemplo, el dominio "svelb1.net" se encuentra unido a la dirección IP "192.168.0.11").
Por último, se inicia el contenedor de red (y, si hace falta, se reinicia el Nginx antes) para que los cambios tengan efecto, con el comando antes mencionado para tal circunstancia.
Independientemente del método a utilizar para desplegar la aplicación en Tomcat, puede comprobarse el resultado accediendo a su dirección IP y su puerto, o bien a su nombre de dominio, escribiendo unos u otro en la barra de direcciones de dicho navegador.
Espero que esta entrada haya sido del gusto del lector. En caso afirmativo, aguardo que la comente y/o la comparta, por favor.
No hay comentarios:
Publicar un comentario
Deje aquí su comentario, si no puede comentar, pruebe a hacerlo desde otro navegador de red u otro equipo.