Downloading Golang dependencies from a kubernetes pod behind a corporate proxy

user_10997760 0
Viewed 63

We are starting out the journey of moving our code to Golang. While deploying our first demo service on kubernetes pod we faced a problem with downloading Go dependencies. Kubernetes pod, where the go code is deployed, is behind a corporate proxy so for outbound access we need to whitelist the domains.

In Kubernetes deployment file we add proxy to download dependencies and as soon as the Docker image is built we remove the proxy to eliminate outbound calls.

This is how the Dockerfile looks like :

FROM {Repository-manager}/golang-base:1.16-alpine

WORKDIR /app

COPY go.mod .
COPY go.sum .

RUN go mod download

ADD . .

EXPOSE 5000

RUN go build -o demo cmd/main.go

CMD ["./demo"]

For other languages like node and python there were package managers like npm and pypi which were used to download the dependencies. But most packages for golang are on several domsins like github.com, goland.org etc.


Is there any way to download the dependencies behind the corporate proxies without having to whitelist all the domains in go.sum and go.mod ? What is the preferred and correct way to deploy and run golang code behind proxy?

TIA!

kubernetes docker go proxy
1 Answers

Assuming you need to supply to modules for building you can download the modules. Below is excerpt from go documentation

go mod vendor Usage: go mod vendor [-e] [-v] [-o] The go mod vendor command constructs a directory named vendor in the main module’s root directory that contains copies of all packages needed to support builds and tests of packages in the main module. Packages that are only imported by tests of packages outside the main module are not included. As with go mod tidy and other module commands, build constraints except for ignore are not considered when constructing the vendor directory. When vendoring is enabled, the go command will load packages from the vendor directory instead of downloading modules from their sources into the module cache and using packages those downloaded copies. See Vendoring for more information. go mod vendor also creates the file vendor/modules.txt that contains a list of vendored packages and the module versions they were copied from. When vendoring is enabled, this manifest is used as a source of module version information, as reported by go list -m and go version -m. When the go command reads vendor/modules.txt, it checks that the module versions are consistent with go.mod. If go.mod changed since vendor/modules.txt was generated, go mod vendor should be run again. Note that go mod vendor removes the vendor directory if it exists before re-constructing it. Local changes should not be made to vendored packages. The go command does not check that packages in the vendor directory have not been modified, but one can verify the integrity of the vendor directory by running go mod vendor and checking that no changes were made. The -e flag (added in Go 1.16) causes go mod vendor to attempt to proceed despite errors encountered while loading packages. The -v flag causes go mod vendor to print the names of vendored modules and packages to standard error. The -o flag (added in Go 1.18) causes go mod vendor to output the vendor tree at the specified directory instead of vendor. The argument can be either an absolute path or a path relative to the module root.*

user_66966840
Related