Page MenuHomePhabricator

Allow running docker-pkg in CI
Open, LowestPublic

Description

We want to be able to do the following:

  • Upon merge-and-submit, run docker-pkg in CI and build the image, then publish it

The only technical difficulty we encounter if we want to do this is... we need to be able to connect to the docker daemon from within a docker container, which AIUI isn't allowed in CI for obvious reasons.

The approach I want to take is to add support for an alternative build tool so that we can build the image within a container without the need to call the docker daemon. The best tool to do so as far as I can tell is kaniko.

So my idea would be to allow docker-pkg to output its dockerfiles and build contexts under a single source directory, then run kaniko to build and publish the various images.

There are two ways of implementing this:

  1. Add a separate command to docker-pkg called kaniko-build with completely separate logic. Basically we'd use the imageFSM only to find the build chain and the initial image status, and possibly to get back from kaniko the result of the build
  2. Add a separate implementation of the Image class and the imagfsm class for kaniko builds, abstracting whatever is common between implementations, then make using kaniko a configuration switch and support build as the same command as before.

I think I'll pick the latter.

An additional difficulty is represented by the fact we want to run everything inside a single docker container, that we will have to build ourselves as kaniko is only supposed to be run inside the official google docker images, which we can easily reverse-engineer though.

Event Timeline

Some random thoughts:

I recently filed a task to track use cases that require access to a Docker daemon: T283724 . Though for building image if we go daemon less and the utility supports being run in a container, that solves the problem.

Kaniko is referred to in the Gitlab documentations so that runners (running in Docker) can build images themselves ( https://docs.gitlab.com/ee/ci/docker/using_kaniko.html ). Ahmon tried that in a demo repo and that works just fine.

@dduvall evaluated Build-Kit which would replace docker build eventually. It is a good read: T268368 At the time it had a few bugs and performance issues though.

https://podman.io/ (by RedHat) which is daemon less, and is a drop-in replacement for the docker cli. I haven't tried to build an image within a container though but maybe it is easier to implement than fitting Kaniko in an unsupported container?

If docker-pkg abstracts the build step, it could potentially have a concrete implementation for each of those tools and one can pick their favorite one. Doesn't prevent docker-pkg to learn to dump all the generated dockerfiles/context to some output directory though.

Joe triaged this task as Lowest priority.Oct 8 2021, 7:28 AM
Aklapper removed Joe as the assignee of this task.Nov 21 2023, 8:17 AM

@Joe: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!