How does this Docker command, which makes a small GoLang container, work?

New to docker here. I followed the instructions here to make a slim & trim container for my Go Project. I do not fully understand what it's doing though, hopefully someone can enlighten me.

Specifically there are two steps to generating this docker container.

1. docker run --rm -it -v "$GOPATH":/gopath -v "$(pwd)":/app -e "GOPATH=/gopath" -w /app golang:1.8 sh -c 'CGO_ENABLED=0 go build -a --installsuffix cgo --ldflags="-s" -o hello'
2. docker build -t myDockerImageName .

The DockerFile itself just contains

FROM iron/base
WORKDIR /app
COPY hello /app/
ENTRYPOINT ["./hello"]

I understand (in a broad sense) that the 1st step is compiling the go program and statically linking the C-dependencies (and doing all this inside an unnamed docker container). The 2nd step just generates the docker image according to the instructions in the DockerFile.

What I don't understand is why the first command starts with docker run (why does it need to be run inside a docker container? Why are we not just generating the Go binary outside of it, and then copying it in?)

And if it's being run inside a docker container, how is binary generated in the docker container being dropped on my local machine's file system?(e.g. why do I need to copy the binary back into the image - as it seems to be doing on line 3 of the DockerFile?)

You're actually using 2 different docker containers, each with a different image. The first container is only around during the compilation... it uses the image golang:1.8. What you're doing is mounting your current working directory into that image and compiling it with the version of GO contained in the image.

The second command builds your custom image that uses the iron/base image as its base. You then copy your built application into that image and run it.

Using a golang container to build the binary is usually done for reproducibility of the build process, i.e.:

• it ensures that always the same Go version is used,
• compilation takes place in an alway clean environment,
• and the build host needs no Go installed at all, or can have a different version,

This way, all parts needed to build the "hello" image can be tracked in a version control system.

However, this example mounts the whole local GOPATH, defeating above purpose. Dependencies must be available to the build container, e.g. by vendoring them. Maybe the author considered vendoring out of scope for his example.

(note: this should be a comment, but my reputation does not allow that)