Juju provides a declarative, model-driven, and interactive way to install, provision, maintain, update, upgrade, and integrate applications on and across Kubernetes, Linux containers, virtual machines, and bare metal machines, on public or private cloud.
The following diagram provides an overview of the high level architecture of a Juju deployment and it describes the key components of the system. You can find a more detailed explanation of all the components you find in this page in the reference section of the Juju documentation.
A cloud (or backing cloud) is a resource that provides machines (instances), and possibly storage, in order for application units to be deployed upon 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:
Controllers must first be installed (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:
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 provide an interface to apply a certain set of changes to a 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, or between different units of the same application.
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:
An action is a script that is triggered via the Juju client and applied to a unit.
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).
Flexibility and portability are at the heart of Juju
Juju and charms support multiple cloud backends, giving you the choice to deploy your applications to the most cost effective, resource-rich or commercially suitable clouds, and then connect them in a way that suits your application model.
In addition Juju gives you flexibility in how to orchestrate your deployment. You can manage everything from a single, centralised Juju controller, or you can have multiple controllers installed on each layer of the cloud.
When applications are deployed on Kubernetes every instance of a workload runs in a pod with its own container and next to the Juju unit agent.
The model corresponds to a namespace and the applications are generally deployed as StatefulSets.
The Juju agent talks to a component called Pebble in order to interact with the workload. Pebble is a daemon that allows the management of non-system processes independently from the system services.
In this model the operations code (the charm) scales together with the workload, reducing the risk for bottlenecks at scale.
In the case of machines the charm runs in a container, alongside the juju agent.
The workload is deployed alongside the charm code and juju agent and it is directly controlled by the unit workers.
Charm architecture encapsulates app management, with charms automating lifecycle actions via a controller, responsive to both admin commands and system events.
Juju integrations are virtual connections between charms to allow the exchange of information.
