README.

md 11/16/2022

POC Kubernetes Docker Nodejs Api

Prueba de Concepto POC de una Api realizada con Nodejs + Express + Typescript, desplegada en un
ambiente de Kubernetes EKS de AWS con Pod Cluster usando la imagen de Docker del Api.

Requisitos Previos
Debemos tener las siguientes herramientas y aplicaciones:

Cuenta AWS

Nodejs

Docker Desktop

Kubectl

Cluster EKS

Arrancando el Proyecto Local

Esto lo haremos sólo para testear la api a nivel local en nuestra PC

Ingresamos a la carpeta app

cd app

Instalamos las dependencias

npm install

npm install -D

Ejecutando el proyecto

npm run dev

Ingresamos a la ruta: http://localhost:4000 en el navegador o desde postman con una petición del tipo GET.

Debemos recibir la respuesta:

1 / 10
README.md 11/16/2022

{
"status": true,
"msg": "Bienvenido al POC Superpos Kubernetes Docker Nodejs Api"
}

Esto indica que nuestra Api está funcionando correctamente.

Imagen de Docker del App

Iniciar sesión en Docker Desktop

Debemos tener creada una cuenta en Docker hub

Si en caso ya tuvieran una, debemos iniciar sesión en Docker Desktop.

Esto nos redirigirá a la web de Docker hub e iniciamos sesión

Nos redireccionará nuevamente a Docker Desktop

2 / 10
README.md 11/16/2022

Verificamos que estemos con sesión iniciada y anotamos el tag o username de docker hub

Para el caso de ejemplo gilgammesh.

Creando la imagen

Abrimos la consola cmd y nos ubicamos en la carpeta app.

Ejecutamos el comando

docker build -t gilgammesh/appnode .

Fijese que el tag de la imagen es gilgammesh/appnode, que contiene el tag anotado anteriormente, esto
deberá reemplazarlo por su tag personal de Docker hub

[+] Building 8.1s (14/14) FINISHED

=> [internal] load build definition from Dockerfile
=> => transferring dockerfile: 250B
=> [internal] load .dockerignore
=> => transferring context: 2B
=> [internal] load metadata for docker.io/library/node:16.17.1-alpine
=> [auth] library/node:pull token for registry-1.docker.io

3 / 10
README.md 11/16/2022

=> [internal] load build context

=> => transferring context: 77.68MB
=> [1/8] FROM docker.io/library/node:16.17.1-
alpine@sha256:4d68856f48be7c73cd83ba8af3b6bae98f4679e14d1ff49e164625ae8831533a
=> CACHED [2/8] WORKDIR /app
=> CACHED [3/8] COPY package*.json ./
=> CACHED [4/8] COPY tsconfig*.json ./
=> CACHED [5/8] RUN npm install
=> CACHED [6/8] RUN npm install -D
=> [7/8] COPY . ./
=> [8/8] RUN npm run build
=> exporting to image
=> => exporting layers
=> => writing image
sha256:78e1799b3ccf40d4876b538bca66e3006e7aa9ba7a84a9172fb9ba76251f02a5
=> => naming to docker.io/gilgammesh/appnode

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and
learn how to fix them

Verificamos que la imagen haya sido creada en Docker Desktop

Ahora debemos subir nuestra imagen a Docker hub, con el siguiente comando:

docker push gilgammesh/appnode

Si todo salio bien, veremos los siguientes logs:

Using default tag: latest

The push refers to repository [docker.io/gilgammesh/appnode]
21334f471c26: Pushed
d15bd836a334: Pushed
6cc548be537b: Layer already exists
e06554900199: Layer already exists
2980b8cfb8e7: Layer already exists

4 / 10
README.md 11/16/2022

58cfe4f21b42: Layer already exists

72117ed1395e: Layer already exists
1eb06ab2fbfa: Layer already exists
86c50c086b6e: Layer already exists
2d85d1174939: Layer already exists
994393dc58e7: Layer already exists
latest: digest:
sha256:f47ea498a9e38879298b70852cf786733880c3eaadae22ce9f003d1519af0e47 size: 2622

Verificamos que se subió la imagen a Docker hub, ingresando al siguiente enlace

https://hub.docker.com/repositories

Si todo salió bien estamos listos para el siguiente paso

Creando el contenedor (opcional)

Nos ubicamos en la raiz del proyecto

Editamos el archivo docker-compose.yml

version: '3.8'
services:
server:
container_name: appnode
image: gilgammesh/appnode
build: ./app
ports:
- 4000:4000
restart: always

Verificamos que el nombre de la imagen coincida con nuestro tag de Docker hub. De ser así lo dejamos, caso
contrario lo reemplazamos con el nuestro.

Eliminamos la imagen creada anteriormente gilgammesh/appnode, ya que está volverá a ser creada.

Luego ejecutamos el siguiente comando:

docker-compose -f ./docker-compose.yml up --build -d

5 / 10
README.md 11/16/2022

Si todo salió bien, veremos los siguientes logs:

Creating network "kubernet-docker-node-typescript-api_default" with the default

