Erstellen eines ZIP-Dateiarchivs Erstellen eines Container-Images Container-Umgebungsvariablendatei Beschleunigen Sie die Erstellungszeiten, indem Sie Ihr Projekt im Quellordner erstellen Beispiele Erstellen von Funktionen außerhalb von AWS SAM

Erstellen von Anwendungen

Verwenden Sie den sam build Befehl , um Ihre Serverless-Anwendung zu erstellen. Dieser Befehl sammelt auch die Build-Artefakte der Abhängigkeiten Ihrer Anwendung und platziert sie im richtigen Format und am richtigen Speicherort für die nächsten Schritte, z. B. lokales Testen, Verpacken und Bereitstellen.

Sie geben die Abhängigkeiten Ihrer Anwendung in einer Manifestdatei an, z. B. requirements.txt (Python) oder package.json (Node.js) oder mithilfe der -LayersEigenschaft einer Funktionsressource. Die -LayersEigenschaft enthält eine Liste von AWS Lambda Ebenenressourcen, von denen die Lambda-Funktion abhängt.

Das Format der Build-Artefakte Ihrer Anwendung hängt von der PackageType Eigenschaft jeder Funktion ab. Die Optionen für diese Eigenschaft sind:

Zip – Ein ZIP-Dateiarchiv, das Ihren Anwendungscode und seine Abhängigkeiten enthält. Wenn Sie Ihren Code als ZIP-Dateiarchiv verpacken, müssen Sie eine Lambda-Laufzeit für Ihre Funktion angeben.
Image – Ein Container-Image, das das Basisbetriebssystem, die Laufzeit und Erweiterungen sowie Ihren Anwendungscode und seine Abhängigkeiten enthält.

Weitere Informationen zu Lambda-Pakettypen finden Sie unter Lambda-Bereitstellungspakete im AWS Lambda -Entwicklerhandbuch.

Themen

Erstellen eines ZIP-Dateiarchivs

Um Ihre Serverless-Anwendung als ZIP-Dateiarchiv zu erstellen, deklarieren Sie PackageType: Zip für Ihre Serverless-Funktion.

AWS SAM erstellt Ihre Anwendung für die von Ihnen angegebene Architektur. Wenn Sie keine Architektur angeben, AWS SAM verwendet x86_64 standardmäßig .

Wenn Ihre Lambda-Funktion von Paketen abhängt, die nativ kompilierte Programme haben, verwenden Sie das ---use-containerFlag. Dieses Flag kompiliert Ihre Funktionen lokal in einem Docker-Container, der sich wie eine Lambda-Umgebung verhält, sodass sie bei der Bereitstellung in der AWS Cloud das richtige Format haben.

Wenn Sie die --use-container Option verwenden, AWS SAM ruft standardmäßig das Container-Image von Amazon ECR Public ab. Wenn Sie ein Container-Image aus einem anderen Repository abrufen möchten, z. B. DockerHub, können Sie die --build-image Option verwenden und den URI eines alternativen Container-Images angeben. Im Folgenden finden Sie zwei Beispielbefehle zum Erstellen von Anwendungen mithilfe von Container-Images aus dem DockerHub Repository:


# Build a Node.js 12 application using a container image pulled from DockerHub
sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs12.x

# Build a function resource using the Python 3.8 container image pulled from DockerHub
sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.8

Eine Liste der URIs, die Sie mit verwenden können--build-image, finden Sie unter , Bild-Repositorien die DockerHub URIs für eine Reihe unterstützter Laufzeiten enthält.

Weitere Beispiele für die Erstellung einer ZIP-Dateiarchivanwendung finden Sie im Abschnitt Beispiele weiter unten in diesem Thema.

Erstellen eines Container-Images

Um Ihre Serverless-Anwendung als Container-Image zu erstellen, deklarieren Sie PackageType: Image für Ihre Serverless-Funktion. Sie müssen das Metadata Ressourcenattribut auch mit den folgenden Einträgen deklarieren:

