-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch the container image from Fedora 39 -> RH UBI 9 #528
base: main
Are you sure you want to change the base?
Conversation
9cd6807
to
6fb07f3
Compare
since v1:
EDIT: Is there a way to silence hadolint via CLI rather than a commentary in the Containerfile as that would be the preferred solution. |
Since v2:
|
ping. I still need to have a look at the integration test failure but I'd like to get first round of reviews on the general idea. |
ping^2 |
I believe that yarn v4 will require node >= 18. How do we want to handle that? |
With multi-stage, which would come next, that would give us all the flexibility we need, both in terms of node an Go. |
A future patch will switch the container image from using Fedora 39 to using UBI9 (Red Hat Universal Base Image 9). Since that one ships with a pretty old version of Nodejs (v16.20.2) we need to revert the line in question as a result of Dependabot updates to satisfy the Node engine limitation on UBI9. Signed-off-by: Erik Skultety <eskultet@redhat.com>
We don't require NPM for anything really, we only need a version that supplies corepack which we'll in turn use to install a specific version of Yarn. Given that we're going to switch the container image from Fedora to UBI9 in a future patch which only ships with an old NodeJS v16.30.2 (i.e. one officially marked as in maintenance from upstream perspective) we need to prevent dependabot from trying to submit update PRs for it. This can be easily done by providing an upper boundary to the version of the NodeJS engine. Signed-off-by: Erik Skultety <eskultet@redhat.com>
We're specifically interested in the 'go' binary which is part of the compiler toolkit. It'll pull in 'golang' anyway, so there's no practical difference from the build's POV, it's the slight nuance of what we actually require for the resulting container and being exact in terms of listing it. Signed-off-by: Erik Skultety <eskultet@redhat.com>
We may need this in order to build some of our Python dependencies (e.g. reflink) that don't build as a wheel (because they're heavily platform dependent) and need to be built locally during installation. Signed-off-by: Erik Skultety <eskultet@redhat.com>
Red Hat ships UBIs as free images with the same stability and security guarantees like any other Red Hat product, so in terms of the runtime environment for cachi2 it makes sense to use a stable, curated, and well maintained base image. As a side-effect, this will rid of the need to follow Fedora releases and bump the base image version every 6 months or so when the next major version is releases, marking the 2nd oldest major release as EOL. However, using a stable and well maintained image isn't rainbows and unicorns either as we'll likely fall into the trap of lacking the latest package manager tooling required by cachi2 consumers which Fedora kinda solved (e.g. by always using the latest release to get the latest Golang version with the exception of >=1.21 and toolchains), but not without any caveats, those would just become more apparent with the selection of the next base image. Since we're switching base images, this patch also updates the integration mock data based on what's reported on UBI9. Resolves: containerbuildsystem#401 Signed-off-by: Erik Skultety <eskultet@redhat.com>
I found one fairly annoying downside to using UBI - for some weird reason it doesn't ship with |
For example if I try Rocky Linux's take on UBI then
Any thoughts/preferences? |
You've hit the main issue with using UBIs as anything other than a base runtime - they're very stripped down. It sounds like Rocky is the way to go, except at that point, are we really better off than just sticking with Fed? |
Uhm, not entirely true I guess. See this has nothing to do with runtime, but repo setup. The Rocky flavour I tested with was also marked as UBI, except without carefully constructed limitations of the base repositories. Without disclosing too much detail, let's just say that the same repository on base RHEL contains the package while the RH UBI counterpart doesn't. And it makes sense to keep RH's UBI licensing and intended usage intact I guess, but what determines the package selection that ends up in those repositories is a mystery to me. I'll just close my thought with a simple: my bad for actually not checking the package catalog on the proposed RH UBI which would tell me immediately what I could get inside and what I couldn't.
Well, pretty much anything is really better than Fedora for a production use (i.e. other than CI to uncover potential problems early) since it won't suffer from the 13 months EOL period. |
This PR switches the existing Fedora 39 container image to the RH UBI 9. A couple of tweaks were needed along the way to be able to perform the switch. This can be (doesn't necessarily need to be) perceived as a prerequisite to ultimately building the image in a multi-stage fashion.
Discussion: #401
Maintainers will complete the following section
Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:
/ok-to-test
(as is the standard for Pipelines as Code)