-
Notifications
You must be signed in to change notification settings - Fork 402
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
Update ray operator Dockerfile #1213
Update ray operator Dockerfile #1213
Conversation
Signed-off-by: Anish Asthana <[email protected]>
Signed-off-by: Anish Asthana <[email protected]>
423a672
to
b367a33
Compare
@kevin85421 can you retrigger CI here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make the dockerfile more portable for build systems that are unable to access gcr.io/distroless/static
Would you mind providing more details about why some systems are unable to access gcr.io/distroless/static
? Thx
Some build systems are unable to pull images from public "non-trusted" registries, so gcr.io (or even quay/dockerhub) would be out of the question unless you go through approval processes. As |
@kevin85421 bump on this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Update ray operator Dockerfile
Why are these changes needed?
We are currently using generic golang and distroless images to build the ray-operator (and other images).
Using “ubi(universal base image)” and “scratch” will improve the security of our images. UBI images are actively maintained, scanned, and updated by Red Hat productization and security teams. Using these images will improve user confidence in what is being provided by the KubeRay community.
scratch
is similar to the distroless, but this will make the dockerfile more portable for build systems that are unable to accessgcr.io/distroless/static
Related issue number
Not directly related, but we should really update the Go version we are using: #518
Go 1.17 seems to have a lot of vulnerabilities. I'll see if I have some time in the next couple weeks to update it.
Checks
I'm happy to create an issue if required. cc @kevin85421