Make it possible to store registry login on the server

[EugenMayer]

Yet, docker_registry just authenticates the chef-client to be able to pull during the run, but the credentials are not store in, e.g. ~/.docker/config.json.

Are there any plans to probably make it possible to define

docker_registry 'registry' do
  serveraddress 'https://registry.com/'
  username registry_user
  password registry_password
  email registry_email
  storage :local
end

By default, storage is :runtime ?

[someara]

Chef is speaking directly to the Docker API rather than shelling out to the docker binary.

https://github.com/chef-cookbooks/docker/blob/a950171f29c3bc729a45d7429575bf14ed965f13/libraries/docker_registry.rb#L26

Stashing credentials on disk would make it convenient for shell users outside of a Chef run, but which user? Chef typically runs as root....

It's best just to use a file or cookbook_file resource to drop off the config.json

[EugenMayer]

@someara well things get complicated this way, if you ignore that fact you will create a second ecosystem driving away from this cookbook. Just for example https://github.com/sboschert/chef-cookbook-docker_compose/issues/6 .. people use this cookbook to authenticate but cannot use docker-compose in the end.

Using this "during chef runs only" beats docker-compose completely, a tool to be used in the shell. The point is, if it is convinient using docker_registry, also stored as config.json, this will grow in the right direction.

I was aware that you ask for the user. I would put that as parameter, but usually docker-engine runs under root, all your commands do also, so this is a good default anyway.

What do you think?

[bflad]

Maybe we could have a separate resource something like docker_credentials that can then be used both by docker_registry (optionally) and a new wrapper file resource for making the config.json?

[EugenMayer]

@bflad not sure if that make sense, could you elaborate why to split that one out? It would mean plain duplication.

I would not change the default behavior for docker_registry, just add an option to deploy that for the shell. Creating a new resource in need for 90% of the same parameters will not help the convenience i suppos

[bflad]

As @someara pointed out, the cookbook would not have the proper details of who gets permissions on the configuration file and where it should be saved by default (although I guess root and ~root/.docker/config.json ... which would overwrite any other settings in there). To support configuring the file itself, the resource would need a couple more attributes (e.g. owner, mode, location, etc), which are really unrelated to a "docker registry". Also, what if the credentials should be saved in multiple locations? You would need to duplicate things or hack together the file resource to copy it around, which sounds messy.

Regardless of splitting out what I'm calling docker_credentials to reduce duplication, I do think something that can drop a managed config file is handy, if its possible/makes sense. I forget off the top of my head if you need to refresh the auth token that gets saved in the config.json (which could complicate things). There's also a few other things that can be dropped in there beyond "auths": https://github.com/docker/docker/blob/master/man/docker-config-json.5.md

[someara]

I have to do some work in this area soon anyway... stay tuned

On Dec 8, 2016, at 1:58 PM, Brian Flad notifications@github.com wrote:

As @someara pointed out, the cookbook would not have the proper details of who gets permissions on the configuration file and where it should be saved by default (although I guess root and ~root/.docker/config.json ... which would overwrite any other settings in there). To support configuring the file itself, the resource would need a couple more attributes (e.g. owner, mode, location, etc), which are really unrelated to a "docker registry". Also, what if the credentials should be saved in multiple locations? You would need to duplicate things or hack together the file resource to copy it around, which sounds messy.

Regardless of splitting out what I'm calling docker_credentials to reduce duplication, I do think something that can drop a managed config file is handy, if its possible/makes sense. I forget off the top of my head if you need to refresh the auth token that gets saved in the config.json (which could complicate things). There's also a few other things that can be dropped in there beyond "auths": https://github.com/docker/docker/blob/master/man/docker-config-json.5.md

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[EugenMayer]

@someara great stuff, i am tuned in :)

[AVVS]

We personally did the following stuff, some variables were redacted, but the idea should be clear, imo

ruby_block 'save docker auth info' do
  block do
    # /root/.docker/config.json
    # beta_gcr_io = node.run_state['docker_auth']['beta.gcr.io']
    # docker_default = node.run_state['docker_auth']['index.docker.io']
    # compose template
    #
    # Reason for this is that chef-docker cookbook keep auth data in memory
    # therefore, if we want to use docker manually (ie pull smth) we need to write this down
    #
    data = {
      'auths' => {
        'https://gcr.io/' => {
          'auth' => Base64.strict_encode64("_json_key:#{docker_json}"),
          'email' => docker_email
        },
        'https://index.docker.io/v1/' => {
          'auth' => Base64.strict_encode64("#{docker_username}:#{docker_password}"),
          'email' => docker_email
        }
      }
    }

    rc = Chef::Resource::File.new('/root/.docker/config.json', run_context)
    rc.path '/root/.docker/config.json'
    rc.mode 0600
    rc.content JSON.pretty_generate(data)
    rc.run_action :create

  end
end

[EugenMayer]

This will do it every single converge run, thats an issue ( we did the same + avoided the converge issue )

[AVVS]

yes, but generally writing a file doesnt really matter ;) Can you post your code with idempotent solution?

[someara]

Why not just use the file resource directly instead of turning it inside out from a ruby_block?

[nickkeyzer]

Sorry to add to this so late but this is exactly the type of functionality I was expecting when I first looked into this resource. I'm also attempting to use this in combination with docker-compose. I want the docker image pull cycle outside the chef-client run.

As @EugenMayer mentioned, this behavior completely ignores the docker-compose scenario. I'm seeing docker-compose being used a lot more often now and some people are even using it in combination with something like systemd to replace traditionally installed services.