If you have reviewed both of my previous postings, you likely noticed that both TIER and Unicon have images for the same applications. Where there is overlap, the TIER images are the officially supported images. I always advocate that official images should be used, unless there is a clear reason why they should not be used. So my hope with this posting is to clarify in which cases the Unicon images might have advantages over the TIER equivalent. I end this post with sharing some thoughts on what may happen with the Unicon images in the future, because I think that they will fill a new role.
As of the date of publishing this post, neither midPoint image is suitable for production use. With that said, the TIER image is the one to keep your eye on.
The Unicon image pre-dated TIER/Evolveum's work. It started as an image for Unicon IAM team members to have an environment to test and train with. Later, when we heard that TIER would be sponsoring their own image, I had decided that we would not persue development of our image much more, but we had clients that were interested in having a placeholder image to setup midPoint DevOps processes around, so it got a little bit more love.
Recommendation: TIER's midPoint image
With COmanage, the decision is easy because Unicon never produced a COmanage image.
Recommendation: TIER's COmanage image
With Grouper, use the TIER image. The Unicon Grouper images have been ignored for some time. Why? Well, I was busy putting together the TIER Grouper image. The Unicon image is actually a set of images, one for each Grouper component. This model ultimately proved problematic, and during a discussion at TechEx/ACAMP 2017, Bert Bee-Lindgren of Georgia Tech suggested the combined image approach. That's what I did, and it has proven to be successful.
Recommendation: TIER's Grouper image
With the Shibboleth IdP images, you have three choices. If you prefer the Windows Docker stack, then you will want to use the TIER Shibboleth IdP for Windows image. If you prefer the Linux Docker stack, then the next major question is, "Do you want Jetty or Tomcat?" The Unicon IdP image has always been Jetty-based, where as the TIER IdP image uses Tomcat.
Another reason that you may choose to use the Unicon image is that it has been around longer and at this point likely has more adopters. The Unicon Shibboleth IdP image has been around since October 2015 (IdP version 3.1.2), which itself is based on IdP v2 images that I started producing in 2014. I receive questions, bug reports, and pull requests from people across the world. On the other hand, the standalone TIER image is only about 8 months old. With that said, the TIER image will likely gain adoption quickly as it is the official TIER image.
Recommendation: It depends. (See the last section for another reason why you might want to consider adopting the Unicon Shibboleth IdP image)
Like the Shibboleth IdP image, you have choices of which Shibboleth SP image you run. If your web app needs to run on a Windows/IIS/ASP.NET stack, then you will want to use the TIER Shibboleth SP for Windows image. For Linux/Apache HTTP Server, both Unicon and TIER's image is based on CentOS 7. The TIER SP image adds more tools to the base image and makes more changes to the default httpd settings.
The Unicon image runs with fewer tools installed and leaves more of the default httpd settings intact. Like the IdP image, the Unicon image has been around longer, and I know of quite a few adopters using it for PHP and Python applications, as well as using it to front Tomcat for use with Java-based web apps.
Recommendation: It depends.
As the TIER images are formally announced, I expect the adoption of the TIER images to increase, and eventually many users of the current Unicon images will look at migrating to the TIER releases. It makes sense to move to where the community is. Does that mean the Unicon images are going to die? No, not at all. My colleague, Jj Johnson, and I have discussed the future of the Unicon Docker images. We think the images' future is bright. Here's why.
The TIER images are designed to be comfortable for university operational staff to work with. They are built on CentOS which include many things not really needed to run their respective applications. These include multiple shells, text editors, and programming execution stacks like Python. A lot of these tools help operations staff troubleshoot issues with running containers, and for that reason the TIER Packaging Working Group decided to include them. But Docker image best practices indicate that images ideally are more lean, running on a stripped down base image. Google actually has distroless base images (https://github.com/GoogleContainerTools/distroless) which do not include shells, editors, nor package managers. They literally have no Linux distribution. The images have only the essential components needed to launch the container's application.
What Jj and I discussed is re-doing the Unicon images to run as distroless images. (I hope to make this some of our Open Source Support's Sustaining Engineering work for the 2019 year.) They will be lean. As organizations become more experienced running Docker containers, we expect the demand for these tighter images will increase, and we will have a solution for that demand. Then when TIER is ready to make the shift to distroless images, Unicon will gladly donate our work. Intrigued? Check out a preliminary Shibboleth IdP image following this model .
So to summarize, you have lots of choices. My general recommendation is go with the official images unless you have a reason not to. If you need an assist on working with any of the TIER images or Unicon images (or the applications themselves), Unicon's IAM team would love to assist you. Please reach out and let's talk.