feat: build and publish weekly alpha/development container image #594

tamcore · 2022-12-23T21:16:38Z

Closes #308. Exerpt from commit message:

make use of docker buildx caching when possible (helpful with local docker builds)
introduce a reusable container workflow which is triggered by docker-release and docker-weekly workflows
added an alpine-dev Dockerfile
split release.sh contents into different Makefile targets
make use of job matrix to build alpine + ubuntu in parallel
make alpine build optional by checking for Dockerfile presence
- as the pre-built release binaries don't work with alpine, because of glibc <-> musl incompatibilities

Tagged images will look like

From pre-existing docker-release workflow (which will not output an alpine image, as Dockerfile.alpine-prod has been renamed)
- For release v0.12.2
- For pre-release v0.12.2
From newly introduced docker-weekly workflow
- For alpine variant
- For ubuntu variant

romange · 2022-12-23T21:22:47Z

Thank you, Phillip. Curious, why did you decide to switch to makefile? Ergonomics?

tamcore · 2022-12-24T07:47:48Z

Felt like it would be overkill to have a bunch of separate scripts for it and didn't want to parameterize release.sh either. So the Makefile felt the "most natural" to place for a handful of one-liners.

Makefile

tools/release.sh

romange · 2022-12-24T08:43:04Z

tools/docker/Dockerfile.ubuntu-build

@@ -0,0 +1,59 @@
+# syntax=docker/dockerfile:1
+FROM ubuntu:20.04 as builder


what's a AIO?

Why do you prefer building dev env here instead of reusing the already built one : ghcr.io/romange/ubuntu-dev:20 ?

This makes it more self-contained and comprehensive for the end-user. It's just an apt-get install, not special tooling :) Also, this way, the outputted container is more up2date on patches (and I feel like, Trivy imagine scanning should also be incorporated here)

Additionally, a special case which comes to my mind: I had a client with an air-gapped environment, where I would've been able to bring in a container image like ubuntu:20.04 and this Git repo as source code, but not neccessarily your dev container.

But honestly, I haven't investigated your dev container too much. Just couldn't find it's origin with 2 clicks and was relying on the instructions in the existing release workflow. Please just let me know your preference, and I'll change it accordingly :)

it's fine, just wanted to understand your rationale.

tools/docker/Dockerfile.ubuntu-build

romange · 2022-12-24T14:30:12Z

tools/docker/Dockerfile.ubuntu-build

+  echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' > /etc/apt/apt.conf.d/keep-cache
+
+RUN \
+  --mount=type=cache,target=/var/cache/apt,sharing=locked \


can you explain what you do here? I understand that it's somehow connected to apt caching but I do not understand exactly what it is. If you have a reference to a blog post or documentation this will also work.

Theoretically, that's supposed to cache and share /var/cache/apt and /var/lib/apt between both builds, but also between runs (through the cache-{to|from}: type=gha parameter). But doesn't seem to work as I'd hoped.

.github/workflows/docker-weekly.yml

.github/workflows/docker-release.yml

romange · 2022-12-26T10:59:42Z

tools/docker/Dockerfile.ubuntu-dev

@@ -0,0 +1,56 @@
+# syntax=docker/dockerfile:1


unless I misunderstand this what this dockerfile does, I think ubuntu-dev is a wrong name for this file.
Would you like that we publish builder images inside dragonflydb org instead of bundling them together with the docker release logic?

another option is to rename the files to Dockerfile.ubuntu-release (the same applies to alpine of course)

To be honest, I'd keep it as-is. That way, the *-dev Dockerfiles can progress (if needed), as development goes on. The only additional change, I'd suggest, is building the actual release containers from source as well. That would make it easier, to add support for alpine, for example.

But I also wanted to have a look at distroless images, to potentially come up with something even smaller. And with the matrix builds now, throwing in another flavor isn't too difficult :D

The alpine build is already 45% smaller than the ubuntu one :)

