Need suggestions with build process

<p>The setup is something like this:</p> <ul> <li><p>I have multiple Go web services developed as separate projects and in separate repos.</p></li> <li><p>Each of them will should be run and deployed as Docker containers.</p></li> <li><p>There is a common library that has some code used by all the services, stuff like logging, middleware, database access, etc.</p></li> </ul> <p>Question: How do I build those services, in their containers, when common library is hosted on a private repo?</p> <p>I know general Go concensus is to vendor all dependencies, but with increasing number of services, it becomes a hindrance. GB is great tool for this, but restoring dependencies from a private repo would require ssh keys inside my containers. I could copy/paste them to each new service. Is this a good approach?</p> <p>If the common lib was on a public repo, I could easily go get it from Dockerfile.</p> <p>Other approach I thought of is to make a Docker image with common library preinstalled on $GOPATH, and use that base image for all other containers. But that would require me to push/pull new image each time common library is updated. Is this a good approach?</p> <p>Finally, is there something else that is painfully obvious and can make this simpler? Ideally I would like to build services as static binaries and run them in empty containers. I am not very experienced with &#34;ops&#34; part of &#34;devops&#34;. :) Thanks for the help!</p> <hr/>**评论：**<br/><br/>egonelbre: <pre><p>Why do you want to build it in the containers? Just build them outside . e.g. <a href="https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/" rel="nofollow">https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/</a></p> <p>Also, have a single repo for all of your services and common and vendored things.</p></pre>kortemy: <pre><p>I&#39;ve read that article before, therefore the idea for static binaries. I could always automate something like that in production, but what about local development?</p> <p>More importantly, why single repo? I want to keep development of each service decoupled from the other. Since they are, in fact, decoupled. And working with many feature branches on a single repo is not a way to go.</p></pre>egonelbre: <pre><blockquote> <p>... but what about local development?</p> </blockquote> <p>Don&#39;t run them in Docker.</p> <blockquote> <p>More importantly, why single repo?</p> </blockquote> <p>It helps to coordinate changes to the service setup. <a href="https://www.youtube.com/watch?v=W71BTkUbdqE" rel="nofollow">see this</a></p> <p>If the services are truly independent (e.g. a random set of different service versions works) then, yes, by all means keep them in separate repos.</p> <blockquote> <p>And working with many feature branches on a single repo is not a way to go.</p> </blockquote> <p>Why do you have many features branches in the first place? It adds <a href="http://www.davefarley.net/?p=160" rel="nofollow">maintenance overhead</a>. If you mean by &#34;in-development branches&#34;, have only one --&gt; unfinished features don&#39;t have value, hence there is no point making many of them.</p></pre>ecmdome: <pre><p>If you must build inside the container(it&#39;s not necessarily bad, also great for development) </p> <p>I have a bash script that runs, and instead of using go get, I just use git clone in order to get the repo I&#39;m looking for and even git checkout to get to a particular branch or commit.</p></pre>