This PR introduces a radically different - and much more wholistic - approach to producing the apicast container image.
The current build relies on RPM packages that must have been built and pushed in a repository, so they can be pulled and installed into this image. However, this poses several issues with regards to how those RPMs are built, how easy they are to update, etc. etc.
The approach here is not entirely new - it comes from the product build, which has already adopted this multi-stage approach in building RPMs within the container image and then installing them in the final produced image.
It should be noted that - eventually - we could remove the RPM packaging altogether and essentially convert the RPM spec files into Containerfile instructions. This would further simplify the build steps. In this PR, we are only taking one first step towards that.
Some notes:
all dependencies have either been added as git submodules, or vendored into the repo,
all RPM builds now happen in a multi-stage build,
this is just the first version of the Containerfile that I was able to get a passing build on, with podman build -f Containerfile .
there are still several improvements to be implemented in the multi-stage build, to reduce some duplication. The previous build system didn't allow reusing previous build stages in subsequent ones (i.e. it didn't allow FROM rpm-builder AS openresty, etc.), so that still needs some clearing up.
we should probably only keep one of Containerfile and Dockerfile. I just didn't overwrite the Dockerfile in one go to allow for a better chance of review.
Open issue: the jaegertracing-cpp-client RPM is currently commented out. That hadn't previously been ported to its own build stage and I don't know if it's worth doing that now. Luckily, support for opentracing is planned to be dropped in the next 3scale 2.16 release (considering we now have support for opentelemetry), so those lines could probably be removed altogether.
@tkan145 I am creating this as a draft PR, so we can slowly start reviewing it.
(Note: while I was able to build a container image, I haven’t tested it in any way yet. I’d also like your help in figuring out if there is anything important missing in the new Containerfile from the existing Dockerfile ).
This PR introduces a radically different - and much more wholistic - approach to producing the apicast container image.
The current build relies on RPM packages that must have been built and pushed in a repository, so they can be pulled and installed into this image. However, this poses several issues with regards to how those RPMs are built, how easy they are to update, etc. etc.
The approach here is not entirely new - it comes from the product build, which has already adopted this multi-stage approach in building RPMs within the container image and then installing them in the final produced image. It should be noted that - eventually - we could remove the RPM packaging altogether and essentially convert the RPM spec files into Containerfile instructions. This would further simplify the build steps. In this PR, we are only taking one first step towards that.
Some notes:
podman build -f Containerfile .FROM rpm-builder AS openresty, etc.), so that still needs some clearing up.ContainerfileandDockerfile. I just didn't overwrite theDockerfilein one go to allow for a better chance of review.Open issue: the jaegertracing-cpp-client RPM is currently commented out. That hadn't previously been ported to its own build stage and I don't know if it's worth doing that now. Luckily, support for opentracing is planned to be dropped in the next 3scale 2.16 release (considering we now have support for opentelemetry), so those lines could probably be removed altogether.
@tkan145 I am creating this as a draft PR, so we can slowly start reviewing it.
(Note: while I was able to build a container image, I haven’t tested it in any way yet. I’d also like your help in figuring out if there is anything important missing in the new Containerfile from the existing Dockerfile ).