Cannot apply patch to base image

[tdiesler]

We are using a wildfly base image with an applied patch. The Dockerfile is

# Use the wildfly-8.1.0.Final image
FROM tdiesler/wildfly:8.1.0.Final

MAINTAINER Thomas Diesler <tdiesler@redhat.com>

# [TODO] Why does this not work?
# ADD wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /opt/jboss/wildfly

# Copy & Extract the WildFly Camel patch
COPY wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /tmp/wildfly-camel-patch.tar.gz
RUN tar -xzf /tmp/wildfly-camel-patch.tar.gz -C /opt/jboss/wildfly 

# Set the default command to run on boot
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone-camel.xml", "-b", "0.0.0.0"]

It seems that I cannot apply a patch with the docker-maven-plugin because it replaces /opt/jboss/wildfly and does not add to it.

To reproduce, please build

https://github.com/tdiesler/wildfly-camel/tree/docker-mvn-plugin

In docker/pom.xml I commented out the wanted target config

[tdiesler]

This has been discussed here: moby/moby#6119
The plugin should perhaps move to COPY and not use ADD any more

[rhuss]

Good point. I'm just cutting a new release, hopefully I get this in right now (if not, next week is the next release scheduled).

I wonder whether there is a risk that somebody is relying on the original behaviour that the directory is set to uid 0 (currently I can't imagine a use case for this).

[rhuss]

BTW, in the documentation they state that also for COPY the uid is set to 0.

Have to check this on my own I guess ....

[rhuss]

Just changed this to use COPY instead of ADD but it still sets the UID to 0 (as described in the documentation).

What we could do is to add an explicit UID to the configuration or we wait until full Dockerfile support is available (as described in #62 , a dedicated ticket is still pending).

Also, you base image could use the /maven dir during startup and copy over the artefacts to another directory (like the consol/tomcat-8.0 doest).

Still have to think a bit, for the release now, I'm afraid that the change ADD to COPY doesn't really helps you.

[tdiesler]

There is no rush - I have this workaround

COPY wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /tmp/wildfly-camel-patch.tar.gz
RUN tar -xzf /tmp/wildfly-camel-patch.tar.gz -C /opt/jboss/wildfly 

which preserves ownership of existing directories. I feel that this should somehow be addressed at the docker level

[tdiesler]

A little more background ...

It is best practise in Docker not to run apps as root. For all our stuff we use a jboss/base image that creates a jboss user. Dirs accessed by this user cannot be owned by root

ADD/COPY always use root.root effectively rendering a dir unaccessible if it was previously be owned by user jboss.

As a consequence, ADD/COPY cannot be used with a user owned dir structure unless some file ownership hack go with it.

[rhuss]

I wonder how Docker deals with this is the recommendation to do an chown on one's one every time a file is added ? I really would support that if a USER directive is given in the Dockerfile everything COPYed afterwards should belong to this user (but then the question is also, whether the USER should be inherited from a base image).

But no problem, we are on it so that in one of the next version it should be possible to add an user or the export directory (see also #64)

[jgangemi]

is this still an issue as of the 0.11.1 release?