Dockerized IdP

[John Gasper]

Just to shed light on Greg's comment about "John's original distribution
had an import script, which would import (some
of) the configuration and rebuilt the WAR."

This was basically a requirement in v2 to build the war. In v2, the
installer had to move things around and swap out placeholders etc. In v3,
after unpacking the zip/tar.gz, there is no requirement to build the
idp.war (or run install.sh), one can just drop credentials and a few
config files in place and it just works. So the import script was
removed... I also removed it because it made more sense to treat the
container as disposable/ephemeral and not as a virtual appliance.

Is it valuable to add back in?

-- 
John Gasper
IAM Consultant
Unicon, Inc.
PGP/GPG Key: 0xbafee3ef



>
>Date: Tue, 8 Mar 2016 12:59:03 -0800
>From: Greg Haverkamp <gahaverkamp at lbl.gov>
>To: Shib Users <users at shibboleth.net>
>Subject: Re: Dockerized IdP
>Message-ID:
>	<CAHEFaoRoCyk7ujZqs4SFYOBRgnb8C=ZSXXVS97ovYfJXChqXOg at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>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