Balanceo de carga con nginx a dos WebAPP de Azure

En el post anterior vimos como instalar un servidor nginx. Una de las capacidades que tiene ngin-x es ser un potente servidor proxy, utilizado como balanceador de carga. En este post vamos a ver como usarlo para balancear la carga de dos WebAPPs (podrían ser tantas como fueran necesarias). Este escenario presenta una particularidad que obliga a modificar ligeramente el procedimiento normal para esta operación.

Partimos de una máquina linux con ngin-x instalado, tal como se vió en el post anterior.

Además vamos a crear dos WebAPPs simples, con un mensaje que nos diferencie entre cada una de ellas por ejemplo, tal como se ve en las siguientes imágenes:

20160505_NGINX_WebAPP_Paso02

20160505_NGINX_WebAPP_Paso03

A continuación vamos a configurar ngin-x siguiendo las pautas normales. Entramos al servidor linux en una consola de comando y editamos el fichero de congiguración con nano por ejemplo:

sudo nano /etc/nginx/nginx.conf

Y modificamos el script para que quede como el siguiente código:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
     worker_connections 768;
     # multi_accept on;
}

http {
     upstream bloqueprimerproxy {
          server xxURL1xx.azurewebsites.net;
          server xxURL2xx.azurewebsites.net;
     }

     server {
          listen 80;
          server_name   localhost;

          location / {
               proxy_pass http://bloqueprimerproxy;
               proxy_set_header  X-Real-IP  $remote_addr;
          }
     }
}

En donde xxURL1xx.azurewebsites.net y xxURL2xx.azurewebsites.net son las URLs de las dos WebAPPs a balancear.

Grabamos el código y reiniciamos el servicio ngin-x con:

sudo service nginx restart

El script anterior sería la forma normal de balancear dos WEBs con ngin-x. Pero si lo probamos ahora obtendremos el siguiente error:

20160505_NGINX_WebAPP_Paso01

Ésto se debe a que Azure App Service usa cookies para ARR (Application Request Routing). Es necesario asegurarse que el proxy pasa la cabecera de forma correcta a la WebAPP para que ésta identifique la petición correctamente.

Para esto editamos de nuevo el fichero de configuración y lo dejamos como sigue:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
     worker_connections 768;
     # multi_accept on;
}

http {
     upstream bloqueprimerproxy {
         server localhost:8001;
         server localhost:8002;
     }

     upstream servidor1 {
         server xxURL1xx.azurewebsites.net;
     }

     upstream servidor2 {
         server xxURL2xx.azurewebsites.net;
     }

     server {
          listen 80;
          server_name   localhost;

          location / {
               proxy_pass http://bloqueprimerproxy;
               proxy_set_header    X-Real-IP    $remote_addr;
          }
     }

     server {
          listen 8001;
          server_name   servidor1;

          location / {
               proxy_set_header Host xxURL1xx.azurewebsites.net;
               proxy_pass http://servidor1;
          }
     }

     server {
          listen 8002;
          server_name   servidor2;

          location / {
               proxy_set_header Host xxURL2xx.azurewebsites.net;
               proxy_pass http://servidor2;
          }
     }
}

En donde igual que antes xxURL1xx.azurewebsites.net y xxURL2xx.azurewebsites.net son las URLs de las dos WebAPPs a balancear.

En este script lo que hacemos es aplicar un doble proxy, de tal forma que balanceamos la entrada contra el mismo ngin-x, atacando por los puertos 8001 y 8002, del cual encaminamos a las WebAPPs, pero añadiendo a la cabecera la URL real de la WebAPP.

Tras grabar el script y reiniciar el servicio ngin-x, si entramos al mismo veremos que nos balancea de una a otra web sin problema.

Para saber más sobre los modos de balanceo disponibles en ngin-x podeis consultar este enlace.

 

 

Instalación de NGINX en una VM Linux Ubuntu 16.04 en Azure

En éste post vamos a ver como instalar nginx en una máquina virtual Linux Ubuntu 16.04 LTS en Azure. Se trata de uno de los mejores servidores HTTP y proxy inversos, además de ser también un proxy IMAP/POP3. Es de código abierto.

Vamos a suponer que ya tenemos desplegada la máquina virtual linux en un estado básico. Si no, como resumen, los pasos serían:

