-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Make all docker images consistent for future updates #35919
Conversation
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public.
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
@@ -1,4 +1,4 @@ | |||
FROM golang:alpine3.15 as builder |
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.
Alpine Linux isn't actually in our support matrix (https://www.elastic.co/support/matrix), so using Debian as the base image here makes more sense anyway.
/test metricbeat-goIntegTest |
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public. (cherry picked from commit 27763e8) # Conflicts: # dev-tools/kubernetes/filebeat/Dockerfile.debug # dev-tools/kubernetes/heartbeat/Dockerfile.debug # dev-tools/kubernetes/metricbeat/Dockerfile.debug
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public. (cherry picked from commit 27763e8)
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public. (cherry picked from commit 27763e8) Co-authored-by: Denis <[email protected]>
…updates (#35929) * Make all docker images consistent for future updates (#35919) We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public. (cherry picked from commit 27763e8) # Conflicts: # dev-tools/kubernetes/filebeat/Dockerfile.debug # dev-tools/kubernetes/heartbeat/Dockerfile.debug # dev-tools/kubernetes/metricbeat/Dockerfile.debug * Delete files that are not present in 7.17 --------- Co-authored-by: Denis <[email protected]>
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first. If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public.
What does this PR do?
We have update CLI that takes care of Docker image updates. In order to cover all the images we need to make them consistent first.
If we keep these images at older versions, we'll be constantly receiving CVE notifications, so it's easier to automate these updates even though these images are internal and are never released to the public.
Why is it important?
It's a preparation step for another PR that will come later and will update the update CLI configuration to include all these paths.
How to test this PR locally
I ran
docker build --no-cache .
on each changed Dockerfile.