Exec /main: нет такого файла или каталога при создании образа Docker приложения Go
У меня есть приложение golang, которое я хочу закрепить и запустить на AWS Lambda. Вот мой Dockerfile:
FROM golang:1.21 as build
WORKDIR /app
RUN apt-get update
RUN apt-get install -y libvips libvips-dev
COPY go.mod go.sum ./
COPY main.go .
RUN GOOS=linux GOARCH=amd64 go build -o main main.go
FROM alpine:3.19
COPY --from=build /app/main /main
ENTRYPOINT [ "/main" ]
Я устанавливаю libvips, потому что использую библиотеку bimg для сжатия изображений.
Вот мое мини-приложение Go:
package main
import (
"context"
"log"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/s3"
"github.com/h2non/bimg"
)
var (
s3Client *s3.Client
)
func init() {
cfg, err := config.LoadDefaultConfig(context.Background())
if err != nil {
log.Fatalf("failed to load AWS config: %v", err)
}
s3Client = s3.NewFromConfig(cfg)
}
func main() {
lambda.Start(Handler)
}
func Handler(ctx context.Context, event events.S3Event) error {
// compress and upload and do stuff
return nil
}
Я не только получаю ошибку exec /main: no such file or directory, когда пытаюсь протестировать лямбду с панели инструментов aws, но также выдает ту же ошибку, когда пытаюсь запустить образ на своем локальном компьютере с помощью следующей команды:
docker run --rm -it s3-image-compressor-lambda:latest
Я знаю, что лямбда-выражение не будет работать на моем локальном компьютере, но я считаю, что оно не должно говорить о том, что файл не найден, а, скорее, я ожидаю ошибку во время выполнения.
ОБНОВЛЕНИЕ: я добавил несколько команд в Dockerfile, чтобы попытаться отладить и посмотреть, что происходит.
Я добавил RUN ls -l / сразу после КОПИИ основного файла, и вот результат:
#16 [stage-1 4/7] RUN ls -l /
#16 0.354 total 18668
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 bin
#16 0.354 drwxr-xr-x 5 root root 340 Apr 4 22:28 dev
#16 0.354 drwxr-xr-x 1 root root 4096 Apr 4 22:28 etc
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 home
#16 0.354 drwxr-xr-x 7 root root 4096 Jan 26 17:53 lib
#16 0.354 -rwxr-xr-x 1 root root 19055376 Apr 4 22:06 main
#16 0.354 drwxr-xr-x 5 root root 4096 Jan 26 17:53 media
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 mnt
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 opt
#16 0.354 dr-xr-xr-x 459 root root 0 Apr 4 22:28 proc
#16 0.354 drwx------ 2 root root 4096 Jan 26 17:53 root
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 run
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 sbin
#16 0.354 drwxr-xr-x 2 root root 4096 Jan 26 17:53 srv
#16 0.354 dr-xr-xr-x 13 root root 0 Apr 4 22:28 sys
#16 0.354 drwxrwxrwt 2 root root 4096 Jan 26 17:53 tmp
#16 0.354 drwxr-xr-x 7 root root 4096 Jan 26 17:53 usr
#16 0.354 drwxr-xr-x 12 root root 4096 Jan 26 17:53 var
#16 DONE 0.4s
Итак, на самом деле в корневом каталоге есть основной файл.
После этого я добавил RUN /main, чтобы посмотреть, что произойдет, и вот результат:
> [stage-1 8/8] RUN /main:
0.258 /bin/sh: /main: not found
@Британцы, нет, к сожалению, не совсем. Чем больше я копаю глубже, тем больше понимаю, что это связано с libvips. Я не уверен на 100% в том, как работает связывание CGO в Go, но кажется, что когда я просто удаляю вторичное изображение и просто добавляю ENTRYPOINT к первому, проблема исчезает. Но, конечно, теперь проблема в том, что у меня огромный имидж, и я этого не хочу.
Попробуйте запустить ldd /main внутри контейнера (вы можете использовать docker exec -it <mycontainer> /bin/sh для запуска оболочки в контейнере); это должно сказать вам, чего не хватает.
Таких вопросов довольно много. Пожалуйста, укажите достаточно подробностей об отладке, чтобы показать, что это не дубликат. Например. stackoverflow.com/q/55106186/596285
@BMitch, похоже, проблема связана с динамическим связыванием. Мне нужно включить CGO при сборке, потому что библиотека bimg, которую я использую, динамически связывает libvips, но вторичное изображение не содержит исполняемые файлы libvips, отсюда и ошибка. Я довольно много изучал это при переполнении стека, но, полагая, что мысль о том, что это может быть связано с AWS Lambda, заставила меня пропустить вопрос, на который вы ссылались.
Ответы 1
FROM golang:1.21 as build
WORKDIR /app
RUN apt-get update
RUN apt-get install -y libvips libvips-dev
COPY go.mod go.sum main.go .
RUN go mod download
RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=1 go build \
-tags netgo \
-o main main.go
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libvips
COPY --from=build /app /app
ENTRYPOINT ["/app/main"]
Вот что я не смогу создать, если отключу CGO, потому что используемая мной библиотека bimg требует динамического связывания с libvips.
Ага! Хорошо, это важная информация.
Отвечает ли это на ваш вопрос? Ошибка запуска Docker: exec /app/backend/server: нет такого файла или каталога. В общем, попробуйте использовать
FROM golang:1.21-alpine as build(ошибка относится к библиотеке/main, а не к самой/main).