Какие способы передачи исходного кода в Docker контейнер существуют

Что проверяют

Понимаете ли вы разницу между кодом, запечённым в образ при сборке, и кодом, примонтированным в работающий контейнер, и когда что уместно. Для Go следом почти всегда спрашивают про многоэтапную сборку и кэш зависимостей.

Как отвечать

При сборке образа:

• COPY из контекста сборки: пути считаются от контекста, а не от корня диска, лишнее отсекает .dockerignore;
• многоэтапная сборка: первая стадия на образе golang компилирует, финальная берёт только бинарник в gcr.io/distroless/static или scratch. С CGO_ENABLED=0 бинарник статический, и образ весит мегабайты вместо сотен мегабайт;
• порядок слоёв: сначала COPY go.mod go.sum ./ и RUN go mod download, потом COPY . .. Правка кода не трогает слой с зависимостями;
• монтирования BuildKit: RUN --mount=type=cache,target=/go/pkg/mod и такой же кэш для /root/.cache/go-build, --mount=type=bind, чтобы не копировать исходники в слой, --mount=type=ssh или type=secret для приватных модулей;
• контекст из Git: docker build принимает URL репозитория, а ADD в BuildKit умеет клонировать репозиторий без git внутри образа.

В работающий контейнер:

• bind mount: docker run -v "$PWD":/app или volumes в Compose, вместе с air для пересборки при изменении файлов. Только для локальной разработки;
• docker compose watch: секция develop.watch, для компилируемого Go обычно действие rebuild;
• docker cp: разовая подкладка файла при отладке.

Где спотыкаются

Пишут COPY . . до скачивания модулей. Любая правка кода сбрасывает кэш, и go mod download выполняется при каждой сборке заново.

Клонируют приватный репозиторий с токеном в ARG или ENV. Токен остаётся в метаданных образа и виден через docker history, для секретов есть --mount=type=secret.

Тащат в прод образ golang с исходниками и компилятором. Он весит сотни мегабайт, расширяет поверхность атаки, а без .dockerignore туда же попадают .git и локальные .env.