See also:
juju deploy --constraints,juju constraints,juju set-constraints
Constraints at the application level can be set at deploy time, via the deploy command. To deploy the mariadb charm to a machine that has at least 4 GiB of memory:
juju deploy mariadb --constraints mem=4G
To deploy MySQL on a machine that has at least 6 GiB of memory and 2 CPUs:
juju deploy mysql --constraints "mem=6G cores=2"
Multiple constraints are space-separated and placed within quotation marks.
To deploy Apache while ensuring its machine will have 4 GiB of memory (or more) as well as ignoring a possible cores constraint (previously set at either the model or application level):
juju deploy apache2 --constraints "mem=4G cores="
For the LXD cloud, we deploy PostgreSQL using a combination of an instance type and a specific CPU constraint. Below, instance type c5.large maps to 2 CPUs and 4 GiB, but the specific memory constraint of 3.5 GiB yields a machine with 2 CPUs and 3.5 GiB of memory:
juju deploy postgresql --constraints "instance-type=c5.large mem=3.5G"
To deploy Zookeeper to a new LXD container (on a new machine) limited to 5 GiB of memory and 2 CPUs, execute:
juju deploy zookeeper --constraints "mem=5G cores=2" --to lxd
To deploy two units of Redis across two AWS availability zones, run:
juju deploy redis -n 2 --constraints zones=us-east-1a,us-east-1d
An application’s current constraints are displayed with the constraints command:
juju constraints mariadb
An application’s constraints are updated, thereby affecting any additional units, with the set-constraints command:
juju set-constraints mariadb cores=2
An application’s default cannot be set until the application has been deployed.
Both the constraints and set-constraints commands work with application custom names. See Deploying applications for how to set a custom name.