6. Implantación

Aquí se realizará un resumen de la implantación, el manual completo del despliegue e implantación está en Manual Despliegue

Para empezar partimos de una VPC ya creada llamada LabVPC, su bloque CIDR es 10.16.0.0/16, tiene dos zonas de disponibilidad a y b y tendrá 2 subredes públicas y 2 subredes privadas. Las subredes públicas saldrán a Internet a través de una gateway de Internet.

6.1. Cloud9

Lo primero será crear un entorno de Cloud9 y entrar en el IDE.

6.1.1 Crear un repositorio de Git para el código de los microservicios y enviar el código a CodeCommit

1. Creamos una carpeta customer y otra employee y cargaremos los archivos de nuestra aplicación dentro de ambas carpetas.

2. Creamos un repositorio de CodeCommit llamado microservices.

3. Iniciamos el repositorio con una rama llamada dev, realizar el commit, añadir el repositorio remoto y enviar los archivos.

6.1.2. Modificación de archivos del cliente

1. Tendremos que modificar varios ficheros para que el microservicio del cliente no tenga las funciones de editar, añadir o borrar a los proveedores ya sea quitando enlaces o funciones en los siguientes archivos.

• customer/app/controller/supplier.controller.js.
• cliente/aplicación/modelos/supplier.model.js.
• customer/views/nav.html
• customer/views/supplier-list-all.html.
• index.js

2. Eliminamos los siguientes archivos de la carpeta customer/views.

• supplier-add.html
• supplier-form-fields.html
• supplier-update.html

6.1.3. Crear Dockerfile del cliente e iniciar un contenedor de prueba

1. En la carpeta customer, creamos el archivo "Dockerfile".

2. Crearemos una imagen a partir del Dockerfile del cliente y verificamos que se ha creado.

3. Iniciamos el contenedor de Docker para que se ejecute el microservicio del cliente en el puerto 8080 y probamos a pegar la ip pública de la instancia de Cloud9 seguido de ":8080", debería de salir nuestra página para el cliente, y debería poder listar los proveedores.

4. Por último hacemos un git commit y git push para mandar los archivos actualizados a nuestro repositorio de CodeCommit.

6.1.4. Modificación de archivos de empleado

Ahora nos tocará modificar los archivos del microservicio del empleado.

1. Para todas las llamadas redirigidas, anteponemos /admin a la ruta en los archivos y en algún caso cambiar el puerto a 8081:

• employee/app/controller/supplier.controller.js,
• index.js
• employee/views/supplier-add.html
• employee/views/supplier-update.html
• employee/views/supplier-list-all.html
• employee/views/home.html

2. En el archivo employee/views/header.html, modificaremos el título a Manage coffee suppliers.

3. Ahora editaremos el archivo employee/views/nav.html, cambiando el título a Manage coffee suppliers y añadimos los enlaces necesarios para la comunicación de ambos microservicios.

6.1.5. Crear Dockerfile del empleado

1. Creamos el Dockerfile del empleado, modificando el puerto por 8081 en una copia del cliente.

2. Creamos la imagen Docker e iniciamos un contenedor Docker en el puerto 8081.

Al igual que con el cliente, podremos poner en el navegador la ip pública de la instancia Cloud9 precedidad de ":8081/admin/suppliers" y se nos mostrará nuestar página de empleado.

Comprobaremos que podemos añadir nuevos registros, modificar o eliminar los anteriores.

4. Ahora, haremos algunos ajustes para implementarlo en Amazon ECS y que funcione en el mismo puerto que el microservicio del cliente y volveremos a crear la imagen.

5. Para acabar con la modificación de la aplicación, haremos un git commit y git push para que se guarden las modificaciones de los archivos en el repositorio.

6.2 Creación de repositorio ECR, un clúster de ECS, definiciones de tareas y archivos AppSpec.

6.2.1. Creación de repositorio ECR y cargar imágenes de Docker

