explore migrating to appc

[edannenberg]

explore migrating to appc

[edannenberg]

No more plans for this, OCI output will probably a thing though.

[edannenberg]

I'll probably play around with appc this week to see if their spec files can be used as a replacement for Dockerfiles. Had a cursory look at the spec and it seems doable.

[edannenberg]

Looks like things are finally taking the right direction now: https://coreos.com/blog/oci-image-specification.html

Gonna look into OCI instead of appc I guess.

[edannenberg]

Had a closer look at OCI and appc/acbuild, I'm not sure it is worth the effort, at least for the near future:

pro:

• I like how acbuild gives more freedom compared to a Dockerfile, you can basically shell script the image build as you wish, but on the other hand we already can do this in the first build phase, which is where most of the heavy lifting is done anyways, so the gain is not that high.

con:

• Currently you end up with an ACI image, which limits you pretty much to runtimes supporting appc, if I read this blog correctly, Docker currently does not support ACI images, only other container executors that conform to the OCI spec

Guess we have to wait a little longer to see how this pans out, once container images become truly interchangeable acbuild looks like a nice alternative.

[mischief]

would love to see aci support. i started working on it but i am not a bash hacker :-)

[edannenberg]

soon(tm) :P

On the standardization front, the Open Container Initiative (OCI) is progressing towards its 1.0 release, and work is well underway in rkt to fully support this important milestone. We’ve started preliminary work on handling OCI images directly, and rkt fetch can already understand the new format as currently drafted.

Docker already supports OCI images via runC AFAIK, so OCI seems like the way forward.

Also good news from acbuild:

coming soon OCI, the format defined in the Open Containers Image Format specification

So yea looks like the stars have finally aligned, I might start playing with acbuild soon. :)

[edannenberg]

From the appc repo:

Accordingly, as of late 2016, appc is no longer being actively developed, other than minor tweaks to support existing implementations.

That being said ACI support should still easily be doable after the switch to acbuild. Focus is on OCI though.

Been playing around/thinking about this, current plan:

• keep using Docker for running/managing build containers => much less changes required and easier handling (docker commit etc)
• remove Dockerfiles and add a new hook in Buildconfig.sh, as a replacement, where the OCI/ACI image is generated via acbuild
• create a helper image that provides oci/aci image dependencies to acbuild in each build container, currently acbuild does not support local folders with images AFAIK.

Should be fairly straight forward judging by some manual test runs with acbuild in a build container, except for the image dependency part. Not a whole lot documentation for that. @mischief How do you usually handle aci images you don't want to publish on quay.io? Is it enough to just serve them via nginx?

[mischief]

@edannenberg sorry for the late reply - yes, it is enough to simply serve a .aci from a plain webserver, such as: offblast.org/aci/tor stored at https://offblast.org/aci/tor-latest-linux-amd64.aci (i don't recommend you pull this old copy of tor..)

IIRC, it is not necessary but useful to use the ACI discovery metatags like so -

<meta name="ac-discovery" content="offblast.org https://{name}-{version}-{os}-{arch}.{ext}">
<meta name="ac-discovery-pubkeys" content="offblast.org https://offblast.org/aci/pubkeys.gpg">

see https://github.com/appc/spec/blob/master/spec/discovery.md for details

[edannenberg]

@mischief No worries, time is a very limited resource. ;( Ok, thanks. Sounds easy enough.

Looks like OCI support is about to land in acbuild. With the latest image structure refactor the switch should be smooth sailing, though I'm currently debating a bit of a rewrite.

[mischief]

@edannenberg want to file a seperate issue for that, detailing what problems exist and what parts would get rewritten?

[edannenberg]

Perhaps refactor is more fitting. Basically try to make functions pure where possible, less globals, bash naming conventions, tests. That sort of things. Shouldn't affect end users too much if at all. Currently toying with some ideas and argbash.

[edannenberg]

Sadly acbuild only supports meta-discovery so nginx didn't look like a straight forward solution. Went with acserver instead. Fairly young project with no documentation yet, had to reverse engineer the code to find out how to use the api, but insecure image push via bash and local discovery via acbuild works now:

$ acserver /etc/acserver-config.yml &
(acbuild a localhost/gentoobb/busybox image which just has alpine base dep for testing)
$ acserver-push localhost busybox-latest-linux-amd64.aci
$ acbuild begin
$ acbuild set-name localhost/gentoobb/test
$ acbuild dep add localhost/gentoobb/busybox
# no systemd so we have to use chroot engine
$ acbuild --insecure --engine=chroot run echo "kk"
::1 - - [07/Feb/2017:08:08:46 +0000] "GET /gentoobb/busybox?ac-discovery=1 HTTP/1.1" 404 19
::1 - - [07/Feb/2017:08:08:46 +0000] "GET /gentoobb?ac-discovery=1 HTTP/1.1" 404 19
::1 - - [07/Feb/2017:08:08:46 +0000] "GET /?ac-discovery=1 HTTP/1.1" 200 1997
::1 - - [07/Feb/2017:08:08:46 +0000] "GET /find?name=localhost/gentoobb/busybox&version=latest&os=linux&arch=amd64&ext=aci HTTP/1.1" 302 97
::1 - - [07/Feb/2017:08:08:46 +0000] "GET /localhost/gentoobb/busybox/busybox-latest-linux-amd64.aci HTTP/1.1" 200 386
Downloading localhost/gentoobb/busybox: [======================] 386 B/386 B
Downloading quay.io/coreos/alpine-sh: [========================] 2.65 MB/2.65 MB
kk

Ran this manually in a bob-interactive build container, all that is left is build orchestration. 🎉

@mischief How do you handle latest versioning with aci? acbuild label add version xxxx would suggest I need to build twice, one for actual version and another for latest tag? Also hardcoding the registry url in the image manifest seems kinda odd, I guess I can work around that by adding a /etc/hosts alias for a configurable ACI_REGISTRY_URL env per namespace before starting acbuild stuff during the build.

---

One thing I had totally forgotten in my smooth sailing estimation is multiple dependencies, will need some further modifications in the generic image dependency resolution to support this format:

IMAGE_PARENT="gentoobb/busybox gentoobb/glibc gentoobb/nginx"

Shouldn't be too bad, but the rabbit hole goes deeper. Currently when building the gentoobb/nginx image we just check IMAGE_PARENT="gentoobb/openssl" and use the gentoobb/bob-openssl image as build container, unless BUILD_FROM overrides. With multiple dependencies not quite so easy. I guess picking the build container of the last listed image in IMAGE_PARENT per default, while also allowing BUILD_FROM to override should do the trick. I'm sensing some nasty edges case though, for example what happens if all 3 listed dependencies each created a different user/group during their image creation? The users/groups from the first 2 should be missing in the final image. Maybe a non-issue.

Planned new hook in image build.sh that replaces Dockerfile.template:

configure_acbuild()
{
     # acbuild begin, set-name, add dep, label add version <- not required, handled by build
     ${acbuild} environment add NAME VALUE
     ${acbuild} run foo
     ${acbuild} set-exec -- echo "foo"
     # acbuild write , end <- not required, handled by build
}

[edannenberg]

So apparently Docker can now save OCI bundles when building, which makes acbuild kinda pointless I think, or are there any other advantages? Would just need to add a config option to output OCI bundles which should be fairly trivial. Thoughts?

[edannenberg]

Took another look at state of things. acbuild is no longer maintained and the alternatives don't look very appealing. I'd say ACI is dead.

img looks kinda interesting though, basically unprivileged docker build. Would just need some work to make the first build phase work unprivileged.