## Type of Change
- [ ] Bug fix
- [x] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
`container` runs each workload in an ephemeral VM, so there's no
built-in way to keep a persistent Linux environment you can log into and
work in. `container machine` adds one.
A container machine is a lightweight, persistent, and integrated Linux
environments that feel like an extension of your Mac, created from
standard OCI images with a familiar UX. The login user matches your host
account with passwordless `sudo`, your home directory is mounted inside
the VM, and each machine keeps its filesystem and runs the image's own
init system (such as`systemd` or `openrc`).
```bash
container machine create alpine:3.22 --name my-machine
container machine run -n my-machine # interactive shell
container machine set -n my-machine cpus=4 memory=8G
```
Subcommands: `create`, `run`, `list` (`ls`), `inspect`, `set`,
`set-default`, `logs`, `stop`, `delete` (`rm`); `m` aliases `machine`.
Docs added to `docs/command-reference.md` (Machine Management) and
`docs/how-to.md` ("Use container machines").
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
Signed-off-by: Raj Aryan Singh <rajaryan_singh@apple.com>
Co-authored-by: Jaewon Hur <jaewon_hur@apple.com>
Co-authored-by: John Logan <john_logan@apple.com>
Co-authored-by: Michael Crosby <michael_crosby@apple.com>
Co-authored-by: Eric Ernst <eric_ernst@apple.com>
Co-authored-by: Danny Canter <danny_canter@apple.com>
- Closes#1557.
- Replaces `executableURL` utility function for getting app executable
path with `executablePath`.
- Adds `FilePath.resolvingSymlinks()` extension.
- Also converts for FilePath for types in `ContainerVersion` target.
This change migrates plugin config format away from using JSON to use
TOML.
- Addresses the plugin portion of discussion #1336
## Type of Change
- [ ] Bug fix
- [X] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Context within https://github.com/apple/container/discussions/1336
> We're looking to improve the user experience and overall functionality
of setting defaults for container to better enable future use cases.
>
> Today container uses macOS's
[UserDefaults](https://developer.apple.com/documentation/foundation/userdefaults)
to configure settings needed at runtime. As mentioned in
https://github.com/apple/container/issues/608, UserDefaults may be
idiomatic for macOS, but they apply globally to all sessions and do not
handle representing complex, hierarchical data well. Additionally, we
currently have two ways of setting these defaults, either directly with
macOS's defaults command or through container system property.
>
> https://github.com/apple/container/issues/608 proposes moving to use
environment variables in place of UserDefaults. However, we do not
believe this is sufficient. Environment variables are not in a
consistent location, are not sourced from data, and also do not handle
representing complex, hierarchical data well.
As part of this migration to TOML for user settings we want to also move
plugin settings to use TOML so that we can have a singular file format
for `container` configurations.
## Testing
- [X] Tested locally
- [X] Added/updated tests
- [ ] Added/updated docs
This PR adds a feature passing resource directory for the plugins.
When a `resources` directory is detected under the plugin's
`installURL`, the path to `resources` directory is passed as an argument
(i.e., `--resources <path>`) to the plugin `start`.
Resource files are distributed and installed together with the
`container` binary.
## Type of Change
- [ ] Bug fix
- [X] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Plugin developers can convey resource files (e.g., shell scripts) under
the `resources` directory.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
This PR reaps already running containers with auto remove flag on
container system start.
Container API server shutdown ideally should stop every running
container, and reap the containers with auto remove flag. However, crash
or unexpected exit of API server leaves the containers running. In such
case, next system start should stop running containers (i.e., launchd
services) and reap the containers with auto remove flag.
## Type of Change
- [X] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Preserve the system to be in a consistent state after unexpected
failure.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
---------
Co-authored-by: Raj <realrajaryan@gmail.com>
- Adds a a `--log-root` option to `swift system start`, propagating the
value as `CONTAINER_LOG_ROOT` to services for logging to files instead
of the OS log facility. This is not a "production" capability as it
neither merges nor rotates logs.
- Currently we don't collect logs on CI builds, and we don't have
permission to run the `log` command there. The PR adds `--log-root` to
the CI test phase, archives the results, and uploads the archive as an
artifact.
- Use FilePath from swift-system for the log root. Foundation URL is a
bit of a footgun for filesystem paths, so unless we identify a
showstopper, we should incrementally transition to this type everywhere
except where we really need network URLs.
- Output the hostname of the CI runner at the start of the test phase so
we can identify runner-specific issues where they exist.
- Fix formatting for log messages with multiple metadata items, and fix
unstructured messages on instances that weren't found using `grep -r
'log\.' Sources`.
- Adds command reference documentation for `--log-root`.
- Closes#1206.
- Closes#1185.
- Closes#507.
- Addresses existing log messages for #642.
- Nondeterministic CI errors are resulting from very slow launch times
for the first runtime helper, which causes ContainersService to be
locked for longer than our 20 sec timeout. Bumping the timeout to 60
seconds addresses this case for now.
- Since many log messages needed to be changed to troubleshoot the
issue, updated all log messages to use structured logging, and
implemented consistent entry/exit logging for all service operations.
- Added logging for ContainerService lock acquisition to help with
finding root cause for the slow service startup.
- Plumbed the `--debug` flag on both `container system start` and
`container system logs` so that the flag is actually useful.
- Updated the `install-init.sh` script so that can install in a custom
app root directory.
## Type of Change
- [x] New feature
- [x] Breaking change
## Motivation and Context
This PR changes the behavior of the `defaultArguments` field in the
service plugin config. Previously, `defaultArguments` was functioning as
a way to indicate how to start a plugin in the event that the plugin is
loaded at boot (such as for the `container-core-images plugin`).
However, we now follow a convention where all plugins have a "start"
command that is used when launching the plugin, so this
`defaultArguments` field wasn't really providing much. Instead, there
are use cases where we may want to set default values to pass to a
plugin. This PR repurposes the `defaultArguments` field for those use
cases.
As an example use case, there are scenarios where someone may want to
use the AllocationOnlyVmnetNetwork even when running on macOS 26+. This
PR adds the ability to pass in a command line option to the vmnet
network plugin to specify that request. Combined with the
`defaultArguments` plugin config change, a user may choose to set that
field to ["--variant", "allocationOnly"] in the
`container-network-vmnet-config.json` to use AllocationOnlyVmnetNetwork
by default for all networks.
## Testing
- [x] Tested locally
- #859 added the traversal necessary to load the app bundle but forgot
to resolve symlinks. This fix adds the resolution, making it possible to
get default system properties from an app bundle Info.plist even if the
user invokes a command from, for example, `/usr/local/bin/container`
which is a symlink to the actual install path of the bundle.
- Also fixes bugs where an incorrect executable path was supplied in
some calls.
- Breaking change: `CommandLine.executablePathUrl` extension moved from
ContainerPlugin to ContainerVersion.
- This helps with brew cask packaging, can postflight link
libexec/container/plugins to the appropriate cask location, and the
plugin discovery will traverse the link.
- 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.
Raj