[keycloak-dev] [Keycloak Operator] Builder image

[Stian Thorgersen]

Thanks, the PR looks good to me.

On Mon, 25 Nov 2019 at 13:25, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

>
>
> On Mon, Nov 25, 2019 at 1:21 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Looks like a sane approach to me. Is it supported on Quay.io?
>>
>
> ooh yeah - just look at [5] I linked before.
>
>
>> On Mon, 25 Nov 2019 at 11:08, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> Greetings!
>>>
>>> When we were working on Keycloak Operator, we introduced a hacky solution
>>> for building our image [1]. It uses a shell script to build the binaries
>>> [2], which turned out to be problematic in Quay due reusing build cache
>>> [3]. This resulted in our builds containing old binaries, which was
>>> critical to fix. We found a workaround but I wanted to revisit this issue
>>> with something better...
>>>
>>> In Pull Request #96 [4] I came up with a solution that uses Docker
>>> Multi-Stage builds. In short - the build is divided into 2 stages. The
>>> first one creates a container that builds our binaries (so called a
>>> builder
>>> container) and then we copy them (the binaries) to the final container.
>>> The
>>> whole point is that the final container doesn't need to contain Golang,
>>> Make or any other things necessary to build binaries.
>>>
>>> This approach has the following advantages:
>>> - It makes the image smaller - from ~250 MB to ~54 MB (see [5][6]).
>>> - It's just a pure UBI8 image with zero other dependencies, which means
>>> smaller CVE surface.
>>> - This approach fixes operator-hub build command.
>>> - It allows to play with build cache using --cache-from (so that you can
>>> reuse previous build results and modify only the final image).
>>>
>>> However, there are some drawbacks as well:
>>> - Say bye bye to Docker 1.13 (which is installed by default on Fedora
>>> OS).
>>> Multi-stage builds require newer Docker version or Podman [*].
>>> - Dockerfile had to be moved to project's root. As the build process
>>> pulls
>>> local files (cloned by git), so everything needs to be in the Docker
>>> context. The easiest (and most stable) way to achieve this is to put the
>>> Dockerfile into the root.
>>> - In order to get `operator-sdk build` command fixed, I had to create a
>>> symbolic link (of the Dockerfile) in the build directory.
>>>
>>> Even though, this solution is not aligned with other Keycloak projects, I
>>> believe that's the right approach. Afterall, with the shell scripts
>>> approach we're simulating this behavior having a proper solution at
>>> hand. I
>>> would highly encourage (and advise) adopting this approach to other
>>> Keycloak images (such as Gatekeeper or maybe even Server).
>>>
>>
>> Doesn't apply to Gatekeeper or Server as they don't build the
>> distribution, those images just download the dist and build the images.
>>
>>
>>>
>>> If you don't like this solution - I prepared a workaround that fixes our
>>> build here [7]. It's much less elegant and frankly, I don't like it.
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> [*] I like Peter's trick for this - he created an alias for `docker`
>>> command pointing to `podman` !!!
>>> [1]
>>>
>>> https://github.com/keycloak/keycloak-operator/blob/master/build/Dockerfile
>>> [2]
>>>
>>> https://github.com/keycloak/keycloak-operator/blob/master/build/Dockerfile#L22
>>> [3] https://github.com/containers/buildah/issues/1906
>>> [4] https://github.com/keycloak/keycloak-operator/pull/96
>>> [5]
>>> https://quay.io/repository/slaskawi/keycloak-operator-private?tab=tags
>>> [6] https://quay.io/repository/keycloak/keycloak-operator?tab=tags
>>> [7] https://github.com/keycloak/keycloak-operator/pull/97
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>