Personnalisez les Go Builds sur AWS SAM avec Dockerfiles et Makefiles

Cet article continue la série Création d'applications avec AWS SAM et Go, en s'appuyant sur le premier volet. Le chapitre précédent a mis en évidence les conseils limités d'AWS sur la structuration de projets Go évolutifs sans code redondant.

Cet article présente des techniques de gestion des processus de build à l'aide de Dockerfiles et de Makefiles.

Le code qui l'accompagne est disponible ici : https://www.php.cn/link/5655cf23be4dda7082c8bb3a8d8f8016. Explorez les différentes branches Git pour différents cas d'utilisation.

Commençons !

Le défi

Après avoir développé une nouvelle structure de projet, j'ai choisi Nix pour la gestion des dépendances (langages, outils, bibliothèques). Nix fonctionne en créant un shell temporaire avec les dépendances spécifiées.

J'ai rencontré une erreur lors de l'exécution de binaires construits dans un shell Nix :

<code>libc.so.6 not found in /nix/23fj39chsggb09s.libc</code>

Cela a interrompu l'exécution de Lambda. Le débogage a révélé la cause première : Go lie parfois dynamiquement les bibliothèques C aux exécutables, en spécifiant les chemins système. Les bibliothèques liées aux exécutables construits par Nix étaient :

<code>$ ldd bootstrap 
        linux-vdso.so.1 (0x00007ffff7fc4000)
        libresolv.so.2 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libresolv.so.2 (0x00007ffff7fac000)
        libpthread.so.0 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libpthread.so.0 (0x00007ffff7fa7000)
        libc.so.6 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/libc.so.6 (0x00007ffff7c00000)
        /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib/ld-linux-x86-64.so.2 => /nix/store/65h17wjrrlsj2rj540igylrx7fqcd6vq-glibc-2.40-36/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc6000)</code>

Le stockage de dépendances non standard de Nix, combiné aux conteneurs Docker isolés de Lambda, a empêché Lambda de localiser ces bibliothèques, car elles n'existaient que dans mon installation Nix locale. Une solution était nécessaire pour expliquer à AWS SAM comment compiler le code et gérer les liaisons de bibliothèques.

Déploiement de projets Go sur AWS

Deux méthodes de déploiement existent :

Fichiers Zip ?

Compilez localement et envoyez l'exécutable à AWS dans un fichier .zip. AWS copie l'exécutable dans le conteneur Docker. Cela offre les démarrages à froid les plus rapides.

Images Docker ?

Fournissez à AWS les instructions pour compiler dans le conteneur Docker d'exécution. Cela garantit la compatibilité mais entraîne des démarrages à froid plus lents.

Solutions

J'ai opté pour Dockerfiles pour continuer à utiliser Nix, mais les deux méthodes sont présentées ci-dessous.

Fichiers Zip ?

Pour les fichiers Zip, utilisez cette structure de projet (notez le Makefile) :

<code>.
├── cmd/
│   ├── function1/
│   │   └── function1.go  # contains main()
│   └── function2/
│       └── function2.go  # contains main()
├── internal/
│   └── SHAREDFUNC.go
├── Makefile
├── go.mod
├── go.sum
├── samconfig.toml
└── template.yaml</code>

Le Makefile définit les commandes de construction pour chaque fonction en utilisant le modèle build-<function_name> (requis par AWS SAM) :

<code>.PHONY: build

build:
    sam build

build-HelloWorldFunction:
    GOARCH=amd64 GOOS=linux go build -tags lambda.norpc -o bootstrap ./cmd/function1/main.go
    cp ./bootstrap $(ARTIFACTS_DIR)

build-ByeWorldFunction:
    GOARCH=amd64 GOOS=linux go build -tags lambda.norpc -o bootstrap ./cmd/function2/main.go
    cp ./bootstrap $(ARTIFACTS_DIR)</code>

Informer SAM de cette démarche :

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

BuildMethod: makefile indique à SAM d'utiliser le Makefile, situé à l'endroit où CodeUri précise.

Images Docker ?

Créez un Dockerfile et un .dockerignore dans le répertoire racine :

<code>.
├── cmd/
│   ├── function1/
│   │   └── function1.go  # contains main()
│   └── function2/
│       └── function2.go  # contains main()
├── internal/
│   └── SHAREDFUNC.go
├── Dockerfile
├── .dockerignore
├── go.mod
├── go.sum
├── samconfig.toml
└── template.yaml</code>

Le Dockerfile spécifie les étapes de construction. ARG ENTRY_POINT spécifie le point d'entrée lambda au moment de la construction :

<code>FROM public.ecr.aws/docker/library/golang:1.19 as build-image
ARG ENTRY_POINT  # !IMPORTANT
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -tags lambda.norpc -o lambda-handler ${ENTRY_POINT}
FROM public.ecr.aws/lambda/provided:al2023
COPY --from=build-image /src/lambda-handler .
ENTRYPOINT ./lambda-handler</code>

Modifier template.yaml :

<code>libc.so.6 not found in /nix/23fj39chsggb09s.libc</code>

Note Metadata et PackageType: Image. DockerBuildArgs passe ENTRY_POINT du Dockerfile, permettant un seul Dockerfile pour tous les lambdas.

Conclusion

Cette explication détaillée fournit une approche complète de la gestion des builds Go dans AWS SAM à l'aide de fichiers Zip et d'images Docker. Le choix dépend des priorités entre la vitesse de construction et la cohérence du déploiement.

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!