How to deploy to a specific machine
To deploy to specific machines the --to option is used. It is supported by commands bootstrap, deploy, and add-unit. This option, along with an argument, is called a placement directive.
When the --to option is used, unless the machine was created via add-machine, a charmed operator has already been deployed to the machine. When multiple charmed operators are deployed to the same machine there exists the chance of conflicting configuration files (on the machine’s filesystem).
There is one type of placement directive that can also be used as a constraint: availability zones. If used together, the placement directive takes precedence. See Using constraints for details.
To apply this option towards an existing Juju machine, the machine ID is used. This is an 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
The above works well with deploy and add-unit as will be shown below. As for bootstrap the --to option is limited to either pointing to a MAAS node or, starting in v.2.5.0, to a LXD cluster node.
Assuming a MAAS cloud named ‘maas-prod’ exists and has a node called ‘node2.maas’:
juju bootstrap maas-prod --to node2.maas
Assuming a LXD cluster cloud named ‘lxd-cluster’ exists and has a node called ‘node3’:
juju bootstrap lxd-cluster --to node3
Contents:
deploy --to
To deploy the ‘haproxy’ application to machine ‘2’ we would do this:
juju deploy --to 2 haproxy
Below, the --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 three different ways:
juju deploy mariadb --to lxd
juju deploy mongodb --to lxd:25
juju deploy nginx --to 24/lxd/3
In the first case, mariadb is deployed to a container on a new machine. In the second case, MongoDB is deployed to a new container on existing machine ‘25’. In the third case, nginx is deployed to existing container ‘3’ on existing machine ‘24’.
Some clouds support special arguments to the --to option, where instead of a machine you can specify a zone. In the case of MAAS or a LXD cluster a node can be specified:
juju deploy mysql --to zone=us-east-1a
juju deploy mediawiki --to node1.maas
juju deploy mariadb --to node1.lxd
For a Kubernetes-backed cloud, a Kubernetes node can be targeted based on matching labels. The label can be either built-in or one that is user-defined and added to the node. For example:
juju deploy mariadb-k8s --to kubernetes.io/hostname=somehost
add unit --to
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 3 --to host1.maas,host2.maas,host3.maas
If the number of values is less than the number of requested units the remaining units, as per normal behaviour, will be deployed to new machines:
juju add-unit rabbitmq-server -n 4 --to zone=us-west-1a,zone=us-east-1b
Any surplus values are ignored:
juju add-unit rabbitmq-server -n 2 --to node1.lxd,node2.lxd,node3.lxd
The add-unit command is often associated with scaling out. See the Scaling applications page for information on that topic.
Last updated 10 months ago.