Dockerized IdP

[Greg Haverkamp]

On Tue, Mar 8, 2016 at 2:03 AM, Etienne Dysli-Metref <
etienne.dysli-metref at switch.ch> wrote:

> One question that always puzzled me with Docker is: how do you properly
> manage the application's configuration? Your example shows several
> possibles answers. :)
>
> I think externalising the whole configuration is best, because then you
> would only have one image to build and you could run it several times
> with different configurations. (Assuming a context where one would run
> many IdPs, one per customer.)
>

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.

Then, I created a second image, based on the baseline image, which I build
that includes our configuration.

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.

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.)


>
> > I think this is the answer if you are thinking of running the IdP in
> > Docker, but feel free to make up your own mind.
>
> What does thing bring compared to managing IdPs with configuration
> management software? I mean you'd need CM anyway to create the IdP's
> configuration (whether in the image or external), so why bother with
> Docker on top of this?
>

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.

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.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160308/cc912c4f/attachment-0001.html>