Criar um serviço SaaS sem servidor não é uma tarefa fácil.
As equipes enfrentam desafios como:
Como você implanta na nuvem?
Como você lida com a observabilidade no domínio sem servidor?
O que torna um manipulador AWS Lambda resiliente, rastreável e fácil de manter?
Como você escreve esse código?
Como você testa seu código?
E se você pudesse ter um gateway mais acessível para o fantástico mundo do AWS Serverless e obter uma solução pronta para produção para esses desafios?
Neste blog, apresentarei meu projeto de modelo de código aberto que fornece um serviço totalmente implantável (com AWS CDK), um pipeline de CI/CD, cobertura de teste de 100% e um manipulador AWS Lambda que contém todas as melhores práticas.
Comece sua jornada Serverless com apenas DOIS cliques do mouse no Github HOJE MESMO.
Este blog se concentra no projeto do modelo GitHub do AWS Lambda Cookbook apresentado nas seis primeiras partes da série de blogs do AWS Lambda Cookbook.
Caso você tenha perdido os últimos blogs:
Parte 1 focada em Registro.
A Parte 2 focou na Observabilidade: monitoramento e rastreamento.
A Parte 3 focou na Observabilidade do Domínio de Negócios .
A Parte 4 focou em Variáveis de Ambiente .
A Parte 5 focou na Validação de Entrada .
A Parte 6 focou na configuração dinâmica e sinalizadores de recursos inteligentes.
Parte 8 focado nas melhores práticas do AWS CDK .
Modelo de serviço sem servidor - O serviço de pedidos
O projeto de modelo que usaremos é um serviço de pedidos simples.
Ele tem uma API GW que aciona uma função AWS Lambda no caminho POST /api/orders.
Ele armazena todos os pedidos em uma tabela do Amazon DynamoDB.
Ele também implanta e armazena configuração dinâmica e sinalizadores de recursos no AWS AppConfig.
Leia mais sobre isso aqui .
Você também está recebendo:
Pipeline de CI/CD baseado em ações do GitHub com Python e melhores práticas de segurança (linters, formatadores de código, etc.).
Projeto implantável CDK 2.
Arquivos do manipulador do AWS Lambda com todas as práticas recomendadas descritas na minha série de blogs sobre práticas recomendadas.
Utilitário Makefile que simplifica o desenvolvimento.
Testes unitários, testes de integração, infraestrutura, segurança e testes E2E.
Cobertura de código de 100%, incluindo testes de segurança.
TL;DR Vídeo
Esta postagem do blog foi apresentada em uma conferência e está disponível como um vídeo.
Começando
Clique no botão "Usar este modelo", ao lado da seção "Sobre".
Em seguida, preencha o nome do seu repositório para seu novo e brilhante aplicativo AWS Serverless.
Você deve selecionar a opção 'Privado'. Você deve escolher público somente se decidir tornar o projeto de código aberto.
Clique em 'Criar repositório a partir deste modelo'.
Para este exemplo, escolhi 'my-service' como nome do repositório.
Nasce um novo aplicativo sem servidor da AWS
Parabéns! Você criou seu próprio aplicativo Python 3.9 Serverless.
Configurações do projeto
Vá até as configurações do projeto 'Geral' e habilite os diferentes scanners em segurança. Essas configurações manterão você seguro e atualizado. Certifique-se também de permitir a varredura de código. Você pode ler mais sobre a integração do dependabot aqui .
O ponto de partida é assim:
Deve ficar assim:
Introdução ao ambiente de desenvolvimento local
Clonar o Projeto
Se você não tiver certeza de como clonar seu projeto e configurar suas credenciais corretamente, siga este guia .
Pré-requisitos de instalação
Acesse a documentação oficial do modelo e siga o guia de primeiros passos.
Criar ambiente virtual
Abra o projeto via IDE. Inicie um terminal.
Usamos poesia para gerenciar dependências do Python.
Execute 'make dev'. Este comando instalará todas as dependências necessárias do projeto e abrirá um novo shell de ambiente virtual.
Faça o arquivo
O projeto tem um makefile totalmente funcional que abrange todos os aspectos do pipeline: formatação de código, linters, classificador de importação e testes.
Você pode ler mais sobre os diferentes comandos makefile aqui .
Implantar na AWS
Execute 'make deploy'.
Assim que o CDK terminar a implantação, você encontrará uma nova pilha chamada 'cookbook' no AWS CloudFormation. Agora você pode executar testes de integração e E2E.
Quando você quiser excluir a pilha, execute 'make destroy.'
Executar testes
Execute 'make pr'. Este comando executará todas as verificações necessárias, hooks de pré-commit, linters, formatos de código, pylint e testes, para que você tenha certeza de que o pipeline do GitHub passará.
Se houver um erro no estágio de pré-confirmação, ele será corrigido automaticamente.
No entanto, eles devem executar 'make pr' novamente para prosseguir para os próximos estágios.
Certifique-se de confirmar todas as alterações que o pr faz.
Testes Unitários
Os testes de unidade podem ser encontrados na pasta tests/unit.
Você pode executar os testes usando o seguinte comando: 'make unit.'
Testes de Infraestrutura e Segurança
Os testes podem ser encontrados na pasta tests/infrastructure.
Você pode executar os testes usando o seguinte comando: 'make infra-tests.'
Leia mais sobre esses testes no meu guia de melhores práticas do CDK.
Testes de Integração
Certifique-se de implantar a pilha primeiro, pois esses testes acionam seu manipulador lambda LOCALMENTE, mas eles podem se comunicar com os serviços da AWS.
Esses testes permitem que você depure sua função AWS Lambda no seu IDE.
Os testes de integração podem ser encontrados na pasta tests/integration.
Você pode executar os testes usando o seguinte comando: 'make integration.'
Testes E2E
Certifique-se de implantar a pilha primeiro.
Os testes E2E podem ser encontrados na pasta tests/e2e.
Esses testes enviam uma mensagem 'POST' para o API GW implantado e acionam a função Lambda na AWS.
Os testes são executados automaticamente por: 'make e2e'.
Estrutura do Projeto
O projeto é construído a partir de dois projetos internos: o projeto CDK de infraestrutura como código e o código de serviço (código do manipulador AWS Lambda com testes).
Pastas:
Pasta CDK : sob a pasta 'cdk'. Um aplicativo CDK implanta uma pilha que consiste em uma ou mais construções CDK. As construções CDK contêm recursos AWS e suas conexões/relações. Leia mais sobre os detalhes do projeto CDK aqui e aqui .
pasta docs : pasta de documentação das páginas do GitHub.
pasta service : Arquivos de projeto do AWS Lambda: handler, esquemas de entrada/saída, etc., e pasta utility. Cada handler tem sua própria pasta schemas. A pasta Utils é um código compartilhado entre vários handlers.
pasta de testes : testes unitários/de integração/infra e E2E.
Pipeline de CI/CD
Você pode ler mais sobre isso aqui .
O pipeline usa comandos Makefile e é baseado em ações do GitHub.
As ações podem ser encontradas na pasta '.github/workflows'.
Adicionando Novo Código
Ao adicionar um novo manipulador do AWS Lambda ou qualquer recurso da AWS, você adicionará o IaC que o implanta na pasta 'cdk', o código do manipulador na pasta de serviço e testará o código nas pastas tests/integration e tests/e2e.
Tem perguntas?
Inicie uma nova discussão no quadro de discussões do GitHub sobre o modelo.
Quer saber mais?
Siga a documentação oficial do modelo aqui .
Clique aqui para ler a série de blogs AWS Lambda CookBook .
Comments