<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 January 2015 at 22:59, Jared Kerim <span dir="ltr"><<a href="mailto:jkerim@mozilla.com" target="_blank">jkerim@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is there a major reason that this build process can't be done at the docker level, capture a version of the container, push it to a docker repo (our own or dockerhub) and then have the AWS instance deploys just pull down the already built containers?</div></blockquote><div><br></div><div><br></div><div>The main reason this a problem on the marketplace 
container builds is that if you're copying the deps file 
(requirements.txt / package.json) and then building off of that - the 
ADD/COPY step will cache-bust the layer created by installing the deps 
when the file changes. This means if one dep is added the entire dep 
install process happens again because that layer needs to be recreated. You could split out all the dep installs into single lines in the docker file so each dep created a FS layer but given the amount of deps in some cases that will quickly get hard to maintain.<br><br></div><div>For more background here's a summary of all the other approaches we've been thinking about for the marketplace env:<br></div><div><br><br></div><div>The zip of cached deps approach was inspired by the way travis handle deps caching in their new container based environment. It seems straightforward enough but does mean you've got to maintain/automate the tarballs. This is something we could certainly build into our wrappers.<br><br></div><div>Another alternative we've been thinking about was whether to create 
an ancestor image that the has the deps installed for which the build 
could be automated on dep changes. That should mean that adding one dep in the child's Dockerfile only installs that one new thing at build time.<br><br>I'd hoped to cache deps on a data volume at build time but
 as yet I've not seen a way to do that. Volumes are only added at run time not 
build time. If we moved the pip/npm deps installation into runtime we'd be able to cache onto a data container which would speed things up much more plus leave the data around for all other containers, but then this feels like this goes against the strengths of docker.<br></div><div><br></div><div>Lastly another approach would be to use something like <a href="https://www.npmjs.com/package/angry-caching-proxy">https://www.npmjs.com/package/angry-caching-proxy</a> and use the HTTP_PROXY env var to point docker at that for network access. The downsides are it would require forcing non-ssl connections to npm etc (not terrible for a dev-env, but not ideal)<br></div><div><br></div><div>It definitely feels like there should be an easier way. <br><br></div><div>Regards,<br><br>Stuart.<br></div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Fri, Jan 16, 2015 at 5:51 PM, Andy McKay <span dir="ltr"><<a href="mailto:amckay@mozilla.com" target="_blank">amckay@mozilla.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div style="word-wrap:break-word">In the Marketplace docker files we have lines that run pip [1], bower or npm [2]. One of the main problems is this is slow, we get real perf problems on building out containers on AWS.<div><br></div><div>The suggested way I think to do this is build out all the requirements, zip them and stick them somewhere. Then instead use an ADD [3] command to pull the file down (which can be a URL).</div><div><br></div><div>So now I’ve got find a way to build those zip files, store them, make sure I get the right version and so on. That does feel like I’m reinventing a wheel here. Before I do that, is there a better way?<br><div><br></div><div><br></div><div>[1] <a href="https://github.com/mozilla/zamboni/blob/master/Dockerfile#L28" target="_blank">https://github.com/mozilla/zamboni/blob/master/Dockerfile#L28</a></div><div>[2] <a href="https://github.com/mozilla/fireplace/blob/master/Dockerfile#L15-L16" target="_blank">https://github.com/mozilla/fireplace/blob/master/Dockerfile#L15-L16</a></div><div>[3] <a href="https://docs.docker.com/reference/builder/#add" target="_blank">https://docs.docker.com/reference/builder/#add</a> </div></div></div><br></div></div>_______________________________________________<br>
Dev-docker mailing list<br>
<a href="mailto:Dev-docker@mozilla.org" target="_blank">Dev-docker@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-docker" target="_blank">https://mail.mozilla.org/listinfo/dev-docker</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Dev-docker mailing list<br>
<a href="mailto:Dev-docker@mozilla.org" target="_blank">Dev-docker@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-docker" target="_blank">https://mail.mozilla.org/listinfo/dev-docker</a><br>
<br></blockquote></div><br></div></div>