APIGateway eseguito localmente con AWS SAM - AWS Serverless Application Model
File di variabili di ambienteLivelli

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

APIGateway eseguito localmente con AWS SAM

L'esecuzione locale di Amazon API Gateway può offrire una serie di vantaggi. Ad esempio, l'esecuzione locale di API Gateway consente di testare gli API endpoint localmente prima della distribuzione nel AWS cloud. Se esegui prima il test localmente, spesso puoi ridurre i test e lo sviluppo nel cloud, il che può aiutare a ridurre i costi. Inoltre, l'esecuzione locale semplifica il debug.

Per avviare un'istanza locale di API Gateway da utilizzare per testare la funzionalità di HTTP richiesta/risposta, utilizza il sam local start-api AWS SAM CLI comando. Questa funzionalità include il ricaricamento a caldo in modo da poter sviluppare e iterare rapidamente le funzioni.

Nota

Il ricaricamento a caldo avviene quando vengono aggiornati solo i file modificati e lo stato dell'applicazione rimane lo stesso. Al contrario, il ricaricamento in tempo reale avviene quando l'intera applicazione viene aggiornata e lo stato dell'applicazione viene perso.

Per istruzioni sull'uso del sam local start-api comando, vedere. Introduzione ai test con sam local start-api

Per impostazione predefinita, AWS SAM utilizza integrazioni AWS Lambda proxy e supporta sia i tipi di risorse che HttpApi i tipi di Api risorse. Per ulteriori informazioni sulle integrazioni proxy per i tipi di HttpApi risorse, consulta Lavorare con le integrazioni AWS Lambda proxy HTTP APIs nella APIGateway Developer Guide. Per ulteriori informazioni sulle integrazioni proxy con i tipi di Api risorse, consulta Understand API Gateway Lambda Proxy Integration nella Gateway Developer API Guide.

Esempio:

$ sam local start-api

AWS SAM trova automaticamente tutte le funzioni all'interno del AWS SAM modello che hanno HttpApi o sono state definite fonti di Api eventi. Quindi, monta la funzione nei HTTP percorsi definiti.

Nell'Apiesempio seguente, la Ratings funzione viene montata ratings.py:handler() su /ratings per GET le richieste:

Ratings:
  Type: AWS::Serverless::Function
  Properties:
    Handler: ratings.handler
    Runtime: python3.9
    Events:
      Api:
        Type: Api
        Properties:
          Path: /ratings
          Method: get

Ecco un esempio di Api risposta:

// Example of a Proxy Integration response
exports.handler = (event, context, callback) => {
    callback(null, {
        statusCode: 200,
        headers: { "x-custom-header" : "my custom header value" },
        body: "hello world"
    });
}

Se modifichi il codice della funzione, esegui il sam build comando for sam local start-api per rilevare le modifiche.

File di variabili di ambiente

Per dichiarare localmente le variabili di ambiente che sovrascrivono i valori definiti nei modelli, procedi come segue:

  1. Create un JSON file che contenga le variabili di ambiente da sovrascrivere.

  2. Utilizzate l'--env-varsargomento per sovrascrivere i valori definiti nei modelli.

Dichiarazione delle variabili di ambiente

Per dichiarare variabili di ambiente che si applicano globalmente a tutte le risorse, specificate un Parameters oggetto come il seguente:

{
    "Parameters": {
        "TABLE_NAME": "localtable",
        "BUCKET_NAME": "amzn-s3-demo-bucket",
        "STAGE": "dev"
    }
}

Per dichiarare variabili di ambiente diverse per ogni risorsa, specificate gli oggetti per ogni risorsa come segue:

{
    "MyFunction1": {
        "TABLE_NAME": "localtable",
        "BUCKET_NAME": "amzn-s3-demo-bucket",
    },
    "MyFunction2": {
        "TABLE_NAME": "localtable",
        "STAGE": "dev"
    }
}

Quando si specificano oggetti per ogni risorsa, è possibile utilizzare i seguenti identificatori, elencati in ordine di precedenza dalla più alta alla più bassa:

  1. logical_id

  2. function_id

  3. function_name

  4. Identificatore di percorso completo

È possibile utilizzare entrambi i metodi precedenti per dichiarare le variabili di ambiente insieme in un unico file. In tal caso, le variabili di ambiente fornite per risorse specifiche hanno la precedenza sulle variabili di ambiente globali.

Salva le variabili di ambiente in un JSON file, ad esempioenv.json.

Ignorare i valori delle variabili di ambiente

Per sovrascrivere le variabili di ambiente con quelle definite nel JSON file, utilizzate l'--env-varsargomento con i comandi invoke orstart-api. Per esempio:

$ sam local start-api --env-vars env.json

Livelli

Se l'applicazione include livelli, per informazioni su come eseguire il debug dei problemi con i layer sull'host locale, consultaAumenta l'efficienza utilizzando i livelli Lambda con AWS SAM.