Ruta de aprendizaje: transforma una aplicación monolítica en una aplicación de GKE - Prepara la aplicación modular para la contenedorización

Este es el tercer tutorial de una ruta de aprendizaje que te enseña a modularizar y contenerizar una aplicación monolítica.

El recorrido de aprendizaje consta de los siguientes tutoriales:

  1. Descripción general
  2. Información sobre el monolito
  3. Modularizar el monolito
  4. Preparar la aplicación modular para la contenerización (este tutorial)
  5. Contenerizar la aplicación modular
  6. Desplegar la aplicación en un clúster de GKE

En el tutorial anterior, Modularizar el monolito, has visto cómo dividir la aplicación Cymbal Books en módulos de Flask independientes. En este tutorial, aprenderás a hacer un cambio en la aplicación modular para prepararla para la contenerización.

Costes

Puedes completar este tutorial sin incurrir en ningún cargo. Sin embargo, si sigues los pasos del último tutorial de esta serie, se aplicarán cargos a tu cuenta deGoogle Cloud . Los costes empiezan cuando habilitas GKE y despliegas la aplicación Cymbal Books en un clúster de GKE. Estos costes incluyen los cargos por clúster de GKE, tal como se indica en la página de precios, y los cargos por ejecutar máquinas virtuales de Compute Engine.

Para evitar cargos innecesarios, inhabilita GKE o elimina el proyecto una vez que hayas completado este tutorial.

Antes de empezar

Antes de empezar este tutorial, asegúrate de haber completado los tutoriales anteriores de la serie. Para ver un resumen de toda la serie y enlaces a tutoriales específicos, consulta Plan de formación: transformar una aplicación monolítica en una aplicación de GKE (resumen).

Si ya has completado el primer tutorial, habrás clonado un repositorio de GitHub. Las tres versiones de la aplicación Cymbal Books se encuentran en ese repositorio, dentro de las siguientes carpetas:

  • monolith/
  • modular/
  • containerized/

Comprueba que estas carpetas estén en tu máquina antes de continuar.

Cambiar el código modular

En el tutorial anterior, vimos que el módulo de la página principal se comunica con los demás módulos. Envía solicitudes a los endpoints de los demás módulos para obtener detalles, reseñas e imágenes de los libros y, a continuación, presenta estos datos en páginas HTML.

En la carpeta modular/, los endpoints están codificados en home.py mediante localhost, de la siguiente manera:

BOOK_SERVICE_URL = "http://localhost:8081"     # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082"   # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083"    # Image module listens on port 8083

Estas URLs funcionan cuando todos los módulos se ejecutan en la misma máquina. Sin embargo, en un entorno de Kubernetes, los módulos se pueden mover a diferentes máquinas para gestionar los errores o equilibrar la carga, lo que significa que sus direcciones IP pueden cambiar.

Para asegurarse de que el módulo de la página principal pueda seguir accediendo a los demás módulos, las URLs deben usar nombres de servicio de Kubernetes en lugar de localhost. El nombre de un servicio actúa como un alias que Kubernetes usa para enrutar las solicitudes al módulo correcto, independientemente de dónde se ejecute. Por ejemplo, cuando el módulo de la página principal envía una solicitud a http://book-details-service/book/1, Kubernetes se asegura de que la solicitud llegue al módulo de detalles del libro.

No es necesario que actualice estas URLs usted mismo. La versión de la aplicación de la carpeta containerized/ ya incluye este cambio: las URLs localhost codificadas se han sustituido por nombres de servicio de Kubernetes. Puedes ver la versión actualizada en containerized/home_app/home_app.py:

BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"

Esta actualización asegura que la aplicación funcione correctamente cuando se ejecute en un entorno de Kubernetes.

El manifiesto de Kubernetes

En la sección anterior, has visto cómo se han actualizado los endpoints de los módulos para usar nombres de servicio de Kubernetes. Los nombres de los servicios se definen en el manifiesto de Kubernetes.

El manifiesto de Kubernetes es un archivo de configuración que define el tipo de clúster de Kubernetes que quieres crear para alojar tu aplicación modular. El manifiesto se escribe en YAML o JSON. En él, se definen aspectos como los servicios (para enrutar entre módulos), el número de réplicas (instancias) de cada módulo y la cantidad de CPU y memoria que puede usar cada módulo.

Se podría escribir una serie completa de tutoriales sobre los manifiestos de Kubernetes. El manifiesto es complejo porque define todo lo relacionado con tu clúster de Kubernetes: su estructura, su comportamiento y sus funciones. En este tutorial, solo se explica cómo coinciden los nombres de los servicios del manifiesto con los nombres que se usan en los endpoints de los módulos. En un tutorial posterior, ejecutarás el comando kubectl apply para crear el clúster de GKE según la configuración definida en el manifiesto, pero en este tutorial solo revisarás el manifiesto.

Ver el archivo de manifiesto

En esta sección, examinarás cómo se definen los servicios en un manifiesto de Kubernetes que se ha escrito para ti. El archivo de manifiesto, que es un archivo YAML, se encuentra en la carpeta containerized/ del repositorio de GitHub que clonaste en el primer tutorial de esta serie. Sigue estos pasos para ver una definición de servicio:

  1. En tu terminal, ve al directorio del contenedor en el repositorio clonado:

    cd containerized

  2. En un editor de texto, abre el archivo de manifiesto de Kubernetes:

    cat kubernetes_manifest.yaml

  3. Busca la definición de servicio del módulo book-details. Tiene el siguiente aspecto:

    apiVersion: v1
kind: Service
metadata:
name: book-details-service
spec:
selector:
    app: book-details-app
ports:
    - protocol: TCP
    port: 80  # External traffic on port 80
    targetPort: 8080  # Targeting container port 8080
type: ClusterIP

El book-details-service Service name del manifiesto coincide con el nombre que se usa en el endpoint del módulo: http://book-details-service. Cuando tu aplicación se ejecuta en Kubernetes, Kubernetes usa estos nombres de servicio para enrutar las solicitudes a los módulos correctos.

El manifiesto de Kubernetes define las características de tu clúster de Kubernetes, incluidos los servicios que gestionan el enrutamiento de solicitudes. Cada módulo de tu aplicación tiene un servicio correspondiente definido en el manifiesto. Si actualizas las URLs del código modular para que coincidan con estos nombres de servicio, te aseguras de que Kubernetes pueda enrutar las solicitudes a los módulos correctos cuando la aplicación se ejecute en un clúster.

Resumen

En este tutorial, has visto cómo se han actualizado las URLs del código modular para usar nombres de servicio de Kubernetes, como http://book-details-service. Estos nombres de servicio permiten que Kubernetes enrute las solicitudes entre módulos aunque cambie su ubicación en el clúster. También has examinado el manifiesto de Kubernetes y has visto cómo los nombres de los servicios del código modular coinciden con los nombres definidos en el manifiesto.

Siguientes pasos

En el siguiente tutorial, Contenerizar la aplicación modular, aprenderás a contenerizar un módulo empaquetándolo en lo que se denomina imagen de contenedor. Después, verás cómo ejecutar una imagen de contenedor como contenedor, probar sus funciones y enviar la imagen de contenedor a Artifact Registry de Google.