Using <user> in <build> does not place USER in the correct location in the resulting Dockerfile

[dhoffer]

Using in build does not place USER in the correct location in the resulting Dockerfile. It should place the USER statement in the order specified in the section but instead it moves it to the end of the Dockerfile.

In our case it must place USER # prior to the RUN statement else that RUN statements cannot succeed.

I am using 0.34.1 Maven version 3.6.3

<user>0</user> <runCmds> <run>chmod -R 775 ${app.home}/tmp/</run> <run>chmod -R 775 ${app.home}/logs/</run> </runCmds>

Must generate this:

USER 0 RUN chmod -R 775 /opt/storefront/tmp/ && chmod -R 775 /opt/storefront/logs/

[dhoffer]

Also this command may need to be used several times per generated docker file so the plugin has to support this as well. It needs to insert the command in the same order as it is in the XML configuration.

[sabi0]

I have the same problem. And would like to suggest a different way to address it. Deprecate <runCmds>. And add instead more versatile <beforeAssembly> and <afterAssembly>.

Then it would be possible to do something like this:

<beforeAssembly>
    <line>USER root</line>
    <line>RUN chmod ...</line>
    <line>USER app</line>
</beforeAssembly>
<assembly>...</assembly>
<afterAssembly>
    <line>ONBUILD ...</line>
</afterAssembly>

('beforeAssembly' and 'afterAssembly' are probably not the best names. 'beforeCopy' / 'afterCopy' ?)

<user> could be left for setting the user at the end of the Dockerfile.

[rhuss]

using the XML configuration for generating a Dockerfile is limited, true. Also because the order of the XML configuration gets erased before it reaches the plugin (i.e. the options are injected as a map with the option keys as values).

I don't want to blow up the XML syntax further so that it gets closer and closer to a Dockerfile anyway. We should not try to reinvent the wheel here, but provide a simplified and opinionated way for configuring standard docker build configuration that might fit in 80-90% of the cases.

If you need a more powerful syntax then please use the Dockerfile mode of dmp. We can discuss whether we want to extend the Dockerfile mode for e.g. more parameterization, but the Dockerfile mode gives you the ultimate freedom to put any Dockerfile directive at any place that you want (including USER)

[sabi0]

Here is my case. I have about 10 modules that all need to build identical Docker images (except for the modules' code, of course). So I wanted to describe the image layout in the parent POM. And then just "activate" the plugin in the modules. Unfortunately I need to run an extra ("hardening") step as root. That is why I need that USER after COPY.

This can be done with Dockerfile of course. But will make the setup quite a bit more complex. I will need to place this shared resource in some module (cannot put it in the POM-only parent). Add this dependency to every module I want to build a Docker image for. And every module would still be responsible for extracting that resource and placing it in the location configured in the plugin in the parent POM. I.e. instead of having everything in one place and then just "enable Docker image", three distinct modules would have to work in tandem to produce a single Docker image.