Neste artigo, abordarei algumas das perguntas mais comuns que surgem em entrevistas sobre o AWS Lambda.

Observe que esta não é uma lista exaustiva – você pode usar este guia, no entanto, como uma referência para atualizar seu conhecimento e obter indicações de estudos mais aprofundados.

A maioria das perguntas será baseada em sua experiência ou em determinados cenários. As perguntas estão nos títulos e você encontrará, logo abaixo delas, observações sobre o raciocínio por trás de fazer as perguntas.

Explique seu último projeto envolvendo o AWS Lambda

O entrevistador quer saber sobre sua experiência na vida real usando o AWS Lambda. Não blefe aqui, pois o entrevistador pode fazer mais perguntas com base nas respostas a essa pergunta.

Você pode ter criado uma API sem servidor (em inglês, serverless), sistemas envolvendo microsserviços, conversão de imagem/vídeo, análise de logs e muito mais. Apenas explique seu projeto em detalhes e fale sobre os benefícios comerciais desse projeto para que o entrevistador saiba que você está vendo o quadro geral.

Quais serviços você integrou com o AWS Lambda?

Essa é uma extensão da pergunta anterior. Ela não é uma lista completa de todas as fontes de eventos que podem se conectar ao AWS Lambda. Conte apenas sobre os serviços que você realmente usou.

Você pode ter usado S3, SNS, SQS, Kinesis, DynamoDB, SES ou outros. Nem todos os projetos serão completamente sem servidor.

Se você usou algum componente sem servidor junto com o AWS Lambda, mencione-os também. Por exemplo, você pode ter usado AWS Lambda com RDS. Se você usou essa configuração, pode explicar sobre isso em seu raciocínio.

Explique o conceito de inicializações a quente e a frio (warm and cold starts) no AWS Lambda

Há duas razões para fazer esta pergunta. Eles querem saber os tempos de execução que você usou e querem saber se você conhece os outros tempos de execução que podem causar uma inicialização a frio.

Os serviços Lambda recebem uma solicitação para executar uma função lambda. O serviço prepara o ambiente de execução baixando o código da função do manipulador e alocando memória junto com outra configuração.

Mesmo que você não seja cobrado por esse tempo de preparação do ambiente de execução, terá que enfrentar o atraso na chamada de sua função lambda. Esse atraso é chamado de "inicialização a frio" (do inglês, "cold start").

O tempo de inicialização a frio é menos significativo para ambientes de tempo de execução do TypeScript e do Python, sendo um pouco maior para ambientes de tempo de execução do Java ou do C#.

Para melhorar o desempenho, o serviço lambda manterá o ambiente de execução por algum tempo. Quando você receber a solicitação para a mesma função lambda novamente durante esse período, seu manipulador poderá começar a executar imediatamente. Esse tipo de chamada é chamada de "inicialização a quente" (do inglês, "warm start").

Qual é a diferença entre invocação síncrona e assíncrona no AWS Lambda?

Mesmo que pareça uma pergunta direta, ela tem muitas implicações para o seu design e tratamento de erros.

Na invocação síncrona, o chamador aguardará a conclusão da execução. Na invocação assíncrona, contudo, o chamador colocará o evento em uma fila interna que, posteriormente, será processada na função lambda.

Um ponto importante a ser observado aqui é que você não pode ditar o tipo de invocação. Isso depende do serviço que você usa com o AWS Lambda.

Por exemplo, se você estiver criando APIs sem servidor usando o API Gateway, será uma invocação síncrona. Se você, no entanto, estiver usando o S3, será uma invocação assíncrona.

Como você implementa tratamento de erros e lógica de novas tentativas no Lambda?

Qualquer componente no sistema orientado a eventos que possa falhar, falhará. Então, o entrevistador quer saber como você lidou com o erro e como tentou novamente em seus projetos anteriores. Abaixo estão alguns exemplos. Sempre explique com exemplos concretos.

Isso depende do serviço que você está usando com o AWS Lambda. Vamos discutir alguns exemplos.

Se você estiver criando uma API sem servidor, é melhor retornar esse erro para o client de chamada (pode ser uma aplicação de front-end neste caso). Em seguida, você permite que sua lógica de front-end decida o que exibir ao usuário com base no tipo de erro.

Se você estiver usando o Lambda com SQS, é melhor usar uma Dead Letter Queue para saber quais mensagens não foram processadas. Por esse mesmo motivo, muitos dos sistemas que usam SNS também podem usar SQS.

No código abaixo, estamos usando uma dead letter queue. Se alguma mensagem não for processada após um determinado número de vezes (conforme especificado por maxReceiveCount), ela será enviada para a "fila de mensagens mortas". Esse comportamento é específico para lambda quando usado junto com filas.

const queue = new sqs.Queue(this, 'AwsLambdaSqsQueue', {
      visibilityTimeout: cdk.Duration.seconds(300),
      receiveMessageWaitTime: cdk.Duration.seconds(20),
      deadLetterQueue: {
        queue: new sqs.Queue(this, 'AwsLambdaDlq'),
        maxReceiveCount: 5,
      },
    });

Quando o lambda é invocado com qualquer outro serviço, você pode configurar o número de tentativas com um valor máximo de 2. Isso significa que você pode ter, no máximo, duas tentativas além da chamada inicial. Por exemplo, você deseja acionar com base no upload do objeto S3 e seu lambda tentará no máximo três vezes.

