In this series of blog posts, we show how to put in place an optimized containerized Go development environment. In part 1, we explained how to start a containerized development environment for local Go development, building an example CLI tool for different platforms. Part 2 covered how to add Go dependencies, caching for faster builds and unit tests. This third and final part is going to show you how to add a code linter, a GitHub Action CI, and some extra build optimizations.
Adding a linter
We’d like to automate checking for good programming practices as much as possible so let’s add a linter to our setup. First step is to modify the Dockerfile:
# syntax = docker/dockerfile:1-experimentalFROM –platform=${BUILDPLATFORM} golang:1.14.3-alpine AS base WORKDIR /src ENV CGO_ENABLED=0 COPY go.* . RUN go mod download COPY . .FROM base AS build ARG TARGETOS ARG TARGETARCH RUN –mount=type=cache,target=/root/.cache/go-build GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /out/example .FROM base AS unit-test RUN –mount=type=cache,target=/root/.cache/go-build go test -v .FROM golangci/golangci-lint:v1.27-alpine AS lint-base
FROM base AS lintCOPY –from=lint-base /usr/bin/golangci-lint /usr/bin/golangci-lintRUN –mount=type=cache,target=/root/.cache/go-build –mount=type=cache,target=/root/.cache/golangci-lint golangci-lint run –timeout 10m0s ./…FROM scratch AS bin-unix COPY –from=build /out/example / …
We now have a lint-base stage that is an alias for the golangci-lint image which contains the linter that we would like to use. We then have a lint stage that runs the lint, mounting a cache to the correct place.
As for the unit tests, we can add a lint rule to our Makefile for linting. We can also alias the test rule to run the linter and unit tests:
all: bin/example test: lint unit-testPLATFORM=local.PHONY: bin/example bin/example: @docker build . –target bin –output bin/ –platform ${PLATFORM}.PHONY: unit-test unit-test: @docker build . –target unit-test.PHONY: lint lint: @docker build . –target lint
Adding a CI
Now that we’ve containerized our development platform, it’s really easy to add CI for our project. We only need to run our docker build or make commands from the CI script. To demonstrate this, we’ll use GitHub Actions. To set this up, we can use the following .github/workflows/ci.yaml file:
name: Continuous Integrationon: [push]jobs: ci: name: CI runs-on: ubuntu-latest env: DOCKER_BUILDKIT: “1” steps: – name: Checkout code uses: actions/checkout@v2 – name: Run linter run: make lint – name: Run unit tests run: make unit-test – name: Build Linux binary run: make PLATFORM=linux/amd64 – name: Build Windows binary run: make PLATFORM=windows/amd64
Notice that the commands we run on the CI are identical to those that we use locally and that we don’t need to do any toolchain configuration as everything is already defined in the Dockerfile!
One last optimization
Performing a COPY will create an extra layer in the container image which slows things down and uses extra disk space. This can be avoided by using RUN –mount and bind mounting from the build context, from a stage, or an image. Adopting this pattern, the resulting Dockerfile is as follows:
# syntax = docker/dockerfile:1-experimentalFROM –platform=${BUILDPLATFORM} golang:1.14.3-alpine AS base WORKDIR /src ENV CGO_ENABLED=0 COPY go.* . RUN go mod downloadFROM base AS build ARG TARGETOS ARG TARGETARCH RUN –mount=target=. –mount=type=cache,target=/root/.cache/go-build GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /out/example .FROM base AS unit-test RUN –mount=target=. –mount=type=cache,target=/root/.cache/go-build go test -v .FROM golangci/golangci-lint:v1.27-alpine AS lint-base
FROM base AS lintRUN–mount=target=. –mount=from=lint-base,src=/usr/bin/golangci-lint,target=/usr/bin/golangci-lint –mount=type=cache,target=/root/.cache/go-build –mount=type=cache,target=/root/.cache/golangci-lint golangci-lint run –timeout 10m0s ./…
FROM scratch AS bin-unix COPY –from=build /out/example /FROM bin-unix AS bin-linuxFROM bin-unix AS bin-darwinFROM scratch AS bin-windows
COPY –from=build /out/example /example.exeFROM bin-${TARGETOS} AS bin
The default mount type is a read only bind mount from the context that you pass with the docker build command. This means that you can replace the COPY . . with a RUN –mount=target=. wherever you need the files from your context to run a command but do not need them to persist in the final image.
Instead of separating the Go module download, we could remove this and just use a cache mount for /go/pkg/mod.
Conclusion
This series of posts showed how to put in place an optimized containerized Go development environment and then how to use this same environment on the CI. The only dependencies for those who would like to develop on such a project are Docker and make– the latter being optionally replaced by another scripting language.
You can find the source for this example on my GitHub: https://github.com/chris-crone/containerized-go-dev
You can read more about the experimental Dockerfile syntax here: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md
If you’re interested in build at Docker, take a look at the Buildx repository: https://github.com/docker/buildx
The post Containerize Your Go Developer Environment – Part 3 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/
Published by