Yes critical to this is to get the graphdriver (COW File Systems) out as a separate package. graphc so to speak. We are working on this.
Once you have graphc you can mount up an image in any of the backends that Docker supports, Devmapper, Btrfs, overlayfs and run a container on them. What would we need next to save a layered image? On 10/30/2015 05:15 PM, Muayyad AlSadi wrote: > > this using runc? > ok let it be runc instead of lxc > > so can we have docker-like dockerlite with *devicemapper* and runc ? > > the idea would be to make use of docker way of saving space with > layers ..etc. (running several containers from same image, saving > space by layers ..etc.) > and support the rich community of images and the ecosystem of build-tools > > > > > > > On Fri, Oct 30, 2015 at 11:08 PM, Daniel J Walsh <dwa...@redhat.com > <mailto:dwa...@redhat.com>> wrote: > > > > On 10/30/2015 04:58 PM, Muayyad AlSadi wrote: > > Hi, > > > > dockerlite is way to provide minimal docker features using > scripts on > > btrfs and lxc > > > > https://github.com/docker/dockerlite > > > > maybe it was aimed to demonstrate how simple docker can be > implemented. > > but I like that the idea of having containers independent of the > daemon > > (ie. we can run non-root containers and containers do not die > when the > > daemon restarted) > > > > I like to see such project that uses > > > > 1. device mapper instead of btrfs > > 2. use systemd-nspawn instead of lxc > > 3. use systemd's @ and dbus > > > > for example docker events api can be implemented as wrapper of dbus > > > > docker run -d foo > > > > will redirect to > > > > echo "whatever=whatever" > /etc/sysconfig/dockerlite/123.rc > > systemctl start dockerlite@123.service > > > > > > > This looks kind of dead, why not look at implementing something like > this using runc? > >