driver
Building server
[+] Building 33.7s (14/14) FINISHED
=> [internal] load build definition from Dockerfile
=> => transferring dockerfile: 250B
=> [internal] load .dockerignore
=> => transferring context: 2B
=> [internal] load metadata for docker.io/library/node:16.17.1-alpine
=> [auth] library/node:pull token for registry-1.docker.io
=> [1/8] FROM docker.io/library/node:16.17.1-
alpine@sha256:4d68856f48be7c73cd83ba8af3b6bae98f4679e14d1ff49e164625ae8831533a
=> [internal] load build context
=> => transferring context: 77.69MB
=> CACHED [2/8] WORKDIR /app
=> CACHED [3/8] COPY package*.json ./
=> CACHED [4/8] COPY tsconfig*.json ./
=> CACHED [5/8] RUN npm install
=> CACHED [6/8] RUN npm install -D
=> [7/8] COPY . ./
=> [8/8] RUN npm run build
=> exporting to image
=> => exporting layers
=> => writing image
sha256:a4096986003a848e0699ed24b69a7fd83775524eff71b4f7169fce2e4b7466b6
=> => naming to docker.io/gilgammesh/appnode

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and
learn how to fix them
Creating appnode ... done

Verificamos que el contenedor haya sido creado en Docker Desktop y esté en color verde Running, con la
imagen anterior creada. Anotamos el puerto.

6 / 10
README.md 11/16/2022

Testeamos la Api ingresando al enlace: http://localhost:4000

Debemos obtener el siguiente resultado:

Creando el POD Kubernetes

Para hacer el deploy en kubernetes, debemos comprender los archivos que componen la carpeta Deploy.

Estructura

kubernet-docker-node-typescript-api/ // Carpeta raíz

+
|——Deploy/ // Carpeta de despliegue de
Kubernetes
| |--app/ // Carpeta de la app
| | |——deployment.yml // Archivo de construcción del POD
de Kubernetes
| | |——service.yml // Archivo de configuración del
servicio de Kubernetes
| |——kustomization.yml // Archivo de despliegue de los
recursos de Kubernetes
+

Leer la documentación para la creación de imágenes: https://kubernetes.io/docs/concepts/containers/images/

deployment.yml => Archivo de construcción del POD de Kubernetes. Donde configuraremos el nombre del
cluster, las replicas para balanceo de carga, el nombre del contenedor de docker, el nombre de la imagen de
docker, el puerto de exposición de la imagen y más configuraciones. Para mayor información leer la
documentación: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

service.yml => Archivo de configuración del servicio de Kubernetes. Donde configuraremos el tipo de
servicio "LoadBalancer", redireccionamos los puertos del lado de la red de kubernetes, referenciamos al
nombre del cluster y más configuraciones. Para mayor información leer la documentación:
https://kubernetes.io/docs/concepts/services-networking/service/

kustomization.yml => Archivo de despliegue de los recursos de Kubernetes. Donde referenciamos todos
los recursos que vamos a desplegar en el cluster de EKS de AWS. Para mayor información leer la
documentación: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

7 / 10
README.md 11/16/2022

Despliegue en el Cluster

Ingresamos a la consola, nos ubicamos en la raíz del proyecto y ejecutamos el comando:

kubectl apply -k .\Deploy\

Si aplicó correctamente veremos los logs:

service/kubeappnode created
deployment.apps/kubeappnode created

Consultamos los pods creados, se deben visualizar 2 réplicas en status Running

kubectl get pods

NAME READY STATUS RESTARTS AGE

kubeappnode-5b764fbb75-jzkl9 1/1 Running 0 13s
kubeappnode-5b764fbb75-zmczh 1/1 Running 0 13s

Consultamos los deployments

kubectl get deploy

NAME READY UP-TO-DATE AVAILABLE AGE

kubeappnode 2/2 2 2 25s

Consultamos los servicios

kubectl get services

NAME TYPE CLUSTER-IP EXTERNAL-IP

PORT(S) AGE
kubeappnode LoadBalancer 10.100.11.193 a6678c2b2078d4b7e901f6b4dc6fab27-
208590083.us-west-2.elb.amazonaws.com 80:31948/TCP 17m
kubernetes ClusterIP 10.100.0.1 <none>

8 / 10
README.md 11/16/2022

Aca anotamos la ruta de EXTERNAL-IP para nuestro ejemplo a6678c2b2078d4b7e901f6b4dc6fab27-

208590083.us-west-2.elb.amazonaws.com. Esta url variará en cada caso y cada vez que se realice un
nuevo despliegue.

Verificación del Funcionamiento

Abrimos un navegador y copiamos la ruta a6678c2b2078d4b7e901f6b4dc6fab27-208590083.us-west-

2.elb.amazonaws.com. Recordar que esto es un ejemplo y variará con cada caso, copiar la que se genera en
su lado.

Debemos ver una respuesta como la imagen

Ahora haremos las consultas de nuestro endpoints

Api para envio de Email

Ruta a6678c2b2078d4b7e901f6b4dc6fab27-208590083.us-west-
2.elb.amazonaws.com/superpos/email

Petición del tipo POST

Enviar en el cuerpo

{
"email": "carlos.santander@gmail.com",
"otp": "123456"
}

9 / 10
README.md 11/16/2022

Debemos recibir como respuesta:

{
"status": true,
"msg": "Se envió el otp: 123456 de autorización del comercio, al correo
carlos.santander@gmail.com"
}

Api para envio de SMS

Ruta a6678c2b2078d4b7e901f6b4dc6fab27-208590083.us-west-2.elb.amazonaws.com/superpos/sms

Petición del tipo POST

Enviar en el cuerpo

{
"phoneNumber": "943217411",
"otp": "123456"
}

Debemos recibir como respuesta:

{
"status": true,
"msg": "Se envió el otp: 123456 de autorización del comercio, por sms al número
943217411"
}

Con esto hemos finalizado nuestra Prueba de Concepto en el ambiente

de Kubernetes y Docker de EKS de AWS
No olvidar eliminar el cluster si no se necesita para no generar costos, y luego cuando se
necesite replicar los pasos.

10 / 10