Docker workflow runs with user not fully configured

[Oliver Gondža]

I am tying to get jenkinsci/packaging to work from Pipeline using
docker-workflow-plugin:

```
builder = docker.build 'jenkins-packaging-builder:0.1'
builder.inside {
sh "make rpm ..."
}
```

All seems well except that rpmbuild comaplins at a couple of places: no
$HOME is defined, the uid/gid for generated files does not exist in the
system.

The problem is the pluign instructs docker to "use" user with uid/gid
matching the outer user (so filesystem can be shared) but the user
account does not exist inside. It seems that docker "creates" the user
to come extend but it is not fully configured causing tools to fail in
weird ways.

I guess I can switch to use the container as root somehow or update the
image to create some user for this purpose but this seems like an
inherent struggle with the approach. What is the best practice here?

In case it is relevant I am using docker 1.10.3 and
docker-workflow-plugin 1.6.

Thanks
--
oliver

[nicolas de loof]

This indeed is required so the actual files on workspace don't get corrupted by user IDs/premissions that only exist in your container.

You should configure your container to relax permission and let arbitrary user run your build tools

--
oliver

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2f6e4595-80e0-18ba-2e2a-6a1053aa0d87%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

Possibly related to https://github.com/jenkinsci/docker-workflow-plugin/pull/57.

[Samuel Van Oort]

Oliver, 

Apologies for the delayed response, but this is a known issue around how docker.inside is implemented.  It was very painful when setting up the docker image. 

This is why the docs and workflow script for the docker image don't use docker.inside -- https://github.com/jenkinsci/packaging/blob/master/docker/README.md

When using the packaging image in Jenkins builds, we have to invoke Docker manually (or run with arguments) rather than using the inside command. 

The sudo-able packaging test images use a different approach, by applying templating to Docker files and rebuilding so you can always have a correctly permissioned user. 

After some tinkering, I hit upon a much better way to do this, by dynamically creating a user within the container on the fly (which is also granted sudo permissions within the container).   There's a PR out for this: https://github.com/jenkinsci/packaging/pull/54

It's still pending review from someone though, but it's been tested out and works (was actually used for something small).  If it gets the community nod, we could merge and have a more robust system (the approach you use requires having a local user created). 

Hope that helps clarify somewhat!

Sam

[Jesse Glick]

On Wed, Sep 7, 2016 at 12:10 PM, Samuel Van Oort <svan...@cloudbees.com> wrote:
> this is a known issue around how
> docker.inside is implemented.

It is not “known” to me, the plugin maintainer, so as I wrote in PR
57: if there is a concrete, small, easily reproducible test case that
demonstrates something that does not work which you feel should,
please file it.

[Samuel Van Oort]

 

It is not “known” to me, the plugin maintainer, so as I wrote in PR
57: if there is a concrete, small, easily reproducible test case that
demonstrates something that does not work which you feel should,
please file it.

To clarify: I'm not saying that this is a result of a *problem* with how docker.inside is implemented, just that there is a bad interaction between the fairly reasonable implementation and what packaging needs to work fully (more than normal).  Nobody is trying to hide bugs from you or shoot holes in the docker-workflow plugin, there are just some cases where docker.inside isn't a good mapping to what is needed so another approach is best used, and this is one.

FWIW there's no guaranteed, comprehensive way to create and fully configure a user at runtime across all containers. When needed that is best handled within the container builds (or with helper scripts if you need to control the created user at runtime).  Containers may contain stripped-down distributions without the normal user management facilities (or with very feature-limited versions if core utilities are not included).  At this point I don't assume that *anything* exists and works in a base image until I see it run successfully.

[Jesse Glick]

On Wed, Sep 7, 2016 at 3:58 PM, Samuel Van Oort <svan...@cloudbees.com> wrote:
> Nobody is trying to hide bugs from you or shoot holes
> in the docker-workflow plugin, there are just some cases where docker.inside
> isn't a good mapping to what is needed

Understood, but if there is something the plugin could be doing
better, I would like to have it filed. Or if it is not feasible to
change the Jenkins behavior, perhaps the documentation could clarify
and emphasize those limitations.

[ogondza]

https://issues.jenkins-ci.org/browse/JENKINS-38438

--
oliver