On Fri, Jun 17, 2022 at 4:56 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
So, when moving openshift apps this week, I really came to the
conclusion we should look at writing up some guidelines for openshift
apps. Perhaps it could have 'MUST' items and 'SHOULD' items and
'SUGGESTION' items.
I know I am coming at this from the operations side of things, so please
do share other viewpoints, but let me mention a few issues I see:
It's very difficult to tell what an application is running on:
- We should probibly forbid 'X:latest' because what the application is
running depends on when it was last built/deployed. (unless: see
below)
- A number of apps use images elsewhere (quay.io, etc). We have very
little way to tell whats in those or how they are made or if anyone is
still making them.
We have a few apps that rebuild/deploy on git changes, which is fine,
but doesn't do anything to keep their container env up to date/secure.
We have a number of apps that tigger on imagestream changes, but as far
as I can tell thats only changes in their image ('bodhi-base') not the
base image that it was built from ('fedora:36'). I'd like to see us
track base images and build/deploy when one changes. If we do that then
:latest might be ok to use, since we know automation took care of
updating it for us.
There's a number of applications using ubi (rhel's base image), which I
think might be worth recommending, especially if we start build/deploy
on base image changes. Likely Fedora base images will change more
quickly.
Fedora's images churning more often is a good thing, not a bad thing.
And frankly, I would not recommend RHEL UBI for a few reasons:
1. It's hard to get things fixed in a timely fashion
2. The content set is too reduced from RHEL
3. We already control the Fedora content, so we should use those
Dogfooding is important, as is self-sufficiency. Inability to do both
makes it much more difficult for others to reuse our stuff.
--
真実はいつも一つ!/ Always, there's only one truth!