This page is dedicated to more advanced topics related to deploying applications with Juju. The main page is Deploying applications.
Topics covered here are:
- Multi-series charms
- Deploying to specific machines
- Deploying to spaces
Charms can be created that support more than one release of a given operating system distro, such as the multiple Ubuntu releases shown below. It is not possible to create a charm to support multiple distros, such as one charm for both Ubuntu and CentOS. Supported series are added to the charm metadata like this:
name: mycharm summary: "Great software" description: It works maintainer: Some One <email@example.com> categories: - databases series: - trusty - xenial provides: db: interface: pgsql requires: syslog: interface: syslog
The default series for the charm is the first one listed. So, in this example,
trusty, all you need is:
juju deploy mycharm
You can specify a different series using the
juju deploy mycharm --series xenial
You can force the charm to deploy using an unsupported series using the
juju deploy mycharm --series bionic --force
Here is a more complete example showing a new machine being added that uses
a different series than is supported by our
mycharm example and then forcing
the charm to install:
juju add-machine --series bionic juju deploy mycharm --to 1 --series bionic --force
Multi-series charms may encounter upgrade difficulties if support for the installed series is dropped. See Forced upgrades for details.
To deploy to specific, pre-existing machines the
--to option is used. When
this is done, unless the machine was created via
add-machine, a charm has
already been deployed to the machine.
Note: When multiple charms are deployed to the same machine there exists the possibility of conflicting configuration files (on the machine's filesystem). Work is being done to rectify this.
Machines are often referred to by their ID number. This is a simple integer
that is shown in the output to
juju status (or
juju machines). For example,
this partial output shows a machine with an ID of '2':
Machine State DNS Inst id Series AZ Message 2 started 10.132.70.65 juju-79b3aa-0 xenial Running
To deploy the 'haproxy' application to machine '2' we would do this:
juju deploy --to 2 haproxy
--constraints option is used during controller creation to ensure
that each workload machine will have enough memory to run multiple
applications. MySQL is deployed as the first unit (in the
'default' model) and so ends up on machine '0'. Then Rabbitmq gets deployed to
the same machine:
juju bootstrap --constraints="mem=4G" localhost lxd juju deploy mysql juju deploy --to 0 rabbitmq-server
Juju treats a container like any other machine so it is possible to target specific containers as well. Here we deploy to containers in two different ways:
juju deploy nginx --to 24/lxd/3 juju deploy mongodb --to lxd:25
In the first case above, nginx is deployed to existing container '3' on machine
'24'. In the second case, MongoDB is deployed to a new container on machine
'25'. The latter is an exception to the rule that the
--to option is always
used in conjunction with a pre-existing machine.
It is also possible to deploy units using placement directives as arguments
--to option. Placement directives are cloud-specific:
juju deploy mysql --to zone=us-east-1a juju deploy mediawiki --to host.mass
The first example deploys to a specific AWS zone while the second example deploys to a named machine in MAAS.
add-unit command also supports the
--to option, including placement
directives. This allows one to specifically target an existing machine when
scaling out. For example, to add a unit of 'rabbitmq-server' to machine '1':
juju add-unit --to 1 rabbitmq-server
A comma separated list of directives can be provided to cater for the case where more than one unit is being added:
juju add-unit rabbitmq-server -n 4 --to zone=us-west-1a,zone=us-east-1b juju add-unit rabbitmq-server -n 4 --to host1,host2,host3,host4
Any extra placement directives are ignored. If not enough placement directives are supplied, then the remaining units will be assigned as normal to a new, clean machine.
Using spaces, the operator is able to create a more restricted network topology
for applications at deployment time (see Network spaces for
details on spaces). This is achieved with the use of the
The following will deploy the 'mysql' application to the 'db-space' space:
juju deploy mysql --bind db-space
For finer control, individual endpoints can be connected to specific spaces:
juju deploy --bind "db=db-space db-admin=admin-space" mysql
If a space is mentioned that is not associated with an interface then it will act as the default space (i.e. will be used for any unspecified interface):
juju deploy --bind "default-space db=db-space db-admin=admin-space" mysql
See Concepts and terms for the definition of an endpoint, an interface, and other closely related terms.
For information on applying bindings to bundles, see Binding endpoints within a bundle.
deploy command also allows for the specification of a constraint. Here is
an example of doing this with spaces:
juju deploy mysql -n 2 --constraints spaces=database
See Adding a machine with constraints for an example of doing this with spaces.
You can also declare an endpoint for spaces that is not used with relations, see Extra-bindings.
This example will have MAAS as the backing cloud and use the following criteria:
- DMZ space (with 2 subnets, one in each zone), hosting 2 units of the haproxy application, which is exposed and provides access to the CMS application behind it.
- CMS space (also with 2 subnets, one per zone), hosting 2 units of mediawiki, accessible only via haproxy (not exposed).
- Database (again, 2 subnets, one per zone), hosting 2 units of mysql, providing the database backend for mediawiki.
First, ensure MAAS has the necessary subnets and spaces. Each subnet has the "automatic public IP address" attribute enabled on each:
- 172.31.50.0/24, for space "database"
- 172.31.51.0/24, for space "database"
- 172.31.100.0/24, for space "cms"
- 172.31.110.0/24, for space "cms"
- 172.31.0.0/20, for the "dmz" space
- 172.31.16.0/20, for the "dmz" space
Recall that MAAS has native knowledge of spaces. They are created within MAAS
and Juju will become aware of them when the Juju controller is built
Second, add the MAAS cloud to Juju. See Using a MAAS cloud for guidance.
Third, create the Juju controller, assuming a cloud name of 'maas-cloud':
juju bootstrap maas-cloud
Finally, deploy the applications into their respective spaces (here we use the constraints method), relate them, and expose haproxy:
juju deploy haproxy -n 2 --constraints spaces=dmz juju deploy mediawiki -n 2 --constraints spaces=cms juju deploy mysql -n 2 --constraints spaces=database juju add-relation haproxy mediawiki juju add-relation mediawiki mysql juju expose haproxy
Once all the units are up, you will be able to get the public IP address of one
of the haproxy units (from
juju status), and open it in a browser, seeing the