Explique seus fluxos de trabalho para desenvolvimento e implantação de funções do AWS Lambda

Fale sobre os frameworks que você usou. O entrevistador pode esperar que você fale sobre o teste de funções lambda também.

Você pode explicar quais frameworks você usou para desenvolver e implantar funções lambda. Você também pode falar sobre qualquer ferramenta de IaC (Infraestrutura como Código) que você usou.

Abaixo, temos uma lista não exaustiva dos frameworks mais usados:

• Serverless
• AWS CDK
• AWS SAM
• CloudFormation
• Pulumi

Se você já usou o Terraform, também pode falar sobre isso.

O Lambda pode ser invocado quando você recebe um e-mail para um determinado endereço de e-mail de suporte? Se sim, projete esse sistema. Se não, explique por quê.

Sim, você pode. Você pode criar um conjunto de regras de recebimento e adicionar uma regra que acione a função lambda.

Você deve armazenar o e-mail no S3 e acionar o lambda depois disso para que possa ter a cópia do e-mail para qualquer referência futura.

Você pode consultar este artigo (em inglês) sobre como receber e-mails de um formulário de contato.

Uma função lambda pode chamar outra função lambda?

O entrevistador quer saber se você conhece esse antipadrão.

Você pode fazer isso, mas não é recomendado. Se quiser criar um fluxo de trabalho que envolva várias funções lambda, você pode usar as funções de etapa.

Você pode ler mais sobre funções de etapa aqui.

Outra abordagem padrão é emitir um evento e acionar um lambda com base no evento. Você pode usar SQS, SNS ou EventBridge como intermediário para esses eventos.

Você pode executar consultas em uma instância do RDS (em uma sub-rede privada) usando o Lambda?

Sim, você pode executar a consulta no RDS usando o AWS Lambda. Para isso, você pode ter seu lambda dentro da mesma VPC.

Pode haver algumas implicações de desempenho se você usar o AWS Lambda diretamente com o RDS. Isso ocorre devido ao tempo de criação da conexão do banco de dados. Para evitar essas implicações, você pode usar um RDS Proxy.

Aqui está um guia passo a passo detalhado (em inglês) que mostra como fazer isso.

O AWS Lambda fornece muitos benefícios. Quais são as desvantagens de se usar o AWS Lambda?

O entrevistador quer saber sobre o seu processo de pensamento. Não diga que o AWS Lambda resolve todos os problemas. 🙂

Sim, o Lambda oferece muitos benefícios, como custo e escalabilidade, sem a necessidade de manter os servidores. Ele, porém, não é a resposta para tudo. Como qualquer serviço, ele tem seus próprios problemas (e você deve ser capaz de discuti-los):

• Depuração: se você estiver usando arquiteturas sem servidor usando o Lambda, talvez precise contar com o log para encontrar a causa raiz do problema. Isso ocorre porque seu aplicativo será distribuído em muitos serviços/funções lambda.
• Teste: você pode simular serviços da AWS em seu teste local. É melhor, no entanto, ter um ambiente separado na AWS para testar seus lambdas. Isso torna o teste um pouco complexo.
• Tarefas em segundo plano: o Lambda tem um limite de tempo limite de 15 minutos. Se você deseja que qualquer tarefa específica leve mais de 15 minutos, talvez seja necessário mudar para o Fargate ou alguma outra solução.
• Custo: se você estiver executando um aplicativo de alto tráfego que processa as solicitações 24 horas por dia, 7 dias por semana, o uso de lambda pode ser caro. É melhor usar Fargate, EC2 ou outros serviços, se você tiver alto tráfego constante.

Como você gerencia simultaneidade e dimensionamento no AWS Lambda?

Você ganhará pontos de bônus se falar sobre os problemas que enfrentou nessas situações.

Simultaneidade (em inglês, concurrency) é a capacidade de executar várias funções lambda ao mesmo tempo. O dimensionamento (scaling) é o processo de aumentar o número de cópias de sua função lambda para lidar com as solicitações recebidas.

Você pode controlar a simultaneidade definindo o valor de simultaneidade reservada para que apenas o número mencionado de funções lambda seja invocado.

Abaixo está o diagrama de alto nível de como lambda escala de acordo com o número de mensagens na fila.

Observação: há algum comportamento estranho se você tentar limitar o AWS Lambda quando usado com a fila padrão do SQS. Você pode usar uma fila FIFO para resolver esse problema.

Como você passa variáveis de ambiente para o AWS Lambda?

O entrevistador pode querer saber como você passa informações sigilosas, por exemplo.

Existem diferentes maneiras de passar variáveis de ambiente para o AWS Lambda, dependendo do tipo de valor que está sendo passado.

Dados não confidenciais: se você deseja passar informações não confidenciais, pode passar os valores diretamente para as variáveis de ambiente da função lambda. Esses valores, contudo, seriam visíveis no console da AWS no serviço Lambda. No exemplo de código abaixo, estamos passando o nome da tabela DynamoDB diretamente como variável de ambiente, pois não são dados confidenciais:

   const readDDBLambdaFn = new NodejsFunction(this, 'readDDBLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'read-ddb.ts'),
      ...nodeJsFunctionProps,
      functionName: 'readDDBLambdaFn',
      environment: {
        tableName: table.tableName,
      },
    });

