<p>I have a project with two services that each depend on a shared database library. It seems like the best practice is 1 Dockerfile per service, but since my project is in a private repo, <code>go get</code>ing the database library seems overly complicated (how to authenticate from Dockerfile without version controlling credentials, for example?) and I can't <code>ADD ../database</code> because it's not a subdirectory. I don't want to have to vendor the database lib into the service directories because I'm going to be rapidly iterating on all three (the two services and the db lib) codebases and updating the vendor directories every time the lib changes seems inhibiting. What's the best way to do this?</p>
<hr/>**评论：**<br/><br/>bmurphy1976: <pre><p>You need to create a third container that acts as the "base" of both of your service containers. e.g.</p>
<p>common.Dockerfile:</p>
<pre><code>FROM whatever
RUN go get databaselibrary
</code></pre>
<p>service1.dockerfile:</p>
<pre><code>FROM common
RUN go build service1
</code></pre>
<p>service2.dockerfile:</p>
<pre><code>FROM common
RUN go build service2
</code></pre>
<p>Alternatively, you could just ensure the first few statements in service1.dockerfile and servic2.dockerfile are <em>exactly</em> the same and docker will cache and share the common layers between both images.</p></pre>weberc2: <pre><p>I think maybe the import syntax for referring to the common dockerfile is bad. I'm getting the following error when I try to build.</p>
<p><code>
Step 0 : FROM common
</code></p>
<p><code>
Pulling repository docker.io/library/common
</code></p>
<p><code>
Error: image library/common:latest not found
</code></p></pre>bmurphy1976: <pre><p>Have you built it? You have to build it first, e.g:</p>
<pre><code>docker build -f common.dockerfile -t common
docker build -f service1.dockerfile -t service1
docker build -f service2.dockerfile -t service2
</code></pre></pre>vruzz: <pre><p>Put the database in its own container, write a service that does all the database access (some databases like CouchDB and MongoDB already come with a REST API for that).
You may want to take a look at this presentation on microservice patterns and anti-patterns.
<a href="https://twitter.com/_holographer_/status/678291256322220032" rel="nofollow">https://twitter.com/_holographer_/status/678291256322220032</a></p>
<p>Here are the slides if you want to browse them quickly
<a href="https://twitter.com/_holographer_/status/678007334019448832" rel="nofollow">https://twitter.com/_holographer_/status/678007334019448832</a></p>
<p>See slide 26, the "data pump" pattern.
Hope that helps.</p></pre>XANi_: <pre><p>lol they lie about competition(zeromq footprint) then dont show one that is faster than them on comparision ( again, zeromq )</p></pre>weberc2: <pre><p>I'd really like to avoid turning a library into a service just to accommodate Docker. It seems like it should be easy to build two containers with a shared dependency library. Maybe it's possible to put multiple dockerfiles (one per service) at the repo root so they can both use the shared library?</p></pre>bmurphy1976: <pre><p>He said "database library", not database. Your solution is overcomplicating a very simple problem.</p></pre>TweetsInCommentsBot: <pre><p><a href="https://twitter.com/_holographer_/" rel="nofollow"><strong>@_holographer_</strong></a></p>
<blockquote>
<p><a href="https://twitter.com/_holographer_/status/678291256322220032" rel="nofollow">2015-12-19 19:10 UTC</a></p>
<p>Powered by @nats_io : Integration Patterns for #Microservices Architectures, by @DavWilliams <a href="https://www.youtube.com/watch?v=f5gZdK8ir4M" rel="nofollow">https://www.youtube.com/watch?v=f5gZdK8ir4M</a> #natsio</p>
</blockquote>
<hr/>
<p><a href="https://twitter.com/_holographer_/" rel="nofollow"><strong>@_holographer_</strong></a></p>
<blockquote>
<p><a href="https://twitter.com/_holographer_/status/678007334019448832" rel="nofollow">2015-12-19 00:21 UTC</a></p>
<p>Don't. #natsio #microservice #integration #patterns #antipatterns <a href="http://www.slideshare.net/Apcera/integration-patterns-and-antipatterns-for-microservices-architectures" rel="nofollow">http://www.slideshare.net/Apcera/integration-patterns-and-antipatterns-for-microservices-architectures</a> </p>
<p><a href="http://pbs.twimg.com/media/CWjEE7MXIAIoR2m.jpg" rel="nofollow">[Attached pic]</a> <a href="http://i.imgur.com/TymoVPg.jpg" rel="nofollow">[Imgur rehost]</a></p>
</blockquote>
<hr/>
<p><sup>This</sup> <sup>message</sup> <sup>was</sup> <sup>created</sup> <sup>by</sup> <sup>a</sup> <sup>bot</sup></p>
<p><a href="http://np.reddit.com/message/compose/?to=jasie3k&amp;subject=TweetsInCommentsBot" rel="nofollow"><sup>[Contact</sup> <sup>creator]</sup></a><a href="https://github.com/janpetryk/reddit-bot" rel="nofollow"><sup>[Source</sup> <sup>code]</sup></a></p></pre>Krish442: <pre><p>Take a look at <a href="https://github.com/tools/godep" rel="nofollow">godep</a>. It would sort of vendorize your database library, but make it much easier to update. I know you said you didn't want to vendorize the library, but since you'll need to trigger a new build of the docker image when your database library changes, it wouldn't be that much harder to ask godeps to update your library and then rebuild. Plus, then you'll have a way to track and revert in version control if something in your library breaks your other code, and you'll have totally reproducible builds.</p></pre>XANi_: <pre><p>you can use api key embedded in https url to download private github repo without asking for password</p>
<p>but it isnt very secure as API keys permissions are very broad</p></pre>intermernet: <pre><p>I do this, and also use build arguments when building the docker container. e.g. <code>docker build --build-arg GH_API_TOKEN=insertgithubtokenhere</code>.</p>
<p>You can generate a one-off token for the purposes of building using the <a href="https://developer.github.com/v3/oauth_authorizations/#create-a-new-authorization" rel="nofollow">Github "Authorizations" API endpoint</a>. The API can also be used to delete the token after use.</p></pre>XANi_: <pre><p>My biggest problem with it is lack of access to private repos read-only and no ability to grant access to single repo. </p></pre>
