The fundamental purpose of Juju is to deploy and manage software applications in a way that is easy and repeatable. All this is done with the help of charms, which are bits of code that contain all the necessary intelligence to do these things. Charms can exist online (in the Charm Store) or on your local filesystem (previously downloaded from the store or written locally).
This page collects together topics related to deploying applications:
- Deploying from the Charm Store
- Deploying from a local charm
- Relating deployed applications
- Exposing deployed applications
- Specifying a charm series
- Deploying a subordinate charm
- Deploying a Kubernetes charm
- Deploying from a charm bundle
- Configuring at deployment time
- Deploying to LXD containers
- Deploying to specific machines
- Deploying to specific availability zones
- Deploying to network spaces
- Scaling out deployed applications
- Trusting an application
Before deploying an application a controller must first be created. See the Creating a controller page for guidance.
Deploying from the Charm Store
Typically, applications are deployed using the online charms. This ensures that you get the latest version of the charm. Deploying in this way is straightforward:
juju deploy mysql
This will create a machine in your chosen backing cloud within which the MySQL application will be deployed. However, if there is a machine present that lacks an application then, by default, it will be used instead.
Assuming that the Xenial series charm exists and was used above, an equivalent command is:
juju deploy cs:xenial/mysql
Where ‘cs’ denotes the Charm Store.
A used charm gets cached on the controller’s database to minimize network traffic for subsequent uses.
Providing applications with a custom name
A custom name, such as ‘db’, can be assigned to the application by providing an extra argument:
juju deploy mysql db
Custom application names must comply with a few syntax rules. They consist lower-case letters (a-z), numbers (0-9), and single hyphens (-). The name must begin with a letter and not have a group of all numbers follow a hyphen.
The Charm Store offers charms in different stages of development. Such stages are called channels. Some users may want the very latest features, or be part of a beta test; others may want to only install the most reliable software. The channels are:
- stable: (default) This is the latest, tested, working stable version of the charm.
- candidate: A release candidate. There is high confidence this will work fine, but there may be minor bugs.
- beta: A beta testing milestone release.
- edge: The very latest version - expect bugs!
As each new version of a charm is automatically versioned, these channels serve as pointers to a specific version number. It may be that after time a beta version becomes a candidate, or a candidate becomes the new stable version.
The default channel is ‘stable’, but you can specify a different channel easily. Here, we choose the ‘beta’ channel:
juju deploy mysql --channel beta
In the case of there being no version of the charm specified for that channel, Juju will fall back to the next ‘most stable’; e.g. if you were to specify the ‘beta’ channel, but no charm version is set for that channel, Juju will try to deploy from the ‘candidate’ channel instead, and so on. This means that whenever you specify a channel, you will always end up with something that best approximates your choice if it is not available.
See Upgrading applications for how charm upgrades work.
Deploying from a local charm
It is possible to deploy applications using local charms. See Deploying charms offline for further guidance.
Relating deployed applications
Many charms work in conjunction with other charms, such as a charm requiring a database that another charm provides. In order to “marry” charms like this a relation needs to be set up between them. The Managing relations page provides details.
Exposing deployed applications
Once an application is deployed changes need to be made to the backing cloud’s firewall to permit network traffic to contact the application. This is done with the
Assuming the ‘wordpress’ application has been deployed (and a relation has been made to deployed database ‘mariadb’), we would expose it in this way:
juju expose wordpress
The below partial output from the
status command informs us that the ‘wordpress’ application is currently exposed. In this case it is available via its public address of 184.108.40.206:
App Version Status Scale Charm Store Rev OS Notes mariadb 10.1.36 active 1 mariadb jujucharms 7 ubuntu wordpress active 1 wordpress jujucharms 5 ubuntu exposed Unit Workload Agent Machine Public address Ports Message mariadb/0* active idle 1 220.127.116.11 ready wordpress/0* active idle 0 18.104.22.168 80/tcp
unexpose command to undo the changes:
juju unexpose wordpress
Specifying a charm series
Charms generally support more than one series. If the target machine is of a different series it is possible to force a charm to deploy to it. See Charms and series to learn more about this subject.
Deploying a subordinate charm
A subordinate charm is a charm that augments the functionality of another regular charm, which in this context becomes known as the principle charm. When a subordinate charm is deployed no units are created. This happens only once a relation has been established between the principal and the subordinate.
Deploying a Kubernetes charm
Kubernetes charms (
v.2.5.0) can be deployed when the backing cloud is a Kubernetes cluster. See page Using Kubernetes with Juju for an overview.
Deploying from a charm bundle
Complex installations requiring multiple charms can be achieved through the use of a bundle. See page Charm bundles for guidance.
Configuring at deployment time
Deployed applications usually start with a sane default configuration. However, for some applications it may be desirable (and quicker) to configure them at deployment time. This can be done whether a charm is deployed from the Charm Store or from a local charm. See Configuring applications for more on this.
Deploying to LXD containers
Applications can be deployed directly to new LXD containers in this way:
juju deploy etcd --to lxd
Here, etcd is deployed to a new container on a new machine.
It is equally possible to deploy to a new container that, in turn, resides on a pre-existing machine (see next section).
Deploying to specific machines
You can specify which machine (or container) an application is to be deployed to. See Deploying to specific machines for full coverage of this topic.
Deploying to specific availability zones
It is possible to dictate what availability zone (or zones) a machine must be installed in. See Deploying to specific availability zones for details.
Deploying to network spaces
Using network spaces you can create a more restricted network topology for applications at deployment time. See Deploying to network spaces for more information.
Scaling out deployed applications
A common enterprise requirement, once applications have been running for a while, is the ability to scale out (and scale back) one’s infrastructure. Fortunately, this is one of Juju’s strengths. The Scaling applications page offers in-depth guidance on the matter.
Trusting an application
Some applications may require access to the backing cloud in order to fulfill their purpose. In such cases, the model’s credential must be shared with the application, which can be done at deployment time. See section Trusting an application with a credential to see how this works.