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>
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
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
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.
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.