Dados confidenciais: se você deseja transmitir dados confidenciais, como senhas e chaves de API, pode usar um gerenciador de segredos ou um armazenamento de parâmetros. Porém, você precisa se certificar de fornecer as funções necessárias ao Lambda para acessar e descriptografar segredos dos respectivos serviços.

No trecho de código abaixo, NÃO estamos passando o segredo real. Em vez disso, estamos apenas passando o ARN (Amazon Resource Name) do segredo.

const rdsLambdaFn = new NodejsFunction(this, 'rdsLambdaFn', {
      entry: path.join(__dirname, '../src/lambdas', 'rds-lambda.ts'),
      ...nodeJsFunctionProps,
      functionName: 'rdsLambdaFn',
      environment: {
        DB_ENDPOINT_ADDRESS: dbInstance.dbInstanceEndpointAddress,
        DB_NAME: databaseName,
        DB_SECRET_ARN: dbInstance.secret?.secretFullArn || '',
      },
      vpc,
      vpcSubnets: vpc.selectSubnets({
        subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
      }),
    });

Em seguida, no lambda, você pode obter o segredo real dinamicamente na função lambda, conforme mostrado abaixo:

export const handler = async (event: any, context: any): Promise<any> => {
    const host = process.env.DB_ENDPOINT_ADDRESS || '';
    const database = process.env.DB_NAME || '';
    const dbSecretArn = process.env.DB_SECRET_ARN || '';
    const secretManager = new AWS.SecretsManager({
      region: 'us-east-1',
    });
    const secretParams: AWS.SecretsManager.GetSecretValueRequest = {
      SecretId: dbSecretArn,
    };
    const dbSecret = await secretManager.getSecretValue(secretParams).promise();
    const secretString = dbSecret.SecretString || '';

    const { password } = JSON.parse(secretString);

}

O autor deste artigo escreveu um tutorial detalhado aqui sobre o mesmo tópico.

Digamos que você tenha alguma ferramenta .exe executável dependente do Windows. Você pode carregá-la em um bucket do S3. Você pode executar este binário com alguns parâmetros usando o AWS Lambda?

Essa é mais uma pergunta para garantir que você entende o ambiente de execução do AWS Lambda – especificamente, o sistema operacional que ele usa.

Não, você não seria capaz de fazer isso, pois o AWS Lambda usa o Linux como sistema operacional. O Linux não seria capaz de executar um binário dependente do Windows.

Como você reutilizaria código entre funções do AWS Lambda?

Existem duas maneiras de reutilizar o código em muitas funções do AWS Lambda:

• Usar as camadas do Lambda: você pode armazenar seu código ou lógica em camadas do lambda, que você pode reutilizar em diferentes funções do lambda.

Abaixo está um código de alto nível para criar e consumir camadas do lambda usando aws cdk:

    const logicLayer = new lambda.LayerVersion(this, 'logic-layer', {
      compatibleRuntimes: [
        lambda.Runtime.NODEJS_14_X,
        lambda.Runtime.NODEJS_16_X,
      ],
      layerVersionName: 'business-logic-layer',
      code: lambda.Code.fromAsset('src/layers/business-logic'),
      description: 'Business logic layer',
    });


    const lambdaWithLayer = new NodejsFunction(this, 'lambdaWithLayer', {
      entry: path.join(__dirname, '../src/lambdas', 'lambda.ts'),
      ...nodeJsFnProps,
      functionName: 'lambdaWithLayer',
      handler: 'handler',
      layers: [logicLayer, utilsLayer],
    });

• Usar monorepo: você pode usar mono repos e pacotes criados dinamicamente em tempo de implantação.

O que acontece com suas funções lambda se você excluir uma camada lambda?

Nesta pergunta, o entrevistador quer ver o quanto você entende de camadas lambda.

As funções lambda existentes que usam essa camada excluída continuarão a funcionar – pois as camadas lambda são mescladas com as funções lambda no momento da implantação.

Você, no entanto, não poderá criar uma nova função lambda usando essa camada lambda excluída.

Você pode aprender mais sobre camadas lambda aqui e eu escrevi um guia sobre o mesmo tópico aqui (ambas as referências em inglês).

Você pode aumentar o tamanho de um pacote de implantação se você usa camadas lambda?

Não, você não pode aumentar o tamanho do pacote de implantação se usar camadas lambda. O tamanho máximo de implantação de 50 MB compactado inclui o tamanho da função lambda e suas camadas lambda associadas.

Se você tiver uma grande base de código e quiser aumentar a implantação, poderá executar contêineres no AWS Lambda.

Posso pegar minha aplicação da web dockerizada existente e executá-la usando o Lambda?

Não. Você não pode pegar nenhuma aplicação do Express, Springboot ou .NET Core (ou qualquer outra aplicação) como está e colocá-la dentro do lambda.

Dito isso, saiba que existem algumas bibliotecas que permitem colocar aplicações que usam esses frameworks da web no AWS Lambda. Internamente, essas bibliotecas convertem essas aplicações da web em APIs compatíveis com o AWS Lambda. Você pode ver um desses exemplos aqui (em inglês).

Ao usar esses frameworks, o tamanho de suas funções lambda será maior e resultará em tempos de inicialização mais longos.