– Crear una máquina virtual desde la galería con Ubuntu 16.04. Puedes ver mi post sobre creación de VM linux.
– Cambiar el puerto ssh por defecto. Tienes instrucciones para hacerlo en Azure en mi post al respecto.
– Actualizar el sistema, conectándonos a una sesión de consola y ejecutando:

sudo apt-get update
sudo apt-get upgrade

Éste paso siempre es recomendable antes de instalar algún paquete (salvo servidores de producción con paquetes productivos previos que habrá que estudiar si es o no conveniente).

Como vamos a instalar un servidor HTTP, si disponéis de un servidor http previo como Apache, tenéis que desinstalarlo para evitar conflictos.

Una vez con la máquina lista para instalar nginx, desde la consola ssh ejecutamos:

sudo apt-get install nginx

Y por último iniciamos el servicio nginx con:

sudo systemctl start nginx

Comprobamos que el servicio está activo con:

sudo service nginx status

Lo que ofrece información del servicio que será similar a la siguiente pantalla:

20160505_Install_NGINX_Paso02

Ya tendríamos instalado nginx, con su configuración por defecto al puerto 80. Si entramos a la máquina por dicho puerto nos aparecerá la siguiente página de cortesía:

20160505_Install_NGINX_Paso03

Para más información sobre nginx podéis acceder a su página en éste enlace.

Cambio de puertos SSH y XRDP en una máquina virtual Linux en Azure

Una recomendación básica de seguridad es cambiar los puertos de conexionado por defecto de un sistema para los distintos servicios de comunicaciones disponibles. Vamos a ver como cambiar el puerto ssh y xrdp en una máquina virtual Linux en Azure.

Cambio de puerto ssh

Nada más crear la máquina virtual, el puerto por defecto es el 22. Conectamos a la máquina por medio de su IP o DNS público con un cliente tipo Putty a través de dicho puerto. Editamos el fichero de configuración con nano por ejemplo:

sudo nano /etc/ssh/sshd_config

Y modificamos donde pone el puerto 22 por el valor que deseemos (por ejemplo yo he puesto 40167):

20160401_CambioSSH_Paso02

Ahora es necesario reiniciar el servicio ssh. Ejecutamos:

sudo service ssh restart

Cerramos la sesión remota que estamos ejecutando, que todavía irá por el puerto 22. Ahora tenemos que editar la regla de seguridad en el panel de control de la máquina virtual para reflejar el cambio de puerto. Para ello, buscamos la máquina en nuestra suscripción de Azure, por ejemplo, en mi caso se llama f23uh4733:

20160401_CambioSSH_Paso04

Pulsamos en la opción de reglas de seguridad de entrada:

20160401_CambioSSH_Paso05

Y hacemos doble clic sobre la regla actual del puerto 22:

20160401_CambioSSH_Paso06

Y modificamos el valor del puerto 22 al puerto definido en el fichero de configuración:

20160401_CambioSSH_Paso07

Pulsando grabar tras la modificación. La regla tardará unos segundos en estar aplicada.

Instalación de un escritorio remoto y cambio de puerto xrdp

Ahora vamos a instalar un escritorio remoto. Ésto será necesario si nuestra imagen de Linux es tipo servidor por ejemplo. Hay que tener en cuenta que xrdp en Ubuntu desde la versión 12.04LTS no soporta Gnome Desktop, por lo que usaremos xfce.

Primero instalamos xrdp, para lo que ejecutamos el siguiente comando en la línea de terminal:

sudo apt-get install xrdp

20160401_CambioSSH_Paso08

Una vez concluida la instalación de xrdp, instalamos xfce, ejecutando el comando:

sudo apt-get install xfce4

20160401_CambioSSH_Paso09

El siguiente paso es configurar xrdp para que use xfce. Ejecutamos el siguiente comando:

echo xfce4-session >~/.xsession

20160401_CambioSSH_Paso10

Una vez instalado el escritorio, vamos a cambiar el puerto por defecto de conexión remota. Usamos un editor, por ejemplo nano, para modificar el fichero de configuración de xrdp. Ejecutamos el comando:

sudo nano /etc/xrdp/xrdp.ini

Y modificamos el puerto con el valor deseado, en éste caso por ejemplo al puerto 40168:

20160401_CambioSSH_Paso12

