1. Introducción
¿Por qué migrar una aplicación monolítica a una arquitectura de microservicios? Desglosar una aplicación en microservicios tiene las siguientes ventajas: La mayoría se debe a que los microservicios están vinculados de manera flexible.
- Los microservicios se pueden implementar y probar de forma independiente. Cuanto más pequeña sea la unidad de implementación, más fácil será la implementación.
- Se pueden implementar en diferentes lenguajes y frameworks. En cada microservicio, puedes elegir la mejor tecnología para tu caso práctico en particular.
- Los pueden administrar diferentes equipos. El límite entre microservicios facilita que un equipo se dedique a uno o varios microservicios.
- Mediante la migración a los microservicios, puedes flexibilizar las dependencias entre los equipos. Cada equipo debe preocuparse solo por las API de los microservicios de los que dependen. El equipo no necesita pensar en cómo se implementan esos microservicios, en sus ciclos de lanzamiento, etcétera.
- Puedes lograr diseños para evitar fallas con más facilidad. Si hay límites entre los servicios, es más fácil determinar qué hacer si un servicio está inactivo.
Estas son algunas desventajas en comparación con las aplicaciones monolíticas:
- Debido a que una aplicación basada en microservicios es una red de servicios diferentes que a menudo interactúan de maneras que no son evidentes, la complejidad general del sistema suele ser mayor.
- A diferencia de los componentes internos de una aplicación monolítica, los microservicios se comunican por medio de una red. En algunas circunstancias, esto puede considerarse un problema de seguridad. Istio resuelve este problema mediante la encriptación automática del tráfico entre microservicios.
- Lograr el mismo nivel de rendimiento que se obtiene con un enfoque monolítico puede resultar difícil debido a las latencias entre servicios.
- El comportamiento de tu sistema no se debe a un solo servicio, sino a muchos de ellos y a sus interacciones. Por esta razón, es más difícil comprender cómo se comporta tu sistema en la producción (su observabilidad). Istio también representa una solución a este problema.
En este lab, ejecutaremos microservicios en Google Kubernetes Engine (GKE). Kubernetes es una plataforma para administrar, alojar, implementar y escalar contenedores. Los contenedores son una forma portátil de empaquetar y ejecutar código. Son adecuados para el patrón de microservicios, en el que cada microservicio puede ejecutarse en su propio contenedor.
En este lab, implementaremos una aplicación monolítica existente en un clúster de Google Kubernetes Engine y, luego, la desglosaremos en microservicios.
Diagrama de la arquitectura de nuestros microservicios
Comenzaremos por desglosar nuestra aplicación monolítica en tres microservicios, uno a la vez. Los microservicios incluyen Pedidos, Productos y Frontend. Compilamos una imagen de Docker para cada microservicio con Cloud Build, que se activa desde Cloud Shell. Luego, implementaremos y expondremos nuestros microservicios en Google Kubernetes Engine (GKE) con un tipo de servicio LoadBalancer de Kubernetes. Haremos esto para cada servicio mientras los refactorizamos, en simultáneo, fuera de nuestra aplicación monolítica. Durante el proceso, ejecutaremos nuestra aplicación monolítica y nuestros microservicios hasta el final, cuando podamos borrar la aplicación monolítica.
Qué aprenderá
- Cómo desglosar una aplicación monolítica en microservicios
- Cómo crear un clúster de Google Kubernetes Engine
- Cómo crear una imagen de Docker
- Cómo implementar imágenes de Docker en Kubernetes
Requisitos
- Una cuenta de Google Cloud Platform con acceso de administrador para crear proyectos o un proyecto con la función Propietario del proyecto
- Conocimientos básicos de Docker y Kubernetes
2. Configuración del entorno
Configuración del entorno de autoaprendizaje
Si aún no tienes una Cuenta de Google (Gmail o Google Apps), debes crear una. Accede a la consola de Google Cloud Platform ( console.cloud.google.com) y crea un proyecto nuevo:
Recuerde el ID de proyecto, un nombre único en todos los proyectos de Google Cloud (el nombre anterior ya se encuentra en uso y no lo podrá usar). Se mencionará más adelante en este codelab como PROJECT_ID.
A continuación, deberás habilitar la facturación en Developers Console para usar los recursos de Google Cloud y habilitar la API de Container Engine.
Ejecutar este codelab debería costar solo unos pocos dólares, pero su costo podría aumentar si decides usar más recursos o si los dejas en ejecución (consulta la sección “Limpiar” al final de este documento). Los precios de Google Kubernetes Engine se documentan aquí.
Los usuarios nuevos de Google Cloud son aptos para una prueba gratuita de$300.
Google Cloud Shell
Si bien Google Cloud y Kubernetes se pueden operar de manera remota desde tu laptop, en este codelab usaremos Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
Esta máquina virtual basada en Debian está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Esto significa que todo lo que necesitarás para este Codelab es un navegador (sí, funciona en una Chromebook).
- Para activar Cloud Shell desde la consola de Cloud, solo haz clic en Activar Cloud Shell
(el aprovisionamiento y la conexión al entorno debería llevar solo unos minutos).
Una vez conectado a Cloud Shell, debería ver que ya se autenticó y que el proyecto ya se configuró con tu PROJECT_ID:
gcloud auth list
Resultado del comando
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Resultado del comando
[core] project = <PROJECT_ID>
Si, por algún motivo, el proyecto no está configurado, solo emite el siguiente comando:
gcloud config set project <PROJECT_ID>
Si no conoce su PROJECT_ID, Observa el ID que usaste en los pasos de configuración o búscalo en el panel de la consola de Cloud:
Cloud Shell también configura algunas variables de entorno de forma predeterminada, lo que puede resultar útil cuando ejecutas comandos futuros.
echo $GOOGLE_CLOUD_PROJECT
Resultado del comando
<PROJECT_ID>
- Establece la zona predeterminada y la configuración del proyecto.
gcloud config set compute/zone us-central1-f
Puedes elegir una variedad de zonas diferentes. Para obtener más información, consulta Regiones y zonas.
3. Clone el repositorio de origen
Usamos una aplicación monolítica existente de un sitio web de comercio electrónico imaginario, con una página de bienvenida simple, una página de productos y una página de historial de pedidos. Solo tendremos que clonar el origen de nuestro repo de Git, así podremos enfocarnos en desglosarlo en microservicios para implementarlos en Google Kubernetes Engine (GKE).
Ejecuta los siguientes comandos para clonar el repositorio de Git en la instancia de Cloud Shell y cambiarlo al directorio correspondiente. También instalaremos las dependencias de Node.js para poder probar nuestra aplicación monolítica antes de implementarla. Es posible que la ejecución de esta secuencia de comandos tarde unos minutos.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
Esto clonará nuestro repositorio de GitHub, cambiará al directorio y, luego, instalará las dependencias necesarias para ejecutar la aplicación de manera local. Es posible que la ejecución de esta secuencia de comandos tarde unos minutos.
4. Cree un clúster de GKE
Ahora que tienes tu entorno de desarrollo activo, necesitamos un clúster de Kubernetes para implementar nuestra aplicación monolítica y, finalmente, los microservicios también. Antes de poder crear un clúster, debemos asegurarnos de que estén habilitadas las APIs correspondientes. Ejecuta el siguiente comando para habilitar la API de contenedores de modo que podamos usar Google Kubernetes Engine:
gcloud services enable container.googleapis.com
Ya está todo listo para crear el clúster. Ejecuta el comando a continuación para crear un clúster de GKE llamado fancy-cluster con 3 nodos.
gcloud container clusters create fancy-cluster --num-nodes 3
La creación del clúster puede demorar varios minutos. Una vez que se haya completado el comando, ejecuta el siguiente comando y observa las tres instancias de VM de trabajador del clúster:
gcloud compute instances list
Resultado:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
También puedes ver tu clúster de Kubernetes y la información relacionada en la consola de Google Cloud. Haz clic en el botón de menú en la esquina superior izquierda, desplázate hacia abajo hasta Kubernetes Engine y haz clic en Clústeres. Deberías ver tu clúster llamado fancy-cluster.
¡Felicitaciones! Acabas de crear tu primer clúster de Kubernetes.
5. Implemente la aplicación monolítica existente
Dado que el enfoque de este lab es explicar el desglose de una aplicación monolítica en microservicios, es necesario poner en marcha una aplicación monolítica. Para los fines de este lab, ejecuta la siguiente secuencia de comandos para implementar una aplicación monolítica en nuestro clúster de GKE:
cd ~/monolith-to-microservices ./deploy-monolith.sh
Cómo acceder a la aplicación monolítica
Para encontrar la dirección IP externa de nuestra aplicación monolítica, ejecuta el siguiente comando.
kubectl get service monolith
Debería ver un resultado similar al siguiente:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
NOTA: Se deben aprovisionar un balanceador de cargas externo y una IP para esto, por lo que el proceso tardará un tiempo. Si tu salida muestra la IP externa como
<pending> Espera unos minutos y vuelve a intentarlo.
Una vez que hayas determinado la dirección IP externa para tu aplicación monolítica, cópiala y escribe esta URL (como http://203.0.113.0) en tu navegador para verificar si se puede acceder a ella.
Debería ver la página de bienvenida del sitio web monolítico, como se muestra en la imagen de arriba. La página de bienvenida es una página estática que será presentada por el microservicio Frontend más adelante. Tu aplicación monolítica ya se está ejecutando por completo en Kubernetes.
6. Migre los pedidos al microservicio
Ahora que el sitio web de monolith existente se está ejecutando en GKE, podemos comenzar a dividir cada servicio en un microservicio. Por lo general, tendrás que planificar qué servicios separar en partes más pequeñas, normalmente en torno a partes específicas de la aplicación, como el dominio de la empresa. A modo de demostración, creamos un ejemplo simple y desglosamos cada servicio en torno al dominio de la empresa, Pedidos, Productos y Frontend. El código ya se migró y nos enfocaremos en compilar e implementar los servicios en Google Kubernetes Engine (GKE).
Microservicio de Create New Orders
El primer servicio que desglosaremos es el de Pedidos. Usaremos la base de código separada que se proporciona y crearemos un contenedor de Docker aparte para este servicio.
Crea un contenedor de Docker con Google Cloud Build
Como ya migramos la base de código por ti, el primer paso será crear un contenedor de Docker para nuestro servicio de pedidos con Google Cloud Build.
Lo normal sería que adoptes un enfoque de dos pasos que implica compilar un contenedor de Docker y enviarlo a un registro para almacenar la imagen que extraerá GKE. Pero podemos simplificar el proceso, ya que podemos usar Google Cloud Build para compilar el contenedor de Docker y colocar la imagen en Google Cloud Container Registry con un único comando. Esto nos permite ejecutar un solo comando para compilar la imagen y moverla a Container Registry. Aquí puede ver el proceso manual de creación y envío de un Dockerfile.
Google Cloud Build comprimirá los archivos desde el directorio y los moverá a un bucket de Google Cloud Storage. Luego, el proceso de compilación tomará todos los archivos del bucket y usará el Dockerfile para ejecutar el proceso de compilación de Docker. Como especificamos la marca --tag con el host como gcr.io para la imagen de Docker, se enviará la imagen de Docker resultante a Google Cloud Container Registry.
Ejecuta los siguientes comandos para compilar tu contenedor de Docker y enviarlo a Google Container Registry:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Este proceso tardará unos minutos en completarse, pero cuando haya finalizado, se mostrará una salida similar a la siguiente en la terminal:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Para ver tu historial de compilaciones o el proceso en tiempo real, dirígete a la consola de Google Cloud. Haz clic en el botón de menú en la parte superior izquierda, desplázate hacia abajo hasta Herramientas → Cloud Build y haz clic en Historial. Aquí, podrás ver una lista de todas tus compilaciones anteriores. Debería haber una sola recién creada.
Si hace clic en el ID de compilación, puede ver todos sus detalles, incluida la salida del registro.
En la página de detalles de compilación, puedes hacer clic en el nombre de la imagen, en la sección de información de la compilación, para ver la imagen del contenedor que se creó.
Implemente el contenedor en GKE
Ahora que alojamos el sitio web en contenedores y lo enviamos a Google Container Registry, es hora de implementarlo en Kubernetes.
Kubernetes representa aplicaciones como Pods, que son unidades que representan un contenedor (o grupo de contenedores estrechamente vinculados). Un Pod es la unidad más pequeña que se puede implementar en Kubernetes. En este instructivo, cada Pod contiene solo tu contenedor de microservicios.
Para implementar y administrar aplicaciones en un clúster de GKE, debes comunicarte con el sistema de administración de clústeres de Kubernetes. Normalmente, esto se hace con la herramienta de línea de comandos kubectl desde Cloud Shell.
Primero, crearemos un recurso Deployment. Este recurso administra varias copias de tu aplicación, que se llaman réplicas, y las programa para que se ejecuten en los nodos individuales de tu clúster. En este caso, Deployment ejecutará solo un Pod de tu aplicación. Los recursos Deployment crean un ReplicaSet para garantizar esto. El ReplicaSet debe asegurarse de que la cantidad especificada de réplicas siempre esté en ejecución.
El comando kubectl create deployment que aparece a continuación hace que Kubernetes cree un Deployment llamado orders en tu clúster con 1 réplica.
Ejecuta el siguiente comando para implementar tu aplicación:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Verifique el recurso Deployment
Para verificar que el recurso Deployment se haya creado correctamente, ejecuta el siguiente comando. Es posible que el estado del Pod tarde unos minutos en cambiar a “Running”:
kubectl get all
Resultado:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
Este resultado nos muestra varias cosas. Podemos ver el objeto Deployment actual, el ReplicaSet con el recuento deseado de Pods de 1, y el Pod en ejecución. Todo indica que la creación se realizó correctamente.
Expone el contenedor de GKE
Ya implementamos nuestra aplicación en GKE, pero no tenemos manera de acceder a ella desde fuera del clúster. Según la configuración predeterminada, los contenedores que ejecutas en GKE no son accesibles desde Internet, ya que no tienen direcciones IP externas. Debes exponer tu aplicación al tráfico de Internet de forma explícita mediante un recurso Service. Este recurso proporciona herramientas de redes y compatibilidad con IP a los Pods de su aplicación. GKE crea una IP externa y un balanceador de cargas (sujeto a facturación) para su aplicación.
Cuando implementamos nuestro servicio Pedidos, lo expusimos en el puerto 8081 de forma interna a través de una implementación de Kubernetes. Para exponer este servicio de forma externa, debemos crear un servicio Kubernetes del tipo LoadBalancer para enrutar el tráfico desde el puerto 80 de forma externa al puerto interno 8081 para el servicio Pedidos. Ejecuta el siguiente comando para exponer tu sitio web a Internet:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Cómo acceder al servicio
GKE asigna la dirección IP externa al recurso Service, no a Deployment. Si quieres averiguar la IP externa que GKE aprovisionó para tu aplicación, puedes inspeccionar el objeto Service con el comando kubectl get service:
kubectl get service orders
Resultado:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Una vez que hayas determinado la dirección IP externa para tu aplicación, cópiala Guárdala para el próximo paso, en el que cambiará la aplicación monolítica para que apunte a nuestro nuevo servicio Pedidos.
Reconfigure la aplicación monolítica
Como quitamos el servicio Pedidos de la aplicación monolítica, tendremos que modificar la aplicación monolítica para que apunte al nuevo microservicio externo Pedidos.
Cuando desglosamos una aplicación monolítica, quitamos fragmentos de código de una base de código único a varios y, luego, los implementamos por separado. Dado que el microservicio se ejecuta en un servidor diferente, ya no podemos hacer referencia a las URLs de nuestro servicio como rutas de acceso absolutas, por lo que necesitamos una ruta a la nueva dirección del servidor de nuestro microservicio Pedidos. Ten en cuenta que esto requerirá cierto tiempo de inactividad en el Service de la aplicación monolítica para actualizar la URL de cada servicio desglosado. Debes tener en cuenta esto al planificar la migración de tus microservicios y su aplicación monolítica al entorno de producción durante el proceso de migración de microservicios.
Debemos actualizar el archivo de configuración en la aplicación monolítica para que apunte a la dirección IP del nuevo microservicio Pedidos. Usa el editor nano para reemplazar la URL local por la dirección IP de nuestro nuevo microservicio Pedidos. Ejecuta el siguiente comando para editar
cd ~/monolith-to-microservices/react-app nano .env.monolith
Cuando se abra el editor, su archivo debería verse de esta forma:
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
Reemplaza REACT_APP_ORDERS_URL por el formato nuevo y, a la vez, reemplaza por la dirección IP de tu microservicio Pedidos para que coincida con lo que se muestra a continuación:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Presiona CTRL+O, ENTER y, luego, CTRL+X para guardar el archivo en el editor nano.
Para probar tu microservicio nuevo, navega por la URL que acabas de configurar en este archivo. La página web debería devolver una respuesta JSON de nuestro microservicio Pedidos.
A continuación, tendremos que volver a compilar el frontend de la aplicación monolítica y repetir el proceso de compilación para compilar el contenedor para la aplicación monolítica y volver a implementarlo en el clúster de GKE. Ejecuta los siguientes comandos para completar estos pasos:
Vuelva a compilar los archivos de configuración de la aplicación monolítica.
npm run build:monolith
Crea un contenedor de Docker con Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Implemente el contenedor en GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
Puedes verificar que tu aplicación responde al nuevo microservicio Pedidos. Para ello, desde tu navegador, ve a la aplicación monolítica y navega a la página Pedidos. Todos los ID de pedido deberían terminar con el sufijo -MICROSERVICE, como se muestra a continuación:
7. Migre Productos a un microservicio
Microservicio de creación de productos nuevos
A continuación, podemos seguir desglosando nuestros servicios migrando el servicio Productos. Seguiremos el mismo proceso que el paso anterior. Ejecuta los siguientes comandos para compilar un contenedor de Docker, implementa tu contenedor y expónlo mediante un servicio de Kubernetes.
Crea un contenedor de Docker con Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Implemente el contenedor en GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
Expone el contenedor de GKE
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
Encuentra la IP pública de nuestros servicios de Productos de la misma manera que lo hicimos para nuestro servicio de Pedidos con el siguiente comando:
kubectl get service products
Resultado:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Guarda la dirección IP para el próximo paso cuando reconfiguremos la aplicación monolítica de modo que apunte a nuestro nuevo microservicio Productos.
Reconfigure la aplicación monolítica
Usa el editor nano para reemplazar la URL local por la dirección IP de nuestro nuevo microservicio Productos:
cd ~/monolith-to-microservices/react-app nano .env.monolith
Cuando se abra el editor, su archivo debería verse de esta forma:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Reemplaza REACT_APP_PRODUCTS_URL por el formato nuevo y, a la vez, reemplaza por la dirección IP de tu microservicio Productos para que coincida con lo que se muestra a continuación:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
Presiona CTRL+O, ENTER y, luego, CTRL+X para guardar el archivo en el editor nano.
Para probar tu microservicio nuevo, navega por la URL que acabas de configurar en este archivo. La página web debería devolver una respuesta JSON de nuestro microservicio Productos.
A continuación, tendremos que volver a compilar el frontend de la aplicación monolítica y repetir el proceso de compilación para compilar el contenedor para la aplicación monolítica y volver a implementarlo en el clúster de GKE. Ejecuta los siguientes comandos para completar estos pasos:
Vuelva a compilar los archivos de configuración de la aplicación monolítica.
npm run build:monolith
Crea un contenedor de Docker con Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Implemente el contenedor en GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
Para verificar que tu aplicación responde al nuevo microservicio Productos, ve a la aplicación monolítica en tu navegador y navega a la página Productos. Todos los nombres de los productos deberían comenzar con el prefijo MS- como se muestra a continuación:
8. Migra el frontend a un microservicio
El último paso del proceso de migración consiste en mover el código Frontend a un microservicio y cerrar la aplicación monolítica. Cuando se complete este paso, habremos migrado con éxito nuestra aplicación monolítica a una arquitectura de microservicios.
Cree un nuevo microservicio Frontend
Sigamos el mismo procedimiento que en los últimos dos pasos para crear un nuevo microservicio Frontend.
Antes, cuando volvimos a compilar la aplicación monolítica, actualizamos la configuración para que apunte a la aplicación monolítica, pero ahora debemos usar la misma configuración para el microservicio Frontend. Ejecuta los siguientes comandos para copiar los archivos de configuración de URLs de microservicios en la base de código del microservicio Frontend:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
Una vez que se complete, seguiremos el mismo proceso que los pasos anteriores. Ejecuta los siguientes comandos para compilar un contenedor de Docker, implementa tu contenedor y expónlo mediante un servicio de Kubernetes.
Crea un contenedor de Docker con Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
Implemente el contenedor en GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
Expone el contenedor de GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
Borre la aplicación monolítica
Ahora que todos nuestros servicios se ejecutan como microservicios, podemos borrar nuestra aplicación monolítica. Ten en cuenta que, en una migración real, esto implicaría también cambios de DNS, entre otros, para lograr que nuestros nombres de dominio apunten a los microservicios nuevos Frontend de nuestra aplicación. Ejecuta los siguientes comandos para borrar nuestra aplicación monolítica:
kubectl delete deployment monolith kubectl delete service monolith
Pruebe su trabajo
Para verificar que todo está en funcionamiento, la dirección IP anterior de tu Service de aplicación monolítica no debería funcionar, y la nueva dirección IP de tu servicio Frontend debería alojar la nueva aplicación. Para ver una lista de todos los servicios y las direcciones IP, usa el siguiente comando:
kubectl get services
El resultado debería ser similar al siguiente:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
Cuando hayas determinado la dirección IP externa para tu microservicio Frontend, cópiala y escribe esta URL (como http://203.0.113.0) en tu navegador para verificar si se puede acceder a tu Frontend. Tu sitio web debería verse igual que antes de desglosar la aplicación monolítica en microservicios.
9. Limpieza
Una vez que esté listo, la forma más fácil de limpiar todas las actividades realizadas es borrar el proyecto. Si borras el proyecto, se borrarán todos los recursos que se crearon en este codelab para garantizar que no se produzcan cargos recurrentes inesperados. Ejecuta el siguiente comando en Cloud Shell, en el que PROJECT_ID es el ID completo del proyecto y no solo el nombre del proyecto.
gcloud projects delete [PROJECT_ID]
Ingresa “Y” para confirmar la eliminación. cuando se te solicite.
10. ¡Felicitaciones!
Desglosaste tu aplicación monolítica en microservicios y los implementaste en Google Kubernetes Engine con éxito.
Próximos pasos
Consulta los siguientes codelabs para obtener más información sobre Kubernetes:
- Cómo implementar, escalar y actualizar tu sitio web en Google Kubernetes Engine
- Compila un bot de Slack con Node.js en Kubernetes
- Entrega continua en Kubernetes mediante Spinnaker
- Cómo implementar una aplicación de Java en Kubernetes en Google Kubernetes Engine
Recursos adicionales
- Docker: https://docs.docker.com/
- Kubernetes: https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE): https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build: https://cloud.google.com/cloud-build/docs/
- Google Container Registry: https://cloud.google.com/container-registry/docs/
- Migración de una aplicación monolítica a microservicios - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke