How to set constraints for an application

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 get-constraints command:

juju get-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 get-constraints and set-constraints commands work with application custom names. See Deploying applications for how to set a custom name.

Last updated 5 months ago.