O blog da AWS
Trabalhando com Amazon API Gateway e AWS Lambda Aliases
Por Raphael Lima, Solutions Architect, Enterprise e
Leonardo Piedade, Solutions Architect, DNB/ISV
Sempre quando falamos do desenvolvimento de Aplicações Modernas é importante destacarmos algumas características que ajudam a aumentar a velocidade das entregas de software e também trazem novas possibilidades aos desenvolvedores. A principal característica deste tipo de aplicação é o desacoplamento, ao desacoplar as camadas da nossa aplicação conseguimos ter mais controle em cada um dos componentes envolvidos. Neste post vamos falar sobre como podemos evoluir o código das nossas aplicações em Lambda sem precisar realizar a alteração nos endpoints que estão sendo consumidos pelos clientes de nossas APIs. Esta técnica é útil em outros casos de uso como, por exemplo, utilizar o canary como estratégia de publicação e até mesmo implementar testes A/B em suas APIs.
Para implementar esta técnica vamos utilizar algumas funcionalidades do Amazon API Gateway e do AWS Lambda.
O API Gateway permite a criação de diversos estágios, onde você pode definir cada um deles como sendo um ambiente diferente, por exemplo, DEV, HOM e PRD. Esta funcionalidade permite a publicação de suas APIs de forma gradual, o que traz mais controle no processo de entrega de software desde o momento que ele está sendo desenvolvido até o momento que ele está disponível para ser utilizado em produção.
Por padrão, o API Gateway utiliza a última versão do Lambda para poder realizar as requisições, esta versão é conhecida como LATEST. Se o desenvolvedor realizar uma alteração no Lambda que está no ambiente de produção, esta alteração será refletida imediatamente no ambiente e caso o código não atenda os requisitos de negócio ou tenha algum outro BUG, o cliente poderá ser impactado. Para resolver este problema utilizamos o versionamento das funções Lambda. Em conjunto com o AWS Lambda Aliases é possível realizar o balanceamento entre diferentes versões do seu código, o que torna o processo de entrega de software mais seguro e confiável. Por exemplo, você pode publicar uma nova versão da aplicação e enviar somente 10% das requisições para ela e avaliar o resultado; e à medida que os resultados são satisfatórios, você pode incrementar esta taxa até chegar em 100% e ter a totalidade das requisições sendo atendidas pela nova versão da aplicação.
Nesse post, será apresentado:
- Parte I: Criação de uma função Lambda e seu Alias;
- Parte II: Criação de uma nova versão da função Lambda;
- Parte III: Publicação no API Gateway;
- Parte IV: Configuração dos Stages & Stage Variables no API Gateway;
- Parte V: Testes dos Múltiplos Stages e Versões de Lambda.
Parte I: Criação de uma função Lambda e seu Alias
- Acesse a Console do serviço AWS Lambda: https://console.thinkwithwp.com/lambda/
- Clique em “Create Function”;
- Mantenha a opção “Author from scratch” selecionada;
- Digite um nome para sua função no campo “function name”;
- Altere o “Runtime” para Python 3.8;
- Clique em “Create Function” novamente.
- Após criada a função Lambda, clique em “Actions” e em “Create alias”
- Crie o alias com o nome “dev” apontando para versão $LATEST
- Crie um segundo alias com o nome “prod” apontando para a versão $LATEST
Com isso você terá dois aliases criados, direcionando para a execução da última versão da sua função Lambda $LATEST
Parte II: Criação de uma nova versão da função Lambda
Vamos agora simular um fluxo de desenvolvimento para nossa função Lambda e o gateway de API. Neste momento nosso alias de prod e dev estão apontando para a “$LATEST”.
1. Agora precisamos criar uma versão para nosso Lambda, e atribuir ao alias de prod. Selecione a opção “Actions” e depois a opção “Publish new version”.
2. Na próxima tela, coloque uma descrição que identifique sua versão e clique em “Publish”
3. Agora você será direcionado a tela da função na versão criada.
Obs: para cada versão criada o id da versão é incrementado em 1.
Precisamos diferenciar a versão da função utilizada por cada Alias que foram criados.
4. Clique na Opção “Version”, selecione a aba “alias” e então clique em “prod”.
5. Agora no alias de prod, vá em “alias configuration” e clique em “edit”.
6. Na próxima tela, selecione a versão criada e clique em “Save”
7. Agora vamos alterar o código da função. Selecione novamente a versão $LATEST clicando na opção “Alias: prod”, selecione a aba “Versions” e escolha a opção “$LATEST”.
8. Mais abaixo, edite o seguinte código e clique em “Deploy”
import json def lambda_handler(event, context): return { 'statusCode': 200, 'body': json.dumps('Hello World!') } |
O resultado são dois Lambda Alias, cada Alias direcionando para uma versão da função:
Parte III: Publicação no API Gateway
- Acesse o Serviço API Gateway: https://console.thinkwithwp.com/apigateway/
- Clique em “Create API”
- Escolha “REST API” e clique em “Build”
- Escolha o nome da API e clique em “Create API”
- Clique em “Actions” para criar uma nova rota no API Gateway integrando com Lambda. Utilizar ${stageVariables.lambdaAlias} para apontar para o Alias de seleção de ambiente.
- Quando você clicar em “Save”, será exibida uma mensagem para Adicionar permissão no AWS Lambda para execução do Gateway, conforme abaixo:
7. Utilizando o awscli, basta executar o comando abaixo substituindo os valores apropriados de sua conta para cada alias da sua função Lambda.
aws lambda add-permission --function-name "arn:aws:lambda:us-east-1:<account-number>:function:HelloWorld:dev" --source-arn "arn:aws:execute-api:us-east-1:<account-number>:<apigw-id>/*/GET/v1/hello" --principal apigateway.amazonaws.com --statement-id <statement-id> —action lambda:InvokeFunction aws lambda add-permission --function-name "arn:aws:lambda:us-east-1:<account-number>:function:HelloWorld:prod" --source-arn "arn:aws:execute-api:us-east-1:<account-number>:<apigw-id>/*/GET/v1/hello" --principal apigateway.amazonaws.com --statement-id <statement-id> —action lambda:InvokeFunction
Parte IV: Configuração dos Stage & Stage Variables no API Gateway
Para que o endpoint seja acessível, é necessário criar um stage e fazer a publicação. Para isso:
- No API Gateway, clique na opção “Actions” em “Resources”, depois selecione a opção “Deploy API”.
- Escolha “New Stage”, digite “dev” em “Stage name” e a descrição do stage e deployment, e então clique em “Deploy”.
- Para que API funcione com o alias da função Lambda, é necessário adicionar a variável lambdaAlias com o valor “dev” no Stage Variables. Vá em “Stages” e cliente na aba “Stage Variables” conforme a imagem:
- É necessário criar o stage de prod. Acesse “Stages” e clique em “Create”, em “Stage name”, digite “prod”.
- Faça o mesmo procedimento para adicionar a variável lambdaAlias com valor “prod” em Stage Variables.
Neste momento, cada Stage está direcionando para um Lambda Alias e cada um possui um endpoint específico publicado no API Gateway.
Parte V: Testes dos múltiplos Stages e versões da função Lambda
Agora que a API está devidamente configurada, com cada stage apontando para seu respectivo alias na função Lambda, você pode escolher algum dos stages criado e copiar o link da URL do seu gateway.
Para testar adicionamos a rota criada, neste caso /v1/hello
Teste o endpoint da API no API Gateway no stage de dev
Teste o endpoint da API no API Gateway no stage de prod
Conclusão
O uso de AWS Lambda Aliases permite melhor controle de uso de cada uma das versões de suas funções Lambda. O uso de múltiplas versões do Lambda em conjunto com os Stages do Amazon API Gateway, simplifica a publicação em múltiplos ambientes, suportando o ciclo de vida das aplicações e trazendo maior maturidade ao processo de engenheira de software.
Sobre o autor
Raphael Lima é arquiteto de soluções na AWS, com mais de 10 anos trabalhando com infraestrutura, DevOps, arquitetura de microsserviços, serverless e segurança. Atua com clientes Enterprise, ajudando em sua jornada para a nuvem.
Leonardo Piedade é arquiteto de soluções na AWS. Trabalha a mais de 15 anos em desenvolvimento de software. Entusiasta da plataforma Java e tecnologias de Blockchain. Atualmente trabalha com foco em aplicações distribuídas e arquiteturas serverless.