Skip to content
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

Cannot apply patch to base image #53

Closed
tdiesler opened this issue Nov 24, 2014 · 8 comments
Closed

Cannot apply patch to base image #53

tdiesler opened this issue Nov 24, 2014 · 8 comments
Milestone

Comments

@tdiesler
Copy link

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
Copy link
Author

tdiesler commented Dec 5, 2014

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

@rhuss
Copy link
Collaborator

rhuss commented Dec 5, 2014

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 rhuss added this to the 0.10.5 milestone Dec 5, 2014
@rhuss
Copy link
Collaborator

rhuss commented Dec 5, 2014

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
Copy link
Collaborator

rhuss commented Dec 5, 2014

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
Copy link
Author

tdiesler commented Dec 5, 2014

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
Copy link
Author

tdiesler commented Dec 8, 2014

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
Copy link
Collaborator

rhuss commented Dec 8, 2014

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
Copy link
Collaborator

is this still an issue as of the 0.11.1 release?

@rhuss rhuss modified the milestones: 0.11.3, 0.11.0 Mar 1, 2015
@rhuss rhuss modified the milestones: 0.11.3, 0.11.4 Apr 21, 2015
@rhuss rhuss modified the milestones: 0.12.0, 0.11.4 May 15, 2015
@rhuss rhuss closed this as completed in 22acd56 May 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants