Ruta de aprendizaje: Transforma un monolítico en una app de GKE: Prepara la app modular para la contenedorización

Este es el tercer instructivo de una ruta de aprendizaje que te enseña a modularizar y contenerizar una app monolítica.

La ruta de aprendizaje consta de los siguientes instructivos:

  1. Descripción general
  2. Comprende la aplicación monolítica
  3. Modulariza la aplicación monolítica
  4. Prepara la app modular para la organización en contenedores (este instructivo)
  5. Crea contenedores para la app modular
  6. Implementa la app en un clúster de GKE

En el instructivo anterior, Modulariza el monolito, viste cómo dividir la app de Cymbal Books en módulos independientes de Flask. En este instructivo, aprenderás sobre un solo cambio que se debe realizar en la app modular para prepararla para la contenerización.

Costos

Puedes completar este instructivo sin incurrir en cargos. Sin embargo, seguir los pasos del instructivo final de esta serie genera cargos en tu cuenta deGoogle Cloud . Los costos comienzan cuando habilitas GKE y, luego, implementas la app de Cymbal Books en un clúster de GKE. Estos costos incluyen los cargos por clúster de GKE, como se indica en la página de precios, y los cargos por ejecutar VMs de Compute Engine.

Para evitar cargos innecesarios, asegúrate de inhabilitar GKE o borrar el proyecto una vez que hayas completado este instructivo.

Antes de comenzar

Antes de comenzar con este instructivo, asegúrate de haber completado los instructivos anteriores de la serie. Para obtener una descripción general de toda la serie y vínculos a instructivos específicos, consulta Ruta de aprendizaje: Transforma un monolito en una app de GKE: Descripción general.

Si ya completaste el primer instructivo, clonaste un repositorio de GitHub. Las tres versiones de la app de Cymbal Books se encuentran en ese repositorio, dentro de las siguientes carpetas:

  • monolith/
  • modular/
  • containerized/

Antes de continuar, verifica que estas carpetas estén en tu máquina.

Cambia el código modular

En el instructivo anterior, aprendiste que el módulo de la página principal se comunica con los demás módulos. Envía solicitudes a los extremos de los otros módulos para recuperar detalles, opiniones e imágenes de los libros, y, luego, presenta estos datos en páginas HTML.

En la carpeta modular/, los extremos están codificados de forma rígida en home.py, con 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 trasladar a diferentes máquinas para controlar las fallas o equilibrar la carga, lo que significa que sus direcciones IP podrían cambiar.

Para asegurarte 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. Un nombre de servicio actúa como un alias que Kubernetes usa para enrutar solicitudes al módulo correcto, sin importar 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 garantiza que la solicitud llegue al módulo de detalles del libro.

No es necesario que actualices estas URLs por tu cuenta. La versión de la app en la carpeta containerized/ ya incluye este cambio: Las URLs localhost codificadas se reemplazaron por nombres de servicios 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 garantiza que la app funcione correctamente cuando se ejecute en un entorno de Kubernetes.

El manifiesto de Kubernetes

En la sección anterior, viste cómo se actualizaron los extremos 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 qué tipo de clúster de Kubernetes deseas crear para alojar tu app modular. El manifiesto se escribe en YAML o JSON. En él, defines aspectos como los servicios (para el enrutamiento entre módulos), la cantidad de réplicas (instancias) de cada módulo y la cantidad de CPU y memoria que se permite usar a cada módulo.

Se podría escribir una serie completa de instructivos sobre los manifiestos de Kubernetes. El manifiesto es complejo porque define todo sobre tu clúster de Kubernetes: su estructura, comportamiento y capacidades. En este instructivo, solo verás cómo los nombres de servicio del manifiesto coinciden con los nombres que se usan en los extremos de los módulos. En un instructivo 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 instructivo, solo revisarás el manifiesto.

Cómo ver el manifiesto

En esta sección, examinarás cómo se definen los Services en un manifiesto de Kubernetes que se escribió 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 instructivo de esta serie. Sigue estos pasos para ver la definición de un servicio:

  1. En la terminal, navega 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 Service para el módulo book-details. Se ve como en el siguiente ejemplo:

    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 nombre del servicio book-details-service en el manifiesto coincide con el nombre que se usa en el extremo del módulo: http://book-details-service. Cuando tu app se ejecuta en Kubernetes, este usa los nombres de estos servicios 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 controlan el enrutamiento de solicitudes. Cada módulo de tu app tiene un servicio correspondiente que se define en el manifiesto. Si actualizas las URLs en el 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 app se ejecute en un clúster.

Resumen

En este instructivo, viste cómo se actualizaron las URLs en el código modular para usar nombres de servicio de Kubernetes, como http://book-details-service. Estos nombres de servicio permiten que Kubernetes enrute solicitudes entre módulos incluso cuando cambian sus ubicaciones en el clúster. También examinaste el manifiesto de Kubernetes y viste cómo los nombres de los servicios en el código modular coinciden con los nombres definidos en el manifiesto.

¿Qué sigue?

En el siguiente instructivo, Crea un contenedor para la app modular, aprenderás a crear un contenedor para un módulo empaquetándolo en algo llamado imagen de contenedor. Luego, verás cómo ejecutar una imagen de contenedor como un contenedor, probar sus funciones y enviar la imagen de contenedor a Artifact Registry de Google.