crun VS bocker

Yep pretty much.

The executables bundle crun (a container runtime)[0], and a fuse implementation of squashfs and overlayfs. Appended to that is a squashfs of the image.

At runtime the squashfs and overlayfs are mounted and the container is started.

[0]: https://github.com/containers/crun

cpu: 4 disk: 60 memory: 12 arch: host hostname: colima autoActivate: true forwardAgent: false # I only tested this with 'docker', not 'containerd': runtime: docker kubernetes: enabled: false version: v1.24.3+k3s1 k3sArgs: [] network: address: true dns: [] dnsHosts: host.docker.internal: host.lima.internal # Added: # - containerd-snapshotter: true (meaning containerd will be used for pulling images) # - default-runtime / runtimes: crun (instead of the default 'runc') docker: default-runtime: crun features: buildkit: true containerd-snapshotter: true runtimes: crun: path: /usr/local/bin/crun vmType: vz rosetta: true mountType: virtiofs mountInotify: false cpuType: host # This provisioning script installs WasmEdge and builds crun with wasmedge support: provision: - mode: system script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 echo "Install system updates:" apt-get update -y apt-get upgrade -y echo "Install WasmEdge and crun dependencies:" # NOTE: packages curl git python3 already installed: apt-get install -y make gcc build-essential pkgconf libtool libsystemd-dev libprotobuf-c-dev libcap-dev libseccomp-dev libyajl-dev libgcrypt20-dev go-md2man autoconf automake criu apt-get clean -y - mode: user script: | [ -f /etc/docker/daemon.json ] && echo "Already provisioned!" && exit 0 echo "Installing WasmEdge:" curl -sSf https://raw.githubusercontent.com/WasmEdge/WasmEdge/master/utils/install.sh | sudo bash -s -- -p /usr/local echo echo "`wasmedge -v` installed!" # NOTE: I failed to Configure Wasmtime properly - turned off for now: #echo "Installing Wasmtime:" #curl -sSf https://wasmtime.dev/install.sh | bash #sudo cp .wasmtime/bin/* /usr/local/bin/ #rm -rf .wasmtime #echo "`wasmtime -V` installed!" echo "Install crun:" git clone https://github.com/containers/crun cd crun ./autogen.sh #./configure --with-wasmedge --with-wasmtime ./configure --with-wasmedge make sudo make install crun -v echo "crun installed! Replacing runc with crun:" # NOTE: replacing runc with runc is to simplify containerd config TRC=`which runc` sudo rm -rf $TRC sudo cp `which crun` $TRC echo "Configuring containerd:" sudo mkdir -p /etc/containerd/ containerd config default | sudo tee /etc/containerd/config.toml >/dev/null echo "Restarting/reloading docker/containerd services:" sudo systemctl daemon-reload sudo systemctl restart containerd # As soon as Colima writes its /etc/docker/daemon.json file (right after this provisioning script), # it will also start the Docker daemon. If we stop Docker here, the changes will actually take effect: sudo systemctl stop docker sshConfig: true mounts: [] env: {}

On this note, I was really surprised to find Red Hat's OCI runtime is written in C: https://github.com/containers/crun

Is anyone working on a Rust version?

It's interesting that, in light of things like this, you still see large software companies adding support for new components written in non-memory safe languages (e.g. C)

As an example Red Hat OpenShift added support for crun(https://github.com/containers/crun) this year(https://cloud.redhat.com/blog/whats-new-in-red-hat-openshift...), which is written in C as an alternative to runc, which is written in Go(https://github.com/opencontainers/runc)...

Kubernetes needs an OCI runtime to run containers with. Crun is one implementation it can use.

Docker also appears to be able to use crun for it's engine as well. https://github.com/containers/crun/issues/37

crun

Looks like https://github.com/containers/crun/issues/255 - start there.

A (joke?) one-liner I came up with while thinking about solutions to centralized container management across multiple SSH hosts. Shame on me.

The name is inspired by bocker [0], albeit this doesn't re-implement docker-compose in bash, I found it to be fitting enough.

I'd love to see someone come up with a smarter and/or shorter way to do this.

[0] https://github.com/p8952/bocker

When I did a talk about docker I also wanted to show a bit of what it does under the hood without going through all the layers and without too much details. This ~120 lines of shell script is really good in providing just an intro into what's needed for containers: https://github.com/p8952/bocker/blob/master/bocker

i tried it and like the concnpt, but until it can be launched via a systemd userspace service (without previously manually booting it) among other problems i will keep using docker (or bocker)

> But you couldn't reimplement podman in a few hundred lines of code.

You don't even need a few hundred: https://github.com/p8952/bocker

And then there's 'dokku' which IIRC, started as a bash version of Heroku.

> Not all ideas have the same quality.

They really do. I've heard all kinds of things in my career, but almost none I would want to dedicate a portion of my life building. Not because they are bad ideas or won't work, but because of the person with the idea or it just didn't interest me. Those people went on to be moderately successful (like hundreds of millions worth) but I'm glad I wasn't on that ride.

Bocker is in this same category...docker clone in bash that's helpful in seeing what's really happening underneath with nsenter, namespaces, network bridging, cgroups, etc.

https://github.com/p8952/bocker

Docker implemented in around 100 lines of bash: https://github.com/p8952/bocker

This is the most mindblowing example for enterprise security teams that think Docker is a new threat on a single tenant Linux host.

No, buddies, all this stuff is already there. If you were fine with your visibility before*, you're still fine. Go find a real problem while we play with our developer dopamine.

* NARRATOR: They shouldn't have been.

Bocker[1] does a reasonably good job of showing the value of Docker was mostly in Docker hub.

[1] https://github.com/p8952/bocker

There is a cool project I've seen called "bocker" (https://github.com/p8952/bocker) which is something of a proof of concept of implementing Docker with bash, which speaks a bit to how Docker is indeed in many ways an amalgam of lower level primitives (such as chroot as you mentioned). Pretty neat!