squish
squish is a novel rootless-only container runtime. The name is never
capitalised, so if it were to come at the start of a sentence, it would still
be written squish.
Why?
squish was born out of frustration with existing container runtimes. They all have their drawbacks (rootful, lack of port rebinds, cache-unfriendliness, slow container starts, ...) that lead to usage thereof being a frustrating experience at best. squish attempts to address these shortcomings.
Preliminary testing shows that squish can get a viable Alpine-rootfs container up in ~5ms. This is an initial figure, and will change over time.
Things that haven't been implemented but are planned
squish also avoids the typical OCI-style container images. The goal of squish is that the only "image" you deploy is a binary, and a manifest with the list of SDKs it uses. At container runtime, the various SDKs are bind-mounted into the container dynamically. Both the rootfs and all SDK layers are mounted read-only.
Roadmap
| Feature | Description | State |
|---|---|---|
| Alpine | Read-only Alpine rootfs | |
| Networking | slirp4netns networking + port binds | |
| Mounts | Bind-mount files and directories ro and rw | |
| Rootless | Containers without root | |
| Container networking | Inter-container networking | TODO |
| Cgroups | Resource limitations etc | TODO |
| Systemd cgroup driver | Set up cgroups via systemd | TODO |
| Layer downloads | Download layers via HTTP | TODO |
| Seccomp | Syscall filtering | TODO |
| Dynamic port rebinds | (Re)bind container ports at runtime | TODO |
What won't be implemented?
- Persistence of containers between daemon reboots
- Getting a shell in a container
Local development
- Set up your environment by running
./setup.sh - Run the daemon with
env RUST_BACKTRACE=1 RUST_LOG=debug cargo run -p daemon - Create a container with
cargo run -p cli -- create test/squishfiles/default.toml - You did it! Read the cli source to learn more commands
Testing
squish currently only has e2e tests. You can run them by running
./test/test-e2e.sh.
Layers and binaries and images and whatnot
squish doesn't have OCI-style container images. Since what actually runs is a
bunch of bind-mounted-together SDKs, your "image" that you push is just a
binary (or tarball, or ...). When actually running a container, you specify its
layer names + tags in your squishfile.toml, as well as optional run + env +
port sections -- and the daemon can put all of it together to figure out what
layers are needed and what command to run. This may seem a bit
counter-intuitive at first, but it's useful for ex. adding a custom debug
layer to containers at creation time, ensuring you have the same tools present
in a container no matter what source layers make it up.
Where did the name come from?
The idea started out as making something like Flatpak for servers -- although squish has significantly diverged since then -- and so the original working name was "squishpak," which eventually shortened into "squish."
Misc
http-asm: https://github.com/poletaevvlad/http-asm