Most people that have used Juju for a little while are quite familiar with the concept of the juju agents executing hooks in the charms to respond to juju lifecycle events.
What fewer people know is a command available on the workload machines to interact back with juju.
juju-run [options] [<unit-name>] <commands>
The juju-run
command executes the command in a hook context of the specified unit.
How this works
The unit agent has an abstract domain socket open named after the unit itself. The juju-run
executable connects to this socket and passes through the commands to run.
The agent then acquires the hook execution lock and creates a hook context, and then shells back out in that context to execute the commands using bash -s
.
Note:
Since juju-run
executes the command in a hook context, the command runs as root. As such, the juju-run
comand must be executed by root
or through sudo
.
Status Updates
One initial use-case for this was to be able to provide out of band status updates from the workload. As an example, letâs say I have an application deployed called foo
, and there is a script that was installed by the charm that has a cron job that wants to set the status based on external events to the server.
juju-run foo/0 "set-status maintenance 'updating the frobulator'"
This status would be observable in juju status
as soon as it is run. This allows charms to provide more immediate feedback rather than waiting for the periodic update-status
hook call from the agent.
Webhooks
An additional use-case is for the charm to set up a webhook. For example providing updates to a charm on an external github update.
Letâs say we have a charm that runs a simple webhook service. The charms makes the webhook endpoint available to the public internet and is then registered with an external provider, like github.
When the webhook is called, the data payload of the webhook can be used to set configuration for the charm. The key here would be to use the leadership data bag. Only the leader can write into it, so some care is needed on deploy and messaging.
# hash variable set from data payload
juju-run foo/0 "leader-set hash=$hash"
This change would then cause the leader-settings-changed
hook to be executed and the normal charm operations could then use that new hash value to go and pull from the upstream branch.