How Juju works

To Juju, a cloud (or backing cloud) is any entity that has an API that can provide compute, networking, and optionally storage resources in order for application units to be deployed on them. This includes public clouds such as Amazon Web Services, Google Compute Engine, Microsoft Azure and Kubernetes as well as private OpenStack-based clouds.

Juju works on most cloud environments. Juju can also make use of environments which are not clouds per se, by treating them as a cloud. MAAS and LXD fit into this last category. Because of this, in Juju a cloud is sometimes also called a substrate.

A controller is the management node of any deployed cloud environment. A controller:

• Talks to the cli as well as all the other juju clients.
• Manages the deployment and keeps track of its state.
• Connects to charmhub to fetch and deploy charms.
• Interacts with the underlying cloud to provision necessary resources (compute, storage, networking).
• Facilitates the integration between charms in the same cloud or across clouds.

Controllers must first be bootstrapped.

A model is a user-defined collection of applications that wraps all of the components required to support them, such as integrations, storage, and network spaces.

A model is associated with a single controller. A controller can have an indefinite number of models and each model can have an indefinite number of applications. Models themselves can be shared amongst Juju users.

Both the model and the controller are associated with a cloud, though they do not both have to be on the same cloud (a controller can manage models across multiple clouds).

A charm is an operator: business logic encapsulated in reusable software packages that automate every aspect of an application’s life.

Charms are publicly available on Charmhub and they are of two kinds, depending on the target deployment substrate:

1. Machine charms: Charms made to deploy on a bare-metal server, virtual machine, or system container.
2. Kubernetes charms: Charms built to deploy on Kubernetes.

An application is a running abstraction of a charm in the Juju model. It is the sum of all units of a given charm with the same name.

Applications could correspond to a traditional software package but they could also include instructions to apply a certain set of changes to an existing workload.

An application is always hosted within a model and consists of one or more units.

Interaction between applications is handled by integrations.

An integration is a connection between applications.

An integration between two applications is formed by connecting their endpoints. Endpoints can only be connected if they support the same interface and are of a compatible role (for example: requires to provides; provides to requires; peers to peers).

Integrations mediate the configuration exchange between applications. Once an integration has been formed the two applications communicate directly (and not through the controller).

A Juju client is any software that implements the Juju client apiserver contract and it is able to talk to the controller.

This currently includes:

• The Juju CLI (juju).
• The Terraform CLI when used with the juju provider plug-in (terraform).
• The python-libjuju library (python-libjuju).
• Jimm, the central management component of Jaas.

An action is a custom operation for a specific charm or application delivered by a charm.

It contains a list of commands defined by a charm to allow a user to interact with the application and streamline the performance of a specific task.

Actions generally simplify routine or complex tasks (like backup and secret rotation), abstracting away their complexity from the IT manager.

In Juju a unit is a deployed charm, a single deployed entity of a deployed application.

The number of units can generally be controlled by the IT manager, however the charm might also specify certain requirements in order to enable certain features (e.g. high availability).