# #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 . .
как заставить его использовать скопированный каталог поставщиков вместо повторной загрузки снова и снова?
таким образом, ожидаемое поведение:
- когда у местных есть
vendor
(используетсяgo mod vendor
),docker build
он должен использовать его - но когда на 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 .