Auto-generate Gentoo docker images

[globalcitizen]

It could be useful to use lxc-gentoo to generate docker images.

Build method Basically all that a docker image generation based on lxc-gentoo would need to do is:

# specify which architecture and variant you would like to build
ARCH=amd64
ARCHVARIANT=hardened+nomultilib
# run in non-interactive mode (will generate gentoo/ and gentoo/rootfs subdirs)
./lxc-gentoo create -q

... then ignore the generated lxc.conf and run a command similar to the following to convert the root filesystem image generated in to a docker image base layer.

# tarball everything from gentoo/rootfs and pipe to docker import
# in order to create a new docker image base layer
sudo tar -C gentoo/rootfs -c . | docker import - gentoo-${ARCH}-${ARCHVARIANT}

In any event, something very close to this process should work just fine.

Additional optimizations would be to tweak openrc and inittab for a docker use-case.

Scheduling Triggering could be achieved either:

1. Automatically upon commit, if the build passes; or
2. Via a secondary on-commit hook executed elsewhere (which would help to keep credentials and process segregated); or
3. Via some polling process, whereby updates to lxc-gentoo that pass testing, updates to stage3 or updates to any packages in portage pre-installed within stage3 all trigger an automated rebuild.

Output structure A separate Data Volume Container for the portage tree could easily be auto-generated based upon polling for portage tree updates.

In any event, it seems docker is here to stay and the automated provisioning of such an image (or a range of such images) would be a good service for the Gentoo community.

There seems to be an existing effort at gentoo/gentoo-docker-images however at a glance it appears to lack a lot of features we have, such as cryptographic validation, and to have been completely broken with no motion forward for at least a month or two. I have commented on two issues over there and asked them to consider using lxc-gentoo instead. We shall see if they respond.

Note that an external portage tree (as a so-called Data Volume; associated with a so-called Data Volume Container) would be the way forward for smaller and longer-lasting images and easier production management.

Output versioning Some investigation in to docker image versioning might be made for both the portage tree Data Volume Container image (probably yyyymmdd would be sufficient, though more frequent update based on UTC timestamp and change-detection based upon polling may be useful) and for arch/archvariant specific images. Currently, docker appears to be only widely deployed on amd64 architecture, so it may be worth skipping builds for other architectures and their variants.

Build infrastructure We could use Travis CI as build infrastucture, since they support docker and sudo-capable build environments. It seems they are not against uploading build artifacts, see built-in Amazon S3 upload docs ... presumably we can just scp or HTTP POST new images someplace else, eg. back to github using something like this.

