Sesuaikan Go Builds pada AWS SAM dengan Dockerfiles dan Makefiles

Siaran ini meneruskan siri Membina APLIKASI dengan AWS SAM dan Go, dibina berdasarkan ansuran pertama. Bab sebelumnya menyerlahkan panduan terhad AWS tentang penstrukturan projek Go boleh skala tanpa kod berlebihan.

Artikel ini menunjukkan teknik untuk mengurus proses binaan menggunakan Dockerfiles dan Makefiles.

Kod yang disertakan tersedia di sini: https://www.php.cn/link/5655cf23be4dda7082c8bb3a8d8f8016. Terokai cawangan Git yang berbeza untuk pelbagai kes penggunaan.

Mari mulakan!

Cabarannya

Selepas membangunkan struktur projek baharu, saya memilih Nix untuk pengurusan pergantungan (bahasa, alatan, perpustakaan). Nix beroperasi dengan mencipta cangkerang sementara dengan kebergantungan yang ditentukan.

Saya mengalami ralat semasa melaksanakan binari yang dibina dalam cangkerang Nix:

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

Ini menghentikan pelaksanaan Lambda. Penyahpepijatan mendedahkan punca utama: Pergi kadangkala memautkan perpustakaan C secara dinamik kepada boleh laku, menentukan laluan sistem. Perpustakaan yang dipautkan kepada boleh laku binaan Nix ialah:

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

Storan pergantungan bukan standard Nix, digabungkan dengan bekas Docker terpencil Lambda, menghalang Lambda daripada mengesan perpustakaan ini, kerana ia hanya wujud dalam pemasangan Nix tempatan saya. Penyelesaian diperlukan untuk mengarahkan AWS SAM tentang cara menyusun kod dan mengurus pemautan perpustakaan.

Menggunakan Projek Go ke AWS

Dua kaedah penggunaan wujud:

Zip Fail ?

Kompilasi secara setempat dan hantar yang boleh laku kepada AWS dalam fail .zip. AWS menyalin boleh laku ke bekas Docker. Ini menawarkan permulaan sejuk terpantas.

Imej Docker ?

Sediakan AWS arahan untuk menyusun dalam bekas Docker pelaksanaan. Ini memastikan keserasian tetapi menghasilkan permulaan sejuk yang lebih perlahan.

Penyelesaian

Saya memilih Dockerfiles untuk terus menggunakan Nix, tetapi kedua-dua kaedah dibentangkan di bawah.

Zip Fail ?

Untuk fail Zip, gunakan struktur projek ini (perhatikan 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>

Makefile mentakrifkan arahan binaan untuk setiap fungsi menggunakan corak build-<function_name> (diperlukan oleh 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>

Maklumkan SAM tentang proses ini:

<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 memberitahu SAM untuk menggunakan Makefile, terletak di mana CodeUri menyatakan.

Imej Docker ?

Buat Dockerfile dan .dockerignore dalam direktori akar:

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

Dockerfile menentukan langkah binaan. ARG ENTRY_POINT menentukan titik masuk lambda pada masa binaan:

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

Ubah suai template.yaml:

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

Nota Metadata dan PackageType: Image. DockerBuildArgs pas ENTRY_POINT daripada Dockerfile, membenarkan satu Dockerfile untuk semua lambda.

Kesimpulan

Penjelasan terperinci ini menyediakan pendekatan komprehensif untuk mengurus binaan Go dalam AWS SAM menggunakan kedua-dua fail Zip dan imej Docker. Pilihan bergantung pada keutamaan kelajuan binaan berbanding ketekalan penggunaan.

Atas ialah kandungan terperinci Sesuaikan Go Builds pada AWS SAM dengan Dockerfiles dan Makefiles. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!