Introduction
I created this to allow for quicker containerising technology than docker on macOS and for testing purposes, testing deployment, learning the macOS kernel and C.
Description
OSXIEC is a native Docker-like solution for macOS developed by Okerew. It leverages native macOS features to provide containerisation capabilities, albeit with some limitations compared to Docker.
Feautures
OSXIEC provides isolation using namespaces, setuid, image layers, basic user process control, memory and CPU control, and special permissions using user IDs and group IDs, unpacking the image into a disk image(APFS), vlans.
Upcoming feautures
Debugging containers, converting osxiec containers to docker one, Better command isolation.
Notes
- Not a Docker Replacement: While OSXIEC offers similar functionality to Docker, it lacks some advanced features of Docker. It is more supposed to be a quicker testing tool than docker on macos, it is not designed to replace it, just to test basic ideas and software.
- macOS Only: OSXIEC uses native macOS features and is not compatible with other operating systems.
- Isolation Limitations: Due to macOS limitations, complete isolation like in Linux is not possible. The contained directory will have some access to the outside environment, hence no config file is needed.
- Supported Features: Despite its limitations, OSXIEC provides isolation using namespaces, setuid, image layers, basic user process control, memory and CPU control, and special permissions using user IDs and group IDs, unpacking the image into a disk image(APFS), vlans.
- Layer Configuration: Ensure a layers folder exists with specified layers as shown in the example folder.
- Support: Remember that not everything will work for example node won’t work because it is making sys calls which spawn things outside the container.
- Temps: If you need a lot of storage for the moment, and you used a container, delete the dmg in /tmp folder, note these images are also deleted each time the system restarts.
- Why is chroot not used? Chroot requires for SIP to be disabled, which causes many security risks, chroot can be easily exited by any process, using the normal macOS restrictions is way more secure, and reliable it causes many permission issues, apple does not really like it and will probably make it harder to use it later on in the future.