Dockerfile: Der Name der Dockerfile-Datei, die der Lambda-Funktion zugeordnet ist.
DockerContext: Der Speicherort der Docker-Datei.
DockerTag: (Optional) Ein Tag, das auf das erstellte Image angewendet werden soll.
DockerBuildArgs: Erstellen Sie Argumente für den Build.

Im Folgenden finden Sie ein Beispiel für einen Abschnitt Metadata mit Ressourcenattributen:


    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: v1

Informationen zum Herunterladen einer Beispielanwendung, die mit dem -ImagePakettyp konfiguriert ist, finden Sie unter Tutorial: Bereitstellen einer Hello-World-Anwendung im Tutorial: Bereitstellen einer Hello World-Anwendung. Wählen Sie in der Eingabeaufforderung mit der Frage aus, welchen Pakettyp Sie installieren möchtenImage.

Anmerkung

Wenn Sie ein Multi-Architektur-Basis-Image in Ihrem Dockerfile angeben, AWS SAM erstellt Ihr Container-Image für die Architektur Ihres Host-Computers. Um für eine andere Architektur zu erstellen, geben Sie ein Basis-Image an, das die spezifische Zielarchitektur verwendet.

Container-Umgebungsvariablendatei

Um eine JSON-Datei bereitzustellen, die Umgebungsvariablen für den Build-Container enthält, verwenden Sie das Argument mit dem sam build Befehl --container-env-var-file . Sie können eine einzelne Umgebungsvariable angeben, die für alle Serverless-Ressourcen gilt, oder verschiedene Umgebungsvariablen für jede Ressource.

Format

Das Format für die Übergabe von Umgebungsvariablen an einen Build-Container hängt davon ab, wie viele Umgebungsvariablen Sie für Ihre Ressourcen bereitstellen.

Um eine einzelne Umgebungsvariable für alle Ressourcen bereitzustellen, geben Sie ein Parameters Objekt wie das folgende an:


{
  "Parameters": {
    "GITHUB_TOKEN": "TOKEN_GLOBAL"
  }
}

Um verschiedene Umgebungsvariablen für jede Ressource bereitzustellen, geben Sie Objekte für jede Ressource wie die folgenden an:


{
  "MyFunction1": {
    "GITHUB_TOKEN": "TOKEN1"
  },
  "MyFunction2": {
    "GITHUB_TOKEN": "TOKEN2"
  }
}

Speichern Sie Ihre Umgebungsvariablen als Datei, z. Benv.json. . Der folgende Befehl verwendet diese Datei, um Ihre Umgebungsvariablen an den Build-Container zu übergeben:


sam build --use-container --container-env-var-file env.json

Precedence

Die Umgebungsvariablen, die Sie für bestimmte Ressourcen angeben, haben Vorrang vor der einzelnen Umgebungsvariablen für alle Ressourcen.
Umgebungsvariablen, die Sie in der Befehlszeile angeben, haben Vorrang vor Umgebungsvariablen in einer Datei.

Beschleunigen Sie die Erstellungszeiten, indem Sie Ihr Projekt im Quellordner erstellen

Für unterstützte Laufzeiten und Build-Methoden können Sie die --build-in-source Option verwenden, um Ihr Projekt direkt im Quellordner zu erstellen. Standardmäßig AWS SAM CLI erstellt in einem temporären Verzeichnis, das das Kopieren über Quellcode und Projektdateien beinhaltet. Mit wird direkt in Ihrem Quellordner --build-in-source AWS SAM CLI erstellt, wodurch der Build-Prozess beschleunigt wird, indem keine Dateien in ein temporäres Verzeichnis kopiert werden müssen.

Eine Liste der unterstützten Laufzeiten und Build-Methoden finden Sie unter --build-in-source.

Beispiele

Beispiel 1: ZIP-Dateiarchiv

Mit den folgenden sam build Befehlen wird ein ZIP-Dateiarchiv erstellt:


# Build all functions and layers, and their dependencies
sam build

# Run the build process inside a Docker container that functions like a Lambda environment
sam build --use-container

# Build a Node.js 12 application using a container image pulled from DockerHub
sam build --use-container --build-image amazon/aws-sam-cli-build-image-nodejs12.x