1. Primero autorizamos al cliente Docker a conectarse al servicio Amazon ECR y nos saldrá un mensaje de que el logueo ha sido correcto.

2. Ahora iremos al servicio ECR y crearemos un repositorio privada para empleado y otro para cliente.

3. Editamos los permisos del repositorio ECR del cliente y del empleado en JSON.

4. Etiquetamos las imágenes Docker con el Id de la cuenta.

5. Enviamos las imágenes Docker al repositorio.

6.2.2 Crear un clúster de ECS

En este paso, solo tendremos que ir al servicio ECS, y crearemos un nuevo clúster con nombre "microservices-serverlesscluster" y tipo "AWS Fargate (sin servidor)".

6.2.3 Crear repositorio de CodeCommit para los archivos de implementación

1. En CodeCommit crearemos un repositorio llamado "deployment".

2. También iremos a nuestro IDE de Cloud9, y a la altura de microservices, crearemos la carpeta deployment y lo iniciaremos como un repositorio git con una sucursal dev.

6.2.4 Crear archivos de definición de tareas para cada microservicio y registrarlos en Amazon ECS

1. En la carpeta deployment, creamos el archivo "taskdef-customer.json" con la información de nuestra cuenta y la RDS.

2. Registramos la definición de la tarea de microservicio del cliente en Amazon ECS.

3. También crearemos el archivo de "taskdef-employee.json" y registramos la definición de la tarea.

Podemos verificar que las tareas se han creado correctamente en la interfaz de Amazon ECS, en Definiciones de tareas.

6.2.5. Crear archivos AppSpec para CodeDeploy para cada microservicio

1. En la carpeta deployment crearemos el archivo "appspec-customer.yaml".

2. También el archivo "appspec-employee.yaml" con el mismo contenido pero cambiando customer por employee.

6.2.6. Actualizar los archivos y enviarlos a CodeCommit

1. Modificamos el archivo taskdef-customer.json y taskdef-employee.json para que en la línea 5 quede lo siguiente "image": "<IMAGE1_NAME>", y enviamos los cambios a CodeCommit.

6.3. Crear grupos de destino y un equilibrador de carga de aplicación

6.3.1. Crear cuatro grupos de destino

Vamos al servicio de EC, en el menú izquierdo, elegimos "Grupos de destino".

1. Creamos los grupos de destino

• customer-tg-one
• customer-tg-two

El tipo de destino será por Dirección IP, el protocolo es HTTP en el puerto 8080 y en nuestra VPC del proyecto.

3. Ahora crearemos los grupos de destino del empleado con nombres "employee-tg-one" y "employee-tg-two".

• La ruta de comprobación de estado es /admin/suppliers.

6.3.2. Crear un grupo de seguridad y un equilibrador de carga de aplicación y configurar reglas para enrutar el tráfico

1. Creamos un grupo de seguridad llamado "microservices-sg" con las reglas de entrada de los puertos 8080 y 80 desde cualquier IP.

2. Ahora creamos un balanceador de carga de aplicaciones que se llame "microservicesLB" expuetso a Internet, en nuestra VPC y con los agentes de escucha correctos.

6.4. Crear dos servicios de Amazon ECS

6.4.1. Crear el servicio ECS para el microservicio del cliente

1. Crearemos el archivo "create-customer-microservice-tg-two.json" en la carpeta deployment con los ajustes necesarios como los ARN de los grupos de destino o los ide de las subredes y grupo de seguridad.

2. Creamos el servicio de Amazon ECS del cliente.

6.4.2. Crear el servicio ECS para el microservicio del empleado

1. Haremos lo mismo para crear el servicio ECS para el empleado, creando el archivo "create-employee-microservice-tg-two.json".

2. Ejecutamos el comando para crear el servicio ECS del empleado.

Si vamos a la consola de Amazon ECS, podremos ver los servicios del clúster creados.

6.5 Configurar CodeDeploy y CodePipeline

6.5.1. Crear una aplicación y grupos de implementación de CodeDeploy

