You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementing this for the elastic-agent images is a breaking change, but we also want to introduce new edot-collector images for Elastic Agent.
For Elastic Agent we want there to be two docker images: elastic-agent which includes all components and elastic-agent-slim, which would be a container built with only agentbeat, osqueryd, and pf-host-agent.
For EDOT Collector, we want there to be one docker image: edot-collector which includes only Agentbeat and osqueryd. Ideally this would be the same image as elastic-agent-slim, simply aliased to edot-collector.
As a workaround to enable availability of the edot-collector image starting with 9.0, without making a breaking change later, we could base our edot-collector image on the existing elastic-agent image, and simply delete the extra components from the image. The addition/removal of the components would still occupy space in the image as they would be done in separate layers, but the binaries would be unavailable for a customer to leverage.
When we are ready to take on work to produce the slim image from scratch we will be able to swap it in without a breaking change for users.
The text was updated successfully, but these errors were encountered:
I assume we want the entrypoint to be different in the edot image?
We may as well introduce elastic-agent-slim at the same time, and just have the base images set up the way we want from the beginning. It won't cost us much more in terms of effort.
P.S. every additional docker image we add needs another trip through our container and kubernetes smoke tests in CI so there is an overhead to adding images from a development perspective.
As a follow-on to #6542
Implementing this for the elastic-agent images is a breaking change, but we also want to introduce new
edot-collector
images for Elastic Agent.For Elastic Agent we want there to be two docker images:
elastic-agent
which includes all components andelastic-agent-slim
, which would be a container built with only agentbeat, osqueryd, and pf-host-agent.For EDOT Collector, we want there to be one docker image:
edot-collector
which includes only Agentbeat and osqueryd. Ideally this would be the same image aselastic-agent-slim
, simply aliased toedot-collector
.As a workaround to enable availability of the
edot-collector
image starting with 9.0, without making a breaking change later, we could base our edot-collector image on the existing elastic-agent image, and simply delete the extra components from the image. The addition/removal of the components would still occupy space in the image as they would be done in separate layers, but the binaries would be unavailable for a customer to leverage.When we are ready to take on work to produce the slim image from scratch we will be able to swap it in without a breaking change for users.
The text was updated successfully, but these errors were encountered: