Before dipping our toes in the water and specifying how similar or different Juju’s dashboard is, we have to explain that Juju is not trying to be a replacement for Rancher. Juju is a service orchestration that enables users to deploy, manage, and scale applications and services in various platforms, like cloud, physical, and containers with ease.
The main idea behind juju is to abstract the complexity of deploying and managing software by representing apps as charms, which are pre-configured scripts and config files that define how services and applications are deployed.
SUSE Rancher is a container management platform built on top of Kubernetes to simplify the deployment, management, and scaling of containerized applications. So, Juju has a broader scope and is said to be able to integrate with Rancher to enhance Kubernetes management.
When accessing the dashboard home menu for Rancher, the first view you have is the clusters. Our local Kubernetes cluster, where Rancher is hosted, and our downstream clusters, where we have our workload. Also, we have buttons for import and create where we can create new downstream clusters for different cloud providers, like Google, Amazon, Azure, etc. Also, import existing clusters for Rancher to manage.
Main dashboard for Juju exposes Juju environments, providing at-scale management, status and collaboration features not found in the Juju CLI. The models view lists all the models associated with the connected controllers access to. The list displays the models across clouds. This allows you to access the health of all the models at a glance, surfacing any relevant errors so you can quickly investigate what has happened.
If you click on any of the models, you will access the model detail view; the purpose of the model details view is to provide a list of the applications running on that model. In this view, you can also manage access to the model.
If you click on any of the applications, you will go into the unit view scope, your list of units to the model and application you are inspecting. This view will give fine-grained information about the status of each unit and information on this public availability.
The controllers view offers a top level view, monitoring across different controllers, and the possibility to add, edit, and manage controllers. It displays a set of aggregate charts to represent the status of the controllers that have been added to the dashboard. It also displays a table listing each controller and the usage of each entity hosted by the controller.
In addition to the controllers that are returned by the Juju deployment you can register additional controllers in the dashboard. The dashboard will then allow you to see aggregate controller data and allow you to view and manage your models and users across all controllers.
This allows users of JAAS to register additional self-bootstrapped controllers into the same dashboard. It also allows users who manage multiple self-bootstrapped controllers the ability to view all of those controllers and their models in a single dashboard.
Most of the features of the dashboard are just visual representations of what you get in a juju status but are more nicely decorated inside a webpage. The only real feature the dashboard offers is the ability to create new controllers, but for you to deploy any sort of workload/applications, you need to go through the CLI.
Opinion
Juju as a tool it's like a screwdriver for nails, a hammer for bolts, and a wrench for screws. It just doesn't fulfill any purpose better than other tools can. Documentation yet while existent is very futile; examples are missing detail, code is deprecated or broken, requiring troubleshooting, and community is slim. When faced with problems, the response from documentation basically tells you to DIY your solution if you encounter problems. Some of the claims made are not possible (at least for beginners), and Juju Charmhub is full of non-working applications, with some having no documentation, e.g., WordPress. Step-by-step guides are confusing and omit key information on what you are actually doing, so you’re left having to wonder around where to find what you're actually doing. In a security standpoint, when faced with creating your controller, if done in the cloud, you will have to give admin permissions to a lot of resources which can violate some of the business grip for security. Overall, if you were needing to control Kubernetes, I would easily recommend Rancher over it, and if you are trying to automate/dumb down the installation process for applications, I would rather recommend Ansible, which gives you more control over with less configuration hassle.
Contact us to learn how we might be able to help.