## 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.
Common subcommands for all defaults.
- Closes#384.
- Replaces `registry default` and `system dns default` subcommands with
`system property`.
- Users can use `system property ls` to see details about each supported
default value.
- `system property set` implements reasonable validation for all
properties.
- NOTE: Probing of the registry for `registry default set` was removed,
which means users will find out about a botched setting when pulling or
pushing.
- Updates docs.
## Type of Change
- [ ] Bug fix
- [x] New feature
- [x] Breaking change
- [x] Documentation update
## Motivation and Context
See #384.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Fixes https://github.com/apple/container/issues/588. This PR changes the
archiver compression file enumeration to use the
[enumerator(atPath:)](https://developer.apple.com/documentation/foundation/filemanager/enumerator(atpath:))
version. This version returns relative paths instead of full file paths
from the filesystem. /tmp is symlinked to /private/tmp and some swift
packages will handle that path differently. While a call to Foundation's
`URL.resolvingSymlinksInPath()` will return "/tmp", a call to
`FileManager.enumerator(at:)` will return "/private/tmp". This
difference causes a container image build to fail when the user is using
a path under /tmp or other special case paths as the context directory.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [ ] Added/updated docs
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Closes#615.
Improves project organization. Separates service so it can be tested and
used separately from the executable target. No functional changes.
- Closes#557.
- Breaking change: removes `.upToNextOption` for labels on volumes as
this is not what is done for containers, and it forces the argument to
precede the options if a label is supplied, which is non-intuitive.
## Type of Change
- [ ] Bug fix
- [x] New feature
- [x] Breaking change
- [x] Documentation update
## Motivation and Context
Consistent features and UX across managed resources.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
Users frequently saw “failed to find plugin …” when the system services
weren’t running; the message didn’t explain the root cause or where
plugins are looked up. No change to plugin execution flow; only error
messaging and path discovery hints are improved for a better UX.
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Description
Correct signal semantics for plugins: Container binary currently execs
into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers
installed, it can intercept/alter signal behavior intended for the
plugin (e.g., preventing graceful shutdown in foreground workflows).
## Motivation and Context
During the development of a plugin (docker compose compatibility
plugin), I encountered a major issues where CTRL-C (SIGTERM) was not
being sent to my plugin. CLI plugins, especially those that have long
running tasks need a way to handle signals from the OS. Current, we exec
into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers
installed, it can intercept/alter signal behavior intended for the
plugin (e.g., preventing graceful shutdown in foreground workflows).
### What we changed:
- Signals handed back to plugins:
- DefaultCommand resets SIGINT/SIGTERM to defaults immediately before
exec’ing the plugin.
- Rationale: since exec replaces the process image, signals should be
delivered to (and handled by) the plugin without parent interference.
- Non‑plugin commands remain unaffected by this change.
- Compatibility: No change to plugin ABI or exec flow.
### Alternatives considered:
- Supervising child instead of exec: central forwarding of signals from
parent to plugin. Rejected for now to avoid changing process tree/stdio
semantics; resetting to defaults before exec preserves current model
while fixing signal interference.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
## Type of Change
- [x] Bug fix
## Description
Allow kernel set with tar to use relative paths to tar file. Fixes
https://github.com/apple/container/issues/573.
## Motivation and Context
`absoluteString` will prefix a scheme to the file path that looks like
"file://". This will cause file manager to fail to find the file at the
file path even if it exists. Change to instead just get the `path` of
the file, which does not add a scheme prefix.
## Testing
- [x] Tested locally
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] New feature
## Description
Add option to force kernel setting and tests for CLI `kernel set`.
Related to https://github.com/apple/container/pull/575.
## Motivation and Context
This PR adds additional tests to ensure that we can set kernels from
local files, remote tar files, and local tar files. A new option `force`
is added to the `kernel set` subcommand which will overwrite an existing
kernel with the same name if one exists to make testing easier. The
tests ensure that a container can be started with the newly set kernel
and resets to the default recommended kernel when complete.
## Testing
- [x] Tested locally
- [x] Added/updated tests
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] Bug fix
## Description
This PR checks if the found entry in the archive for the requested
kernel path is a symlink, and if so, follows the symlink. I've opened a
separate issue to track creating tests for kernel downloading here
https://github.com/apple/container/issues/574 and will create a
follow-up PR for those.
## Motivation and Context
This PR fixes an issue reported in
https://github.com/apple/container/issues/475 where installing a kernel
from a tar archive does not follow symlinks in the archive.
## Testing
- [x] Tested locally
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] Bug fix
## Description
Resolves#565. Relative paths in type=bind mounts now resolve to
absolute paths instead of being validated as volume names. Added some
tests generated using gen AI for this scenario.
- Fixes#231.
- Extends #313 (@dcantah) so that all of `container create`, `container
run`, `container build`, `container image pull`, and `container image
save` accept the three options.
- `container build` now processes comma-separated lists for
`--platform`, `--arch`, and `--os`. It first checks `--platform`,
assembling the union of all platform values. If that set is non-empty,
the builder builds the values in the set. Otherwise, the set consists of
all combinations of the specified architecture and os values, finally
defaulting to `linux` and the host architecture if no options are
provided.
- All other commands work accept a single platform, preferring the
`--platform` option over `--arch` and `--os` when both are specified.
`--os` defaults to `linux`, and `--arch` defaults to the host
architecture.
- Clarify help messages and present the args in consistent order, with
platform first since it takes precedence if present.
- Deduplicate redundant platform options for `container build`.
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.
Today force deleting (if a container is running then stop()'ing first)
is handled entirely in the cli, which is brittle. The CLI doesn't know
if the container was started with --rm so it would have to do a weird
timeout + list dance to check if the containers gone after stopping.
This change remedies this by just having the daemon take in a `force`
boolean to the delete rpc. If this is provided and the container is
running then we'll stop first, and then cleanup. We can additionally not
cleanup if --rm was provided as the daemon has the data to determine if
a container asked for autoRemove.
- 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.
This PR fixes SSH forwarding for exec processes.
Currently, only init processes received the `SSH_AUTH_SOCK` environment
variable when using `--ssh` flag. Exec processes didn't have access to
the SSH agent socket, even though the socket was mounted.
Now we set environment variable for exec processes to match init process
behavior, ensuring SSH forwarding works consistently across processes,
and refactoring SSH forwarding condition into `hostSocketUrl()` helper
function.
Add `--ssh` flag to forward the host's SSH agent socket into the
container, so we can use SSH authentication for things like cloning
private repos, and also updates the socket path every time the container
starts to handle socket path changes like reboot/re-login.
Closes#498
- Closes#150, #394.
- Introduces `AttachmentConfiguration` type so that we can add key-value
options to `--network` in the future.
- Eliminates redundant `ContainersService.Item` type.
- Since we now ensure at ContainersService that hostnames will not
conflict, the network helper IP allocator now simply provides the
existing IP if for an allocation on an existing hostname, which should
handle (in an eventually consistent way) the case where a container
fails to deallocate an IP on shutdown.
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.
This PR defines the snapshotter protocol
```swift
///Mount a snapshot and all its previous layers
func prepare(_ snapshot: Snapshot) async throws -> Snapshot
/// Commit a snapshot, making it permanent.
func commit(_ snapshot: Snapshot) async throws -> Snapshot
/// Remove a snapshot from snapshot store
func remove(_ snapshot: Snapshot) async throws
```
It updates executors to work with this new protocol
This PR introduces the `Differ` with methods:
```swift
// Differ protocol
func diff(base: Snapshot?, target: Snapshot) async throws -> Descriptor
func apply(descriptor: Descriptor, to base: Snapshot?) async throws -> Snapshot
```
It also introduces `DiffKey`, which is a MerkeTree based key for fast
diff computations between two dirs
Today if you asked for a pty and also wanted to detach we'd open stdin
and then immediately close that pipe which would close the guest relay
as well. I don't believe we need stdin open unless it's asked for with
-i. Truthfully there's one extra bit here that is needed which is if -i
and -d are supplied we need to tell the daemon to open stdin, but not
send an fd (as they're client supplied and the client/cli is going to
exit immediately). That will need to be a followup, as it's mainly
useful for attach which we don't have today.
- 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.
- Part of #384.
- Rename to reflect that these are not just client defaults.
- Relocate so callers don't need the heavyweight coupling to
ContainerClient to access the type.
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
```
Remove the option token from the dockerfile tokenizer for the native
builder. This cleans up some of the logic around handling options
depending on if they're instruction options or user provided options to
a command.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
This PR adds support for CMD and LABEL instructions in the native
builder's parser.
This also changes how options are tokenized. Options now include the raw
string so that when constructing a command for instructions like CMD and
RUN, we can use the exact user input without having to add logic in the
tokenizer to know when we're parsing a command verses other options,
etc.
Closes https://github.com/apple/container/issues/428 and
https://github.com/apple/container/issues/429
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Closes: #314
This change uses the new `.hosts` config entry
on Containerization's LinuxContainer config to setup a default
/etc/hosts file in the container. Today the two entries are localhost to
127.0.0.1 and the container's IP to its hostname.
Fixes#212
This PR:
- adds a `package func resolved()` on `ClientImage` that makes use of
the new `com.apple.containerization.index.indirect` annotation to
identify and resolve wrapper indices created by Containerization;
- replace the digest displayed in `container image list` with the one of
the resolved manifest;
- use the resolved manifest for `container image inspect` if the index
is a wrapper.
We're working on making a pure swift container image build system that
leverages containerization. This PR represents our initial design and
initial work towards this goal.
The native builder is still in active development and most of the
implementation has not been started or completed. We will be opening a
series of issues that represent various (but not necessarily all) pieces
of work that need to be done here.
There are docs included in this PR that describe the overall design of
each component and outline some of our goals. The easiest way to view
the docs by themselves (since this is a massive PR) is to look at the
docs commit in the `Commits` tab.
We'd love any feedback!
@wlan0
---------
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
This matches other container commands that rely on user arguments at the
end, such as `container run`. Closes#395.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Morris Richman