Shibboleth Idp3 as docker install on AWS

[Joseph Fischetti]

Thanks for the overview Ryan, that's incredibly helpful.

I'll be reaching out to you offline, I hope that's alright.

Joe

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Ryan Rumbaugh
Sent: Friday, May 15, 2020 8:24 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth Idp3 as docker install on AWS

[EXTERNAL EMAIL]

In our case, containers and their orchestration has helped us tremendously. If you support just one IdP, with a small team or a team of one, then I don't see much benefit with the Shib IdP container (other than exposing you to Docker and container concepts). I suppose it lets you bypass the installation of Shib in a way, but you still need to what you are doing to the extent you are placing the right configuration files in the right places (Tomcat & Shib).

For us, we support six IdP's with a team of five and every member of the team, all at various levels of experience, technical knowledge, and not necessarily dedicated to SSO, are capable of onboarding new services via configuration changes and getting them deployed to our test/staging servers by merging feature branches in Gitlab into a specific IdP branch. Six IdP's means we have 12 production containers all running on Docker Swarm and 12 more for test. When we inherited the six IdP's all were at various versions of you name it, (java, linux, tomcat, jetty) so the use of ITAP containers helped us standardize as well.

What using containers will eventually allow us to do is scale those out rather easily. Admittedly we are not quite there yet, but what we're working towards is being able to either predict heavy demand (course drop/add, high enrollment) and scale our services up or down appropriately.

Using containers has also given members of the team experience with Docker, CI/CD, and orchestration to the extent that managing our ITAP Grouper Swarm containers is a piece of cake.

--
Ryan Rumbaugh



On 5/14/20, 9:37 AM, "users on behalf of Joseph Fischetti" <users-bounces at shibboleth.net on behalf of Joseph.Fischetti at marist.edu> wrote:

    Non-NU Email

    The way I've always handled it is that Tomcat points to a symlink for the current deployment.
    Update the symlink and restart tomcat to switch deployments.
    Rollback is just as simple.

    It's also not immutable, so you can make configuration changes and utilize reloadable services on the fly.

    Pushing from test to prod is as simple as tar -> scp -> untar -> symlink, which is all scripted.

    Docker sounds like unnecessary overhead and complexity in this case.  Perhaps I'm missing something.
    --
    For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=Cu5g146wZdoqVuKpTNsYHeFX_rg6kWhlkLF8Eft-wwo&r=x_uM7qpgXzh_70B3Dgey5pfdCFAWMhq-IedVFyaAIwg&m=Wi7Y4_AvEJmptWPDFjq2_qxjGoJOHzBz2Z5zu2guXTw&s=QtOAIsvJXxJ3ja4KXR2mlLKvqroWc-G9yLHs5C58lyc&e=
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net