Erstellen einer API mit AWS SAM und Go

AWS SAM ist eine großartige Möglichkeit, Webanwendungen über Infrastructure as Code (IAC) bereitzustellen. Ich habe kürzlich versucht, es in meinem Arbeitsprojekt zu verwenden und bin auf eine harte Realität gestoßen ...

Go ist das hässliche Entlein von AWS?

Der Go gewidmete Abschnitt der AWS SAM-Dokumentation ist sehr kurz und vage und empfiehlt eine ausführliche Wiederholung unseres Quellcodes ! Jede Lambda-Funktion hat eine go.mod-, go.sum- und Utility-Funktion?!

Ich schreibe diesen Artikel für Sie, die genauso verwirrt sind wie ich?‍?. Lassen Sie uns dieses Problem gemeinsam lösen!

Dies wird eine zweiteilige Serie sein:

1. Dateistruktur (dieser Artikel)
2. SAM-Konfiguration

Laufzeitkontext aufrufen

Derzeit wird Lambda in der Go-Laufzeitumgebung nicht unterstützt. Das bedeutet, dass AWS Lambda keine spezifische Option hat, um anzugeben, dass Ihr Code in Go geschrieben ist. Stattdessen bietet AWS zwei gängige Laufzeiten an?:

• al2 (Amazon Linux 2)
• al2023 (Amazon Linux 2023)

Dies bezieht sich auf das Betriebssystem, auf dem das Lambda ausgeführt wird. Es wird empfohlen, al2023 zu verwenden, da es neuer und mit AWS Graviton-Prozessoren kompatibel ist, die eine bessere Leistung zu einem niedrigeren Preis bieten.

Jedenfalls erfordern diese Laufzeiten, dass wir eine ausführbare Datei (normalerweise Bootstrap genannt) bereitstellen, die innerhalb jeder Lambda-Funktion ausgeführt wird. Anstatt also Code an ein Lambda zu liefern, liefern wir eine ausführbare Datei , die wir zuvor mit Go kompiliert haben. Ziemlich einfach, oder?

Dadurch entfällt auch die Notwendigkeit einer Lambda-Schicht für Sprachen wie JS, da alle gängigen Abhängigkeiten in die kompilierte ausführbare Datei gepackt werden.

Frage

Wie erstellen wir also diese ausführbare Datei? AWS empfiehlt, dass jedes unserer Lambdas zusammen mit seiner go.mod und go.sum in einem Ordner gespeichert wird. Die bereitgestellte Vorlage sieht folgendermaßen aus:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

Dies ist die Funktionsdefinition in template.yaml

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

Wenn wir uns die Lambda-Definition ansehen, erfahren wir:

1. BuildMethod: go1.x Wir verwenden den integrierten Go-Builder von AWS, um die ausführbare Datei für uns zu erstellen
2. CodeUri: Hallo-Welt/Lambda-Code wird ausschließlich in diesem Verzeichnis gespeichert.
3. Handler: Bootstrap Der Name der ausführbaren Datei lautet Bootstrap
4. Laufzeit: vorausgesetzt.al2023 Dies wird die Laufzeit sein.

Sehen Sie das Problem? Derzeit benötigen wir ein zweites Lambda. Wir müssen ein neues Verzeichnis mit eigenem go.mod, go.sum und Abhängigkeiten erstellen. Was ist, wenn wir eine Dienstprogrammfunktion zwischen den beiden Lambdas teilen möchten? Schade?! Sie müssen dieselben Dateien in den neuen Lambda-Ordner kopieren. Dies hinterlässt eine Dateistruktur, die wie folgt aussieht:

Das ist so schlimm?!

<code>.
├── function1/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── function2/
│   ├── go.mod
│   ├── go.sum
│   ├── main.go
│   └── SHAREDFUNC.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

Es gibt viel doppelten Code!

Und es wird schlimmer, je mehr Lambdas wir hinzufügen. Es muss einen besseren Weg geben!

Lösung

Da ich go.mod, go.sum und Utility-Code über alle Lambdas teilen möchte, habe ich mir diese Struktur ausgedacht:

<code>.
├── hello-world/
│   ├── go.mod
│   ├── go.sum
│   └── main.go
├── events/
│   └── ...
├── samconfig.toml
└── template.yaml</code>

1. Ich habe den gesamten öffentlichen Code in den Ordner „internal/“ kopiert,
2. Platzieren Sie die Dateien go.mod und go.sum im Stammverzeichnis
3. Verschieben Sie alle Lambda-Einstiegspunkte nach /cmd (in Go gibt es eine Konvention, dass immer dann, wenn ein Projekt mehrere ausführbare Dateien produziert, die Einstiegspunkte im cmd-Verzeichnis platziert werden)

Jetzt muss ich AWS SAM nur noch über diese neue Struktur informieren?! Ich habe die Lösung gefunden, indem ich einfach die Werte von CodeUri und Handler angepasst habe.

Geheimnis?

Es scheint, dass, wenn Sie

• Verschieben Sie go.mod und go.sum in den Stammordner
• Setzen Sie CodeUri auf den Ordner, in dem sich der Funktionseinstiegspunkt befindet.

SAM erkennt es automatisch und erstellt mit Root-Abhängigkeiten und internem Code?

<code>  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2023
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET</code>

Kann es besser sein?

Ja✨, wir werden im nächsten Artikel weitere Möglichkeiten zur Anpassung der Go-Kompilierung besprechen!

Das obige ist der detaillierte Inhalt vonErstellen einer API mit AWS SAM und Go. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!