Golang dev environments with Docker

<p>How are developers setting up their dev environments for Golang with Docker? I setup a multi-stage Docker file, but then it seems i have to build the container every time I want to try out my changes. Is this the best practice or is there a better way?</p> <pre><code>FROM golang:1.9.2 as builder RUN mkdir -p /go/src/github.com/mycompany/myapp WORKDIR /go/src/github.com/mycompany/myapp RUN go get github.com/aws/aws-sdk-go/aws \ github.com/aws/aws-sdk-go/aws/session COPY app/ . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --from=builder /go/src/github.com/mycompany/myapp . CMD [&#34;./app&#34;]` </code></pre> <hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>I would develop and test as much as I can outside a container and run the Dockerfile only for deploying the tested binary to a staging or production environment.</p></pre>SeerUD: <pre><p>I think a lot of people just don&#39;t develop in a Docker container. If you are really set on doing it, I&#39;d look into mounting your code in a running container as a volume, and using some kind of file-watcher that triggers a rebuild and a restart of a process, otherwise you&#39;re going to be hampering your productivity.</p> <p>Have tests, run them in your Docker container when you build it, and then otherwise develop locally is what I&#39;d recommend. Unless of course you&#39;re testing something that&#39;s Linux-specific and you work on a Mac say, then I&#39;d go with what I said in the paragraph above.</p> <p>People may argue that that would be doing it &#34;wrong&#34; because you wouldn&#39;t be using the same image as what you&#39;d use in production. I try to find a balance. Get as close as possible without impacting productivity. So, if possible, I&#39;d use the same base image, same Go version, etc. and the rest would be &#34;close enough&#34; whilst remaining a productive environment to work in.</p></pre>earthboundkid: <pre><p>No need to <code>mkdir</code>. <a href="https://docs.docker.com/engine/reference/builder/#workdir" rel="nofollow">From the docs</a>:</p> <blockquote> <p>If the <code>WORKDIR</code> doesn’t exist, it will be created even if it’s not used in any subsequent <code>Dockerfile</code> instruction.</p> </blockquote></pre>Redundancy_: <pre><p>I don&#39;t really like to run &#34;go get&#34; inside a build process, since it&#39;s not going to be repeatable, and that slows things down each time.</p></pre>hell_0n_wheel: <pre><blockquote> <p>i have to build the container every time I want to try out my changes</p> </blockquote> <p>That just sounds like you aren&#39;t using Docker efficiently.</p> <blockquote> <p>Is this the best practice or is there a better way?</p> </blockquote> <p>Dunno about best practice, but Docker seems a bit heavyweight for golang. Go does not (yet) reach so far into the OS that you need to partition off a virtual root image just to isolate one installation from another. A directory all one needs for containment; set <code>$GOPATH</code> and <code>$GOROOT</code> accordingly and you&#39;re off to the races.</p> <p>GOPATH allows you to specify dependencies that are unique to your project GOROOT allows you to choose a specific golang installation to build and run your project</p> <p>Easy peasy. Use something like <code>direnv</code> to switch your GOPATH / GOROOT as you change projects, and the switching is seamless.</p></pre>earthboundkid: <pre><p>If you use dep, there&#39;s no need to switch GOPATH between projects, because all your dependencies&#39; code is in the vendor subdirectory.</p> <p>There&#39;s never a reason to touch GOROOT unless you&#39;re developing Go itself and have multiple versions installed.</p></pre>hell_0n_wheel: <pre><blockquote> <p>There&#39;s never a reason to touch GOROOT...</p> </blockquote> <p>You&#39;re forgetting when one develops services written against multiple versions of Go. Ideally, we&#39;d all run the latest and greatest, but we can&#39;t pivot Go versions on a dime...</p></pre>earthboundkid: <pre><p>But each binary should know where its own root is, no? I thought that was baked into the build. </p></pre>hell_0n_wheel: <pre><p>Huh? A binary doesn&#39;t need a root.</p></pre>earthboundkid: <pre><p>GO_ROOT is baked into <code>go</code> AFAIK. </p></pre>