Lembre-se de que, mesmo ao usar contêineres com Lambda, a API de tempo de execução existente do Lambda permanece a mesma. O Lambda ainda vai:

• ser uma única função
• ser invocado por um evento ou manualmente
• ter um limite de tempo de 15 minutos.

Como você pode ver no código abaixo, não haverá alteração na API lambda. A vantagem de usar o Docker é que você pode usar pacotes grandes sem se preocupar com o tamanho.

import { Context, APIGatewayProxyResult, APIGatewayEvent } from 'aws-lambda';

export const handler = async (
  event: APIGatewayEvent,
  context: Context
): Promise<APIGatewayProxyResult> => {
  console.log(`Event: ${JSON.stringify(event, null, 2)}`);
  console.log(`Context: ${JSON.stringify(context, null, 2)}`);
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: 'Running this handler from docker',
    }),
  };
};

e é assim que você o usa:

 const repo = ecr.Repository.fromRepositoryName(
      this,
      'dockerLambda',
      'docker-lambda'
    );

    const dockerLambda = new lambda.DockerImageFunction(
      this,
      'DockerLambdaFunction',
      {
        code: lambda.DockerImageCode.fromEcr(repo),
      }
    );

O autor deste artigo escreveu um tutorial passo a passo sobre execução de contêineres do Docker para sua aplicação em aws lambda aqui (em inglês).

Como você compartilha arquivos grandes entre funções lambda?

Você pode usar o Elastic File System (EFS) para compartilhar arquivos grandes entre diferentes funções.

Você pode criar um access point (em português, ponto de acesso) no EFS, criado com as permissões apropriadas, e usar esse access point em seu caminho de montagem em seu lambda.

Todos os arquivos gravados nesse caminho de montagem estarão acessíveis a todas as outras funções lambda, desde que tenham o caminho de montagem com as permissões apropriadas.

Abaixo vemos o diagrama lógico de alto nível sobre como usar o AWS Lambda com o Elastic File System (EFS):

Você pode ler sobre isso aqui (em inglês e um pouco antigo). O autor deste artigo escreveu um guia passo a passo prático mais recente aqui (em inglês) sobre EFS com funções Lambda.

Conclusão

Espero que este artigo tenha ajudado você a se preparar para entrevistas que envolvam o AWS Lambda.

Obrigado por ler até aqui. O autor também escreve sobre aws e tecnologias sem servidor em https://www.cloudtechsimplified.com (blog em inglês). Se estiver interessado, pode se inscrever no blog dele.

Infraestrutura como código (ou, em inglês, infrastructure as a code, ou IaC) é o processo de provisionamento e gerenciamento de seus recursos de nuvem escrevendo um arquivo de modelo que pode ser lido por humanos e consumível pela máquina.

Para o desenvolvimento na nuvem com a AWS, a escolha integrada para infraestrutura como código é o AWS CloudFormation.

Usando a IaC, os desenvolvedores podem gerenciar a infraestrutura de um projeto com eficiência, permitindo que eles configurem e mantenham facilmente as alterações na arquitetura e nos recursos de um projeto.

Existem inúmeras ferramentas de IaC disponíveis, como Ansible, Puppet, Chef e Terraform.

Para este guia, no entanto, usaremos o CloudFormation, que foi feito especificamente para os recursos da AWS.

O que você vai aprender neste tutorial

Depois de passar por este tutorial, você entenderá como manter seus recursos em um arquivo de software.

Além disso, você aprenderá os benefícios relacionados à velocidade que a infraestrutura como código traz. Sem a IaC, o tempo e o custo da implantação manual de várias infraestruturas podem ser muito maiores em comparação com a manutenção da infraestrutura como software.

Neste artigo, vamos considerar um exemplo. Ele demonstrará o provisionamento manual de recursos versus a implantação de um script CloudFormation para criar uma função Lambda sem servidor e uma API REST na AWS.

Serviços que vamos usar neste tutorial

Vamos usar os seguintes serviços para implementar infraestrutura como código na AWS:

Para quem é novo na AWS, é bom ter algum conhecimento dela para entender o artigo. Então, você pode me acompanhar criando uma conta na AWS aqui e certificando-se de ter a AWS CLI instalada para trabalhar com o exemplo.

Visão geral do exemplo

Para o artigo, implementaremos uma API REST com um gateway de API. Ele será integrado a uma função Lambda de back-end sem servidor que lida com POST e obtém solicitações feitas por nossa API.

A primeira etapa mostrará como criar e implantar manualmente esses recursos usando o console AWS. A segunda etapa mostrará como automatizar o processo usando o CloudFormation.

Como implantar manualmente

Na implantação (ou, em inglês, deployment) manual, trabalharemos dentro do console AWS. É um pouco difícil acompanhar as alterações ao trabalhar fora do IDE local, especialmente para projetos de grande escala.

Na primeira etapa, criaremos uma função Lambda.

Se você deseja que sua função Lambda funcione com algum outro serviço como o Comprehend, deve conceder permissões para esse serviço. Portanto, certifique-se de criar uma função com essas permissões.

A seguir está nossa função Lambda que retornará "Hello World" quando integrada ao gateway da API.

import json

def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello World!')
    }

Agora que configuramos nossa função Lambda, a próxima etapa é criar uma API REST para interagir com a função Lambda.

Para isso, vá para o Amazon API Gateway, clique em "Create API" (Criar API) e selecione REST API nas opções fornecidas.