# Build a function resource using the Python 3.8 container image pulled from DockerHub
sam build --use-container --build-image Function1=amazon/aws-sam-cli-build-image-python3.8 

# Build and run your functions locally
sam build && sam local invoke

# For more options
sam build --help

Beispiel 2: Container-Image

Die folgende AWS SAM Vorlage wird als Container-Image erstellt:


Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      ImageConfig:
        Command: ["app.lambda_handler"]
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: v1

Im Folgenden finden Sie ein Beispiel für Dockerfile:


FROM public.ecr.aws/lambda/python:3.8

COPY app.py requirements.txt ./

RUN python3.8 -m pip install -r requirements.txt

# Overwrite the command by providing a different command directly in the template.
CMD ["app.lambda_handler"]

Beispiel 3: npm ci

Für Node.js-Anwendungen können Sie npm ci anstelle von verwenden, npm install um Abhängigkeiten zu installieren. Um zu verwendennpm ci, geben Sie UseNpmCi: True unter BuildProperties im Metadata Ressourcenattribut Ihrer Lambda-Funktion an. Um verwenden zu könnennpm ci, muss Ihre Anwendung über eine - package-lock.json oder -npm-shrinkwrap.jsonDatei in der CodeUri für Ihre Lambda-Funktion verfügen.

Im folgenden Beispiel wird verwendetnpm ci, um Abhängigkeiten zu installieren, wenn Sie ausführensam build:


Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.handler
      Runtime: nodejs14.x
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get
    Metadata:
      BuildProperties:
        UseNpmCi: True

Erstellen von Funktionen außerhalb von AWS SAM

Wenn Sie ausführen, sam build AWS SAM erstellt standardmäßig alle Ihre Funktionsressourcen. Weitere Optionen sind:

Erstellen aller Funktionsressourcen außerhalb von AWS SAM – Wenn Sie alle Ihre Funktionsressourcen manuell oder über ein anderes Tool erstellen, sam build ist nicht erforderlich. Sie können den nächsten Schritt Ihres Prozesses überspringen sam build und mit diesem fortfahren, z. B. lokale Tests durchführen oder Ihre Anwendung bereitstellen.
Erstellen einiger Funktionsressourcen außerhalb von AWS SAM – Wenn Sie einige Ihrer Funktionsressourcen erstellen AWS SAM möchten, während andere Funktionsressourcen außerhalb von erstellt werdenAWS SAM, können Sie dies in Ihrer AWS SAM Vorlage angeben.

Erstellen einiger Funktionsressourcen außerhalb von AWS SAM

Damit eine Funktion bei der Verwendung von AWS SAM überspringtsam build, konfigurieren Sie Folgendes in Ihrer AWS SAM Vorlage:

Fügen Sie die SkipBuild: True Metadateneigenschaft zu Ihrer Funktion hinzu.
Geben Sie den Pfad zu Ihren erstellten Funktionsressourcen an.

Hier ist ein Beispiel, bei dem so TestFunction konfiguriert ist, dass es übersprungen wird. Die erstellten Ressourcen befinden sich unter built-resources/TestFunction.zip.


TestFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: built-resources/TestFunction.zip
    Handler: TimeHandler::handleRequest
    Runtime: java11
  Metadata:
    SkipBuild: True

Wenn Sie jetzt ausführen, sam build AWS SAM führt Folgendes aus:

AWS SAM überspringt Funktionen, die mit konfiguriert sindSkipBuild: True.
AWS SAM erstellt alle anderen Funktionsressourcen und speichert sie im .aws-sam Build-Verzeichnis zwischen.
Bei übersprungenen Funktionen wird ihre Vorlage im .aws-sam Build-Verzeichnis automatisch aktualisiert, um auf den angegebenen Pfad zu Ihren erstellten Funktionsressourcen zu verweisen.

Hier ist ein Beispiel für die zwischengespeicherte Vorlage für TestFunction im .aws-sam Build-Verzeichnis:
```
TestFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: ../../built-resources/TestFunction.zip
    Handler: TimeHandler::handleRequest
    Runtime: java11
  Metadata:
    SkipBuild: True
```

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Erstellung

Erstellen von Node.js-Lambda-Funktionen mit esbuild