Hacer pruebas en local esta bien pero tarde o temprano necesitamos desplegar nuestras aplicaciones en un servidor real y lo mejor es hacerlo cuanto antes para no encontrarnos con sorpresas desagradables por culpa de que el entorno de desarrollo o su configuración no son iguales que las de producción y las cosas funcionan.
Por eso y aprovechando que estoy planeando crear un nuevo tutorial de Angular que se ira unificando con el de Spring Boot (uno de los próximos pasos va a ser precisamente añadir servicios Rest para cambiar la capa de presentación) voy a crear un entorno completo de «producción» con un servidor independiente para la vista (Angular), para el backend (Spring Boot) y para la bd (Mysql de momento) viendo paso a paso el proceso completo desde generar las aplicaciones para desplegarlas en producción y elegir los servidores hasta tener nuestro propio dominio configurado con TLS y con todas las partes conectadas y funcionando.
Elegir el Hosting
La primera tarea que tenemos que hacer es analizar cuáles son las necesidades y el coste que estamos dispuestos a asumir para desplegar nuestra aplicación, por lo tanto no hay una mejor decisión universal.
En este caso me voy a decir por un Cloud VPS, porque aunque a priori por precio el hosting compartido va a ser mejor, con los servidores en la nube tenemos una mayor flexibilidad y también mayor disponibilidad, por lo tanto la posibilidad de escalar fácilmente la aplicación me hace decantarme por los servidores en la nube.
Una vez tomada la decisión de qué camino tomar es hora de buscar y buscar y de preguntar y preguntar para encontrar el proveedor adecuado y la verdad es que la tarea no es fácil pero después de un poco de investigación y algunas recomendaciones me he decidido por clouding.io que ofrece un rendimiento muy bueno, es muy sencillo de configurar, es bastante económico y además está en España, del nivel del soporte no puedo hablar porque no he tenido problemas en las pruebas que he realizado y no lo he necesitado y para hacer las configuraciones para hacer este post tampoco he tenido ningún problema.
Si quieres seguir los pasos del tutorial puedes crearte una cuenta porque al registrarte de dan 5€ de regalo y es más que suficiente para hacer las pruebas que quieras porque como se paga por horas siempre puedes crearte incluso un servidor de 16 cores y 64Gb de ram y luego reducirlo a uno más pequeño, archivarlo para pagar menos (ya que con el servidor archivado sólo pagas por el disco SSD, no la RAM ni la CPU) o incluso borrarlo para que no te cobren nada, creo recordar que al registrarte te piden que metas una tarjeta pero como es un servicio prepago te puedes quedar tranquilo porque aunque se acabe el saldo gratis no te van a cobrar más de lo que cargues en tu cuenta si es que decides hacerlo y si no simplemente tienes que borrar tus servidores y ya está. Si eres un poco paranoico con eso de poner tu tarjeta en «cualquier sitio» te recomiendo que uses Monese o Bnext (este enlace solo funciona desde el movil) que son las que uso yo habitualmente y además te dan 15 y 5€ respectivamente por solicitarlas y a mí también si usas esos enlaces 😉 .
Conseguir un dominio
Aunque para hacer pruebas con tener una IP nos vale perfectamente siempre es mejor tener un dominio que es más fácil de recordar e identificar y cuando queramos publicar nuestra aplicación vamos a necesitar uno. Para registrar un dominio tenemos montones de opciones, basta con buscar en google dominio web y tenemos un montón de webs entre las que elegir y muchas suelen tener ofertas durante el primer año, también tenemos la opción de registrar dominios gratuitos que es la opción que voy a utilizar porque para hacer esta prueba es más que suficiente.
Por lo tanto nos vamos a freenom que ha sido mi elección y buscamos el nombre del dominio que queremos usar y seleccionamos uno de los que son gratis (.tk, .ml, .ga, .cf y .gq).
Para no ser muy original me he quedado con prueba-spring-angular.tk, una vez seleccionado elegimos el periodo de tiempo que lo queremos tener y lo configuramos para que apunte al servidor en el que vamos a desplegar la aplicación Angular que va a ser el que sea visible.
Desplegar aplicación Angular en un servidor cloud VPS
Vamos a empezar por el servidor para desplegar nuestra aplicación Angular.
El proceso para crear nuestros servidores en clouding.io es rápido y sencillo, escogemos un nombre para identificarlo, seleccionamos el SO que queramos (voy a utilizar CentOS 7), seleccionamos los recursos que le queremos asignar, le damos a enviar y en unos 30s tenemos listo nuestro servidor.
Nos conectamos con el cliente SSH (PAC Manager, MobaXterm, PuTTY, …) con el que nos sintamos más cómodos usando su IP pública y empezamos con la configuración.
Como buena práctica antes de nada actualizamos los paquetes instalados en el sistema.
[root@angular-server ~]# sudo yum -y update
A continuación instalamos el servidor web Apache.
[root@angular-server ~]# sudo yum -y install httpd
Comprobamos la versión que hemos instalado y de paso vemos que todo ha ido bien.
[root@angular-server ~]# httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built: Nov 5 2018 01:47:09
Y finalmente lo habilitamos como servicio del sistema, lo arrancamos y probamos en nuestro navegador que al meter la IP o el dominio si lo hemos configurado veamos una pantalla como la siguiente.
[root@angular-server ~]# sudo systemctl enable httpd
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.
[root@angular-server ~]# sudo systemctl start httpd
Vale, ya tenemos el servidor web preparado, bueno en realidad por lo menos deberíamos de activar la compresión y establecer la cache para que todo cargue más rápido, pero para no hacer esto infinito vamos a pasar de ello y vamos a preparar nuestra aplicación de Angular para desplegarla.
Cuando estamos probando la aplicación en local lo normal es utilizar el comando ng serve, pero para un entorno de «verdad» no podemos o no debemos usarlo aunque exista ng serve --prod, por eso hemos instalado un servidor http de verdad, pero no te preocupes que para hacer el despliegue solo hay que ejecutar ng build --prod que nos genera el código en la carpeta dist del proyecto.
Ahora todo lo que tenemos que hacer es subirlo a la carpeta /var/www/html de nuestro servidor usando un cliente ftp. Como no hemos configurado ningún virtualHost en el apache tenemos que subir los archivos que se generaron dentro de la carpeta con el nombre del proyecto dentro de dist.
Ahora ya tenemos desplegada la aplicación, podemos comprobarlo recargando nuestro dominio en el navegador, pero aun no vamos a dar esta parte por finalizada, vamos a ver como instalar un certificado TLS para tener una conexión segura.
Para configurar nuestro certificado primero debemos definir un virtual host creando un archivo en /etc/httpd/conf.d con el nombre que queramos aunque mejor que sea un nombre descriptivo, por ejemplo angular.conf, y le ponemos el siguiente contenido para que siga apuntando a nuestra aplicación:
<VirtualHost *:80>
ServerName prueba-spring-angular.tk
ServerAlias www.prueba-spring-angular.tk
ServerAdmin admin@prueba-spring-angular.tk
DocumentRoot /var/www/html
<Directory /var/www/html>
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
ErrorLog /var/log/httpd/prueba-spring-angular.tk-error.log
CustomLog /var/log/httpd/prueba-spring-angular.tk-access.log combined
</VirtualHost>
Ahora vamos a usar Let’s Encrypt para conseguir un certificado gratis, lo primero es instalar el cliente Certbot.
[root@angular-server ~]# sudo yum install epel-release
[root@angular-server ~]# sudo yum install certbot python2-certbot-apache mod_ssl
Para obtener el certificado ejecutamos el siguiente comando indicando cada uno de los dominios para los que queremos que se genere y automáticamente nos lo deja todo completamente configurado.
[root@angular-server ~]# sudo certbot --apache -d prueba-spring-angular.tk -d www.prueba-spring-angular.tk
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.prueba-spring-angular.tk
http-01 challenge for prueba-spring-angular.tk
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/httpd/conf.d/ssl.conf
Created an SSL vhost at /etc/httpd/conf.d/angular-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/conf.d/angular-le-ssl.conf
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Created redirect file: le-redirect-prueba-spring-angular.tk:443.conf
Redirecting vhost in /etc/httpd/conf.d/angular.conf to ssl vhost in /etc/httpd/conf.d/angular-le-ssl.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://prueba-spring-angular.tk
and https://www.prueba-spring-angular.tk
You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=prueba-spring-angular.tk
https://www.ssllabs.com/ssltest/analyze.html?d=www.prueba-spring-angular.tk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/prueba-spring-angular.tk/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/prueba-spring-angular.tk/privkey.pem
Your cert will expire on 2019-09-23. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the "certonly" option. To non-interactively renew *all* of
your certificates, run "certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
[root@angular-server ~]# sudo systemctl restart httpd
Reiniciamos el Apache y ahora ya si tenemos nuestra aplicación desplegada y funcionando por https con su certificado perfectamente configurado.
Lo malo de estos certificados es que se caducan a los 90 días por lo que lo recomendable es crear una tarea programada que lo intente renovar cada día por ejemplo y así nos evitamos olvidarnos de hacerlo.
[root@angular-server ~]# sudo crontab -e
[root@angular-server ~]# sudo crontab -l
0 0 * * * certbot renew >> /var/log/letencrypt-renew.log
Crear el servidor para la base de datos
El proceso para crear el servidor para la bd es el mismo, vuelvo a elegir un CentOS 7 con los recursos mínimos y lo creo, bueno… en realidad es mejor darle un poco más de recursos y así os cuento como se redimensiona un servidor aunque en realidad es muy fácil, estando en los detalles del servidor hay que seleccionar redimensionar y se abre una pantalla para elegir la nueva configuración, lo ajustamos a nuestras nuevas necesidades y en menos de 1 minuto ya lo tenemos listo otra vez con los nuevos recursos. Lo único que no se puede hacer es reducir el espacio en disco, así mejor ir seleccionando tamaños razonables y siempre lo podremos aumentar cuando lo necesitemos.
Tal y como nos muestra el aviso al hacer el redimensionado el servidor se reinicia durante el proceso y aunque es muy rápido, un reinicio es un reinicio así que hay que tenerlo en cuenta para no tener problemas al reiniciar en medio de algún proceso importante. Estaría bien que tuviese la posibilidad de hacerlo en caliente e incluso poder programar el escalado para momentos en los que preveamos mayor carga o ya puestos que se redimensionase automáticamente en función de la carga, aunque con estas cosas hay que tener cuidado porque te puedes llevar alguna sorpresita porque luego hay que pagarlo y realmente para la mayoría de las aplicaciones lo normal va a ser no necesitarlo y optar por hacer el escalado horizontal (más servidores) puede dar mejores resultados aunque esto tampoco nos lo facilita porque tampoco se puede programar el encendido/apagado de los servidores (a pesar de que se podrá dentro de unos meses cuando lancen su API), pero bueno no vamos a ir tan deprisa que no es tan fácil llegar a tener esas necesidades 😆 .
Vale, vamos con la instalación y configuración de MySQL en CentOS 7. Lo primero es añadir el repositorio de la última versión y hacer la instalación.
[root@mysql-server ~]# sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm
[root@mysql-server ~]# yum install mysql-community-server
Como siempre comprobamos la versión instalada para ver que todo ha ido bien y ver que hemos instalado la versión que queríamos.
[root@mysql-server ~]# mysqld --version
/usr/sbin/mysqld Ver 8.0.16 for Linux on x86_64 (MySQL Community Server - GPL)
Lo siguiente es habilitar el servicio, para que se arranque automáticamente y arrancarlo.
[root@mysql-server ~]# sudo systemctl enable mysqld
Created symlink from /etc/systemd/system/multi-user.target.wants/mysqld.service to /usr/lib/systemd/system/mysqld.service.
[root@mysql-server ~]# sudo systemctl start mysqld
Al arrancar el MySQL por primera vez se genera una contraseña temporal para el usuario root que podemos buscar en el log, para hacerlo sencillo hacemos un grep para buscar la password.
[root@mysql-server ~]# sudo grep 'temporary password' /var/log/mysqld.log
2019-06-27T18:36:07.499617Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: w*v#l+c1dkN(
Y para terminar con la instalación ejecutamos el mysql_secure_installation para cambiar la contraseña del usuario root, eliminar los usuarios anónimos, el login remoto con el usuario root y la base de datos test y dejar una instalación más limpia y segura.
[root@mysql-server ~]# sudo mysql_secure_installation
Securing the MySQL server deployment.
Enter password for user root:
The 'validate_password' component is installed on the server.
The subsequent steps will run with the existing configuration
of the component.
Using existing password for root.
Estimated strength of the password: 100
Change the password for root ? ((Press y|Y for Yes, any other key for No) : y
New password:
Re-enter new password:
Estimated strength of the password: 100
Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y
By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.
Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.
Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.
Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.
By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.
Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
- Dropping test database...
Success.
- Removing privileges on test database...
Success.
Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.
Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.
All done!
Ahora solo nos queda crear la base de datos y los usuarios, aunque hemos desactivado el usuario root para el acceso remoto y tampoco hemos abierto el puerto 3306 en el firewall, podemos conectarnos haciendo un túnel pero como son unas tareas simples vamos a hacerlo desde el propio servidor usando el cliente de MySQL
[root@mysql-server ~]# mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 8.0.16 MySQL Community Server - GPL
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
Lo primero es crear nuestra base de datos.
mysql> CREATE DATABASE pruebas;
Query OK, 1 row affected (0.01 sec)
A continuación creamos el usuario indicando el nombre, las IPs desde las que se puede conectar y la contraseña. Si queremos que el usuario se pueda conectar desde varias IPs podemos usar el comodín ‘%’, para que se acepte cualquier IP o un determinado rango ‘10.20.10.%’, en mi caso prefiero poner solo la IP de la red privada del servidor en el que estará la aplicación de Spring Boot que es el único lugar desde el que quiero que se pueda conectar el usuario.
mysql> CREATE USER 'usuariospring'@'10.20.10.5' IDENTIFIED BY 'Mipassword1+';
Query OK, 0 rows affected (0.02 sec)
Lo siguiente es asignarle los privilegios al usuario (CREATE, DELETE, DROP, INSERT, SELECT, UPDATE, …) o ALL para asignarle todos que es lo que voy a hacer aunque no debería.
mysql> GRANT ALL PRIVILEGES ON pruebas.* TO 'usuariospring'@'10.20.10.5' WITH GRANT OPTION;
Query OK, 0 rows affected (0.01 sec)
Y para terminar aplicamos los cambios para que se actualicen los privilegios de los usuarios
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)
mysql> exit
Bye
Ya lo tenemos listo, ejecutamos nuestros scripts, creamos algún usuario más si lo necesitamos, …
Desplegar aplicación Spring Boot en un servidor Cloud VPS
El último paso que nos queda es crear y configurar nuestro último servidor CentOS 7 para poder desplegar la aplicación de Spring Boot que será nuestro backend.
Antes de empezar con el servidor vamos a hacer unas pequeñas modificaciones a la aplicación que vamos a desplegar que va a ser la del tutorial de Spring Boot para que se genere como una aplicación ejecutable y por su puesto para cambiar los datos de conexión de la base de datos para que utilice los de la que acabamos de crear.
Lo primero que vamos a hacer es modificar los datos de acceso a la BD en nuestro application.yml usando la IP de la red privada entre nuestros VPS y el usuario y el esquema que creamos antes. Como ya habíamos dejado la configuración preparada para tener varios profiles añadimos uno nuevo o modificamos el que tenemos de producción con los nuevos datos.
spring:
profiles: prod
datasource:
url: jdbc:mysql://10.20.10.4:3306/pruebas
username: usuariospring
password: Mipassword1+
Ahora ya tenemos nuestra aplicación correctamente configurada pero hay un cambio que podemos hacer en nuestro pom.xml para hacer que la aplicación se pueda ejecutar como una aplicación normal y no tener que usar el java -jar y que consiste simplemente en añadir <configuration><executable>true</executable></configuration> en el pom.xml dentro del spring-boot-maven-plugin, por lo tanto el plugin quedara así:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<executable>true</executable>
</configuration>
</plugin>
Y finalmente Run As > Maven Build… ponemos package en Goals, prod como profile, marcamos Skip Tests y le damos a Run para que nos genere nuestro jar ejecutable con la configuración de nuestro entorno.
La preparación de este último servidor también es muy sencilla, como en los 2 servidores anteriores vamos a volver a elegir CentOS 7, seleccionamos los recursos que le queremos asignar sin olvidarnos de habilitar la red privada para poder acceder al servidor en el que tenemos el MySQL y también para que el del Angular puede usar los servicios Rest usando la red interna (cuando les añadamos 🙂 ).
Esperamos unos segundos a que se cree y se inicie y ya podemos conectarnos para instalar la jdk para poder ejecutar nuestra aplicación.
[root@spring-server ~]# yum install java-1.8.0-openjdk
Y comprobamos la versión para ver que la instalación ha sido correcta.
[root@spring-server ~]# java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
Subimos el jar de nuestra aplicación por ftp a /usr/local/spring_boot por ejemplo, y le damos permisos de ejecución.
[root@spring-server spring_boot]# chmod +x tutorial-spring-boot-0.0.1-SNAPSHOT.jar
Y ya podemos ejecutarlo como cualquier otra aplicación gracias al cambio que hicimos antes para hacerla ejecutable.
[root@spring-server spring_boot]# ./tutorial-spring-boot-0.0.1-SNAPSHOT.jar
Ya tenemos nuestra aplicación ejecutándose pero si reiniciamos el servidor vamos a tener que iniciarla manualmente y eso no suele ser muy buena idea por eso vamos a hacer que nuestra aplicación de Spring Boot se inicie como un servicio del sistema y lo vamos a hacer con systemd para que se arranque como el Apache o el MySQL usando systemctl.
Para esto tenemos que crear un script en /etc/systemd/system con el siguiente contenido.
[Unit]
Description=Mi aplicacion Spring Boot
[Service]
Restart=always
ExecStart=/usr/local/spring_boot/tutorial-spring-boot-0.0.1-SNAPSHOT.jar
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
Y habilitamos y ejecutamos la aplicación como en los casos anteriores.
[root@spring-server system]# systemctl enable mispringapp.service
Created symlink from /etc/systemd/system/multi-user.target.wants/mispringapp.service to /etc/systemd/system/mispringapp.service.
[root@spring-server system]# systemctl start mispringapp.service
Ahora ya tenemos la aplicación entera desplegada en 3 servidores distintos pero perfectamente conectados gracias al uso de la red privada que además nos permite dejar cerrados todos los puertos de los servicios que no queremos que sean accedidos públicamente como la base de datos por ejemplo y que podemos redimensionar a nuestro antojo según lo que necesitemos.
[root@spring-server system]# systemctl status mispringapp.service
● mispringapp.service - Mi aplicacion Spring Boot
Loaded: loaded (/etc/systemd/system/mispringapp.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-06-27 22:12:47 CEST; 1min 12s ago
Main PID: 5662 (tutorial-spring)
CGroup: /system.slice/mispringapp.service
├─5662 /bin/bash /usr/local/spring_boot/tutorial-spring-boot-0.0.1-SNAPSHOT.jar
└─5679 /usr/bin/java -Dsun.misc.URLClassPath.disableJarChecking=true -jar /usr/local/spring_boot/tutorial-spring-boot-0.0.1-SNAPSHOT.jar
Clonar un servidor en clouding.io
Si hubiésemos utilizado Docker por ejemplo, montar una nueva máquina para tener por ejemplo 2 instancias de la aplicación Spring Boot sería muy rápido y sencillo, bueno en realidad tampoco es que nos haya sido muy complejo porque este servidor no nos ha requerido mucha configuración pero aunque ese no fuese el caso y hubiésemos necesitado mucho más tiempo, trasteando por las opciones de clouding.io he visto que existe la opción de clonar los servidores y la verdad es que no me pude resistir a probarlo porque parece una opción interesante.
Después de introducir los datos del «clon» en un formulario muy similar al de creación con el añadido de que te da la opción de que se apague el servidor del que vas a hacer la copia para que el proceso sea más estable y esperar un poco más que para crear un servidor nuevo porque me pareció que tardo un par de minutos (aunque quizás fuesen las ganas de probarlo 🙄 ) el resultado es el esperado.
Nada más conectarte ya ves que es una copia idéntica porque hasta tienes el historial de comando ejecutados y rápidamente me puse a comprobar si la aplicación estaba funcionando, abrí el puerto 9876 (no es necesario hacerlo desde el servidor, se puede hacer desde el panel de administración de los servidores añadiendo una nueva regla al firewall) que es el que está configurado en la aplicación y … nada que no funciona, pero el problema no es grave, simplemente es que el usuario de MySQL lo habíamos creado para que se conectase desde la IP del otro servidor, por lo tanto nos conectamos al servidor de la bd y creamos un nuevo usuario igual al que habíamos creado pero ahora con la IP del nuevo servidor y automáticamente ya tenemos la aplicación arrancada porque en el script del servicio habíamos puesto Restart=always lo que hace que cada vez que la aplicación se para vuelve a arrancar.
CREATE USER 'usuariospring'@'10.20.10.6' IDENTIFIED BY 'Mipassword1+';
GRANT ALL PRIVILEGES ON pruebas.* TO 'usuariospring'@'10.20.10.5' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Ahora ya sí que podemos decir que tenemos nuestra aplicación completamente desplegada en la nube y estamos preparados para escalarla vertical y/o horizontalmente según nuestras necesidades o borrarla y empezar con otra prueba y además todo por un precio sorprendentemente bueno, en el tiempo que he tardado en hacer estas pruebas hasta ahora que termino de escribirlo no llega a los 2€ y eso que es un despliegue exagerado de servidores para hacer unas simples pruebas.
Por lo tanto la elección de Clouding.io parece que ha sido una muy buena idea porque en unos segundos puedes tener un nuevo servidor disponible y hacer lo que quieras sabiendo que solo te van a facturar exactamente lo que consumas, el panel de control es muy intuitivo y es muy sencillo configurar el firewall, crear snapshots, programar los backups, etc. y lo más importante que el rendimiento no defrauda en absoluto así que creo que estas pruebas no son más que el comienzo porque ya tengo varias ideas para nuevos post y alguna cosilla un poco más ambiciosa.
