https://prefect.io logo
Join Slack
Powered by
<@ULVA73B9P> has there been any consideration abou...
# ask-marvin
s
@Marvin has there been any consideration about using UBI as a base image in addition to the Python slim image currently being used?
m
❌ Error: unhandled errors in a TaskGroup (1 sub-exception)
Sorry, I encountered an error while processing your request. Please try again.
s
@Marvin has there been any consideration about using UBI as a base image in addition to the Python slim image currently being used?
m
✅ thought for 125.4 seconds
I couldn’t find any public evidence that Prefect has specifically considered UBI as an official base image option. What I did find: - Prefect’s main image build defaults to 
python:<version>-slim
- There is also a conda-based variant, but no UBI-based variant showed up in: - the current Dockerfiles - GitHub issues - GitHub discussions - docs / deployment docs From the code-research, the current Dockerfile pattern is essentially:
Copy code
dockerfile
ARG BASE_IMAGE=python:${PYTHON_VERSION}-slim
FROM ${BASE_IMAGE}
So the important nuance is: - Officially: no sign of a documented UBI offering or roadmap item - Technically: the image build setup is flexible enough that a UBI-based image could be used/customized by consumers There are a couple of likely reasons 
python-slim
remains the default: - it’s small and familiar - Debian/`apt` works well with the system packages Prefect images commonly need - it avoids some compatibility issues seen with other alternatives like Alpine Relevant references: - Prefect repo: github.com/PrefectHQ/prefect - Main Dockerfile: Dockerfile - Docker image utilities: dockerutils.py If you want, I can also help with either of these: 1. a UBI-based custom Dockerfile for Prefect workers/flow runs, or 2. checking whether your specific OpenShift / enterprise requirement is likely to work cleanly with Prefect on UBI.
n
not really. any reason (besides convenience) you don't want to build your own?
s
that's actually what I've been working on. At first we forked prefect, as a get-it-done-now! effort, but that is unsustainable for our team. I am currently working on an implementation that simply 
pip install prefect
into a UBI9 image. Though it has been floated that we create a public fork that builds based on UBI. Our goal (probably quite obvious) is Red Hat certification for use in our product.
n
yep that makes sense! that would be my first instinct as well
prefect rocket 1
s
IMO, maintaining a fork, even public-facing, is quite a larger task than I think we can take on at this time.
n
sorry, i wasn't super clear. forking i wouldnt say is my first instinct. i just mean installing prefect on top of your required base
prefect rocket 1
what's the motivation for the fork? just having a point in time thing?
s
my spike looked into these three approaches: 1. Install into a UBI image 2. Create a public fork 3. Contribute back to the base prefect repo a Dockerfile that either built multiple images or offered an option to build to a target base image Oh, I'm with you, I think the "install to UBI" is the best way
we don't need to upgrade very often, and with a simple parameter we can control which version is installed
2 Views
Open in Slack
PreviousNext
Powered by