Shipyard – Left Wanting
Shipyard was the solution we were most excited about when we had started. Likely this is because we have had a Google Keep note for around a year that says “try Shipyard for Docker.” It has been a project we wanted to try but never got around to for years. You can see our raw initial impressions in our lab notes.
Unlike Portainer, Shipyard does have its own set of infrastructure. That means that you will see several containers running to manage the service, although fewer than we saw Rancher launch.
Overall the setup process was simple and Shipyard works. We especially liked the drill down into individual containers where one could see charts with CPU utilization, logs and even access a web-based console for the container.
Creating a global service while easy on both Portainer and Rancher was not intuitive for us with Shipyard. We had three folks try to set a simple global service up with a three-minute timeout and nobody did it successfully (via the GUI).
For Docker-only management, go with Portainer over Shipyard. Shipyard creates several additional containers for managing the cluster and many seem redundant with what the Docker team has incorporated into the latest engine releases. In our four node cluster we had a total of 20 Shipyard related containers while Portainer used one. For many folks Shipyard is going to be the right solution and you can get a more detailed walkthrough by either launching your own Shipyard tool or checking out the project’s official walkthrough.
Rancher – Robust
Rancher is by far the most robust solution. In fact, Rancher has solutions for things the other solutions never contemplated. The base installation uses its Cattle orchestration management instead of Docker Swarm. Docker Swarm environments are still in “Experimental Mode” along with Windows. Rancher also supports Mesos and Kubernetes which is something the other solutions we looked at cannot claim.
Even with just four nodes, looking at the Infrastructure Hosts view provided a lot of information.
One small note here is that as we have been transitioning to 40GbE+ in the lab, it would have been nice to see bits like how fast the external network cards are along with CPU and RAM specs.
We did not setup Rancher in HA mode but it is possible and there are clear guides and UI elements for that purpose. Adding containers was simple and more similar to what we saw with Portainer. There is a lot going on and you can see features like “Health Check” options that are not available with Portainer at this time.
The Rancher catalog was significantly more robust than other offerings. The ability to quickly configure and deploy a myriad of different solutions was excellent.
If you have a bit more time to set a solution up, the robustness of Rancher is excellent compared to the other two solutions we tried, especially in a lab environment. If you have an enterprise cluster where you want external authentication sources, the ability to drive containers on different infrastructure such as AWS, Azure and etc, Rancher should be atop your list.
In the end, we are likely to use a combination of Portainer and Rancher. Rancher we will use for our primary clusters as it does provide an expanded feature set we can use. Portainer we will utilize for testing clusters and will be our go-to lightweight Swarm management GUI. If you have an existing Docker Swarm and want to try a GUI, try Portainer. Portainer is so lightweight and follows Docker so closely that if you were to delete the Portainer image (without persistent storage) and re-launch Portainer one of the only items missing would be user authentication changes. Rancher is the robust solution that allows you to handle many different types of containers. Since we were able to get all three working on the same four nodes, you can replicate this experiment and try them all for yourself with 15 minutes or so of work.