<div dir="ltr"><div>I think the goals of minimizing the size (and attack
surface) of docker images and using CentOS to maintain compatibility
with legacy infrastructure are mutually exclusive.<br>Perhaps a hybrid approach?<br><br> - use a minimal image for development and local testing<br>
- run your "outer loop" integration and/or functional tests in docker
containers optimized for similarity to existing deployment
infrastructure in CI<br><br><br></div>The smallest python docker images I've found so far are based on <a href="https://github.com/gliderlabs/docker-alpine">https://github.com/gliderlabs/docker-alpine</a>:<br><br> - <a href="https://github.com/frol/docker-alpine-python2">https://github.com/frol/docker-alpine-python2</a><br><div> - <a href="https://github.com/frol/docker-alpine-python3">https://github.com/frol/docker-alpine-python3</a><br><br></div><div>However, building dependencies in alpine can be challenging, and going with a Debian base image is a popular option that is a decent compromise between size and ease of use.<br>The main thing I've been looking at to address build dependency issues is <a href="http://conda.pydata.org/">Conda</a>, specifically their <a href="https://github.com/ContinuumIO/docker-images/blob/master/miniconda/Dockerfile">miniconda docker base image</a>, coupled with either their hosted <a href="https://binstar.org/">Binstar</a> service or a self-hosted <a href="http://conda.pydata.org/docs/custom-channels.html">custom channel</a>. The beauty of that approach is that the built packages could also be used outside of Docker in production deployments, meaning that production webheads and admin nodes would no longer need build dependencies, just binaries.<br><br></div><div>Josh<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 11:06 AM, Gregory Szorc <span dir="ltr"><<a href="mailto:gps@mozilla.com" target="_blank">gps@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You've touched on a reason why the Dockerfile model of building images "from within" is sub-optimal. In addition to size, all those extra binaries sitting around inside the container provide an increased attack surface an attacker can leverage to construct a more effective attack once the container is compromised. e.g. why should your container have a shell and be exploitable to things like shellshock when nothing in your container requires a shell?<br><br></div>I see this culminating with container best practices consisting of building images externally. Unfortunately, Docker doesn't itself seem to be showing leadership here. Instead, look towards efforts like RedHat's Project Atomic to enable this.<br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, May 21, 2015 at 7:25 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word">I’ve been investigating the reason why some of our repos are so large and one reason is that they do all the building of the packages and hence need gcc and all the gubbins that comes along with that.<div><br></div><div>On Centos, our base image of 200MB balloons to well over a gig with just a few yum installs for weird reasons [1], including the addition of gcc etc. That got me thinking that the best way to do that is to get an end point for some of the key base packages so we can pre build them and then share them. A nice small Python, for starters.</div><div><br></div><div>We’ve kind of got one for Marketplace:</div><div><br></div><div><a href="https://github.com/mozilla/marketplace-env/blob/master/mkt/data/base-images/python27/yum/mkt.repo" target="_blank">https://github.com/mozilla/marketplace-env/blob/master/mkt/data/base-images/python27/yum/mkt.repo</a></div><div><br></div><div>But its getting out of date, I’d like to add packages to it and make one we can all use.</div><div><br></div><div>Does one of these exist already and I’m missing it? </div><div><br></div><div>We’d like to use CentOS if possible since for us, thats the closest to whats being run on prod in our non-dockerised deployments.</div><div><br></div><div>[1] <a href="https://github.com/mozilla/solitude/issues/425#issuecomment-104132736" target="_blank">https://github.com/mozilla/solitude/issues/425#issuecomment-104132736</a></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">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>