Recommended practices for Dockerizing the IdP

[Claudio Ramirez]

Hi Keith,

We, at the KU Leuven University in Belgium, put IdP 3.3 in production using
Docker in our own on-premises servers.

About dockerizing the IdP:
It was not trivial, and certainly one of the most complicated apps we
dockerized. But once you decide what goes in the image and what is
persistent data (we manage that with Puppet), it's OK.

About logging:
journald is awful for applications that do a lot of logging, like the IdP.
Expect CPUs at 100% while journald is parsing and indexing the logs and
storing them in a binary format. We configured logback for Jetty and Shib
to log into a persistent local directory (offered to the container as a
volume from the Docker host) and directly to syslog from the container.
This works very well.

About the Data Sealer:
We looked into shared storage but I found it cumbersome and fragile.
It's funny you posed the question, because yesterday I uploaded to Github
what we use: https://github.com/KULeuven-CCIS/idp-sealer-rollover.
In short, it runs on a deployment server that supports Docker. The scripts
pulls (once) a minimalistic Docker image I created with the minimum Shib
libraries needed for creating/updating the data sealer. Once created/update
locally it uploads to the persistent storage on the Docker hosts. In utils
you'll find the source Dockerfile in case you wish to create it yourself. A
self-contained version of the script is added, so you don't need to install
any dependencies.

About metadata:
Although not an answer: don't put that in the container. Make your images
as generic as possible.

Regards,

Claudio Ramirez
KU Leuven - CCIS






2017-02-20 20:35 GMT+01:00 Wessel, Keith <kwessel at illinois.edu>:

> All,
>
> Hoping others who have already done this might have some wisdom to share.
>
> We're in the process of moving our IdP to the cloud, specifically to an
> AWS Elastic Beanstalk instance. Dockerizing the IdP isn't hard and, in
> fact, we can leverage TIER's packaging should we choose to and if we're
> willing to move from jetty back to Tomcat.
>
> Specific areas of interest are logging and data sealer credential storage.
>
> I'm assuming, with all of the logs coming out of Tomcat/Jetty and the IdP,
> it's best to send the application server logs to stdout and everything else
> to a syslog server, but I'm curious if others have other ideas.
>
> The data sealker creds lend themselves to externally mounted storage for
> consistency across restarts, but if anyone can suggest another way to
> handle this that's lighter weight, I'd be interested.
>
> Of less significance is metadata: presumably, the IdP will pull down the
> latest federation metadata aggregate on start-up, but if for som reason
> that's unavailable, we'll be stuck with any metadata stored in the Docker
> image as a fallback. This could be stale. Any recommendations for dealing
> with this?
>
> Thanks for any guidance,
> Keith
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170224/972055ce/attachment.html>