tracker
tracker copied to clipboard
turnkeylinux
[TKLDev] Support running TKLDev inside a container
Currently TKLDev will not run inside a container (e.g. LXC, OpenVZ, Docker, etc) due to it's use of AuFS OverlayFS.
It would be good if TKLDev wasn't limited in this way.
I have run it as OVF. Is that a "container" per say? Evidently not, but rather a quick template.
ACTUALLY, now that I think of it, I am not getting good builds. I did get a build last week, but fresh installs, not (Wheezy). ISOs some more success. (difficult to attribute however) Crashing on OVF Wheezy TKLDEV Core even.
Generally VMware products. VirtualBox and KVM provide (and are used for) what is referred to as 'full virtualisation'. It essentially provides the OS with a range of 'virtual computer hardware'. A similar but different virtualisation is 'para-virtualisation' (e.g. Xen) which provides greater access to a the real hardware but requires modification of the OS to run. Historically para-virtualisation provided much better performance. This is changing and even Xen is moving to 'full virtualisation'. It is the way things will go in the future IMO.
OTOH containers (also known as OS level virtualisation) are quite different. They are purely software based and provide no true virtualisation at all; instead they piggy back on the host OS (i.e. they do not have their own kernel etc). The advantages of this are huge as it means that resources aren't wasted providing the virtualisation layer. However the downside is that you can only use an OS similar to the host. I.e. generally containerisation is limited to Linux OSes. Also you can only access hardware that the host OS can access.
:+1:
I would also say: Improve TKLDev to build Docker images for each product (besides building ISO images)
This requires a Docker image for the TKLCore, and then a Dockerfile for each product that is built on top of TKLCore. Maybe it needs some radical changes/improvements in the way that fab works.
@dashohoxha - You might want to have a look at buildtasks. That's how we build our docker images (see bt-docker). It converts an ISO into a docker container (and uploads it to docker hub) It's sort of a hacky way, but it works... So if you want to build a docker image of an existing appliance it will download the ISO; otherwise you build the ISO first (using bt-iso).
I know that for end users it'd be quicker/easier to just build the docker container (or whatever build type they wanted) off the bat; but buildtasks was designed for our (internal) workflow.
Building a Docker image from an ISO image is, as you say, a hackish solution, it does not use the powerfull features of docker. The other way around would seem to me more reasonable (building iso images from docker images).
Docker has features that allow layered filesystems (maybe they use aufs internally), which could replace deck, fab-chroot, etc. It also allows to kind of extend one image (appliance) from another one, by installing/removing some packages, customizing configurations, etc. In short, it has all the features to develop turn-key solutions, which can be deployed (installed) easily.
So, I think that it could be a good foundation for building TKL appliances.
I'm re pinning this to v14.2 for now...
@dashohoxha Containerisation is definitely the go but at this point we would want to support TKLDev working inside any/all host systems, be they docker, LXC, nspawn, whatever... I guess Docker could do that but for now we have a workflow that works.
Re-designing our approach to building images is a major undertaking. Not that we shouldn't do it; we're going to need to at some point. But we shouldn't do it lightly...
Now there is an open container standard things should hopefully get easier WRT supporting different containers...
I have developed a docker script framework: https://github.com/docker-scripts/ds I am not sure how compatible it is with the TKL workflow, but at least you can pick up some ideas or details to help you with the containerization process.
Hi @dashohoxha - Thanks for sharing. :+1: That looks pretty cool. I'll have a play when I get a chance.
As of v15.0 (not yet released) it should be possible to use TKLDev in a privileged container. However, I'm going to leave this issue open for now as I haven't 100% confirmed with extensive testing. So I'm going to move this issue to v15.1 for further testing and/or discussion.