philipp@ ~ $ docker image ls | grep tamcore/dragonfly ghcr.io/tamcore/dragonfly alpha-alpine 36c1d38c6f2e 2 hours ago 107MB ghcr.io/tamcore/dragonfly alpha-ubuntu 78dbf284cc5c 2 hours ago 194MB

FYI, I had trouble with alpine in the past due to its particular choice of using musl library. I do not remember specifics but I refrain from recommending alpine as a default dragonfly container.

Regarding your comment - I do not understand it. dev containers are for building dev environment, but you added the next build step to build a container equivalent to a release container, so not i's not a dev container anymore. Right? So what do you mean by "keeping as is" and what do you mean by "building actual release containers from source" ?

FYI, I had trouble with alpine in the past due to its particular choice of using musl library. I do not remember specifics but I refrain from recommending alpine as a default dragonfly container.

Fair point. I had a ton of issues trying to get the pre-compiled Dragonfly binaries working under alpine. But so far it seems fine, with the version compiled directly on alpine.

Regarding your comment - I do not understand it. dev containers are for building dev environment, but you added the next build step to build a container equivalent to a release container, so not i's not a dev container anymore. Right? So what do you mean by "keeping as is" and what do you mean by "building actual release containers from source" ?

I guess we're thinking about different things here 😅

Maybe the name *-dev is indeed not optimal. But if we rename them to *-release, they kinda obsolete the *-prod images, no? Then we could just remove the suffix altogether and have the same Dockerfile for both the weekly and release builds, where the latter would then be built from source as well, rather than relying on the build artifacts from the normal release workflow.

hmm, building a binary for aarch64 takes like 2 hours on qemu.... In addition, if we reuse the same binary we will avoid weird synchronization bugs of us having different binaries for the same release.

Ok, now I understand that dev applies to a release "flavor". Lets keep the name as is.

romange · 2022-12-26T11:04:41Z

Makefile

+	./helio/blaze.sh $(HELIO_FLAGS)
+
+build:
+	cd build-opt; \


Unless I am mistaken, this makefile is intended to build only the release version of dragonfly.
From this code it seems like it because you cd to build-opt which is created only for release.

if you intend to extend the makefile functionality to debug variant as well, then it support "cd build-dbg".

if you do not want to support debug builds then this HELIO_RELEASE logic is over-complication - you can just hardcode these flags into HELIO_FLAGS without requiring a caller to pass a special flag.

I guess we should support debug builds as well, while we're already in here. Might make it easier down the road.

romange · 2022-12-26T14:49:18Z

.github/workflows/docker-weekly.yml

+  weekly-container-build:
+    uses: ./.github/workflows/reusable-container-workflow.yaml
+    with:
+      dockerfile: dev


nit: maybe rename "dockerfile" to "flavour" but besides this LGTM

Changed this spot to build_type, because, usually, the distro is referenced as the flavor. Now called that way as well.

- make use of docker buildx caching when possible (helpful with local docker builds) - introduce a reusable container workflow which is triggered by docker-release and docker-weekly workflows - added an alpine-dev Dockerfile - split release.sh contents into different Makefile targets - make use of job matrix to build alpine + ubuntu in parallel - make alpine build optional by checking for Dockerfile presence -- as the pre-built binaries don't work with alpine, because of glibc <-> musl incompatibilities Signed-off-by: Philipp Born <git@pborn.eu>

romange

Well, I hope you will be nearby when we cut our next release 😆

tamcore · 2022-12-26T18:28:50Z

I've built it so often over the last few days, no need for automations anymore. Can do it by hand 😂

The latest changes still seem to work:

https://github.com/tamcore/dragonfly/actions/runs/3782782504
https://github.com/tamcore/dragonfly/actions/runs/3782792556
- (only fails because i'm not supplying it with PATs for the push-protected action)

romange · 2022-12-26T18:41:50Z

Thanks Philipp, much appreciated! 🤝