Skip to content

USER and Layers Discussion #30110

@duglin

Description

@duglin

While reviewing #28499 in today's maintainer meeting we decided to take a step back and talk about whether we should consider this at a higher level.

It seems there are two issues at play here:
1 - under what id should a certain Dockerfile command be executed under? root vs USER
2 - is the USER --chown issue really a work-around because of the layering issue?
Meaning, are people ok with COPY+RUN chmod... if an extra layer wasn't created? Which is related to @stevvooe's comment: https://github.com/docker/docker/issues/29853#issuecomment-271469066

So, we decided to open up this issue to have a discussion around how to move forward.

Let's start with some questions:
1 - If we were starting from scratch (and didn't have to worry about backwards compat) would people prefer for USER to change the id under which subsequent COPY/ADD/RUN/... commands run?
2 - is it true that while being able to COPY --user john ... is perhaps easier to write than COPY ... + RUN chmod ..., are people ok with two commands if an extra layer were not created?

Personal opinion:

  • I think USER impacting subsequent commands is more natural, so I would be in favor of USER --persist john type of flag to enable this. This won't break backwards compat.
  • I liked @stevvooe's suggestion of using an @ prefix on a Dockerfile command to indicate that we should skip the commit on this command. I have no idea what kind of impact this would have on caching yet, but if we can make it work I like that better than previous suggestions of BEGIN/END type of commands. It seems so non-intrusive. And yes I know we have a squash command on build now, but there are time when people still want layers, just not as many as they get today.

Please post your comments/opinions here instead of in #28499 and moby/buildkit#4242

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/builderBuildkind/enhancementEnhancements are not bugs or new features but can improve usability or performance.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions