Compartilhar:
){kind=small}
Adam é um desenvolvedor e consultor que gosta de corridas de ultramaratona, escrever em blogs e gravar vlogs, além de ajudar outras pessoas a dominar a tecnologia para realizar coisas incríveis, movido por um desejo insaciável de orientar e ajudar.
Implantação de uma função AWS Lambda para retornos de chamada de voz da Vonage usando PHP
A implantação de uma aplicação completa e acessível pela web no AWS Lambda apresenta um conjunto específico de requisitos e desafios. Entre eles estão as configurações de execução e permissões. Nesta postagem, vou dar continuidade a algumas postagens anteriores, reunindo-as em um exemplo prático.
Esta publicação utiliza um exemplo de aplicativo de callback retirado de “AWS Transcribe com Nexmo Voice usando PHP”. Ele também utiliza “AWS Lambda com PHP usando Bref e Serverless Framework”. Além disso, aplico o modelo de permissões apresentado em “Como funcionam as permissões no AWS Lambda” para AWS S3 e Amazon Transcribe. Juntas, essas informações permitem que você crie seu próprio função AWS Lambda , criando um microsserviço de transcrição para ser usado em suas Applications.
Observação: você não precisa ler as três postagens mencionadas acima para acompanhar esta. Abordo detalhadamente tudo o que você precisa saber a seguir.
Neste exemplo, são necessários os seguintes elementos:
PHP instalado localmente (de preferência a versão 7.3)
Um clone local do nexmo-community/voice-aws-speechtotext-php no GitHub
Serverless Framework instalado globalmente. (mais sobre isso depois)
Você precisará de um Account na AWS, bem como credenciais do IAM associadas a um usuário com privilégios suficientes. Essa permissão garante que o Serverless possa criar a função Lambda e atribuir permissões conforme necessário.
Crie um bucket do S3 para armazenar os arquivos MP3 das gravações de voz obtidos da Vonage. O Amazon Transcribe poderá então acessar facilmente esses arquivos para transcrição posteriormente.
Depois de criá-lo, certifique-se de marcar a caixa ao lado do nome do bucket. Um painel se abre à direita; assim, você pode clicar no botão “Copiar ARN do bucket” e salvá-lo para uso posterior.
Selecione o Console de gerenciamento do IAM no painel “Serviços”:
Select IAM Management Console
Na Consola de Gerenciamento do IAM, adicione um novo usuário do IAM clicando no botão azul “Adicionar usuário”:
Add a new IAM user
Abaixo está um trecho de código JSON para atribuir as permissões necessárias ao novo usuário.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
O Bref utiliza o Serverless Framework , que é uma “solução completa para criar e operar aplicativos sem servidor”. Portanto, nosso primeiro passo é instalar essa estrutura no sistema de desenvolvimento que você está usando. Recomendo instalá-la globalmente, para permitir o uso de qualquer lugar por meio da CLI.
Após instalar o Serverless, certifique-se de também ter configurado as credenciais da AWS mencionadas acima como administrador, para que o Serverless possa interagir com os diversos serviços da AWS. Você pode ler mais sobre isso em serverless.com e bref.sh , por isso não entraremos em detalhes aqui.
Em seguida, preparamos o aplicativo usando o Composer para baixar as dependências. É necessário fazer uma pequena alteração no código para que ele funcione corretamente com as URLs do Lambda.
A preparação do aplicativo envolve algumas etapas antes de executar o comando `composer install`. Precisamos incluir o Bref para que as funcionalidades do Serverless funcionem. Digite o seguinte no seu terminal depois de acessar o diretório do projeto que contém o código.
O primeiro comando instala as dependências do aplicativo. Em seguida, o segundo comando instala o Bref, juntamente com as dependências necessárias para ele. Como alternativa, você pode editar o composer.json arquivo para incluir o Bref e executar apenas o install comando.
Normalmente, para uma nova aplicação, você daria o comando ao Bref para inite criar serverless.yml e index.php. No entanto, neste caso, basta criar um arquivo chamado serverless.yml no diretório raiz, da seguinte maneira:
service: app
provider:
name: aws
region: us-east-1
runtime: provided
iamRoleStatements:
- Effect: Allow
Action:
- s3:PutObject
- s3:GetObject
- s3:DeleteObject
Resource: 'arn:aws:s3:::{{bucket-name}}/*'
- Effect: Allow
Action: transcribe:*
Resource: '*'
plugins:
- ./vendor/bref/bref
functions:
api:
handler: index.php
description: ''
timeout: 28 # in seconds (API Gateway has a timeout of 29 seconds)
layers:
- ${bref:layer.php-73-fpm}
events:
- http: 'ANY /'
- http: 'ANY /{proxy+}'
# Exclude files from deployment
package:
exclude:
- 'node_modules/**'
- 'tests/**'Observação: Você deve atualizar a região da AWS e substituir {{bucket-name}} conforme suas necessidades.
Além disso, observe que iamRoleStatements estamos definindo permissões para que o Lambda utilize o AWS S3 e também o Amazon Transcribe. Consulte a publicação “Como funcionam as permissões no AWS Lambda”, mencionado acima, para obter mais detalhes.
Como parte da preparação, renomeie o .env.default arquivo para que fique como .env, e atualize conforme necessário para se adequar às informações de seus accounts da AWS e da Vonage. Embora você possa ignorar com segurança AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY, já que eles são adicionados automaticamente ao ambiente pelo Lambda.
Você também não conseguirá preencher o VONAGE_APPLICATION_PRIVATE_KEY_PATH e VONAGE_APPLICATION_ID valores até DEPOIS de fazer a implantação no Lambda, o que faz com que seja necessário implantar no Lambda duas vezes. A primeira vez para fornecer a você as URLs necessárias para criar o aplicativo da Vonage. Em seguida, a segunda implantação contém um arquivo .env com os valores da Vonage. Tudo isso será abordado mais adiante.
Devido à diferença na forma como o Lambda lida com a URI, você também precisará editar o index.php arquivo no aplicativo. Especificamente, você precisará alterar as eventUrl nas linhas 33 e 47. O resultado final ficará assim, respectivamente:
// Line 33
'https://'.$uri->getHost().'/dev/webhooks/fetch'
// Line 47
'https://'.$uri->getHost().'/dev/webhooks/transcribe'
A atualização é causada pelo fato de $request não ser exibido com https, e o Lambda também inclui o ambiente nas URLs do API Gateway.
Depois de concluir todas as etapas acima, você já está pronto para implantar o aplicativo no Lambda usando o Serverless. No seu terminal, execute o seguinte comando:
Após a implantação, você receberá a URL necessária para acessar o aplicativo por meio do API Gateway. Anote a URL para a próxima etapa.
IMPORTANTE: O aplicativo de exemplo, da forma como está, não possui nenhum mecanismo de autenticação ou verificação. Qualquer pessoa com acesso à URL fornecida após a implantação poderá acessá-lo. Isso pode resultar em cobranças inesperadas em seus Accounts. Portanto, proteja o aplicativo caso pretenda mantê-lo ativo.
Infelizmente, no caso da implantação de aplicativos do AWS Lambda, você só ficava sabendo da URL após a implantação. No entanto, ainda é necessário criar o aplicativo na Vonage para obter o VONAGE_APPLICATION_PRIVATE_KEY_PATH e VONAGE_APPLICATION_ID para que a aplicação funcione.
Usando a CLI da Vonage, instalada como pré-requisito, digite o seguinte comando:
A título de exemplo, o comando poderia ser assim:
A resposta do comando fornece o Application ID e o Private Key, a serem usados nas etapas a seguir.
Renomeie o arquivo private.key.default para private.key e salve o Private Key no arquivo.
Atualize o .env arquivo com os valores para VONAGE_APPLICATION_PRIVATE_KEY_PATH e VONAGE_APPLICATION_ID. Ficará mais ou menos assim:
A última etapa para configurar o Vonage é associar o número alugado do Vonage ao aplicativo recém-criado. Para isso, use o seguinte comando:
Certifique-se de atualizar as variáveis acima com o seu número da Vonage e o app_id fornecido na criação das Applications. Certifique-se de incluir o código do país no início, para evitar falhas. Veja um exemplo:
Ao criar o aplicativo da Vonage e associar o número, você instrui a Vonage a realizar chamadas de retorno quando ocorrerem eventos, e você deseja que essas chamadas de retorno sejam direcionadas para o aplicativo recém-criado.
A URL de evento é utilizada quando um evento altera o status de uma chamada, enquanto a URL de atendimento é solicitada para quaisquer chamadas recebidas, a fim de recuperar um objeto NCCO (Nexmo Call Control Object).
Agora concluímos a configuração do Vonage. É hora de reimplantar no Lambda com o seguinte comando:
Após alguns minutos, o aplicativo atualizado será reimplantado no Lambda. Embora o conteúdo do aplicativo tenha mudado, a URL permanece a mesma.
Agora é hora de fazer uma ligação de teste para o seu número da Vonage. Após ligar, a voz automatizada deve dizer: “Por favor, deixe uma mensagem após o sinal e, em seguida, pressione #”, a menos que você tenha alterado essa mensagem em index.php. Em seguida, depois de deixar uma breve mensagem de voz e pressionar #, a voz automatizada deve dizer: “Obrigado pela sua mensagem. Até logo.”
Para confirmar se tudo funcionou conforme o esperado, você deve conseguir ver o arquivo MP3 no bucket do S3 que você especificou. Também deve haver um trabalho de transcrição em execução no Amazon Transcribe. Tudo isso pode ser acessado pelo Console da AWS.
Parabéns! Você criou sua primeira função Lambda!
Existem várias opções de próximos passos, dependendo das suas necessidades. Uma solução possível seria criar um evento no AWS CloudWatch para receber um alerta quando um trabalho do Transcribe estiver “Concluído”. O evento poderia chamar outra função Lambda para enviar a transcrição por e-mail ou adicioná-la a um banco de dados. Resumindo, agora você tem uma versão em texto da mensagem de voz deixada por quem ligou. Se tiver alguma dúvida ou encontrar dificuldades, entre em contato com @VonageDev no Twitter ou fazer sua pergunta na Comunidade de Desenvolvedores da Vonage no Slack.