Machines and Containers

Machines and containers

If one thing on this page is worth reading, it is this — and an earlier version of this page got it backwards, so if you learned the old story here, this corrects it.

The short version

Machines and containers are siblings, not nested. A container does not run inside a machine you created, and you cannot put one there.

Your Mac cannot run Linux containers directly, so Apple's container gives each container its own lightweight Linux VM, created when the container starts and gone when it stops. A machine is a separate thing: a Linux VM you make and keep, and shell into yourself.

your Mac (macOS)
├── container  nginx      ← its own VM, made for it
├── container  redis      ← its own VM
├── machine    dev        ← a VM you made and kept
└── machine    scratch    ← another one

How we know

Measured on this Mac, not inferred:

• Both machines were stopped — including the one marked default — and a container still ran normally.
• Neither machine started as a result.
• The container took its own address on the same bridge as the machines: buildkit on 192.168.64.6, the two machines on .7 and .8, the new container on .13. Sequential neighbours on one network, not one thing inside another.
• container run has no flag for choosing a machine, and a container's own inspect output never mentions one.

Do I have to care about Machines?

No. You can run containers, build images, use volumes and networks, and never open the Machines section. Nothing there is required for any of it.

Then what is a machine for?

A small persistent Linux box on your Mac that you can get a shell in. It survives across reboots of your own choosing, you set its CPUs and memory, and it can mount your home directory. Useful when you want a Linux userland to poke at — compile something, test a shell script, try a package — without it being tied to a container's lifetime.

If that is not something you need, you will not miss it.

What a machine is not

It is not Vagrant, Lima or UTM, and it will not become them. A machine's root filesystem is a container image, and the kernel comes from Apple's runtime. That is why:

• images come from registries like Docker Hub rather than from a box catalogue;
• a machine's disk shows as tens of megabytes, not gigabytes;
• there is no installer, no bootloader and no /boot.

If you want a real Ubuntu or Fedora VM, use Lima, UTM or Vagrant. That is the right tool for that job, and this is not it.

Which images boot as a machine

Use alpine.

Narrower than you would expect. ubuntu, debian and fedora are perfectly good container images and do not boot as machines — each pulls around 100 MB, creates a machine record, and dies. They expect a full boot sequence and an init system that is not there.

Flotilla's create form only offers images that have actually been booted successfully, which is why the list is short. See Machines.

Resources

A container's CPUs and memory are its own, because a container is its own VM. They are not a share of some machine's total, and a machine's size does not cap a container.

A machine's CPUs and memory belong to that machine and to whatever you run inside it by hand.

Set as Default

container records one machine as the default. Its own documentation says only "Set the default container machine" and does not say what the default affects — so this page will not guess. What it certainly does not do is decide where containers run, because nothing does.

Where the other things fit

• Images are what containers are made from, and also what a machine's filesystem is made from. They live on your Mac.
• Volumes are storage that outlives a container — see Volumes and networks.
• Networks give containers their own addressing so they can reach each other by name.
• The Terminal tab opens a shell inside a container. A machine's Terminal tab opens a shell inside that machine. Both are real shells, in two unrelated places. See Terminal.