A model is a workspace. It is a logical grouping of applications and infrastructure that work together to deliver a service or product.

Models allow the low-level storage, compute, network and software components to be reasoned about as a single entity, with common configuration applied model-wide where appropriate.

All Juju models are managed by a Juju controller. This enables clients to have a single point of contact with the system and allows commands to be executed independently from the workloads.

What is application modelling?

Juju provides simplicity, stability and security. Models reduce the cognitive gap between the whiteboard picture of your service and how it is implemented. An application model is a definition of which applications are providing a service and how they inter-relate.

Technical details such as CPU core counts, disk write throughput, and IP addresses are secondary. They are accessible to administrators, but an application model places the applications at the front.

What do models offer?

The primary function of a model is to enable you to maintain an uncluttered view of your service. Operational simplicity improves communication and understanding. Models provide an abstract view of the infrastructure that’s hosting your service.

A. Service isolation

Juju models enforce service isolation. A model maintains exclusive access of the resources under its control.

B. Access control

Models provide access control. Juju enables you to create user accounts that have limited ability to alter the deployment.

C. Repeatability

Models provide repeatable infrastructure deployments. Once your model is in-place and functional, it becomes simple to export a model’s definition as a bundle, then re-deploy that model in another host.

D. Boundaries

Models respect bureaucratic boundaries. Models enable you to partition compute resources according to your internal guidelines. You may wish to keep a central set of databases in the same model. Juju’s access controls are model-specific, enabling you to know exactly who has permissions to perform direct database administration. Those databases could be made available to various consuming applications from other models via relations (which can span models). Other use cases for central models include secrets (using the vault charm) and identity management (using the keystone charm).

Model management tasks

Common model management tasks are summarised below. The most important ones are Adding a model and Configuring models.

Add a model

Models can be added easily to a controller. The Adding a model page provides a full explanation and includes examples.

juju add-model <model-name> [[<cloud>/]<region>]

Change models

Use the switch command to change from one model to another. Running the command with no arguments will return the currently active controller and model.

juju switch <controller>[:<model>]
Ways to change to a model:
juju switch foo Selects the last used model in controller ‘foo’ (if the latter exists), otherwise model ‘foo’ in the current controller.
juju switch :foo Selects model ‘foo’ in the current controller.
juju switch foo:bar Selects model ‘bar’ in controller ‘foo’.
juju switch foo: Selects the last used model in controller ‘foo’.

Configure a model

Configuration can occur at the model level. This will affect all Juju machines in the model. For instance, a logging level and API port can be stipulated. See the Configuring models page for explanations.

Compare a bundle to a model

A Juju administrator can compare a model with a charm bundle. This is useful for determining what has changed since the bundle was deployed or just how a model differs from a bundle that was not yet used. This topic is covered on the Charm bundles page.

juju diff-bundle <bundle>

Destroy a model

When a model is destroyed all associated applications and machines are also destroyed. It is a very destructive process. See page Removing things for details.

juju destroy-model <model>

Disable commands

It is possible to curtail command use for Juju users on a per-model basis. The Disabling commands page gives more information.

Examine a model

Use the show-model command to examine a specific model.

juju show-model <model>

List all models

Use the models command to list all models for a controller.

juju models

Manage user access

If you’re using multiple Juju users you will need to manage access to your models. See page Working with multiple users for a full explanation.

Migrate models

Model can be migrated from one controller to another. Model migration is useful when upgrading a controller and for load balancing. For a complete explanation see the Migrating models page.

Enable secure shell (SSH) access

SSH access can be provided to all machines, present and future, on a per-model basis. For in-depth coverage see page Machine authentication.

Set constraints for a model

Charmed operators constraints can be managed at the model level. This will affect all charms used in the model unless overridden. Constraints are used to select minimum requirements for any future machines Juju may create. This subject is covered on page Setting constraints for a model.

Upgrade a model

Juju software is upgraded at the model level with the upgrade-model command. This affects the Juju agents running on every machine Juju creates. This does not pertain to the Juju software package installed on a client system. See Upgrading models for complete coverage.

View logs

Use the debug-log command to examine logs on a per-model basis. This allows inspection of activities occurring on multiple Juju machines simultaneously. Due to the expected large volume of data, advanced filtering is available. A full explanation is provided on the Juju logs page.

View model status

Use the status command to view the status of a model. Tutorial Basic client usage gives an overview of the various elements of this command’s output.

juju status [--storage] [--relations]

Related concepts

Cross model relations

Traditionally, when adding a relation between two applications (see Managing relations) the applications reside within the same model and controller. It is possible to overcome this limitation by employing cross model relations. This topic is covered on the Cross model relations page.

The paragraph before “Model management tasks” appears to be incomplete.

Thanks for reporting this. I’ll fix it right away.

[edit: I’ve made some changes to the text to flesh out three use cases]

1 Like