You may have heard the term probes or juju-doctor and are wondering what even are probes, and why does Juju need a doctor? If this is all new to you, then you found the right place for enlightenment!
Let’s start with, what Juju Doctor is not:
- juju-lint ⇾ deployment validation DSL on Juju status/bundle
- hotsos ⇾ analysis scenarios in YAML with Python libs
- sosreport ⇾ generate support archives
- goss ⇾ serves validation endpoints: Prometheus, Nagios
- scriptlets ⇾ sandboxed & event-driven (GoLang)
These are/were crucial projects which solve the age-old problem of support archival, analysis, and validation. Juju Doctor has overlap with some of these tools, but is carving its own path to be your go-to deployment doctor.
So why does Juju need a doctor?
There are many validation bins in the charming ecosystem like:
- Collect-status
- Update-status
- Pebble checks
- i.e. custom notices
- Charm action: “self-test”
They are a piece of the puzzle, but fail to provide a holistic validity check for deployments. The validation bins, mentioned above, are insufficient when we no longer have access to the live deployment, which is often the case in a support role.
Imagine you, as a Juju admin, are able to run a single command on a deployment and have confidence that the deployment is valid according to those who designed it. Alternatively, if there are misconfigurations, they are surfaced, providing resolution context.
What is Juju Doctor?
- Validate deployments by running a set of atomic “probes”, indicating “the right way” to deploy the solution that this ruleset is designed for.
- Source these probes both locally and/or from a remote (decentralized) source.
- On a live or offline (with a support archive) environment.
From usage examples, an output from Juju Doctor may look like:
Results
├── fail
│ └── 🔴 tests_resources_probes_python_failing.py (bundle, show_unit, status)
└── pass
└── 🟢 tests_resources_probes_python_passing.py
Total: 🟢 3 🔴 3
What are probes?
A probe is a programmatic, configurable assertion. They are like a waiting room for checks to be absorbed by the charm. Probes are written in Python, consuming one (or multiple) Juju artifact(s). Production examples in Grafana and Grafana-agent may be too complex, so we can observe a minimalist probe:
The probe can assert against any supported Juju artifact. Juju 4’s dump-model will improve authoring probes since it combines all Juju artifacts into one!
A single probe is often an incomplete picture. The Ruleset probe solves this by assembling probes, which defines the “the right way” way to deploy a solution:
From the sample above, these probes are written in YAML and can execute Python, Ruleset, and directories of probes. With probes being authored for many use cases, it is important for Juju Doctor to consume those that are universal and apply to the large majority of deployments like required relations, topology restrictions, etc.
Summary
With future improvements coming in Juju 4 and leveraging decentralized probes, authoring probes is becoming easier and scalable. Rulesets collect defined probes and execute them on a live or support archive. This process defines the “the right way” way to deploy the solution.