Agora, vamos integrar o Lambda com a API. Para isso, crie um método GET no menu de ações e aponte nossa API REST para a função Lambda.

Estamos em condições de implantar e testar nossa API para sua integração adequada com o Lambda. Selecione o nome que desejar – para este exemplo, estou usando "prod".

Depois de implantar a API, você pode ver um URL no estágio "prod". Atingir esse URL acionará a função Lambda. Como retornamos "Hello World" a partir de nossa função Lambda, você poderá ver o resultado desejado.

Como implantar com CloudFormation

Até aqui, vimos como funciona a implantação manual, que costuma levar alguns minutos.

Vamos imaginar, no entanto, que temos mais de uma API, método e mais de um desenvolvedor trabalhando neles. Nesse cenário, rastrear todos os recursos e mudanças seria um desafio.

Portanto, nesta seção, usaremos o AWS CloudFormation. Ele dará flexibilidade aos desenvolvedores, permitindo que eles ajustem sua infraestrutura com um script simples.

Como o CloudFormation funciona?

Usaremos o arquivo YAML para provisionar e declarar esses recursos e implantá-los na AWS para criar uma stack do CloudFormation. O CloudFormation é uma stack que contém todos os recursos necessários para o projeto.

Usaremos o modelo SAM, conforme descrito acima na seção de serviços. É uma abstração do CloudFormation para criar aplicações sem servidor com menos código YAML.

Para quem não conhece o YAML, você pode pensar nele como se fosse um JSON. O CloudFormation, porém, usa esses dois formatos de arquivo.

Na primeira etapa, vamos para nosso IDE local e escrevemos a mesma função Lambda que escrevemos no console da AWS.

helloworld.py:

import json

def lambda_handler(event, context):
    # TODO implementar
    return {
        'statusCode': 200,
        'body': json.dumps('Hello World!')
    }

Em seguida, criaremos um arquivo template.yaml contendo nossa infraestrutura. Definiremos nossa função Lambda e API Gateway neste arquivo.

Para criar este arquivo, precisamos adicionar algumas informações que são comuns a todos os modelos SAM.

template.yaml:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: First CloudFormation template

Agora, temos que adicionar "Globals" a este arquivo template.yaml do CloudFormation. Globals são as configurações comuns para os recursos que você vai implantar. Globals permitem que você declare informações globalmente para um tipo de recurso específico, em vez de especificá-las repetidas vezes para recursos diferentes.

template.yaml:

Globals:
    #Comum a todas as funções Lambda que você cria
    Function:
      MemorySize: 128
      Runtime: python3.6
      Timeout: 5

Temos que definir a tag Resources em nosso arquivo template.yaml. A função Lambda e a API REST estarão sob esta tag.

template.yaml:

Resources:

    ##Lambda e API GW integrados
    helloworld:
        Type: AWS::Serverless::Function
        Properties:
          #nome_de_arquivo.nome_da_função
          Handler: helloworld.lambda_handler

          #REST API criada
          Events:
            PostAdd:
              Type: Api
              Properties:
                Path: /helloworld
                Method: get

No código acima, definimos parâmetros para criar a função Lambda. Para o evento, criamos uma API REST que aciona a função Lambda.

Observação: há alguns parâmetros, como CodeURI e description, que você pode especificar para sua função serverless. A melhor maneira de criar um arquivo de modelo é consultar os documentos do CloudFormation e ver os parâmetros disponíveis para seu recurso/serviço especificado.

Como implantar o arquivo de modelo

Podemos implantar nosso arquivo template.yaml usando os dois comandos da AWS CLI a seguir:

##s3 bucket armazena o modelo sam que precisamos implantar
aws cloudformation package --template-file template.yaml --output-template-file sam-template.yaml --s3-bucket helloworld-sam

Depois de executar o comando acima, você poderá ver um arquivo de modelo SAM. Usaremos esse arquivo no segundo comando abaixo.

Neste comando, forneça o caminho apropriado para o arquivo sam-template.yaml:

#Implantar a stack
#aponta para o arquivo modeleo criado por um comando anterior e um nome da stack, bem como a região na qual estamos implantando

aws cloudformation deploy --template-file /path to sam-template.yaml file --stack-name test-stack --capabilities CAPABILITY_IAM --region us-east-1

Depois de executar esses dois comandos, você verá a stack criada na CLI. Você pode verificá-la usando o CloudFormation no console.

Aqui você verá todos os recursos provisionados por meio do código criado e implantado usando o arquivo template.yaml.

Você pode clicar na API e acessar o URL para verificar a saída, como fizemos para a implantação manual.

Resumo

Era isso! Você implementou com sucesso a infraestrutura como código na AWS usando o CloudFormation.

Espero que este artigo tenha sido útil para quem deseja entender a implementação de infraestrutura como código na AWS.

Conecte-se com o autor do artigo pelo LinkedIn e pelo Twitter.

Até a próxima! 🙂

Os Cron Jobs são normalmente usados para agendar comandos em um horário específico. Você pode usá-los para tarefas como executar backups, monitorar o status do sistema ou executar tarefas de manutenção do sistema.

Os Cron Jobs são utilitários úteis para os administradores de sistemas. Quando você está administrando um sistema na nuvem, os Cron Jobs ainda são muito úteis – afinal, você ainda precisa fazer muitas tarefas administrativas nos sistemas.

