Двоичный файл, скомпилированный Go, не будет работать в контейнере alpine docker на хосте Ubuntu

По умолчанию при использовании пакета net сборка, скорее всего, создаст двоичный файл с некоторой динамической компоновкой, например. к libc. Вы можете проверить динамическую или статическую ссылку, просмотрев результат ldd output.bin

Есть два решения, с которыми я столкнулся:

• Отключить CGO через CGO_ENABLED=0
• Принудительно использовать реализацию сетевых зависимостей Go, netgo через go build -tags netgo -a -v, это реализовано для определенных платформ

Из https://golang.org/doc/go1.2:

Пакет net по умолчанию требует cgo, потому что операционная система хоста должна в целом выполнять настройку сетевых вызовов. Однако в некоторых системах можно использовать сеть без cgo, и это полезно, например, чтобы избежать динамического связывания. Новый тег сборки netgo (по умолчанию отключен) позволяет создавать пакеты net на чистом Go в тех системах, где это возможно.

Вышеприведенное предполагает, что единственной зависимостью CGO является пакет net стандартной библиотеки.

У меня была такая же проблема с бинарным файлом go, и я заставил его работать после добавления этого в мой файл докера:

RUN apk add --no-cache \ libc6-compat

Компилятор Go с вашей сборочной машины, вероятно, связывает ваш двоичный файл с библиотеками в другом месте, чем в Alpine. В моем случае он был скомпилирован с зависимостями в /lib64, но Alpine не использует эту папку.

FROM alpine:edge AS build
RUN apk update
RUN apk upgrade
RUN apk add --update go=1.8.3-r0 gcc=6.3.0-r4 g++=6.3.0-r4
WORKDIR /app
ENV GOPATH /app
ADD src /app/src
RUN go get server # server is name of our application
RUN CGO_ENABLED=1 GOOS=linux go install -a server

FROM alpine:edge
WORKDIR /app
RUN cd /app
COPY --from=build /app/bin/server /app/bin/server
CMD ["bin/server"]

Я работаю над статьей об этой проблеме. Вы можете найти проект с этим решением здесь http://kefblog.com/2017-07-04/Golang-ang-docker .

Что мне помогло, так это включение статической ссылки в параметрах компоновщика:

$ go build -ldflags '-linkmode external -w -extldflags "-static"'

Параметр -linkmode указывает Go использовать внешний компоновщик, параметр -extldflags устанавливает параметры для передачи компоновщику, а флаг -w отключает отладочную информацию DWARF для улучшения размера двоичного файла.

См. go tool link и статически скомпилированные программы Go, всегда, даже с cgo, с использованием musl Больше подробностей

При выполнении бинарного файла go внутри контейнера докеров Debian столкнулся с этой проблемой: /bin/bash: line 10: /my/go/binary: No such file or directory

Бинарный файл был собран с помощью docker-in-docker (dind) из контейнера alpine с помощью команды: GOOS=linux GOARCH=amd64 go build

Исправлено это с помощью следующей среды при сборке бинарника: CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build

У меня было приложение, которое требовало CGO_ENABLED=1.

Исправление для запуска скомпилированного двоичного файла go в контейнере debian-slim состояло в том, чтобы собрать двоичный файл с использованием RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=1 go build -o goapp

И выполните следующие команды в Debian Slim

RUN apt-get update && apt-get install -y musl-dev
RUN ln -s /usr/lib/x86_64-linux-musl/libc.so /lib/libc.musl-x86_64.so.1

После этого я смог запустить goapp

СОВЕТ: ldd goapp показал, что в контейнере отсутствует libc.musl-x86_64.