Créer une API avec AWS SAM and Go

AWS SAM est un excellent moyen de déployer des applications Web via Infrastructure as Code (IAC). J'ai récemment essayé de l'utiliser dans mon projet de travail et je me suis heurté à une dure réalité...

Go est le vilain petit canard d'AWS ?

La section de la documentation AWS SAM dédiée à Go est très courte et vague, recommandant de répéter abondamment notre code source ! Chaque fonction lambda a des fonctions go.mod, go.sum et utilitaires ?!

J'écris cet article pour vous qui êtes aussi confus que moi ?‍?. Résolvons ce problème ensemble !

Ce sera une série en deux parties :

1. Structure des fichiers (cet article)
2. Configuration SAM

Aller au contexte d'exécution

Actuellement, lambda n'est pas pris en charge dans le runtime Go. Cela signifie qu'AWS lambda n'a pas d'option spécifique pour spécifier que votre code est écrit en Go. Au lieu de cela, AWS propose 2 environnements d'exécution courants ? :

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

Il s'agit du système d'exploitation sur lequel le lambda fonctionnera. Il est recommandé d'utiliser al2023 car il est plus récent et compatible avec les processeurs AWS Graviton qui offrent de meilleures performances à un prix inférieur.

Quoi qu'il en soit, ces runtimes nous obligent à fournir un fichier exécutable (généralement nommé bootstrap) qui sera exécuté dans chaque fonction lambda. Donc, au lieu de livrer du code à un lambda, nous livrons un exécutable que nous avons préalablement compilé avec Go. Assez simple, non ?

Cela élimine également le besoin d'une couche lambda pour les langages comme JS, car toutes les dépendances courantes seront regroupées dans l'exécutable compilé.

Question

Alors, comment construisons-nous cet exécutable ? AWS recommande que chacun de nos lambdas soit stocké dans un dossier, avec ses go.mod et go.sum, et le modèle qu'ils fournissent ressemble à ceci :

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

Voici la définition de la fonction dans 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>

Si on regarde la définition Lambda, on apprend :

1. BuildMethod : go1.x Nous utilisons le générateur Go intégré d'AWS pour créer l'exécutable pour nous
2. CodeUri : le code hello-world/lambda sera stocké exclusivement dans ce répertoire.
3. Gestionnaire : bootstrap Le nom de l'exécutable sera bootstrap
4. Runtime : provide.al2023 Ce sera le runtime.

Voyez-vous le problème ? Actuellement nous avons besoin d'un deuxième lambda, nous devons créer un nouveau répertoire avec ses propres go.mod, go.sum et dépendances, et si nous voulons partager une fonction utilitaire entre les deux lambdas ? Dommage?! Vous devez copier les mêmes fichiers dans le nouveau dossier lambda. Cela laisse une structure de fichier qui ressemble à ceci :

C'est si grave ?!

<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>

Il y a beaucoup de code en double !

Et cela empire à mesure que nous ajoutons des lambdas. Il doit y avoir une meilleure façon !

Solution

Comme je souhaite partager go.mod, go.sum et le code utilitaire via tous les lambdas, j'ai trouvé cette structure :

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

1. J'ai cassé tout le code public dans le dossier internal/,
2. Placez les fichiers go.mod et go.sum dans le répertoire racine
3. Déplacez tous les points d'entrée lambda vers /cmd (il existe une convention dans Go selon laquelle chaque fois qu'un projet produit plusieurs exécutables, les points d'entrée sont placés dans le répertoire cmd)

Il ne me reste plus qu'à informer AWS SAM de cette nouvelle structure ?! J'ai trouvé la solution simplement en ajustant les valeurs de CodeUri et Handler.

Secret ?

Il semble que si vous

• Déplacez go.mod et go.sum vers le dossier racine
• Définissez CodeUri sur le dossier dans lequel se trouve le point d'entrée de la fonction.

SAM le détectera automatiquement et construira avec les dépendances racine et le code interne ?

 ?

<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>

Est-ce que ça peut être mieux ?

Oui✨, nous discuterons d'autres façons de personnaliser la compilation Go dans le prochain article !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!