Grabamos los cambios y reiniciamos el servicio xrdp para que surtan efecto, mediante el siguiente comando:

sudo service xrdp restart

20160401_CambioSSH_Paso13

Una vez tenemos configurado el puerto, al igual que antes, tenemos que crear la regla de seguridad que nos permita acceder. Para ello volvemos al listado de reglas de entrada, y pulsamos el botón añadir:

20160401_CambioSSH_Paso14

Y añadimos una regla indicando el puerto destino que hayamos configurado en el paso anterior:

20160401_CambioSSH_Paso15

Pulsamos grabar y esperamos a que la regla se aplique. Posteriormente ya podemos abrir una conexión por escritorio remoto contra la máquina por el puerto:

20160401_CambioSSH_Paso16

Nos tendremos que identificar con un usuario UNIX. Si no hemos creado ninguno, el usuario administrador nos serviría:

20160401_CambioSSH_Paso17

Y accederíamos al escritorio de la máquina Linux:

20160401_CambioSSH_Paso18

 

Linux_Azure_Creation

Crear una máquina virtual Linux en Azure

Dentro del marketplace de Azure nos encontramos múltiples imágenes listas para desplegar. Entre ellas están varias distribuciones de Linux creadas por varias compañías, con varios paquetes ya preinstalados llegado el caso.

Creación de una máquina virtual Linux

Vamos a ver el proceso completo de aprovisionamiento de una máquina virtual (IaaS) con una imagen de Canonical de Ubuntu Server 15.10.

Paso 1

Entramos en nuestra suscripción de Azure y pulsamos sobre máquinas virtuales:

20160311_CreaciónVM_Paso01

Paso 2

Pulsamos en agregar nueva máquina virtual:

20160311_CreaciónVM_Paso02

Paso 3

Buscamos por Ubuntu y seleccionamos la imagen Ubuntu Server 15.10 de Canonical:

20160311_CreaciónVM_Paso03

Paso 4

Nos aparece la descripción de la imagen, en donde podremos seleccionar si la queremos en modo clásico o administrador de recursos. Vamos a elegir administrador de recursos. Puedes consultar las diferencias en éste enlace. Pulsamos crear para iniciar el proceso de provisión:

20160311_CreaciónVM_Paso04

Paso 5

Rellenamos los datos básicos de la máquina, con especial atención a la zona geográfica de despliegue y el grupo de recursos al que asignarla. Seleccionar la ubicación más cercana a donde queráis dar el servicio o aquella en donde tengáis todo vuestro CPD virtual.

Respecto al grupo de recursos, recordad que todo lo que metáis dentro no se reiniciará de forma simultánea ante mantenimientos, por lo que su uso es para situaciones de alta disponibilidad.

En éste paso definiréis el usuario y contraseña root, así que asegurad que los datos son correctos.

Una vez relleno todo pulsáis aceptar.

20160311_CreaciónVM_Paso05

Paso 6

Ahora seleccionar el tamaño, lo que define el coste de la máquina. Elegid el que necesitéis en función del uso estimado. La serie DS, con discos SSD, son apropiados para servicios LAMP por ejemplo.

20160311_CreaciónVM_Paso06

Paso 7

Toca configurar opciones adicionales, como la red, tipo de almacenamiento y otros. Al terminar pulsad aceptar. Si no conocéis todavía estos conceptos en Azure, las opciones por defecto os servirán para empezar.

20160311_CreaciónVM_Paso07

Paso 8

Se presenta un resumen del proceso y se solicita una última confirmación. Si está todo bien, pulsar aceptar y se comenzará a aprovisionar la máquina. Si no, podéis volver hacia atrás para corregir.

Creación VM Ubuntu

En el área de notificaciones tendréis un aviso del progreso del proceso, al igual que en el panel principal.

Una vez concluido el despliegue, lo que puede llevar unos 5 a 10 minutos, podéis conectar por SSH con un cliente tipo Putty, usando la IP pública de la máquina y contra el puerto 22, con el usuario root definido en las opciones básicas del paso 5.

Sin embargo dicha configuración por defecto no es la más segura. En un próximo post veremos como cambiar los puertos por defecto e instalar un escritorio para acceso remoto. Posteriormente veremos como configurar al servidor para convertirlo es un stack LAMP.