Uma maneira de executar Cron Jobs na nuvem é usar uma função como um serviço (FaaS), como a Lambda no ecossistema AWS.

As funções executam quando são acionadas para isso e executam o código na nuvem sem a necessidade de prover ou manter qualquer infraestrutura. Elas também podem ser configuradas para serem executadas em um determinado momento ou com certa periodicidade, como os Cron Jobs tradicionais.

Neste artigo, usarei o ecossistema AWS para mostrar um exemplo concreto de como criar um Cron Job usando uma função na nuvem.

Eventos da Amazon CloudWatch

A fim de usar a função Lambda como um Cron Job, precisamos entender os eventos da Amazon CloudWatch.

Os eventos da Amazon CloudWatch são enviados quando há mudanças nos recursos da AWS. Esses eventos podem acionar uma função AWS Lambda. Quando os seus recursos da AWS mudam de estado, eles automaticamente enviam eventos CloudWatch para o stream de eventos.

Portanto, você pode criar uma regra que aciona uma função Lambda específica quando algo acontece. Por exemplo, você pode invocar automaticamente uma função Lambda quando há uma mudança em um grupo AutoScaling.

Além disso, os eventos CloudWatch podem invocar uma função Lambda para ser executada regularmente. Deste modo, você pode ter, por exemplo, uma função Lambda que desativa todos os seus testes e desenvolvimento em EC2 depois das 18h e outra que os ativa após as 8h.

Configurando a demonstração

Quero mostrar a você um exemplo de uma função Lambda que pode realizar ações em suas instâncias da EC2. Vou usar o AWS SAM para definir a minha função Lambda como infraestrutura como código.

Se você quiser experimentar essa demonstração, precisará ter uma conta na AWS e uma ou mais instâncias da EC2 configuradas em sua conta da AWS. Estas são as que vamos manipular a partir das funções Lambda. As instâncias da EC2 são a versão da AWS das máquinas virtuais na nuvem.

Você pode tentar a demonstração no IDE AWS Cloud9 (um IDE baseado em navegador), já que o AWS SAM já está configurado nesse IDE. Se você quiser saber como usar a IDE AWS Cloud9 para operar as funções Lambda, você pode conferir este vídeo (em inglês).

Neste exemplo, vamos começar e parar as instâncias da EC2 usando duas funções Lambda da AWS diferentes, que são acionadas em um determinado momento. Vamos iniciar as instâncias às 8h todos os dias e desativá-las às 18h, quando o dia terminar.

Para isso, vamos usar um evento CloudWatch para acionar a função Lambda no momento certo, além do AWS SDK para realizar as operações nas instâncias.

O código finalizado para o exemplo está disponível neste repositório do GitHub. Para que esse código funcione no IDE AWS Cloud9, você precisa configurar a sua conta do GitHub no IDE para poder clonar o projeto e depois cloná-lo dentro do IDE.

Quando tiver isso pronto, basta executar este comando dentro do diretório clonado:

$ sam deploy --guided

Ao executar esse comando, você receberá um conjunto de perguntas que precisa responder para configurar o projeto para que ele seja executado com sucesso.

A primeira coisa que você precisa definir é um nome para o seu projeto. Em seguida, você definirá a região onde ele está sendo implantado – escolha a mesma região onde estão suas instâncias da EC2. Depois, precisamos dar ao roteiro de deploy uma lista das instâncias que queremos manipular. Estamos prontos – o deploy do projeto será feito em nossa conta da AWS.

Definindo a função AWS Lambda

A primeira coisa que quero mostrar a você é como definimos uma função AWS Lambda, que é acionada em um tempo específico usando o AWS SAM. Esta definição estará no arquivo chamado "template.yml".

Essa é a aparência de uma função. Vejamos as linhas importantes:

A primeira linha é o nome da função – nesse caso, "StartInstanceFunction".

Depois, temos a definição de "Properties". A primeira propriedade é o "Handler". Aqui, especificaremos o módulo (arquivo) onde está o código que precisa ser executado e, depois, o método dentro desse módulo.

Então, temos "CodeUri", que é o caminho que mostra onde encontrar esse arquivo. Nesse caso, nosso código estará dentro de um diretório chamado "cron" em um arquivo chamado "handler.js" e em um método chamado "startInstance".

Depois disso, temos a definição de "Runtime". Usarei o NodeJS versão 12, mas você pode usar Python, Java, Go, C# ou qualquer outra linguagem de sua preferência. A Lambda suporta múltiplos tempos de execução desde o princípio e você pode usar seu próprio ambiente de tempo de execução, se quiser (links em inglês).

Temos a definição de "Environment", que usaremos para definir a única variável de ambiente. Essa variável nos permitirá enviar o código dinamicamente para diferentes instâncias de ids, dependendo da configuração de quando fazemos o deploy.

Depois disso, temos uma seção chamada "Policies", que é onde definimos as permissões que essa função Lambda específica terá.

É importante saber que todas as funções Lambda são criadas sem nenhuma permissão. Isso significa que elas não podem fazer nada em nenhum outro recurso da AWS.

Para que essa função Lambda possa iniciar uma instância da EC2, ela precisa de permissões para fazer essa ação específica sobre esse recurso específico da AWS. Nessa política específica, estamos concedendo permissões para iniciar TODAS as instâncias da EC2 nessa conta da AWS. TODAS são representadas com o "*" na seção de recursos.

