<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 21, 2015, at 1:56 PM, Josh Mize <<a href="mailto:jmize@mozilla.com" class="">jmize@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class="">Perhaps a hybrid approach?<br class=""></div></div></div></blockquote><div><br class=""></div><div>Perhaps. I feel like the main concern is trying to maintain Docker images for developers, that don’t go into production. It’s so tempting just to keep throwing things into the containers and they keep growing. It’s easy to justify not adding Emacs to a production container.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> - use a minimal image for development and local testing</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">
- run your "outer loop" integration and/or functional tests in docker
containers optimized for similarity to existing deployment
infrastructure in CI<br class=""></div></div></div></blockquote><div><br class=""></div><div>I think the idea of having multiple Dockerfiles is something we will probably have to do.</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>The smallest python docker images I've found so far are based on <a href="https://github.com/gliderlabs/docker-alpine" class="">https://github.com/gliderlabs/docker-alpine</a>:<br class=""><br class=""> - <a href="https://github.com/frol/docker-alpine-python2" class="">https://github.com/frol/docker-alpine-python2</a><br class=""><div class=""> - <a href="https://github.com/frol/docker-alpine-python3" class="">https://github.com/frol/docker-alpine-python3</a><br class=""><br class=""></div><div class="">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 class="">The main thing I've been looking at to address build dependency issues is <a href="http://conda.pydata.org/" class="">Conda</a>, specifically their <a href="https://github.com/ContinuumIO/docker-images/blob/master/miniconda/Dockerfile" class="">miniconda docker base image</a>, coupled with either their hosted <a href="https://binstar.org/" class="">Binstar</a> service or a self-hosted <a href="http://conda.pydata.org/docs/custom-channels.html" class="">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 class=""></div></div></div></blockquote><div><br class=""></div><div>Yeah I should look at conda. I did find that our Python is out of date and has a pile of weird stuff built into it.</div><div><br class=""></div><div>Thanks</div></div><br class=""></body></html>