## 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#1647.
- `id` will become a system assigned (Docker-like) identifier
for the managed resource, and `configuration.name` is the
user-assigned name.
Normalize JSON output for network and volume resources. (#1624)
- Reworks both JSON output presets to use sorted keys, ISO timestamps.
`compact` is used for `ls` output, and `pretty` is used for `inspect`.
- Extracts non-DRY option configuration into presets.
- Closes#1623.
- Refactor network model types: replace `NetworkState` enum and
phase-based NetworkStatus with a flat `NetworkStatus` struct.
- Simplify API server ↔ plugin protocol: plugin `status()` returns
runtime status only, API server owns configuration.
- `NetworksService` `list()`/`create()` now return `NetworkResource`
directly.
- Remove lifecycle phase checks and state machine guards throughout CLI
and API server.
- `variant` is plugin-specific, it's not a required property. This PR
replaces `NetworkPluginInfo` with a `plugin` name property on
`NetworkConfiguration` and an `options` list similar to that for
volumes.
- Moved `variant` to the option list.
- Part of #1404.
- Updates containerization to 0.33.2.
- Reorganizes network plugin targets into:
- `ContainerNetworkClient` - network plugin client and default types
- `ContainerNetworkServer` - separate protocols for `Network` which
manages the underlying virtual network, `NetworkService`, which takes a
network and implements the API, and an actor `NetworkHarness` that
marshals between the API and the XPC protocol. The service-harness
separation will help us ensure XPC protocol compatibility in both
directions as we evolve the plugin APIs.
- Removes `disableAllocator()` which is no longer used since #1545
switched over to using XPC connections between runtime and network
plugin instances to track whether a network has attached containers.
- 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.
## Type of Change
- [ ] Bug fix
- [x] New feature
- [ ] Breaking change
- [x] Documentation update
## Motivation and Context
Adds the `container copy` (aliased as `cp`) command to copy files
between a running container and the local filesystem.
I saw [#1023](https://github.com/apple/container/pull/1023) and the
feedback from @dcantah — the previous attempt relied on tar being
installed inside the container.
This implementation takes the recommended approach:
file transfers go through the guest agent via the existing
`copyIn`/`copyOut` methods on the core `Containerization`, with no
dependency on container tooling.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
---------
Co-authored-by: jwhur <57657645+JaewonHur@users.noreply.github.com>
- This adds support for reading configurations from
a three layer hierarchy:
1. User provided TOML
2. Install root TOML
3. Code defaults
- We add some code to support plugin configurations
via the ConfigurationLoader. Each plugin can provide
a struct with an accompanying id that gets used to
parse the scoped section of the TOML.
- Part of #1318.
- Part of #1378.
- `RouteHandler` now accepts an additional `XPCServerSession` which
include a disconnect handler.
- `XPCServer` configures a session for each client connection and passes
it to every route handler.
- `XPCServer.route(fn:)` can be used to wrap existing route handlers
that don't care about sessions.
- `XPCClient` adds functions to support client-side session handling.
- Update all existing routes.
- Discussion topic #1336.
- This change migrates away from using `UserDefaults`,
instead providing a TOML configuration mechanism for
user configurable settings. All existing system property
settings keys are supported in the new configuration
file. However, users will have to migrate any settings
they have configured in the `UserDefaults` into TOML
for these settings to take effect.
- Breaking changes:
* `container system property get` is removed in favor of
users directly utilizing `container system property list --format toml | jq<>`.
* `container system property set` is removed since the TOML
configuration is effectively immutable during the lifetime of the
`container` daemon. Uses can edit the TOML they have in their home
directory, however no changes will take effect until the daemon is
restarted via `container system stop && container system start`
* `container system property list --format table` is removed as
generating tabular format is non-trivial and the new TOML format is
intended to be human readable
- A recent change moved the list and delete
network XPC calls within an availability check,
making them only available on macOS 26.
However, there are some code flows that rely
on being able to call `list` on the NetworksService,
including anything that uses `networkClient.builtin`.
- `container` does not officially support macOS 15
and as a result we do not have GitHub action runners
for validation on macOS 15. That said, we try to avoid
breaking compatibility on macOS 15 as much as
possible.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Closes#1450.
- If we require that bundle-packaged installs must populate a
Unix-structured `bin` and `libexec`, we don't need the code that
searches the app bundle install root. As it stands, we enumerate both
the app bundle and the Linux paths, meaning we're looking at the same
plugins (in different paths) twice.
This changes the semantics around `ReservedVmnetNetwork` and
`AllocationOnlyVmnetNetwork` to only create ipv4/6 subnets for networks
when the values are explicitly passed in the `NetworkConfiguration`.
Previously if the values in the `NetworkConfiguration` were not present
it would attempt to source them via `DefaultsStore`.
## Type of Change
- [X] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
The change solves an issue that caused `container network create <name>`
to fail when `UserDefaults` was set to a value that is identical to the
hard coded default ("192.168.64.1/24"/"fd00::/64"). It would fail
because a network with these parameters would already exist, and thus
could not be reserved.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
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
- Part of #1404.
- COMPATIBILITY: Breaking change to client API. XPC protocol and
persistent data remain fully compatibile.
- Renames `ClientNetwork` to `NetworkClient`, aligning with
`ContainerClient`.
- Client uses instance methods instead of utility functions, with an
`init(serviceIdentifier:)` for the XPC service name. The value is
currently unused.
- Closes#1359.
- Create a ResourceLabels type and extract the label validation from
NetworkConfiguration into the new type.
- Create a base AppError type that is compatible with structured logging
and delegates message presentation to the error receiver.
- Define LabelError over AppError for label validation.
- Slightly reworks NetworkConfiguration entity migration code in
NetworksService.
Kathryn Baldauf