1. Vamos al servicio CodeDeploy y creamos una aplicación con el nombre "microservices" utilizando Amazon ECS como plataforma informática.

2. Ahora vamos a crear los grupos de implementación en la aplicación microservices.

• "microservices-customer" que utilice el balanceador y los grupos de destino serán "customer-tg-two" y "customer-tg-one".

3. También crearemos el otro grupo de implementación, cambiando:

• El nombre será "microservices-employee" y los grupos de destino serán "employee-tg-two" y "employee-tg-one".

6.5.2. Crear una canalización para el microservicio del cliente

1. Nos iremos al servicio CodePipeline y empezaremos creando la canalización del cliente con nombre "update-customer-microservice", seleccionamos el rol, el origen del código que es CodeCommit y demás cosas.

2. Crearemos la canalización, y la editamos agregando la imagen en "Source" y en "Deploy" para que la use. Guardaremos los cambios y haremos un cambio de versión para volver a invocar la canalización.

6.5.3. Probar la canalización CI/CD para el microservicio del cliente

Cuando termine de invocarse la canalización, podremos observar que todo ha salido correctamente y probamos su funcionamiento copiando el DNS del balanceador y lo pondremos en el navegador, nos saldrá el home del cliente.

Al darle a "List of suppliers", se mostrarán los proveedores.

6.5.4. Crear una canalización para el microservicio del empleado

Seguimos creando la canalización del microservicio del empleado.

1. Volvemos al servicio CodePipeline y la creamos con el nombre "update-employee-microservice".

2. Crearemos la canalización, y la editaremos igual que la otra y guardamos los cambios.

6.5.5. Probar la canalización CI/CD para el microservicio del empleado

Cuando termine de invocarse la canalización,al igual que la del cliente, podremos observar que todo ha salido correctamente y probamos su funcionamiento, con la página que ya teníamos del cliente, le daremos a "Administrator link" y saldrá la página del empleado en la que se puede añadir, editar y borrar proveedores.

Por lo que ahora la aplicación está completa y podremos pasar desde la parte del cliente al del empleado y viceversa.

6.6. Ajustar el código de microservicio para hacer que la canalización se ejecute de nuevo

6.6.1. Limitar el acceso al microservicio del empleado

1. En los agentes de escucha, tanto HTTP:80 como HTTP:8080, añadimos la segunda condición, se enrrutará al usuario a los grupos de destino sólo si la IP fuente de la solicitud es nuestra dirección IP pública que podremos comprobar en internet.

6.6.2. Ajustar las UI para el microservicio del empleado y enviar las imágenes actualizadas a Amazon ECR

1. Modificamos el archivo empleado/vistas/nav.html cambiando el estilo.

2. Volvemos a generar la imagen Docker.

3. Ahora enviamos la imagen actualizada a ECR y la canalización se invocará y ejecutará.

Cuando termine, probaremos a entrar y ver si ha cambiado la interfaz.

6.6.3. Probar el acceso al microservicio del empleado

Para probar el acceso al microservicio del empleado, iremos al navegador usando el DNS de nuestro balanceador de carga.

Podremos comprobar que el título de la página ahora es claro, aunque las páginas alojadas por el microservicio del cliente siguen teniendo el banner oscuro lo que demuestra que, con una arquitectura de microservicios, se puede modificar de forma independiente la UI o las funciones de cada microservicio sin afectar a los demás.

También probaremos el acceso desde otro dispositivo, debería de aparecer un error 404, con esto comprobamos que no se puede conectar al microservicio de empleado desde otra dirección IP.

6.6.4. Escalar el microservicio del cliente

Ahora podremos escalar el número de contenedores que soportan el microservicio del cliente con una orden en Cloud 9.

Si vamos al servicio ECS, podremos ver lo que hemos hecho reflejado en Servicios, donde en el del cliente debería ahora 3 tareas.

Por lo que podríamos escalar a cualquier número de contenedores de ambos microservicios, lo que es nuestra finalidad.