<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 2:03 AM, Etienne Dysli-Metref <span dir="ltr"><<a href="mailto:etienne.dysli-metref@switch.ch" target="_blank">etienne.dysli-metref@switch.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":10o" class="a3s" style="overflow:hidden">One question that always puzzled me with Docker is: how do you properly<br>
manage the application's configuration? Your example shows several<br>
possibles answers. :)<br>
<br>
I think externalising the whole configuration is best, because then you<br>
would only have one image to build and you could run it several times<br>
with different configurations. (Assuming a context where one would run<br>
many IdPs, one per customer.)<br></div></blockquote><div><br></div><div>We've currently gone with a hybrid.  We keep metadata external, but we keep configuration - or, at least, a baseline - internal.  Whether it was a good idea or not, I'm unsure of, but when I set everything up, I forked John's installation, made some local customizations, and built a baseline Shibboleth IdP image.</div><div><br></div><div>Then, I created a second image, based on the baseline image, which I build that includes our configuration.</div><div><br></div><div>John's original distribution had an import script, which would import (some of) the configuration and rebuilt the WAR.  I extended it to be able to specify which aspects of the configuration to import.  So, if we make changes that need to be deployed to production, make the changes in our git repository, but then I also have to import them and reload the affected service.  Whenever more substantial changes occur, I rebuild what we call our runtime, which builds against the most recent configuration.</div><div><br></div><div>The nice thing about that is that we can quickly crank up a new container with a fully working image, and the only thing we have to provide is metadata.  The downside is the import step.  We'll probably eliminate it as a requirement, and instead map the external volume from the repository we already keep on the host.  That way, we can still deploy anywhere without getting a repository cloned, but we can also, if we so desire, keep changes in the local git repository for the primary systems.  (In all honesty, I'm not really sure when we'd need to hurriedly get a container running on a new machine, so I may be overthinking all of the above.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":10o" class="a3s" style="overflow:hidden">
<br><span class="">> I think this is the answer if you are thinking of running the IdP in<br>
> Docker, but feel free to make up your own mind.<br>
<br>
</span>What does thing bring compared to managing IdPs with configuration<br>
management software? I mean you'd need CM anyway to create the IdP's<br>
configuration (whether in the image or external), so why bother with<br>
Docker on top of this?</div></blockquote></div><br>If you can quickly spin up VMs, perhaps not much.  However, if you have a set of oversized hosts hosting containers, it permits you to do things like running identical servlet containers in parallel with varying Shibboleth configurations.  We use it as a staging process.  Make our changes, crank up the "staging" container.  Then, using the load balancer-based selection process I've written about before, select the staging container, and we can even let user readily test to see if the changes we've made fix whatever issue they might have been having.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you have CM system that can rapidly deploy your environment onto VMs, you could do the same thing, of course.  But we don't.  Even though we (IAM) "own" our VM infrastructure, we don't manage it, so it's still a ticket for me to get a new VM set up.  (And we don't really have the scale to use a CM system, anyway.)  With Docker, between my dev and production environments, I can finally easily and independently get new instances of the IdP up and running, tweak them, test the changes, get others to test them, etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Greg</div></div>