<div dir="ltr">I'm not sure if I've said it yet, but I quickly outgrew the limited features in Fig/Compose and resorted to using docker-py to talk to the Docker Remote API directly. e.g. Compose builds images serially. I have 8 images for one "cluster" and this was taking over a minute. I hooked concurrent.futures up to docker-py and now images build in seconds. I also had issues with startup race conditions. e.g. I wanted to wait for the HTTP server in a container to be available before tests started running. Compose makes no such guarantees, especially if you have an entrypoint script that takes a few seconds to run. At some point I realized that hacking around Compose's limitations was about the same work as consuming the Docker Remote API directly via docker-py, so I evicted Compose. I also found that talking to the Docker Remote API increased my understanding of Docker. Once you grok that `docker` (the CLI tool) is simply a thin client to a bunch of HTTP calls to the Docker Remote API, things just started clicking for me.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 27, 2015 at 9:37 AM, Andy McKay <span dir="ltr"><<a href="mailto:amckay@mozilla.com" target="_blank">amckay@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah cool, that’s easy. I think again I’m at the point of wanting to make the docker-compose.yml file more and more configurable - so that overriding volumes or other options are easier.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Apr 27, 2015, at 4:43 AM, Giorgos Logiotatidis <<a href="mailto:giorgos@mozilla.com">giorgos@mozilla.com</a>> wrote:<br>
><br>
> On masterfirefoxos [0] we use docker for development and deployment. On<br>
> every image built we add the source [1] which is overriden by<br>
> docker-compose volumes during development [2]. This way there is only<br>
> one Dockerfile and every image contains the source.<br>
><br>
> Giorgos<br>
><br>
> [0] <a href="https://github.com/mozilla/masterfirefoxos" target="_blank">https://github.com/mozilla/masterfirefoxos</a><br>
> [1] <a href="https://github.com/mozilla/masterfirefoxos/blob/master/Dockerfile#L14" target="_blank">https://github.com/mozilla/masterfirefoxos/blob/master/Dockerfile#L14</a><br>
> [2] <a href="https://github.com/mozilla/masterfirefoxos/blob/master/fig.yml#L7-8" target="_blank">https://github.com/mozilla/masterfirefoxos/blob/master/fig.yml#L7-8</a><br>
><br>
> Andy McKay writes:<br>
><br>
>> Currently we’ve been using docker for deployment and we are thinking of using docker for deployment (probably not for production instances yet).<br>
>><br>
>> For development we have everything in the container except the source. We mount the source from local volumes, this allows developers to use local tools etc.<br>
>><br>
>> I’m thinking for deployment we want to have the source inside the container so it’s completely self contained. Each release of the software is then completely contained in the container image that was built. To move to different builds its a matter of just moving to a different container.<br>
>><br>
>> That feels like we’ve got two different containerization strategies for the same project.<br>
>><br>
>> Are we doing this right?<br>
>><br>
>> Are there any libraries anyone would recommend for doing that easily, it feels like we need to manage our Dockerfile and docker-compose files to do this.<br>
<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>
</div></div></blockquote></div><br></div>