## Type of Change
- [ ] Bug fix
- [x] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Plugins technically exist, but to add shortcuts or to do existing things
with functions in `container` requires calling a compiled binary. This
pull request aims to remove that hurdle and instability by exposing
commands as a new `ContainerCommands ` target.
Simply import `ContainerCommands` and you can access almost
any command as if it were a native part of the binary. This makes
plugin development significantly easier.
Closes#609.
I'm not sure why we had these going to OSLog, but I'd wager they're a
bit more useful being displayed directly to the user during the command
they're running.
We were defer closing the IO for run/exec/start fairly late in the
container run cycle which had the downside of that if the container run
failed your tty would be stuck in raw mode. This change just moves the
closing (return tty to origin state) to directly after we create the IO.
- Sets up API server as source of truth for installation root, similarly
to what was done for the data root. `system start` establishes the
install root, setting the environment variable `CONTAINER_INSTALL_ROOT`
when launching the API server.
- The API server propagates the environment variable when launching
helpers, and returns the install root to the CLI via the health check
XPC.
- Includes several fixes for detecting plugins that use app bundle
layout.
Closes#339.
This change adds named volume support to container, providing volume
management CLI commands - `create, delete, list and inspect`. The
implementation uses EXT4 block-based persistent storage with a new
`VolumesService` actor for thread-safe operations, integrates seamlessly
with the existing container mount system through a new `.volume`
filesystem type, and provides atomic volume operations with XPC-based
API communication. Volumes are stored in isolated directories with
configurable sizes (default 512GB) and include proper cleanup and
container usage tracking for safe deletion.
Example Usage:
```
# Create a volume
container volume create mydata
# Use volume in container
container run -v mydata:/data alpine
# List volumes
container volume list
# Inspect volume details
container volume inspect mydata
# Clean up
container volume rm mydata
```
0.5.0 introduces a new way to configure the containers and execs. This
is now done all upfront at constructor time in a callback style. I'm
very happy with the config improvements, but because IO can only be
setup at constructor time this makes it so that we need to supply IO at
creation time of the VM or exec, which isn't the end of the world. All
that really changes is `boostrap()` and `createProcess()` now take in IO
instead of slightly later in `process.start()`
See discussion below for example. For multiple network interfaces in a
single container we'll want to integrate against a containerization that
includes apple/containerization#156.
The change bumps the containerization dependency to 0.2.0 and addresses
the breaking API changes.
```console
% container network
OVERVIEW: Manage container networks
USAGE: container network <subcommand>
OPTIONS:
--version Show the version.
-h, --help Show help information.
SUBCOMMANDS:
create Create a new network
delete, rm Delete one or more networks
list, ls List networks
inspect Display information about one or more networks
See 'container help network <subcommand>' for detailed help.
```
Closes https://github.com/apple/container/issues/80
Adds the following help message if you try to run `container` against a
host that hasn't started the container system:
```
❯ /usr/local/bin/container list
Error: internalError: "failed to list containers" (cause: "interrupted: "Connection invalid: ensure container system has been started with `container system start`"")
❯ /usr/local/bin/container run -it --rm docker.io/alpine
Error: interrupted: "Connection invalid: ensure container system has been started with `container system start`"
```
Implements a way for the CLI to wait until the IO streams from the
SandboxService have been drained before closing them.
Follows the same pattern as
https://github.com/apple/containerization/pull/110
This change also performs some cleanup in the
`SandboxService.startProcess` method - splitting the code paths to
handle the init process and an exec'd process into two different private
methods to make easier reading
---------
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
This PR adds a warning that the performance may be degraded when running
a debug build.
Debug build:
```
% bin/container run -it --rm alpine:latest date
Warning! Running debug build. Performance may be degraded.
Fri Jun 13 18:10:35 PDT 2025
```
Release build:
```
% bin/container run -it --rm alpine:latest date
Fri Jun 13 18:10:35 PDT 2025
```
The output now looks like the following
#### When build against a tagged HEAD in `RELEASE` mode
```
container --version
container CLI version 0.0.2 (build: release, commit: ed4a4cb)
```
Morris Richman