docker-commons support for DOCKER_CONFIG

[nicolas de loof]

Docker 1.8 introduces DOCKER_CONFIG (aka --config) which can be used to set an alternate configuration directory

IIUC current design does not support multiple executors running docker commands with distinct credentials, as both will concurrently update and rely on same $HOME config file. 

I'd like to detect docker 1.8 or later and then rely on a temp directory, fully isolated per build.

To achieve this I need to enforce all KeyMaterialFactory to use the exact same KeyMaterialContext, which will require 

1. to ensure client code do combine them with KeyMaterialFactory#plus and does not invoke them separately (like https://github.com/jenkinsci/docker-build-publish-plugin/blob/master/src/main/java/com/cloudbees/dockerpublish/DockerBuilder.java#L384 does)

2. remove KeyMaterialFactory#contextualize reassign check so KeyMaterialFactory#plus can force all factories to use the same context

any thoughts ?

[Jesse Glick]

On Wed, Aug 12, 2015 at 6:08 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Docker 1.8 introduces DOCKER_CONFIG (aka --config) which can be used to set
> an alternate configuration directory

Great.

> IIUC current design does not support multiple executors running docker
> commands with distinct credentials, as both will concurrently update and
> rely on same $HOME config file.

Well, it sort of works, but: https://issues.jenkins-ci.org/browse/JENKINS-28702

> To achieve this I need to enforce all KeyMaterialFactory to use the exact same KeyMaterialContext

Did not follow any of that at first glance, but anyway better describe
in JENKINS-28702.

[nicolas de loof]

2015-08-13 0:21 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:

On Wed, Aug 12, 2015 at 6:08 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Docker 1.8 introduces DOCKER_CONFIG (aka --config) which can be used to set
> an alternate configuration directory

Great.

> IIUC current design does not support multiple executors running docker
> commands with distinct credentials, as both will concurrently update and
> rely on same $HOME config file.

Well, it sort of works, but: https://issues.jenkins-ci.org/browse/JENKINS-28702

I don't think this is the sole issue.

Let's say I have slave with 2 executors, and two jobs running docker push to registry, with distinct credentials, running concurrently

- job 1 do set .docker/config.json with credentials c1

- job 2 do set .docker/config.json with credentials c2

- job 1 do run docker push, expecting c1 well set for registry - push fails, as c2 does not allow to push to this repository

 

> To achieve this I need to enforce all KeyMaterialFactory to use the exact same KeyMaterialContext

Did not follow any of that at first glance, but anyway better describe
in JENKINS-28702.

added comment on https://issues.jenkins-ci.org/browse/JENKINS-28702

 

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0WUEdiXRm8_oC5zA6QhhAoHv00cMvu3BP5SBwWGGOs7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jesse Glick]

On Wed, Aug 12, 2015 at 6:39 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Let's say I have slave with 2 executors, and two jobs running docker push to
> registry, with distinct credentials, running concurrently
> - job 1 do set .docker/config.json with credentials c1
> - job 2 do set .docker/config.json with credentials c2
> - job 1 do run docker push, expecting c1 well set for registry - push fails,
> as c2 does not allow to push to this repository

AFAIK this is not an issue in the current plugin because the registry
URL is a key in the JSON. Unless you mean that they are both trying to
access the _same_ registry, and this registry has some accounts which
are read-only and some which allow push. Theoretically possible though
it seems unlikely. Anyway if we can use the 1.8 feature then of course
we should do it.

[nicolas de loof]

2015-08-13 20:46 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:

On Wed, Aug 12, 2015 at 6:39 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Let's say I have slave with 2 executors, and two jobs running docker push to
> registry, with distinct credentials, running concurrently
> - job 1 do set .docker/config.json with credentials c1
> - job 2 do set .docker/config.json with credentials c2
> - job 1 do run docker push, expecting c1 well set for registry - push fails,
> as c2 does not allow to push to this repository

AFAIK this is not an issue in the current plugin because the registry
URL is a key in the JSON. Unless you mean that they are both trying to
access the _same_ registry, and this registry has some accounts which
are read-only and some which allow push.

Yes exactly, typically accessing dockerhub to push to project repositories, each team having distinct credentials

 

Theoretically possible though
it seems unlikely. Anyway if we can use the 1.8 feature then of course
we should do it.

--
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-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1yoW5K%2BhKMgTsZL0ig3V0hhrRQ_DTTXnbDsjMuXDeBwQ%40mail.gmail.com.