Se você tiver esse código em produção, recomendo que você limite os recursos exatamente àqueles que você deseja que essa função Lambda possa iniciar.

Finalmente, a última seção é a seção "Events". Aqui, definiremos como essa função Lambda será acionada. Essa função será acionada com um evento CloudWatch agendado, que acionará a Lambda todos os dias às 8 da manhã. Basicamente, às 8 todos os dias, ela ativará todas as instâncias da EC2 que você especificar.

Há muitas regras para formar essa expressão Cron: por exemplo, para dizer que você gostaria que ela funcionasse apenas de segunda a sexta-feira (em inglês, MONday-FRIday), escreva cron(0 8 ? * MON-FRI *). Você pode encontrar mais informações no site da documentação dos eventos CloudWatch aqui.

Programando a função AWS Lambda

Agora que definimos a função Lambda, precisamos fornecer algum código para ela. Na pasta "cron", no arquivo "handler.js", precisamos adicionar o método chamado "startInstance", que tem esta aparência:

Este método será chamado quando a função for acionada todos os dias às 8 horas da manhã. Ele obterá a lista de instâncias da EC2 a partir de uma variável de ambiente em que passamos todas as ids de instâncias durante o tempo de deploy. Em seguida, ele criará um array com essas instâncias.

Quando tiver esse array, ele chamará o AWS SDK e enviará o array de ids de instâncias como um parâmetro. Se houver algum erro, ele o registrará e o completará. Imediatamente após essa Lambda terminar a execução, você pode ir até o seu console da EC2 e ver que suas instâncias foram ativadas.

A função de desativar as instâncias da EC2 é muito semelhante, com algumas pequenas diferenças. Você pode encontrar o código para essa função neste link e verificá-lo.

Executando o Cron Job

Para executar esse Cron Job, não há muito o que fazer. Depois de feito o deploy das duas funções em sua conta da AWS, na mesma região em que as suas instâncias estão, elas executarão e farão o que foram programadas para fazer.

Agora, é preciso esperar até as 8h ou 18h para ver se elas funcionam. Se você quiser testar agora mesmo, mude o horário do evento na definição Lambda para um horário que sirva para você. Certifique-se de que a instância esteja ligada se você estiver planejando desligá-las ou o contrário, para que você possa ver as mudanças.

Espere e veja o que acontece no console da EC2. Logo após a configuração, você verá a instância ser ativada ou desativada na hora que você configurar. Isto continuará para sempre até que você remova as funções Lambda.

Limpeza da sua conta AWS

Após completar essa demonstração, recomendo que você desligue (ou remova a instância que criou para testar) e remova as funções Lambda que você acabou de criar.

A remoção das funções Lambda é tão fácil quanto colocá-las no seu serviço CloudFormation. Em seu console de gerenciamento da AWS, remova a pilha de recursos que o AWS SAM criou.

Não se esqueça de encerrar e remover as instâncias da EC2 se você as criou apenas para essa demonstração.

Para concluir

As funções AWS Lambda são uma ferramenta muito útil para realizar todos os tipos de tarefas em sua conta da AWS. Você pode, basicamente, obter notificações de qualquer mudança nos recursos da AWS através dos eventos CloudWatch e, então, pode acessar quase todos os serviços usando o AWS SDK. Assim, você pode realizar todos os tipos de tarefas de manutenção e tarefas automatizadas em sua infraestrutura.

Obrigado pela leitura.

A autora se chama Marcia Villalba, advocate de desenvolvimento da AWS e apresentadora de um canal no YouTube chamado FooBar, onde você encontrará mais de 250 tutoriais em vídeo sobre Serverless, AWS e práticas de engenharia de software.

Escrito por: Filip Jerga

Um guia passo a passo que explica como fazer o upload de uma imagem ou qualquer arquivo para o serviço Amazon S3.

Esta é a primeira parte de um tutorial no qual trataremos da parte do servidor (Node.js) do código.

Eu também preparei um tutorial em vídeo no YouTube. Você pode encontrar um link nos recursos na parte inferior deste artigo.

1. O que precisamos instalar e uma breve descrição.

multer: middleware para manipulação de arquivos de dados. Usado principalmente para o upload de arquivos. Mais informações: link para o npm

multer-s3: extensão do multer para o upload fácil de arquivos para o serviço Amazon S3. Mais informações: link para o npm

aws-sdk: pacote necessário para trabalhar com o AWS(Amazon Web Services) – no nosso caso, com o serviço S3. Mais informações: link para o npm

Vá para seus projetos e vamos instalar os pacotes:

npm install —-save multer multer-s3 aws-sdk

2. Login na AWS

Primeiro, vamos criar uma conta em https://aws.amazon.com. A Amazon oferece um nível gratuito incrível, que você pode usar durante o primeiro ano. Após o login, procure pelo serviço S3.

Simplificando, o S3 é um serviço de nuvem para armazenar arquivos.

Precisamos criar um Bucket. Você pode imaginar um bucket como sendo uma pasta para seus arquivos. Escolha um nome para o bucket e sua região. Como esta é uma configuração simples, não estamos interessados em outras configurações (a configuração padrão já serve). Clique em "Next" (Avançar) até chegar na Revisão e crie seu bucket.

