An option to explore is CoreOS' rkt.

It was designed to work natively with the containerization capabilities of systemd, so the most obvious advantage over docker is that it doesn't need it's own service.

kubernetes and others have a lot of the features from newer Docker releases (orchestration and such) that the blog post talks about. For just plain containers, there's also rkt.

There are alternative - but compatible with docker - container engines in the works (well, not sure how feature complete they are, but definitely dont have the mindshare that docker does) that are designed to be much more secure.

For example podman lets you run containers as a normal user. The traditional user-id based file restrictions apply to any containers you launch. rkt does something similar too.

Neither Vagrant nor Docker work in a Crouton chroot. But I was able to install and use rkt (container runtime from CoreOS which can run Docker images). The only gotcha is that you have to use host networking, the virtualized networking modes do not work.

The info on ACI you're looking for might be here: https://github.com/appc/spec/blob/master/spec/aci.md#image-archives

A guide for getting started building images with rkt, is here: https://coreos.com/rkt/docs/latest/getting-started-guide.html

This guide links to a few different ways to build rkt images: https://github.com/rkt/rkt/blob/master/Documentation/trying-out-rkt.md#building-an-app-container-image

As far as a standard way to build the image, docker2aci might be easiest for now. As it's noted on the rkt/rkt page, the project is working towards OCI compatibility. So, may not be worth it to get too deep in the appc spec. It's likely to be succeeded by OCI.

docker just uses cgroups, network namespaces and filesystem namespaces(which function as a more advanced version of chroot). If you want something more lightweight than docker look into systemd-nspawn or even better rkt

Check out rkt - it’s a container runtime built by CoreOS because of the underlying security concerns outlined in this thread. It uses systemd to manage containers that are launched as separate processes vs run by a daemon with root privileges. It also works with Dockerfiles and is compatible with docker.

> That would be fine, but this composable functionality (namespacesl is usually used one way.

Runtimes like rkt, docker, oci-d, nspawn, etc, etc. All do things a little bit differently and that's a good thing because they can target different use cases or explore different avenues of solving particular problems.

Namespaces and cgroups are basically just the objects that your container runtime are probably going to want to use at some point in the course of doing its thing.

Namespaces themselves are independently useful which is why pam_namespace is a thing. It's also within reason to think sharing/unsharing functionality would be useful in running some sort of un-containerized daemon process. There's also the possibility of unforeseen use cases that just aren't issues yet and in that scenario we may wish we hadn't bundled everything together.

It's really not a mess at all, it's just that the unifying logic is in the container runtime rather than in the kernel. Which is fine. Moving the code from runtime to kernel just changes its location without much benefit and in the process threatens to make it more rigid or try to get people to do things a particular way when that might not be the way that works best for them in their case.

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "rkt"

^Please ^PM ^/u/eganwall ^with ^issues ^or ^feedback! ^| ^Delete

What do you mean? If you use Crouton you can use containers. Heck you have containers even without using Crouton.

The big difference is with Crouton you are using a true chroot. When using containers on ChromeOS without Crouton you have to use a fake chroot.

So what is unfortunate is the Docker Daemon needs a true chroot. Really should not be necessary but what it is. People have been pushing Docker to fix this for other reasons and Chromebooks users would just benefit.

If you want to run Docker on your Chromebook with Crouton.

sudo startcli sudo apt install iptables libnfnetlink0

... install rkt with https://coreos.com/rkt/docs/latest/distributions.html#deb-based

sudo rkt run --net=host docker://redis --insecure-options=image

Rkt can run any docker image: https://coreos.com/rkt/docs/latest/running-docker-images.html

The difference is largely in the architecture https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html

For the latest see my video from a few days ago: https://youtu.be/JgUEXKTSVXw

It can also run OCI and appc images as well but as you saw appc is not being developed in favor of OCI.