Deploy applications

The primary role of Juju is to deploy and manage software applications in a way that is easy, repeatable and adheres to best practices. This is achieved with the help of charmed operators, small pieces of software that encapsulate all the necessary logic for not only installing, configuring and upgrading the application but also supporting post day-one operations.

The authors of charmed operators publish their work to charmhub.io which in addition to serving as an open platform for hosting the operators themselves also provides a user-friendly interface to search for operators and access their associated documentation. Furthermore, operators may also be downloaded locally for offline use (e.g. when working in an air-gapped environment).

Contents:

In order to deploy any application, you first need to have access to a Juju controller. See the Creating a controller page for guidance.

Deploying from charmhub-io

CharmHub is the canonical source for deploying charmed operators via Juju. Using the store ensures that you not only have access the latest published version of the charmed operator but also that you can be automatically notified when a new operator release becomes available so you can effortlessly upgrade via the Juju command line client.

The juju deploy command can be used to deploy a charmed operator. For example:

juju deploy mysql

Depending on the cloud substrate that your controller is running on, the above command will allocate a suitable machine (physical, virtual, LXD container or a kubernetes pod) and then proceed to deploy and configure MySQL.

Depending on your use-case, you may alternatively opt to provision a set of machines in advance via the juju add-machine command. In this case, when running the above juju deploy command, Juju will detect that the model contains machines with no applications assigned to them and automatically schedule MySQL to one of those machines instead of spinning up a new machine.

Specifying a charmed operator channel

In addition to offering the latest stable version of each operator, CharmHub also allows users to download or deploy operators in different stages of development. Some users may be interested in the bleeding edge (in development) version of an operator where others may be part of a beta test group tasked with evaluating the next release candidate for a particular operator.

Juju refers to these stages using the term channel. The following channel names are currently supported:

  • stable: (default) This is the latest, tested, working stable version of the charmed operator.
  • 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 charmed operator 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.

Unless otherwise instructed, Juju automatically uses the stable channel when deploying operators. However, users can explicitly specify the channel to pull the operator from as an argument to the juju deploy command as demonstrated below:

juju deploy mysql --channel beta

If CharmHub cannot identify a suitable operator version using the specified channel, Juju will automatically fall back to the next most stable channel for which an operator is available. For instance, if no operator is available in the beta channel, Juju will then attempt to deploy from the candidate channel instead, and so on until a suitable operator version can be located.

See Upgrading applications for how charmed operator upgrades work.

Overriding the name of deployed applications

Generally, when a new application is deployed, the charm name is used as the application name in the Juju model. However, the juju deploy command allows you to override this behavior and specify a custom application name by providing an extra argument to the juju deploy command. For example, the following command will deploy the mysql charm but override its name to db:

juju deploy mysql db

Custom application names must comply with the following 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.

Based on the above set of rules, the following application names would be valid: myappname, custom-app, app2. On the other hand, the following application names would be invalid: myAppName, custom--app, app2-23, areacode-555-info.

When overriding the application name, the specified name will be displayed in juju status output and must used with any juju client command that interacts with the particular application.

Deploying a local charmed operator

Instead of downloading operators from CharmHub, it is also possible to upload and deploy an operator from your local filesystem. See Deploying charmed operators offline for further guidance.

Deploying a charmed operator bundle

When attempting to provision a complex application stack that comprises of several charmed operators, you can use a bundle to deploy and configure all operators in a single step rather than having to deploy each operator manually. See page Charmed operator bundles for guidance.

Exposing deployed applications

By default, once an application is deployed, it is only reachable by other applications in the same Juju model. However, if the particular deployment use-case requires for the application to be reachable by Internet traffic (e.g. a web server, wordpress installation etc.), Juju needs to tweak the backing cloud’s firewall rules to allow Internet traffic to reach the application. This is done with the juju expose command.

After running a juju expose command, any ports opened by the application’s charmed operator will become accessible by any public or private IP address.

Assuming the ‘wordpress’ application has been deployed (and a relation has been made to deployed database ‘mariadb’), the following command can be used to expose the application outside the Juju model:

juju expose wordpress

When running juju status, its output will not only indicate whether an application is exposed or not but also the public address that can be used to access each exposed application:

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        54.147.127.19           ready
wordpress/0*  active    idle   0        54.224.246.234  80/tcp

The juju unexpose command can be used to undo the firewall changes and once again only allow the application to be accessed by applications in the same Juju model:

juju unexpose wordpress

Since Juju 2.9, operators can explicitly specify the list of CIDRs and/or spaces that should be able to access the ports opened by the application. See Controlling application expose settings via the Juju CLI to learn more about this feature.

Configuring at deployment time

Most charmed operators ship with a sensible default configuration out of the box. However, for some use-cases, it may be desirable to override the default application configuration options at deployment time. See Configuring applications for more on this.

Deploying applications to LXD containers

Instead of acquiring a new machine from the backing substrate and deploying an application directly to it, Juju also supports deploying applications as LXD containers to new or existing (see following section) machines.

For example, the following command will allocate a new machine and deploy etcd into an LXD container hosted on the allocated machine:

juju deploy etcd --to lxd

Deploying applications to specific machines

The juju deploy command allows users to target (via the --to flag) a particular machine (or container) when deploying applications. See Deploying to specific machines for full coverage of this topic.

Targeting specific availability zones at deploy time

If the backing cloud substrate supports multiple availability zones (AZs), users can explicitly specify which availability zone (or zones) to use when spinning up machines during a deploy operation. See Deploying to specific availability zones for details.

Targeting network spaces when deploying applications

The concept of network spaces allows users to specify a more restricted network topology for the units that comprise deployed charmed operators. See Deploying to network spaces for more information.

Scaling out deployed applications

A common enterprise requirement is the ability to scale out (and scale back) the underlying infrastructure. Juju provides this functionality out of the box. The Scaling applications page offers in-depth guidance on the matter.

Trusting an application

Some operators may require privileged access to the backing cloud in order to function. In such cases, the cloud credential associated with the Juju model the application is part of must be shared with the application. This can be achieved either at deploy time (e.g. juju deploy --trust) or later via the juju trust command. See section Trusting an application with a credential to learn more about this topic.


Last updated a day ago.