Vamos a avanzar en esta ultima parte de la serie, como prometimos, e intentaremos abordar -paso a paso-, con el máximo detalle, la puesta en marcha de este escenario que planteamos, toda vez que nuestra primera entrada nos permitió dar una introducción rápida pero no pudimos ver el detalle de pasos a seguir, que sin duda os ayudará. Esta entrada va dirigida especialmente a los que dais vuestros primeros pasos, como siempre, que sois quien mas ayuda necesitáis. Podéis acceder al enlace a la primera parte de la serie:  Taller práctico: Curioseando en AWS y DataSnap (1/2)

Así que me he armado de paciencia y me he dispuesto a repetir todo el proceso nuevamente, desde la creación de la instancia hasta que el servicio de DataSnap estaba exponiendo datos desde la Nube. Y en cada paso, he hecho una captura, incluyendo al final un video que os muestra básicamente, como se estaba ejecutando el servidor de datansap y enlazaba con el cliente abierto en mi herramienta de desarrollo, tras insertar la ip publica de acceso, vía tcp/ip.

Por supuesto que a estas horas, tras las capturas e iniciar la escritura de estas lineas, los recursos creados, incluyendo instancias EC2, pares de claves y contraseñas, direcciones ip o das, etc, se eliminaron y no puedo repetir ni corregir nada de lo que se pueda haber capturado. El video solo tiene unos minutos pero lo suficiente para que veáis que se produce la conexión entre la capa cliente y el servidor de datasnap.

Respecto a la imagen que compartíamos y que esquematizaba el escenario, me quedaba la idea de que podía resultar un tanto vaga por lo que me vais a permitir que hagamos un par de cambios. Ayudado de la aplicación rediseño el esquema para generar dos ideas muy similares pero un matiz que las hacen distintas.

El primer escenario, un poco mas real que esa primera imagen, situaría nuestra capa de datos en algún lugar de Internet, posiblemente en un servidor compartido, que sería accedido por un servidor de DataSnap ubicado en la Nube. En la parte inferior, he situado lo que representa a una Red, que también es alimentada desde los servicios del Servidor ubicado en su interior. Es mas similar a la situación que planteaba Germán en su serie.

Esta es la imagen:

 

La segunda es similar, pero el matiz es que hemos ubicado nuestra capa de datos en el interior de la Red, que representa a la Empresa que la esta explotando, y que interpone entre los clientes externos y el servidor de BBDD la capa del Servicio de DataSnap en la Nube.

Estos despliegues, nos podrían permitir establecer reglas concretas de acceso al firewall que protege al sistema en el que se ubica la BBDD, toda vez que únicamente nuestros servicios de DataSnap van a estar autorizados a su acceso y puede generarse reglas adecuadas para autorizar o denegar la comunicación. En este esquema, nunca se accedería de forma directa a nuestra BBDD, al menos desde fuera de nuestra RED local. Desde dentro de la RED siempre va a haber alguien que mande mas que nosotros y que pervertirá nuestro sistema.

😀

Preparativos: algunos pasos a seguir…

Nuestro punto de partida es el acceso a lo que sería el tablero de administración del servicio de EC2, que es la imagen que a continuación podéis ver.

Así que vamos a empezar. Parto del supuesto de que os habéis registrado ya en AWS y que habéis iniciado el proceso de activación del servicio de EC2, que os obligará necesariamente a aportar una tarjeta de crédito. Esto os dará acceso a la zona de administración referida (*).

(*) ¡Ya! Imagino lo que pensáis .. A mi tampoco me hace gracia dar una tarjeta de crédito para hacer pruebas, pero si queremos ser parte del sistema y que AWS nos considere usuarios «reales» no nos queda mas remedio que transigir.  Fiel a mi desconfianza en todos sistemas, sobretodo en los que presumen de ser seguros, di mi número de tarjeta cash que tiene un par de eurillos para las emergencias.    😀    ¡Es broma!

Buscad bajo el título Créate Instance, el botón Launch Instance que iniciará el proceso de creación de la instancia de Amazon EC2, nuestro servidor virtual.

El proceso nos llevará a concretar los datos de que tipo de instancia va a ser creada e los detalles de configuración que podamos necesitar ajustar previamente.  En la parte inferior, podéis ver el despliegue de pasos (el pluggin de WordPress os permitirá recorrerlos pulsando en los botones laterales, leyendo los comentarios ubicados en la parte inferior).

Así que adelante. Vamos a crear la instancia:

Entre los enlaces que tenemos a mano en la documentación, os incluyo este para los que todavía tengáis alguna duda de como hacer una conexión remota desde vuestro sistema, Connecting to Windows Instances Using RDP.

