docker-commons: plugin that centralizes docker configurations

[Kohsuke Kawaguchi]

I'm seeing a lot of docker related plugins in the community. They are already popular, and becoming more popular for obvious reasons.

So I started looking into how to improve the story around Jenkins and Docker, and I talked to some of you that a low-hanging fruit is to provide some common credentials configuration across those docker related plugins, so that people won't have to configure them repeatedly.

So I took my first stab at https://github.com/jenkinsci/docker-commons-plugin.

The plugin contains two sets of credential+endpoint information, one for talking to docker daemon and one for talking to docker registry. For registry, the credential is a token (and username+password for DockerHub.) For daemon, the credential is SSL client authentication stuff.

The endpoint combines the credential with the URL/URI of the registry/daemon. They expose a method that helps you invoke docker CLI in the right environment, an it hides the details of making key materials and tokens available to docker CLI. See some code example for details.

The endpoints are Describable, so that you can insert them into your builder/publisher etc, and it provides all the necessary configuration GUI.

I think it has enough shape in it to get the idea across, and so I wanted to have a conversation about that here before I release 1.0 and commit to the backward compatibility. I'll reach out to the folks who maintain popular docker plugins, but your thoughts are appreciated.

Just in case you want to play with the signature and so on, I published 1.0-alpha-1, but it's still missing a number of things to make it actually runnable, such as proper Descriptor implementations and config UIs.

--

Kohsuke Kawaguchi

[Kanstantsin Shautsou]

Frankly speaking credentials is the last thing that docker-plugin has issues with.

Cloud API is actively changes in latest jenkins versions and it difficult to follow for Cloud plugins developers what is really critical and how it should be used with backward compatibility.

Your experienced review will be welcome with architecture/internals suggestions. For example comments for Retention strategies questions that i raised in separate thread.

[Kanstantsin Shautsou]

I'm watching notifications from this repository and i feel impression that:

1) CloudBees even didn't reviewed any existed plugins and features that they have, imho docker-plugin itself can be a common for other plugins.

2) As i see they are implementing another one docker api client instead of existed https://github.com/jenkinsci/docker-commons-plugin/pull/3

This is really amazing and mostly looks like https://xkcd.com/927/

[Jesse Glick]

On Fri, Apr 10, 2015 at 9:42 AM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> CloudBees even didn't reviewed any existed plugins and features that they have

I think Kohsuke did, but missed the miscellaneous features in docker-plugin.

> docker-plugin itself can be a common for other plugins.

This is not suitable as a base since it provides end-user features.
What is needed is a library plugin.

> they are implementing another one docker api client

No, this is a misunderstanding discussed in that PR.

[Kanstantsin Shautsou]

On Friday, April 10, 2015 at 5:14:13 PM UTC+3, Jesse Glick wrote:

On Fri, Apr 10, 2015 at 9:42 AM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> CloudBees even didn't reviewed any existed plugins and features that they have

I think Kohsuke did, but missed the miscellaneous features in docker-plugin.

Yes, he firstly wrote code, created repository, released and then asked for comments.  

> docker-plugin itself can be a common for other plugins.

This is not suitable as a base since it provides end-user features.
What is needed is a library plugin.

1) It may be refactored, i see 0 comments about what can be reused from this plugin. 

2) Use jar and not hpi and it will be library?

> they are implementing another one docker api client

No, this is a misunderstanding discussed in that PR.

Yeah, really:

[WiP] Sketching a DockerClient API #3

[Jesse Glick]

On Fri, Apr 10, 2015 at 10:46 AM, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:
> Use jar and not hpi and it will be library?

Common code should use hpi packaging so it is loaded once. This is
advisable for internal utilities, and mandatory for APIs.