<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Keith,<br><br></div>We, at the KU Leuven University in Belgium, put IdP 3.3 in production using Docker in our own on-premises servers.<br><br></div><div>About dockerizing the IdP:<br></div><div>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.<br></div><br>About logging:<br></div>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.<br><br></div>About the Data Sealer:<br></div>We looked into shared storage but I found it cumbersome and fragile. <br>It's funny you posed the question, because yesterday I uploaded  to Github what we use: <a href="https://github.com/KULeuven-CCIS/idp-sealer-rollover">https://github.com/KULeuven-CCIS/idp-sealer-rollover</a>. <br>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.<br><br></div>About metadata:<br></div>Although not an answer: don't put that in the container. Make your images as generic as possible.<br><br></div>Regards,<br><br></div>Claudio Ramirez<br></div>KU Leuven - CCIS<br><div><div><div><div><div><br><br><div><div><br><br><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-20 20:35 GMT+01:00 Wessel, Keith <span dir="ltr"><<a href="mailto:kwessel@illinois.edu" target="_blank">kwessel@illinois.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
Hoping others who have already done this might have some wisdom to share.<br>
<br>
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.<br>
<br>
Specific areas of interest are logging and data sealer credential storage.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks for any guidance,<br>
Keith<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></span></blockquote></div><br></div>