It would be a good idea to aim for fully repeatable/deterministic builds, and the use of parallel build infrastructure on multiple CI providers for the explicit purposes of build pipeline security (do not trust one CI provider's infrastructure).

New github project option Perhaps the best place for such a script and output is an entirely new project (thus allowing for 'releases' to differentiate between build output artifacts - ie. actually built images for lxc, docker, or something else - and the lxc-gentoo tool itself), however as it would be using this codebase it seems a reasonable place to discuss the options beforehand.

[alunduil]

Does this work with hub's autobuilding mechanism? It's elegant to use the autobuild since that can trigger downstream builds if anyone sets up a dependent image.

[globalcitizen]

I assume you are referring to this description of docker hub automated builds, which I have never used.

My interpretation of the process, based upon...

Automated build repositories rely entirely on the integration with your code repository. You cannot push to these image repositories using the docker push command. You can only change the image by committing to your code repository. If you want to do both, docker push and an automated build, you would create a regular repository for the docker push and an automated build repository.

... and ...

Within GitHub, a Docker integration appears in your repositories Settings > Webhooks & services page.

... and ...

Docker Hub builds your image

... and ...

To trigger Automated Builds programmatically, you can set up a remote build trigger in another application such as GitHub or Bitbucket. When you Activate the build trigger for an Automated Build, it supplies you with a Token and a URL.

... is as follows.

Scheduling/triggering Docker Hub automated builds are easily triggered, normally by one of three mechanisms (in rough order of frequency):

1. github (or bitbucket) post-commit hooks, ie. after you commit code to a repo that has the relevant hook set up
2. (According to you, but not the documentation, as far as I can see) Some kind of dependent image link thing
3. Custom triggering via the same API that the github (or bitbucket) trigger uses

Build location Builds are executed on a Docker Hub environment, which as a probably relatively small/low-traffic infrastructure would appear to be potentially less flexible/well defined/stable than some other infrastructure options such as Travis CI.

Next steps @alunduil Could you please provide a clear reference ot the 'trigger downstream builds' notion you mention so that I can understand your comment? I am willing to spend time looking in to it but need appropriate context.

[alunduil]

If you look at the build settings on docker hub for an automated repository, you'll see configuration that specifies repository links. Once this link is input, when the linked image is built, the image currently being configured will also be built.

There doesn't seem to be much documentation on the feature but I did find a blurb at the very bottom of this URL: https://docs.docker.com/v1.7/docker/docker-hub/builds/.

Let me know if I can shed any more light on this but the easiest way to investigate would probably be to look through the docker hub interface (due to the lacking documentation).

[globalcitizen]

I see.

Repository links are a way to associate one Automated Build with another. If one gets updated,the linking system triggers a rebuild for the other Automated Build. This makes it easy to keep all your Automated Builds up to date. To add a link, go to the repository for the Automated Build you want to link to and click on Repository Links under the Settings menu at right. Then, enter the name of the repository that you want have linked.

This is just setting in Docker Hub that lets you trigger builds of other projects when one project is complete. It implies they are all your own projects. My interpretation of your initial description implied there was a third party project involved.

So, in final answer to your question ... I don't think this is really an exciting feature since any normal post-commit hook or post-build hook could trigger a build of a project you own anyway, but yes, it is fully supported.

[alunduil]

It may imply that they are all one's own projects but the links are truly arbitrary. For example, the gentoo images finish building and a project I own personally gets updated as a result. Thus, the third party project is involved.

This is the only feature I utilize in a build system involving docker images and Gentoo. Without it I don't see much reason to use a build system. I don't want to host my own image building systems when solutions (quay and docker hub) already fill that need. I will concur that lxc-gentoo may not desire this but suggesting that lxc-gentoo can supplant the current docker build system isn't being sold very well at this point.

[globalcitizen]

@alunduil Well yes, the third party thing is supported... if it works now, it will work with an lxc-gentoo based build.

As for your other comments ... one could equally posit that suggesting that there is a current Gentoo docker build system that works isn't being sold very well at this point.

1. Issues on the github repo (linked above) seem to suggest it doesn't work.
2. Looking at the code it doesn't cryptographically validate its sources, which is a bit of a worry
3. It has significant code duplication between architectures/variants.

I think it would be easier to scratch it and replace with lxc-gentoo than to bother trying to duplicate the tested functionality, but that's just my opinion.

[alunduil]

All valid points. Can you show what that would look like? I have the automated build triggers enabled to kick hub once a day. If you can show me the Dockerfile (possibly with a pull request against gentoo-docker-images), I'd possibly see what you're trying to argue for.

Sorry if my post last night was a bit rambly, should've waited until today to respond.

[necrose99]

@mudler of Sabayon Linux /Gentoo has a docker Packer if you want Squashed containers. https://github.com/mudler/boson if your repo has a boson , updated ? spawn docker container build. https://github.com/mudler/vagrant-dockerbuilder https://github.com/mudler/docker-companion

But as for ARM64 Gentoo Docker , I've tried a number of means to get one working , so far "Vanilla" works just fine , scratch stage-3 > /
however no scripts will run after ... as I've had some reliability issues with varrious emu's today working , next week when new gentoo stage 3 @#$%^(&^%$#$%^ !! Broken... gentoo-amd64 , I'm testing tweking it , using busybox to run a few setups lxc time etc. injecting emu's into /NewWorldOrder etc. have a test case in my repo...

had i one of the nice Valkyrie Penguin pc servers (amr64 calverium the xfce/Debian docker would run it all day , gentoo lxc or docker image. ) I'm curious ESP as SECOPS , what +/- it has for Cloud security. other than run of the mill amd64 worms/virri wont run on it.

https://hub.docker.com/r/necrose99/gentoo-arm64/ https://github.com/necrose99/Docker-Gentoo-ARM64

Gentoo has official scripts so far i've been meddling when i got time... of late its rare. however mudler has a number of arm6/7 types of dockers that run. but as a researcher/Tinkerer i've been vexed to get proot /etc to run all that good. its been a rather painful trial and error testing...

I have a container to pull as a base , just getting the !@#$&%$# emulation to run would be a plus. however with other toys like packer in lxc one could pack to docker via catalyst/Sabayon- molecule most of your lxc - trash packages... or extra Devops'y things...

Gentoo Stage-4's also usable in lxc , ++++ as a util can pack them for openstack on the fly.

however getting arm64 in this package might be more of use , as I can drop in binfmt misc / qemu static etc.

getting https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot these bits to do in LXC for targets via lxc-gentoo might be of use.

[necrose99]

https://github.com/gentoo-build-service/docker-images https://github.com/geaaru/sabayon-reload

related.