Inline RPM dependencies in container image build #1510
Conversation
|
@gsaslis Overall LGTM. If this target is 2.15 then I'm afraid we still need to support opentracing. I noticed that the CI jobs are failing, I will look into it but it doesn't seem related to this commit |
That's a good point!! I'll create the 2.16 branch to point at HEAD of 2.15 and use that as the target branch. ;) |
gsaslis
changed the base branch from
3scale-2.15-stable
to
3scale-2.16-stable
|
@gsaslis would you mind to rebase this PR on top of master branch? I think it's better to merge it into master, merging into 2.16 now and cherry-picking commits from master later can be hairy. Also |
shouldn't it be ? I mean... doesn't the latest release carry over from the previous one ? I'm not sure what your current branching strategy here is, but for the other components we usually avoid cherry-picking individual commits and we just fast-forward to the HEAD of main/master branch. Having said that, please feel free to move 3scale-2.16-stable to point wherever you like. In the product build I'll just point to 3scale-2.16-stable. |
gsaslis
force-pushed
the
feat/better_build
branch
from
6056f38 to
756a29e
Compare
Signed-off-by: Yorgos Saslis <[email protected]>
Signed-off-by: Yorgos Saslis <[email protected]>
Signed-off-by: Yorgos Saslis <[email protected]>
Signed-off-by: Yorgos Saslis <[email protected]>
the RPM builds fine without this package. Finding the `rpmdevtools` package is a problem anyway because it's part of the entitled content - and not available in UBI repos. Signed-off-by: Yorgos Saslis <[email protected]>
- all RPM builds 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. Hopefully, support for opentracing can be dropped in the next release (considering we now have support for opentelemetry). Signed-off-by: Yorgos Saslis <[email protected]>
Signed-off-by: Yorgos Saslis <[email protected]>
Signed-off-by: Yorgos Saslis <[email protected]>
gsaslis
force-pushed
the
feat/better_build
branch
from
756a29e to
e7d2ad8
Compare
So I tend to base new branch on master and fast-forward later.
Thanks mate |
|
closing in favour of #1514 (branch name was causing jobs to fail) |
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 ).