El resultado final es el acceso a la maquina virtual, como se puede apreciar por la siguiente imagen:

Ahora ya estamos preparados para subir nuestro exe incluyendo el servicio de DataSnap y lanzar su  ejecución para probarlo. Puede bastar un copia pega si vuestro sistema local es windows y el acceso remoto permite compartir el contenido del portapapeles. En caso contrario, cualquier sistema ingenioso puede ser usado (¡no te cortes en esas minucias! 😛 ).

Mas sabe el diablo por viejo…

 Lo dice el dicho y casi siempre con razón. El diablo sabe mas por viejo que por diablo y metidos en estas harinas, no deberías subir a tu maquina virtual solo el servidor, sino que para esta primera prueba, harías bien en subirte el cliente de datasnap. Mas que nada porque puedes descubrir que, aunque se ejecute correctamente nuestro servicio, la invocación de los primeros metodos desde el cliente haga que emergen los errores de conexión a la capa de datos.

De hecho, guardé tres capturas de los diferentes errores que fueron emergiendo, pasando a dar solución a cada uno de ellos.

El primer error, provenía de que el sistema carecía de los drivers de conexión propios de la parte cliente motor de Sql Server y la advertencia nos hacía pensar en que era necesaria la búsqueda en internet.

En este caso concreto, el servidor de DataSnap del Taller de Delphi Basico, intentaba conectarse a la base de datos de SQL Server ubicada en el servidor compartido de mi dominio y el problema es que no encontraba el cliente de conexión para SQL Server. Así que procedimos a buscarlo

Microsoft SQL Server 2008 Service Pack 3 Feature Pack

Y seguidamente, lo instalamos en la maquina virtual. Podeis seguir los pasos en la siguiente galería de imágenes:

Si que me gustaría resaltar de las imágenes anteriores, que pongáis atención a elegir correctamente el cliente adecuado a 32 o 64 bit. Si os fijáis, el paquete incluye la descarga de ambos y por tanto, podéis accidentalmente confundirlos.

Y seguidamente otros errores menores…

Tras solucionar el problema anterior quizás descubras que falten algunas librerías que tu sistema local encuentra y que en la maquina virtual no existen. Fue el caso de la librería de dbexpress dbxmss.dll que no se encuentra y que posiblemente no habrás advertido de copiar en un momento inicial.

O bien, en la parte cliente, la librería midas.dll, si no se ha enlazado en el ejecutable. Es posible, dependiendo de la naturaleza de tu servidor y de tu cliente, que aparezcan estas librerías u otras.

Hecho esto, y subsanados todos los errores que fueron emergiendo, fui capaz, ¡por fin! de ver ejecutarse en mi maquina virtual mi cliente de DataSnap consumiendo datos del servicio DataSnap en ejecución. Había ganado parte de una batalla y me sentía feliz.

En la captura podeis ver la ventana de acceso a la aplicación que pudimos compartir en el Taller, ejecutándose en el servidor virtual de forma local.

Ganar la batalla y ganar la Guerra.

Estamos ya acabando. ¡No os desespereis!.

Nos quedan dos cosas importantes que no debéis de olvidar

1º Tenemos que revisar el Firewall de Windows de nuestra maquina virtual, para que nuestra aplicación pueda exponer hacia el exterior el puerto de comunicación, y que pueda ser encontrado por el sistema interesado. En nuestro caso, en las reglas avanzadas del Firewall de Windows Server 2012 dimos de alta el puerto 211  en la zona de comunicaciones entrantes.

A partir de ese momento, en teoría deberíamos ser capaces de ver nuestro servicio de datasnap en la red.

De forma similar, nuestra consola de Gestión en la Maquina Virtual, permite crear reglas de acceso y salida, permitiéndonos dotar de mayor seguridad a nuestro despliegue o proyecto.

Esta es una captura de la zona que administra la política de acceso que gestiona la consola de administración de EC2.

En este punto, no deberíamos dejar abiertos, definidos como 0.0.0.0, los accesos RDP.

2º Ahora podemos también establecer determinadas políticas de acceso y seguridad a nivel de firewall y reglas, en lo que atañe a la capa de datos, que puede en alguna medida evitar comprometerse, ya que solo deberíamos permitir el acceso a la capa de datos mas que de los servidores que autoricemos a conectar.

El video finalmente, nos muestra como conecto mi cliente local, desde el entorno de desarrollo, para que apunte al nuevo servidor en la nube, modificando el path de conexión del componente que representa el driver de conexión de datasnap, con la nueva ip.

Espero y deseo que os haya gustado y os pueda ayudar.

Sed felices y buen camino.