Construir un servicio SaaS sin servidor no es una tarea fácil.
Los equipos enfrentan desafíos como:
¿Cómo se implementa en la nube?
¿Cómo se gestiona la observabilidad en el dominio sin servidor?
¿Qué hace que un controlador de AWS Lambda sea resistente, rastreable y fácil de mantener?
¿Cómo se escribe un código así?
¿Cómo pruebas tu código?
¿Qué pasaría si pudiera tener una puerta de entrada más accesible al fantástico mundo de AWS Serverless y obtener una solución lista para producción para estos desafíos?
En este blog, presentaré mi proyecto de plantilla de código abierto que proporciona un servicio completamente implementable (con AWS CDK), una canalización CI/CD, una cobertura de prueba del 100 % y un controlador AWS Lambda que contiene todas las mejores prácticas.
Comience su viaje sin servidor con solo DOS clics del mouse en Github HOY.
Este blog se centra en el proyecto de plantilla de GitHub de AWS Lambda Cookbook presentado en las primeras seis partes de la serie de blogs de AWS Lambda Cookbook.
En caso de que te hayas perdido los últimos blogs:
La parte 1 se centró en el registro.
La segunda parte se centró en la observabilidad: seguimiento y rastreo.
La parte 3 se centró en la observabilidad del dominio empresarial .
La parte 4 se centró en las variables de entorno .
La parte 5 se centró en la validación de entrada .
La parte 6 se centró en la configuración dinámica y los indicadores de funciones inteligentes.
Parte 8 centrado en las mejores prácticas de AWS CDK .
Plantilla de servicio sin servidor: el servicio de pedidos
El proyecto de plantilla que utilizaremos es un servicio de pedidos simple.
Tiene una API GW que activa una función AWS Lambda en la ruta POST /api/orders.
Almacena todos los pedidos en una tabla de Amazon DynamoDB.
También implementa y almacena configuraciones dinámicas y marcas de características en AWS AppConfig.
Lea más sobre esto aquí .
También obtendrás:
Pipeline CI/CD basada en acciones de GitHub con Python y mejores prácticas de seguridad (linters, formateadores de código, etc.).
Proyecto implementable CDK 2.
Archivos del controlador AWS Lambda con todas las mejores prácticas descritas en mi serie de blogs sobre mejores prácticas.
Utilidad Makefile que simplifica el desarrollo.
Pruebas unitarias, pruebas de integración, infraestructura, seguridad y pruebas E2E.
Cobertura de código del 100%, incluidas pruebas de seguridad.
Vídeo TL;DR
Esta entrada de blog se presentó en una conferencia y está disponible como vídeo.
Empezando
Haga clic en el botón “Usar esta plantilla”, junto a la sección “Acerca de”.
A continuación, complete el nombre de su repositorio para su nueva y brillante aplicación AWS Serverless.
Debes seleccionar la opción "Privado". Debes elegir público solo si decides que el proyecto sea de código abierto.
Haga clic en “Crear repositorio a partir de esta plantilla”.
Para este ejemplo, elegí “mi-servicio” como nombre del repositorio.
Nace una nueva aplicación sin servidor de AWS
¡Felicitaciones! Has creado tu propia aplicación Python 3.9 Serverless.
Configuración del proyecto
Dirígete a la configuración del proyecto "General" y habilita los diferentes escáneres en la sección de seguridad. Estas configuraciones te mantendrán seguro y actualizado. Asegúrate también de permitir el escaneo de código. Puedes leer más sobre la integración de dependabot aquí .
El punto de partida se ve así:
Debería verse así:
Introducción al entorno de desarrollo local
Clonar el proyecto
Si no está seguro de cómo clonar su proyecto y configurar sus credenciales correctamente, siga esta guía .
Requisitos previos de instalación
Vaya a la documentación oficial de la plantilla y siga la guía de inicio.
Crear entorno virtual
Abra el proyecto a través de IDE. Abra una terminal.
Usamos poesía para gestionar las dependencias de Python.
Ejecute "make dev". Este comando instalará todas las dependencias necesarias del proyecto y abrirá un nuevo entorno virtual.
Archivo Make
El proyecto tiene un makefile completamente funcional que cubre todos los aspectos del pipeline: formato de código, linters, clasificador de importaciones y pruebas.
Puede leer más sobre los diferentes comandos makefile aquí .
Implementar en AWS
Ejecute 'make deployment'.
Una vez que CDK finalice la implementación, encontrará una nueva pila llamada "libro de recetas" en AWS CloudFormation. Ahora puede ejecutar pruebas de integración y de extremo a extremo.
Cuando desee eliminar la pila, ejecute 'make destroy'.
Ejecutar pruebas
Ejecute 'make pr'. Este comando ejecutará todas las comprobaciones necesarias, los ganchos de preconfirmación, los linters, los formatos de código, pylint y las pruebas, por lo que puede estar seguro de que la canalización de GitHub funcionará correctamente.
Si hay un error en la etapa previa a la confirmación, se corrige automáticamente.
Sin embargo, deben ejecutar 'make pr' nuevamente, para continuar con las siguientes etapas.
Asegúrese de confirmar todos los cambios que realiza pr.
Pruebas unitarias
Las pruebas unitarias se pueden encontrar en la carpeta pruebas/unidad.
Puede ejecutar las pruebas utilizando el siguiente comando: 'make unit'.
Pruebas de infraestructura y seguridad
Las pruebas se pueden encontrar en la carpeta pruebas/infraestructura.
Puede ejecutar las pruebas utilizando el siguiente comando: 'make infra-tests'.
Lea más sobre estas pruebas en mi guía de mejores prácticas de CDK.
Pruebas de integración
Asegúrese de implementar la pila primero, ya que estas pruebas activan su controlador lambda LOCALMENTE, pero pueden comunicarse con los servicios de AWS.
Estas pruebas le permiten depurar en su IDE su función AWS Lambda.
Las pruebas de integración se pueden encontrar en la carpeta pruebas/integración.
Puede ejecutar las pruebas utilizando el siguiente comando: 'make integration'.
Pruebas E2E
Asegúrese de implementar la pila primero.
Las pruebas E2E se pueden encontrar en la carpeta pruebas/e2e.
Estas pruebas envían un mensaje 'POST' a la API GW implementada y activan la función Lambda en AWS.
Las pruebas se ejecutan automáticamente mediante: 'make e2e'.
Estructura del proyecto
El proyecto se construye a partir de dos proyectos internos: el proyecto CDK de infraestructura como código y el código del servicio (código del controlador AWS Lambda con pruebas).
Carpetas:
Carpeta CDK : en la carpeta "cdk". Una aplicación CDK implementa una pila que consta de una o más construcciones CDK. Las construcciones CDK contienen recursos de AWS y sus conexiones/relaciones. Lea más sobre los detalles del proyecto CDK aquí y aquí .
Carpeta docs : carpeta de documentación de las páginas de GitHub.
Carpeta de servicio : archivos del proyecto AWS Lambda: controlador, esquemas de entrada/salida, etc., y carpeta de utilidades. Cada controlador tiene su propia carpeta de esquemas. La carpeta de utilidades es un código compartido entre varios controladores.
Carpeta de pruebas : pruebas unitarias/de integración/de infraestructura y E2E.
Canalización de CI/CD
Puedes leer más sobre ello aquí .
La canalización utiliza comandos Makefile y se basa en acciones de GitHub.
Las acciones se pueden encontrar en la carpeta '.github/workflows'.
Agregar nuevo código
Cuando agrega un nuevo controlador de AWS Lambda o cualquier recurso de AWS, agregará el IaC que lo implementa en la carpeta "cdk", el código del controlador en la carpeta de servicio y probará el código en las carpetas pruebas/integración y pruebas/e2e.
¿Tienes preguntas?
Inicie una nueva discusión en el tablero de discusiones de GitHub de la plantilla.
¿Quieres saber más?
Siga la documentación oficial de la plantilla aquí .
Haga clic aquí para leer la serie de blogs AWS Lambda CookBook .
Comments