-
Notifications
You must be signed in to change notification settings - Fork 49
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
Amend Dockerfile to support alternative base image #612
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ |
Hi @jason-fox, I really like the flexibility this PR adds, that's great. But it also introduces quite a bit of complexity, is this a Fiware requirement? |
@jason-fox |
here's a start. there may be more places though if you could please fix the paths and push again, hopefully we get a clean test run :-) |
On a side note, I was wondering how you guys feel about moving away from Docker files and using Nix instead? Some advantages I can think of off the top of my head:
Just an idea... |
Fixed b1f7073 . Because you are extensively using Docker for integration testing (of potentially failing code) it makes more sense to maintain and update the existing
The advantage of the former is that it applies the Which one makes sense for the orchestracities dev team to push to your container registry depends on this line here in Even if you choose to revert this |
Lots of ongoing discussions around Log4Shell and CVEs. The aim of the PR is to reduce the burden of maintaining and testing a safe and current base image elsewhere. It shouldn't be the OrchestraCities dev team building and testing every possible variant of an image. Given our relationship with RedHat, I could see the FIWARE Foundation testing and then pushing UBI images of selected FIWARE components to quay.io for example, where the open CVEs on the image would be publicly readable. |
Having a Dockerized container image is already a FIWARE Contributor requirement:
Nothing stopping you from doing so, but there is no push from the FIWARE Foundation to move to Nix. |
A fixed user is set in the Dockerfile, USER build-arg is not currently supported.
Cool, I actually missed having a Docker file is a requirement. I'd rather go w/ Docker then, ignore my suggestion about Nix :-) |
i am a bit lost :) @jason-fox, let me try to recap what I understood:
correct? if that's the case:
|
actually, reading the docker docs, we can simply take advantage of the target options:
feelings? |
`description`,`name` and `summary` are standard UBI `LABELS`. These need to be present in the Dockerfile for the underlining `LABELS` from the base image to be overwritten with meaningful descriptions.
hi @jason-fox did you have any chance to look at my comment? |
Proposed changes
This PR updates the
Dockerfile
so it is flexible enough to be able to use alternative base images should you wish. The base image still defaults to using thealpine
distro, but other base images can be injected using--build-arg
parameters on the command line. For example, to create a container based on Red Hat UBI (Universal Base Image) 8add
BUILDER
,DISTRO
,PACKAGE_MANAGER
parameters as shown:To create a container based on Debian Linux add
BUILDER
,DISTRO
,PACKAGE_MANAGER
parameters as shown:
Types of changes
What types of changes does your code introduce to the project: Put
an
x
in the boxes that applyfunctionality to not work as expected)
Checklist
Put an
x
in the boxes that apply. You can also fill these out aftercreating the PR. If you're unsure about any of them, don't hesitate to
ask. We're here to help! This is simply a reminder of what we are going
to look for before merging your code.
feature works
downstream modules
Further Comments
The default build does not change, it just give a user the chance to try out different things. I've seen articles like Don't use Alpine or Switch to Python 3.10 - this is giving the end-user the option to try things out for themselves.
Image sizes vary wildly, but of course if you want to standardize your base images this isn't an issue.
There are minor updates to the
Dockerfile
like setting a non-privileged USER to follow best practice. Hadolint still complains, but these are false positives like not setting the POSIX shell (which is recommended to be an ignored rule for alpine actually)