J Logan
4c800db3fd
## Type of Change - [x] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation update ## Motivation and Context - CI build is failing because runners don't have an /etc/resolver directory, causing the directory monitor to fail. This occurs while the install-kernel make target is running, so it appears that kernel download is failing when it's just that the API server is dying. Created #1207 for the issue. - Fixing the initial scan for the directory just moves the problem to the filesystem watch loop, likely because we're not testing the result of `open()` for errors. - Right now the priority is getting CI running and PRs merged, so just commenting out the realhost DNS server setup. - Also seeing that under some conditions it can take quite a while for launchd to start the helper for the default network (8 seconds or more). With the 10 second health check timeout after API server registration, this means that some CI runs can exhibit this failure mode. Added a `--timeout` option to SystemStart and set a 60 second timeout for install-kernel and integration Makefile targets. - Fixed a bug where `--debug` was being placed in the wrong location in the api server startup args. - Disabled all network CLI tests due to container bootstrap errors when trying to run the container immediately after creating the network. The slow network helper launch could be the reason behind the failures that drove us to serialize these tests. Filed #1206 for this issue. ## Testing - [x] Tested locally - [ ] Added/updated tests - [ ] Added/updated docs
container
container is a tool that you can use to create and run Linux containers as lightweight virtual machines on your Mac. It's written in Swift, and optimized for Apple silicon.
The tool consumes and produces OCI-compatible container images, so you can pull and run images from any standard container registry. You can push images that you build to those registries as well, and run the images in any other OCI-compatible application.
container uses the Containerization Swift package for low level container, image, and process management.
Get started
Requirements
You need a Mac with Apple silicon to run container. To build it, see the BUILDING document.
container is supported on macOS 26, since it takes advantage of new features and enhancements to virtualization and networking in this release. We do not support older versions of macOS and the container maintainers typically will not address issues that cannot be reproduced on the macOS 26.
Install or upgrade
If you're upgrading, first stop and uninstall your existing container (the -k flag keeps your user data, while -d removes it):
container system stop
/usr/local/bin/uninstall-container.sh -k
Download the latest signed installer package for container from the GitHub release page.
To install the tool, double-click the package file and follow the instructions. Enter your administrator password when prompted, to give the installer permission to place the installed files under /usr/local.
Start the system service with:
container system start
Uninstall
Use the uninstall-container.sh script (installed to /usr/local/bin) to remove container from your system. To remove your user data along with the tool, run:
/usr/local/bin/uninstall-container.sh -d
To retain your user data so that it is available should you reinstall later, run:
/usr/local/bin/uninstall-container.sh -k
Next steps
- Take a guided tour of
containerby building, running, and publishing a simple web server image. - Learn how to use various
containerfeatures. - Read a brief description and technical overview of
container. - Browse the full command reference.
- Build and run
containeron your own development system. - View the project API documentation.
Contributing
Contributions to container are welcomed and encouraged. Please see our main contributing guide for more information.
Project Status
The container project is currently under active development. Its stability, both for consuming the project as a Swift package and the container tool, is only guaranteed within patch versions, such as between 0.1.1 and 0.1.2. Minor version number releases may include breaking changes until we achieve a 1.0.0 release.