Machine¶
See also: manage-machines
In Juju, a machine is a compute resource requested implicitly (e.g., through juju deploy, juju add-unit, etc.) or explicitly (e.g., through juju add-machine) from a machine cloud.
Important
This definition suggests that, regardless of whether the cloud is a bare metal cloud, a virtual machine cloud, or a LXD container- or VM-based cloud, and regardless of whether the command targets a regular instance or rather a LXD container on a regular instance (all the commands above can apply to both), what’s being provisioned is always, from the point of view of Juju, a ‘machine’.
From the point of view of an end user, this is absolutely true, with one small caveat – even though listed in juju outputs under ‘Machines’, and in general handled via the same CLI commands as a machine, a LXD container provisioned on top of a regular cloud instance will be named after its host machine; e.g., 0/lxd/5 = LXD container 5 on machine 0.
Machines and units¶
When you deploy an application on a machine, there is usually one unit per machine. However, it is usually possible to optimise resources by deploying multiple units of the same or of different applications to the same machine.
Machines and system (LXD) containers¶
In Juju, they are both essentially the same – ‘machines’. For example, most Juju CLI commands that target machines can actually target system containers in the exact same way.
Example
E.g., juju add-machine lxd starts a LXD container on a new machine and adds both as ‘machines’ – the only difference being that the container ‘machine’ is prefixed with the ID of its host machine and the annotation lxd:
$ juju add-machine lxd
created container 1/lxd/0
$ juju machines
Machine State Address Inst id Base AZ Message
0 started 10.154.118.110 juju-dadfb7-0 [email protected] Running
1 pending pending [email protected] Creating container
1/lxd/0 pending pending [email protected]
And if you then deploy an application to a LXD container (without specifying any particular container), that will again provision two machines:
$ juju deploy postgresql --to lxd
Located charm "postgresql" in charm-hub, revision 288
Deploying "postgresql" from charm-hub charm "postgresql", revision 288 in channel 14/stable on [email protected]/stable
ubuntu@charm-dev:~/.local/share/juju$ juju machines
Machine State Address Inst id Base AZ Message
0 started 10.154.118.110 juju-dadfb7-0 [email protected] Running
1 started 10.154.118.72 juju-dadfb7-1 [email protected] Running
1/lxd/0 pending juju-dadfb7-1-lxd-0 [email protected] Container started
2 started 10.154.118.209 juju-dadfb7-2 [email protected] Running
2/lxd/0 pending pending [email protected] acquiring LXD image
Machine designations¶
In Juju, many different commands have a machine argument. The shape of this argument depends on whether the machine is existing vs. new and a regular cloud instance vs. a LXD container on top of a regular cloud instance. The argument can also contain combinations, in comma-separated format. The examples below illustrate all the various cases:
shape of the machine argument |
meaning |
|---|---|
a new machine |
|
|
machine 0 |
|
machines 0 and 4 |
|
a new LXD container on a new machine |
|
a new LXD container on machine 25 |
|
LXD container |
|
machine 3, LXD container 2 on machine 0, and a new LXD container on machine 5 |
Machine customisation¶
A machine’s specific hardware can be customised via constraints.
Machine base¶
Starting with Juju 3.1, a ‘base’ replaces the older notion of ‘series’.
In Juju, a base is a way to identify a particular operating system (OS) image for a Juju machine.
This can be done via the name of the OS followed by the @ symbol and the channel of the OS that you want to target, specified in terms of <track> or, optionally, <track>/<risk>. For example, ubuntu@22.04 or ubuntu@22.04/stable.