[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Status of containerizing docker and https://github.com/projectatomic/atomic-system-containers



Colin Walters <walters verbum org> writes:

> Does anyone know what the status of
> https://github.com/projectatomic/atomic-system-containers
> is in general, and in particular I'm interested in the
> "containerized docker" approach.
>
> Can someone who knows a bit more about this add
> e.g. a `README.md` with getting started instructions?

We have tried different solutions to get it done, the current version in
atomic-system-containers is using a chroot for running the Docker
container, but I don't really like this approach and anyway it brings
its own set of issues as maintaining/creating the rootfs for the
container manually.

Yes, it is a bit messy, I am going to work on this and try to make it
clearer.  The gscrivano/docker-fedora and gscrivano/docker-centos
containers are based on the PR here:

  https://github.com/projectatomic/atomic-system-containers/pull/38

As soon as it gets a bit more stable, we will need to move somewhere
else than my Docker hub account, as we did for Flannel and etcd.

The biggest issue is how to support live-restore.  Docker remounts
/var/lib/docker/devicemapper/* as MS_PRIVATE when it runs, so whatever
mount it creates there, it will not be accessible once the namespace is
destroyed without some dirty tricks.
I've filed an issue for Docker upstream, as in general it is not
possible to run Docker in its own mount namespace and support
live-restore (could be useful even for things like systemd
InaccessiblePaths=):

  https://github.com/docker/docker/issues/31489

There are some workarounds in the PR, but I got it to work somehow.  The
limitation is that you can't exec in a Docker container that is living
more than two Docker containers update (as a system container keeps only
two deployments).  The reason for this limitation is that when you do
"docker exec ...", it will use the runc that was installed as part of
the system container deployment that after two updates is removed.

I wouldn't worry too much of it for now. IIUIC in libcontainerd
master there is some work to let the shim process attached to a docker
container do the exec itself, so we won't have the limitation with
upgrading the Docker system containers as won't be required to run runc
from the mount namespace the container was created.

> # atomic host status
> State: idle
> Deployments:
> ‚óŹ fedora-atomic:fedora-atomic/25/x86_64/docker-host
>              Version: 25.80 (2017-03-13 23:35:50)
>               Commit: 24d4499420ffb2cc49681020bbe5aa6780d780d2b811eab1f5ffea6446b5a4c5
>               OSName: fedora-atomic
> # atomic install --system gscrivano/docker-fedora
> # systemctl start docker-fedora
> ...
> Mar 15 16:02:02 localhost.localdomain runc[4867]: container_linux.go:247: starting container process caused "process_linux.go:359: container init caused \"rootfs_linux.go:89: jailing process inside rootfs caused \\\"pivot_root invalid argument\\\"\""

looks bad, I am going to have a look.

Regards,
Giuseppe


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]