Navegue até o bucket criado e verifique sua barra de URL. Lembre-se do nome do bucket (para mim, "medium-test") e região (para mim, "us-east").

Agora, precisamos obter nossas credenciais seguras. Navegue pelo nome de sua conta até "My Securuty Credentials" (minhas credenciais de segurança, em português). Depois "Access Keys" (chaves de acesso, em português) e "Create Access Key" (criar chave de acesso, em português).

Nunca compartilhe suas chaves com ninguém! Guarde temporariamente essas chaves em algum arquivo ou baixe o arquivo de chave, pois precisamos de chaves para configurar o upload de um arquivo.

Tudo certo. a configuração da Amazon foi concluída!

3. Uso do editor de código

Não vou explicar o básico de Node ou Express aqui. Este tutorial está focado apenas no upload do arquivo. Se você estiver interessado em toda a implementação do projeto, verifique meu repositório no GitHub ou assista o tutorial completo. (Você pode encontrar o link no final deste artigo).

1. Crie seu serviço de upload de arquivos com a seguinte implementação (primeira parte):

Observação importante: nunca exponha suas credenciais secretas diretamente em um arquivo! Nunca divulgue suas credenciais secretas! Considere configurar variáveis de ambiente em seu ambiente local ou, no caso de projetos com o deploy realizado, variáveis em seu provedor de nuvem. A melhor solução seria usar os perfis da AWS (texto em inglês).

Primeiro, importamos todos os nossos pacotes instalados. A segunda parte é a configuração da AWS. Precisamos fornecer nossas chaves secretas e região a partir da barra de URLs que mostrei antes.

Após a configuração da AWS, podemos criar uma instância do nosso Amazon S3. Ainda não terminamos. Agora, vamos ver a segunda parte desta implementação.

Podemos criar uma solução para o upload do multer. Precisamos dar funcionalidade ao objeto do multer com as seguintes propriedades:

1. s3: instância do Amazon S3 que criamos antes.
2. bucket: nome do nosso bucket (no meu caso: "medium-test")
3. acl: controle de acesso ao arquivo ("public read" significa que qualquer pessoa pode ver os arquivos). Você pode verificar todos os tipos disponíveis aqui: link da documentação da Amazon (texto em inglês)
4. metada: função de callback para definir metadados dos arquivos carregados. Aqui, estou definindo metadados adicionais para um nome de campo. Você pode ver esses dados na imagem abaixo.

5. key: função de callback para definir a propriedade key (chave na qual seu arquivo será salvo no bucket). Em nosso caso, estamos fazendo um carimbo de data/hora atual e salvando esse arquivo com um nome. Desse modo, nosso nome de arquivo será sempre único, mas você pode escolher o nome que quiser.

Depois de toda a configuração, exportamos o objeto do upload a fim de utilizá-lo em outros arquivos.

4. Configuração de uma rota para o upload da imagem

Estamos quase terminando, mas os usuários do nosso aplicativo ainda não têm acesso ao upload da imagem. Precisamos expor essa funcionalidade a eles. Vamos criar um endpoint para salvar um arquivo.

Exportamos nosso objeto de upload criado anteriormente e criamos outro objeto a partir dele. O novo objeto é mais específico, com configuração adicional para um único upload de imagem. Fornecemos um valor de "image" para ele. Esse valor é muito importante, pois enviaremos nosso arquivo para um servidor sob esta chave.

A segunda parte é a própria rota, o endpoint de POST para "/image-upload". Dentro dela, chamamos singleUpload. Não se esqueça de passar req e res como parâmetros, pois o multer receberá o arquivo que estamos enviando para o servidor a partir do objeto de req.

Verificamos, então, a existência de erros. Se não houver nenhum, devolvemos o JSON com o valor da localização do nosso arquivo, que é apenas um URL para o arquivo da Amazon.

Estamos prontos! Já podemos carregar arquivos no Amazon S3. Simples, não acha?

5. Teste no Postman.

Para ver os resultados de nosso trabalho, precisamos enviar um pedido para o servidor com uma imagem da qual queremos fazer o upload. Nessa parte, vamos testar isso através do Postman. Na segunda parte do tutorial, criaremos uma implementação para uma aplicação em Angular.

Se você não tiver o Postman, pode simplesmente fazer o download dele como uma extensão do Google Chrome. Basta pesquisar por 'postman google chrome extension'. O Postman é um aplicativo para inicializar, enviar e testar pedidos ao servidor de modo simplificado.

1. Envie uma solicitação de post para o endpoint que criamos antes. No meu caso, especifiquei no caminho do node de /image-upload.
2. Selecione Body em form-data.
3. Forneça a chave de uma imagem. Você notará que essa é uma key (chave, em inglês) que estabelecemos antes em nosso código. Procure e selecione algum arquivo de imagem em seu computador.
4. Envie a solicitação.

Você deve receber de volta o JSON com o URL de seu arquivo carregado.

Aí está! É isso, pessoal. Este é um upload de arquivo simples para o Node. No próximo artigo, faremos uma implementação de front-end para o Angular.

Se gostou deste tutorial, fique à vontade para conferir meu curso completo na Udemy — The Complete Angular, React & Node Guide | Airbnb style app.

Tutorial em vídeo: vídeo no YouTube

Projeto concluído: meu repositório no GitHub