NOTE: THIS DOC IS BEING DEPRECATED. PLEASE SEE INSTEAD How to manage 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:
- Deploying from charmhub-io
- Deploying a local charmed operator
- Deploying a charmed operator bundle
- Exposing deployed applications
- Configuring at deployment time
- Deploying applications to LXD containers
- Deploying applications to specific machines
- Targeting specific availability zones at deploy time
- Targeting network spaces when deploying applications
- Scaling out deployed applications
- Trusting an application
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.