Как предотвратить повторную загрузку сборки docker скопированным поставщиком Go

# #docker #go #caching

Вопрос:

Я пытаюсь ускорить Dockerfile запуск , копируя весь каталог (в том числе vendor , потому что повторная загрузка зависимостей заняла более 10 м в стране третьего мира, где я живу), но когда я пытался запустить его, он всегда снова и снова загружал поставщика, go mod vendor в отличие от локального:

 FROM golang:1.14-alpine AS builder
RUN apk --update add ca-certificates git make g  
ENV GO111MODULE=on

WORKDIR /app

RUN go get github.com/go-delve/delve/cmd/dlv

COPY . .

RUN go mod vendor

ARG COMMIT_HASH
ENV COMMIT_HASH=${COMMIT_HASH}
ARG BUILD_DATE
ENV BUILD_DATE=${BUILD_DATE}

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 
    go build 
    -o app

FROM golang:1.14-alpine

WORKDIR /app

COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
COPY --from=builder /go/bin/dlv /
COPY --from=builder /app/app .
COPY --from=builder /app/db ./db
EXPOSE 8080 63342
CMD [ "/dlv", "--listen=:63342", "--headless=true", "--api-version=2", "--accept-multiclient", "exec", "./app" ]
 

ранее использование этого (без поставщика) также было медленным:

 COPY go.mod .
COPY go.sum .
RUN go mod download -x
COPY . .
 

попытка с этим также не сработала:

 COPY vendor /go/pkg/mod
COPY vendor /go/pkg/mod/cache/download
COPY go.mod .
COPY go.sum .

RUN go mod download -x

COPY . .
 

как заставить его использовать скопированный каталог поставщиков вместо повторной загрузки снова и снова?

таким образом, ожидаемое поведение:

  1. когда у местных есть vendor (используется go mod vendor ), docker build он должен использовать его
  2. но когда на CI (поскольку vendor/*/* он не привязан к репо) или разработчику, у которого его нет vendor/*/* , вероятно, следует перезагрузить все (мне все равно, так как у них хорошая пропускная способность).

go mod vendor команда предназначена для CI и разработчиков, которые не использовали go mod vendor

Комментарии:

1. Разве вы не можете просто смонтировать ${GOPATH}/pkg/mod и позволить артефактам накапливаться на вашем бегуне? Торговля ощущается как шаг назад.

2. как тебе это? @Zyl ты имеешь в виду докер-композитор? это не работает для многоступенчатой сборки

3. Если «КОПИРОВАТЬ go.mod .; КОПИРОВАТЬ go.sum .; ЗАПУСТИТЬ загрузку go mod-x» выполняется медленно, то кэш слоя изображений docker не поражается. Он даже не выполнит загрузку «go mod», если слой уже существует.

4. да, о чем я думаю, так это о step backward повторной загрузке всей зависимости, даже если она изменена лишь частично

Ответ №1:

go mod vendor загружайте зависимость только из сети, если зависимость не готова в локальной сети. В противном случае он просто скопирует зависимость в папку vendor без доступа к сети. Итак, здесь ваша проблема связана с go mod cache невозможностью повторного использования во время многократной сборки.

В качестве решения вы можете использовать решение для кэширования buildkit, далее приведен минимальный пример:

главное.вперед:

 package main

import _ "github.com/jeanphorn/log4go"

func main() {
}
 

Докерфайл:

 # syntax = docker/dockerfile:1.3
FROM golang:1.14-alpine AS builder

RUN apk --update add git

ENV GO111MODULE=on
WORKDIR /app

COPY main.go /app

RUN go mod init hello

RUN --mount=type=cache,mode=0755,target=/go/pkg/mod go get github.com/go-delve/delve/cmd/dlv amp;amp; go get github.com/jeanphorn/log4go
RUN --mount=type=cache,mode=0755,target=/go/pkg/mod go mod vendor
 

1-я казнь:

 $ export DOCKER_BUILDKIT=1
$ docker build --progress=plain -t abc:1 . --no-cache
#16 [builder 6/7] RUN --mount=type=cache,mode=0755,target=/go/pkg/mod go get github.com/go-delve/delve/cmd/dlv amp;amp; go get github.com/jeanphorn/log4go
#16 sha256:ae394bc67787799808175eada48c5f4e09101b6e153d535ddb5e4040fbf74395
#16 1.941 go: downloading github.com/go-delve/delve v1.7.1
#16 4.296 go: found github.com/go-delve/delve/cmd/dlv in github.com/go-delve/delve v1.7.1
......
#16 23.78 go: finding module for package github.com/toolkits/file
#16 23.96 go: downloading github.com/toolkits/file v0.0.0-20160325033739-a5b3c5147e07
#16 24.17 go: found github.com/toolkits/file in github.com/toolkits/file v0.0.0-20160325033739-a5b3c5147e07
#16 DONE 27.3s
 

2-е исполнение:

 $ export DOCKER_BUILDKIT=1
$ docker build --progress=plain -t abc:1 . --no-cache
#15 [builder 6/7] RUN --mount=type=cache,mode=0755,target=/go/pkg/mod go get github.com/go-delve/delve/cmd/dlv amp;amp; go get github.com/jeanphorn/log4go
#15 sha256:bee74f92ceb79cce449b9702c892cb39815461981838f6b63d500414be87c21d
#15 1.467 go: found github.com/go-delve/delve/cmd/dlv in github.com/go-delve/delve v1.7.1
#15 7.511 go: github.com/jeanphorn/log4go upgrade => v0.0.0-20190526082429-7dbb8deb9468
#15 7.533 go: finding module for package github.com/toolkits/file
#15 7.675 go: found github.com/toolkits/file in github.com/toolkits/file v0.0.0-20160325033739-a5b3c5147e07
#15 DONE 8.7s
 

Вы могли видеть golang mod cache , что сгенерированный 1-м запуском уже повторно используется 2-м запуском без загрузки из Интернета, теперь он действует так же, как и при выполнении на хосте.

ПРИМЕЧАНИЕ: Я не предлагал напрямую привязывать какой-либо кэш на хосте к контейнеру, я думаю, это не портативно.

Комментарии:

1. эй, подожди, но это не сработает на CI, верно?

2. о, неважно :3 BuildKit has been integrated to docker build since Docker 18.06 .