As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Construindo funções do Rust Lambda com Lambda de carga in AWS SAM
Use a interface de linha de AWS Serverless Application Model comando (AWS SAMCLI) com suas AWS Lambda funções Rust.
Tópicos
Pré-requisitos
- Linguagem Rust
-
Para instalarRust, consulte Instalar Rust
no Rust site do idioma. - Cargo Lambda
-
O AWS SAMCLI requer a instalação de um subcomando Cargo Lambda
, para Cargo. Para obter instruções, consulte Instalação na Documentação do Cargo Lambda. - Docker
-
É necessário criar e testar as Rust funções do Lambda Docker. Para obter instruções de instalação, consulte Instalação do Docker.
Configurar AWS SAM para usar com funções Rust Lambda
Etapa 1: configure seu AWS SAM modelo
Configure seu AWS SAM modelo com o seguinte:
-
Binário - Opcional. Especifique quando um único Cargo pacote define mais de um binário, para identificar qual binário criar para essa função. Você não precisa dessa propriedade quando cada função é seu próprio Cargo pacote, como em um Cargo espaço de trabalho.
-
BuildMethod –
rust-cargolambda. -
CodeUri— caminho para seu
Cargo.tomlarquivo. -
Manipulador –
bootstrap. -
Tempo de execução –
provided.al2023.
Para saber mais sobre tempos de execução personalizados, consulte AWS Lambda Tempos de execução personalizados no Guia do AWS Lambda desenvolvedor.
Aqui está um exemplo de um AWS SAM modelo configurado:
AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: MyFunction: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda BuildProperties: function_a Properties: CodeUri: ./rust_app Handler: bootstrap Runtime: provided.al2023 ...
Etapa 2: use o AWS SAM CLI com sua função Rust Lambda
Use qualquer AWS SAMCLI comando com seu AWS SAM modelo. Para obter mais informações, consulte AWS SAM CLI.
Exemplos
Exemplo do Hello World
Neste exemplo, criamos o aplicativo Hello World de amostra usando Rust como nosso tempo de execução.
Primeiro, inicializamos um novo aplicativo sem servidor usando o sam init. Durante o fluxo interativo, selecionamos o aplicativo Hello World e escolhemos o tempo de execução do Rust.
$sam init... Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice:1Choose an AWS Quick Start application template 1 - Hello World Example 2 - Multi-step workflow 3 - Serverless API ... Template:1Use the most popular runtime and package type? (Python and zip) [y/N]:ENTERWhich runtime would you like to use? 1 - dotnet8 2 - dotnet6 3 - go (provided.al2) ... 18 - python3.11 19 - python3.10 20 - ruby4.0 21 - ruby3.3 22 - ruby3.2 23 - rust (provided.al2) 24 - rust (provided.al2023) Runtime:24Based on your selections, the only Package type available is Zip. We will proceed to selecting the Package type as Zip. Based on your selections, the only dependency manager available is cargo. We will proceed copying the template using cargo. Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]:ENTERWould you like to enable monitoring using CloudWatch Application Insights? For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]:ENTERProject name [sam-app]:hello-rust----------------------- Generating application: ----------------------- Name: hello-rust Runtime: rust (provided.al2023) Architectures: x86_64 Dependency Manager: cargo Application Template: hello-world Output Directory: . Configuration file: hello-rust/samconfig.toml Next steps can be found in the README file at hello-rust/README.md Commands you can use next ========================= [*] Create pipeline: cd hello-rust && sam pipeline init --bootstrap [*] Validate SAM template: cd hello-rust && sam validate [*] Test Function in the Cloud: cd hello-rust && sam sync --stack-name {stack-name} --watch
A seguir está a estrutura do nosso aplicativo Hello World:
hello-rust ├── README.md ├── events │ └── event.json ├── rust_app │ ├── Cargo.toml │ └── src │ └── main.rs ├── samconfig.toml └── template.yaml
Em nosso AWS SAM modelo, nossa Rust função é definida da seguinte forma:
AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: HelloWorldFunction: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda Properties: CodeUri: ./rust_app Handler: bootstrap Runtime: provided.al2023 Architectures: - x86_64 Events: HelloWorld: Type: Api Properties: Path: /hello Method: get
Em seguida, executamos sam build para criar nosso aplicativo e nos preparar para a implantação. O AWS SAMCLI cria um diretório .aws-sam e organiza nossos artefatos de construção lá. Nossa função é construída usando Cargo Lambda e armazenada como um binário executável em .aws-sam/build/HelloWorldFunction/bootstrap.
nota
Se você planeja executar o comando sam local invoke no macOS, precisa criar funções diferentes antes de invocar. Para fazer isso, use o seguinte comando:
SAM_BUILD_MODE=debug sam build
Esse comando só será necessário se for feito um teste local. Isso não é recomendado na criação para implantação.
hello-rust$sam buildStarting Build use cache Cache is invalid, running build and copying resources for following functions (HelloWorldFunction) Building codeuri: /Users/.../hello-rust/rust_app runtime: provided.al2023 metadata: {'BuildMethod': 'rust-cargolambda'} architecture: x86_64 functions: HelloWorldFunction Running RustCargoLambdaBuilder:CargoLambdaBuild Running RustCargoLambdaBuilder:RustCopyAndRename Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Validate SAM template: sam validate [*] Invoke Function: sam local invoke [*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch [*] Deploy: sam deploy --guided
Em seguida, implantamos nosso aplicativo usando sam deploy --guided.
hello-rust$sam deploy --guidedConfiguring SAM deploy ====================== Looking for config file [samconfig.toml] : Found Reading default arguments : Success Setting default arguments for 'sam deploy' ========================================= Stack Name [hello-rust]:ENTERAWS Region [us-west-2]:ENTER#Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [Y/n]:ENTER#SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]:ENTER#Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]:ENTERHelloWorldFunction may not have authorization defined, Is this okay? [y/N]:ySave arguments to configuration file [Y/n]:ENTERSAM configuration file [samconfig.toml]:ENTERSAM configuration environment [default]:ENTERLooking for resources needed for deployment: ... Uploading to hello-rust/56ba6585d80577dd82a7eaaee5945c0b 817973 / 817973 (100.00%) Deploying with following values =============================== Stack name : hello-rust Region : us-west-2 Confirm changeset : True Disable rollback : False Deployment s3 bucket : aws-sam-cli-managed-default-samclisam-s3-demo-bucket-1a4x26zbcdkqr Capabilities : ["CAPABILITY_IAM"] Parameter overrides : {} Signing Profiles : {} Initiating deployment ===================== Uploading to hello-rust/a4fc54cb6ab75dd0129e4cdb564b5e89.template 1239 / 1239 (100.00%) Waiting for changeset to be created.. CloudFormation stack changeset --------------------------------------------------------------------------------------------------------- Operation LogicalResourceId ResourceType Replacement --------------------------------------------------------------------------------------------------------- + Add HelloWorldFunctionHelloW AWS::Lambda::Permission N/A orldPermissionProd ... --------------------------------------------------------------------------------------------------------- Changeset created successfully. arn:aws:cloudformation:us-west-2:012345678910:changeSet/samcli-deploy1681427201/f0ef1563-5ab6-4b07-9361-864ca3de6ad6 Previewing CloudFormation changeset before deployment ====================================================== Deploy this changeset? [y/N]:y2023-04-13 13:07:17 - Waiting for stack create/update to complete CloudFormation events from stack operations (refresh every 5.0 seconds) --------------------------------------------------------------------------------------------------------- ResourceStatus ResourceType LogicalResourceId ResourceStatusReason --------------------------------------------------------------------------------------------------------- CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole - CREATE_IN_PROGRESS AWS::IAM::Role HelloWorldFunctionRole Resource creation ... --------------------------------------------------------------------------------------------------------- CloudFormation outputs from deployed stack --------------------------------------------------------------------------------------------------------- Outputs --------------------------------------------------------------------------------------------------------- Key HelloWorldFunctionIamRole Description Implicit IAM Role created for Hello World function Value arn:aws:iam::012345678910:role/hello-rust-HelloWorldFunctionRole-10II2P13AUDUY Key HelloWorldApi Description API Gateway endpoint URL for Prod stage for Hello World function Value https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/ Key HelloWorldFunction Description Hello World Lambda Function ARN Value arn:aws:lambda:us-west-2:012345678910:function:hello-rust-HelloWorldFunction- yk4HzGzYeZBj --------------------------------------------------------------------------------------------------------- Successfully created/updated stack - hello-rust in us-west-2
Para testar, podemos invocar nossa função do Lambda usando o endpoint da API.
$curl https://ggdxec9le9.execute-api.us-west-2.amazonaws.com/Prod/hello/Hello World!%
Para testar nossa função localmente, primeiro garantimos que a propriedade Architectures de nossa função corresponda à nossa máquina local.
... Resources: HelloWorldFunction: Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction Metadata: BuildMethod: rust-cargolambda # More info about Cargo Lambda: https://github.com/cargo-lambda/cargo-lambda Properties: CodeUri: ./rust_app # Points to dir of Cargo.toml Handler: bootstrap # Do not change, as this is the default executable name produced by Cargo Lambda Runtime: provided.al2023 Architectures: - arm64 ...
Como modificamos nossa arquitetura de x86_64 para arm64 neste exemplo, executamos sam build para atualizar nossos artefatos de construção. Em seguida, executamos sam local invoke para invocar localmente nossa função.
hello-rust$sam local invokeInvoking bootstrap (provided.al2023) Local image was not found. Removing rapid images for repo public.ecr.aws/sam/emulation-provided.al2023 Building image..................................................................................................................................... Using local image: public.ecr.aws/lambda/provided:al2023-rapid-arm64. Mounting /Users/.../hello-rust/.aws-sam/build/HelloWorldFunction as /var/task:ro,delegated, inside runtime container START RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Version: $LATEST {"statusCode":200,"body":"Hello World!"}END RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 REPORT RequestId: fbc55e6e-0068-45f9-9f01-8e2276597fc6 Init Duration: 0.68 ms Duration: 130.63 ms Billed Duration: 131 ms Memory Size: 128 MB Max Memory Used: 128 MB
Projeto de função do Lambda única
Aqui está um exemplo de um aplicativo sem servidor contendo uma função Rust Lambda.
Estrutura do diretório do projeto:
. ├── Cargo.lock ├── Cargo.toml ├── src │ └── main.rs └── template.yaml
AWS SAM modelo:
AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: MyFunction: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda Properties: CodeUri: ./ Handler: bootstrap Runtime: provided.al2023 ...
Projeto de função do Lambda Múltipla
Aqui está um exemplo de um aplicativo sem servidor contendo várias funções do Rust Lambda, organizadas como um espaço de trabalho. Cargo
Recomendamos um Cargo espaço de trabalho para aplicativos com várias funções do Rust Lambda. Cada função é seu próprio pacote, então as funções podem declarar dependências independentes enquanto compartilham código comum por meio de um pacote de biblioteca. Cada pacote produz um único binário com o nome do pacote, então você não precisa definir a propriedade de Binary construção.
Estrutura do diretório do projeto:
. ├── Cargo.lock ├── Cargo.toml ├── function_a │ ├── Cargo.toml │ └── src │ └── main.rs ├── function_b │ ├── Cargo.toml │ └── src │ └── main.rs └── template.yaml
Cargo.tomlArquivo de espaço de trabalho, na raiz do projeto:
[workspace] resolver = "2" members = [ "function_a", "function_b", ] [workspace.dependencies] lambda_runtime = "0.13" serde = { version = "1", features = ["derive"] } tokio = { version = "1", features = ["macros", "rt"] }
Cargo.tomlarquivo para cada função, comofunction_a/Cargo.toml:
[package] name = "function_a" version = "0.1.0" edition = "2021" [dependencies] lambda_runtime = { workspace = true } serde = { workspace = true } tokio = { workspace = true }
AWS SAM modelo. O CodeUri de cada função aponta para o diretório do pacote dessa função:
AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 ... Resources: FunctionA: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda Properties: CodeUri: ./function_a Handler: bootstrap Runtime: provided.al2023 FunctionB: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda Properties: CodeUri: ./function_b Handler: bootstrap Runtime: provided.al2023
nota
O AWS SAMCLI constrói todas as funções do espaço de trabalho no target diretório compartilhado do espaço de trabalho, então Cargo compila as dependências compartilhadas uma vez em vez de uma vez para cada função. Esse comportamento requer a AWS SAMCLI versão 1.165.0 ou posterior. Nas versões anteriores, cada função é criada em seu próprio target diretório e a árvore de dependências completa é recompilada para cada função, o que torna as compilações mais lentas à medida que você adiciona funções.
Dê a cada pacote de funções um nome binário exclusivo. Os nomes dos pacotes são exclusivos em um espaço de trabalho, portanto, o nome binário padrão já é exclusivo. Se você substituir o nome binário por uma [[bin]] seção, não dê a dois pacotes o mesmo nome binário. Eles são compilados no mesmo caminho no target diretório compartilhado e se sobrescrevem. Ele AWS SAMCLI registra um aviso quando detecta isso.
Como alternativa, um único pacote pode definir vários binários. Nesse caso, use a propriedade Binary build para selecionar o binário para cada função:
Resources: FunctionA: Type: AWS::Serverless::Function Metadata: BuildMethod: rust-cargolambda BuildProperties: Binary: function_a Properties: CodeUri: ./ Handler: bootstrap Runtime: provided.al2023
Otimizando as incorporações do Rust GitHub Ações
As compilações do Rust exigem muita computação e um executor de integração contínua começa sem artefatos compilados. Aplicativos com várias funções que compartilham grandes dependências, como an AWSSDK, podem passar a maior parte do tempo de criação compilando as mesmas dependências. As práticas a seguir reduzem o tempo de construção emGitHub Actions.
- Use a AWS SAMCLI versão 1.165.0 ou posterior para espaços de trabalho
-
A versão 1.165.0 e posterior incorpora todos os membros de um espaço de Cargo trabalho no
targetdiretório compartilhado do espaço de trabalho, para que as dependências compartilhadas sejam compiladas uma vez por compilação, em vez de uma vez para cada função. Especifique a versão mínima ao instalar o AWS SAMCLI para que uma compilação não volte silenciosamente ao comportamento mais lento. - Armazene em cache o Cargo registro e o
targetdiretório -
Armazene em cache o Cargo registro (
~/.cargo/registrye~/.cargo/git/db) e otargetdiretório do espaço de trabalho entre as execuções, para que as dependências inalteradas sejam restauradas em vez de recompiladas. Use um cache separado para cada destino de compilação. Uma tarefa que compila de forma cruzada artefatos de lançamentoarm64produz artefatos diferentes de uma tarefa para a qual compila nativamentex86_64, portanto, um cache compartilhado nunca coincide. - Incluir configurações de compilação na chave de cache
-
Cargoinclui configurações como
opt-levelecodegen-unitsna impressão digital que ele usa para decidir se um artefato compilado pode ser reutilizado. Se você alterar a[profile.release]seção doCargo.tomlarquivo do seu espaço de trabalho sem alterar a chave de cache, o cache será restaurado, mas todas as caixas serão recompiladas de qualquer maneira. Inclua um hash doCargo.tomlarquivo do espaço de trabalho na chave de cache para que a alteração de uma configuração de perfil inicie um novo cache. - Confirme seu
Cargo.lockarquivo -
As funções do Lambda são executáveis, então confirme seu
Cargo.lockarquivo. Isso fornece compilações reproduzíveis e uma chave de cache estável que muda somente quando suas dependências mudam. - Ajuste o perfil de lançamento para o tempo de construção e partida a frio
-
Seu código de função é recompilado em cada execução, porque ele muda com mais frequência do que suas dependências. O perfil de lançamento padrão otimiza a taxa de transferência de tempo de execução, que muitas funções do Lambda não precisam. A otimização do tamanho produz binários menores, o que também ajuda no tempo de inicialização a frio, e o aumento do número de unidades de geração de código aumenta o paralelismo durante a compilação. Deixe a otimização do tempo do link (
lto) desativada, pois isso torna a compilação mais lenta. Adicione o seguinte ao seuCargo.tomlarquivo de espaço de trabalho:[profile.release] opt-level = "s" codegen-units = 256 lto = false strip = trueMeça o efeito em seu próprio aplicativo. Essas configurações trocam uma pequena quantidade de desempenho de tempo de execução pelo tempo de construção e pelo tamanho do binário.
- Evite execuções duplicadas de fluxo de trabalho
-
Um fluxo de trabalho que é executado em ambos
pushospull_requesteventos é executado duas vezes para a mesma confirmação. GitHub ActionsOs caches têm o escopo definido por branch e pull request, então os dois executam a gravação em escopos de cache diferentes e nenhum deles reutiliza o cache do outro. Use um grupo de simultaneidade que esteja codificado no commit principal, para que apenas uma execução crie cada confirmação.
O fluxo de trabalho a seguir cria um Cargo espaço de trabalho de funções do Rust Lambda e aplica as arm64 práticas anteriores:
name: Build on: push: branches: [main] pull_request: # Collapse the push and pull_request runs for the same commit into a single run. concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.head.sha || github.sha }} cancel-in-progress: true jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - uses: dtolnay/rust-toolchain@stable with: targets: aarch64-unknown-linux-gnu # Cache the Cargo registry and the workspace target directory. The key covers # the compilation target, Cargo.lock, and the workspace Cargo.toml, so that # changing a dependency or a release profile setting starts a new cache # instead of restoring one whose artifacts Cargo discards. - uses: actions/cache@v4 with: path: | ~/.cargo/registry/index ~/.cargo/registry/cache ~/.cargo/git/db target key: cargo-arm64-${{ hashFiles('Cargo.lock', 'Cargo.toml') }} restore-keys: | cargo-arm64- - name: Install build tools run: pip install cargo-lambda 'aws-sam-cli>=1.165.0' - name: Build run: sam build
A restore-keys entrada permite que uma execução comece no cache mais recente quando a chave não corresponde exatamente, para que uma alteração de dependência reutilize as caixas que não foram alteradas em vez de compilar tudo novamente.