-
Notifications
You must be signed in to change notification settings - Fork 143
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
Elastic Agent ACI compliant image #3778
Conversation
…nstances (elastic#3576)" (elastic#3723)" This reverts commit 29386eb.
still working on -complete image size |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
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.
Aside from some unnecessary change of ownership in the earlier stage, the change looks good.
Just out of curiosity: how hard would it be to always create the elastic-agent
user and group, associate all the files to that and as last instruction add a USER instruction ? (ideally with the value being an argument instead of a template)
The user could be specified at runtime by using something like docker run --user elastic-agent ...
if we want to run as non-root without having to decide at image build time
{{- if ne .user "root" }} | ||
RUN groupadd --gid 1000 {{ .BeatName }} && \ | ||
useradd -M --uid 1000 --gid 1000 --groups 0 {{ .user }} && \ | ||
true | ||
{{- end }} | ||
|
||
RUN mkdir -p {{ $beatHome }}/data {{ $beatHome }}/data/elastic-agent-{{ commit_short }}/logs && \ | ||
chown -R root:root {{ $beatHome }} && \ | ||
COPY --chown={{ .user }}:{{ .user }} beat {{ $beatHome }} | ||
|
||
RUN true && \ | ||
{{- if ne .user "root" }} | ||
usermod -d {{ $beatHome}} {{ .user }} && \ | ||
{{- end}} | ||
# ECE needs to create config here under non-1000 user | ||
chmod 0777 {{ $beatHome}} && \ | ||
mkdir -p {{ $beatHome }}/data {{ $beatHome }}/data/elastic-agent-{{ commit_short }}/logs && \ | ||
find {{ $beatHome }} -type d -exec chmod 0755 {} \; && \ | ||
find {{ $beatHome }} -type f -exec chmod 0644 {} \; && \ | ||
find {{ $beatHome }}/data -type d -exec chmod 0770 {} \; && \ | ||
find {{ $beatHome }}/data -type f -exec chmod 0660 {} \; && \ | ||
find {{ $beatHome }}/data -type d -exec chmod 0777 {} \; && \ | ||
find {{ $beatHome }}/data -type f -exec chmod 0666 {} \; && \ |
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.
Why do we need to create the user and the correct ownership in the intermediate stage ? Wouldn't it be enough to copy with the correct ownership and user in the last stage (line ~127) ?
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.
hmm that;s a nice idea, will check, not sure it will let us differentiate /d/f though
@@ -27,7 +38,7 @@ RUN mkdir -p {{ $beatHome }}/data {{ $beatHome }}/data/elastic-agent-{{ commit_s | |||
(chmod 0755 {{ $beatHome }}/data/elastic-agent-*/components/pf-elastic-collector || true) && \ | |||
(chmod 0755 {{ $beatHome }}/data/elastic-agent-*/components/pf-elastic-symbolizer || true) && \ | |||
(chmod 0755 {{ $beatHome }}/data/elastic-agent-*/components/pf-host-agent || true) && \ | |||
find {{ $beatHome }}/data/elastic-agent-{{ commit_short }}/components -name "*.yml*" -type f -exec chown root:root {} \; && \ | |||
find {{ $beatHome }}/data/elastic-agent-{{ commit_short }}/components -name "*.yml*" -type f -exec chown {{ .user }}:{{ .user }} {} \; && \ |
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.
this is a no, modules permissions are checked to be owned by root
Did we confirm this image can be deployed to Elastic Cloud successfully and that ECE stack can come up. I would also like @blakerouse to review this before merge to see if there is anything that will cause problems for the non-root/unprivileged agent work. |
i created cloud instance using our regular testing/cloud env. this was fine. |
i'm seeing some weird behavior but i see it on main as well. |
seems like some env issues on my side, rebuilt on my linux machine and it seems to produce system metrics normally. |
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.
Looks good to me
…gent into image-custom-uid
SonarQube Quality Gate |
What does this PR do?
Bringing back work which allows
Size comparison