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

Integrate docker login for private repositories #28

Open
agemooij opened this Issue Apr 30, 2015 · 10 comments

Comments

Projects
None yet
3 participants
@agemooij

We push to a private registry (i.e. on dockerhub but private) so before we can do a docker push, we need to call docker login. It would be great if this plugin would support this.

Suggested solution:

  • create a DockerRegistry case class instead of the String currently used in ImageName and add a private boolean and an optional credentials field
  • update DockerPush to perform the necessary docker login command for private registries
  • (optionally) update DockerPush to perform the docker logout command afterwards

I'll probably start building this very soon since our project needs these features so if you agree with the suggested solution, I'll send you a pull request next week.

Regards,
Age

@marcuslonnberg

This comment has been minimized.

Show comment
Hide comment
@marcuslonnberg

marcuslonnberg May 1, 2015

Owner

I'm interested in your use case. Can you explain where you need it?
The way I handle this is that docker login runs once on every machine, in order to both pull and push images.

Regarding your suggested solution. I think it would be better to handle credentials globally. You set them once and then they are automatically used whenever they are needed.

Owner

marcuslonnberg commented May 1, 2015

I'm interested in your use case. Can you explain where you need it?
The way I handle this is that docker login runs once on every machine, in order to both pull and push images.

Regarding your suggested solution. I think it would be better to handle credentials globally. You set them once and then they are automatically used whenever they are needed.

@agemooij

This comment has been minimized.

Show comment
Hide comment
@agemooij

agemooij May 1, 2015

To be honest, I mostly asked because this is the way we currently push Docker images from Ansible. I'll look into the reasons behind this but I assume the main reason is to make builds self-contained instead of requiring some form of initialization.

I guess we could offer a dockerRegistryCredentials setting that would be very similar to the credentials setting used for ivy/maven repositories. I guess then it makes sense to also offer a dockerLogin task and leave the choice whether to login or not to the user? Otherwise how would the credentials be associated with a particular registry?

AFAIK DockerHub requires the email address as a third parameter next to username and password so reusing the existing Credentials class would not be possible but it should be usable in the same way, i.e. both specified directly and by loading a file.

agemooij commented May 1, 2015

To be honest, I mostly asked because this is the way we currently push Docker images from Ansible. I'll look into the reasons behind this but I assume the main reason is to make builds self-contained instead of requiring some form of initialization.

I guess we could offer a dockerRegistryCredentials setting that would be very similar to the credentials setting used for ivy/maven repositories. I guess then it makes sense to also offer a dockerLogin task and leave the choice whether to login or not to the user? Otherwise how would the credentials be associated with a particular registry?

AFAIK DockerHub requires the email address as a third parameter next to username and password so reusing the existing Credentials class would not be possible but it should be usable in the same way, i.e. both specified directly and by loading a file.

@marcuslonnberg

This comment has been minimized.

Show comment
Hide comment
@marcuslonnberg

marcuslonnberg May 1, 2015

Owner

I like the idea of having a dockerLogin task and that it's up to every user to decide if and when to run it.
Unfortunately it will change the .dockercfg file, which effects the credentials for Docker from outside of sbt. But that might be ok given that the user understands that when running the dockerLogin task.

If you decide to build it is probably best to create a new credentials class. dockerRegistryCredentials sounds good as the key.

Owner

marcuslonnberg commented May 1, 2015

I like the idea of having a dockerLogin task and that it's up to every user to decide if and when to run it.
Unfortunately it will change the .dockercfg file, which effects the credentials for Docker from outside of sbt. But that might be ok given that the user understands that when running the dockerLogin task.

If you decide to build it is probably best to create a new credentials class. dockerRegistryCredentials sounds good as the key.

@agemooij

This comment has been minimized.

Show comment
Hide comment
@agemooij

agemooij Jun 18, 2015

Hi Marcus. I lost track of this for a while but we are still working around this so I wanted to pick it up again.

I think the dockerLogin task should be interactive to ask for the password, right?

I guess we could use a dockerRegistryCredentials key for the username and email address but I don't think it would be a good thing to hardcode the password in a build file.
We could also default to asking all three questions if no dockerRegistryCredentials key has been set (i.e. the key is an Option[DockerRegistryCredentials]).

What do you think?

Hi Marcus. I lost track of this for a while but we are still working around this so I wanted to pick it up again.

I think the dockerLogin task should be interactive to ask for the password, right?

I guess we could use a dockerRegistryCredentials key for the username and email address but I don't think it would be a good thing to hardcode the password in a build file.
We could also default to asking all three questions if no dockerRegistryCredentials key has been set (i.e. the key is an Option[DockerRegistryCredentials]).

What do you think?

@marcuslonnberg

This comment has been minimized.

Show comment
Hide comment
@marcuslonnberg

marcuslonnberg Jun 22, 2015

Owner

I have started prototyping on integrating scala-docker into sbt-docker. So that sbt-docker does not have to call the docker binary but instead uses the DockerClient from scala-docker.
When this is done it would be natural to support some way of adding registry auths to the client. Either with a key such as dockerRegistryCredentials or by adding auths directly to the client DockerClient().withAuths(...) with a task.
This approach will not make any changes to the .dockercfg, only reading auths from it.

Regarding interactive task or not. I think it will be sufficient to have the credentials in a dockerRegistryCredentials key.
If you don't want to hard code your passwords in credentials and dockerRegistryCredentials you should be able to use environment variables for that.
I don't see any use case where you would manually run the dockerLogin task and adding credentials interactively.

Seq[DockerRegistryCredential] is probably a good type for dockerRegistryCredentials.

Owner

marcuslonnberg commented Jun 22, 2015

I have started prototyping on integrating scala-docker into sbt-docker. So that sbt-docker does not have to call the docker binary but instead uses the DockerClient from scala-docker.
When this is done it would be natural to support some way of adding registry auths to the client. Either with a key such as dockerRegistryCredentials or by adding auths directly to the client DockerClient().withAuths(...) with a task.
This approach will not make any changes to the .dockercfg, only reading auths from it.

Regarding interactive task or not. I think it will be sufficient to have the credentials in a dockerRegistryCredentials key.
If you don't want to hard code your passwords in credentials and dockerRegistryCredentials you should be able to use environment variables for that.
I don't see any use case where you would manually run the dockerLogin task and adding credentials interactively.

Seq[DockerRegistryCredential] is probably a good type for dockerRegistryCredentials.

@agemooij

This comment has been minimized.

Show comment
Hide comment
@agemooij

agemooij Jun 22, 2015

True, environment vars would be a good way to deal with this.

Does the fact that the dockerRegistryCredentials setting returns a Seq mean that the login task should attempt all of them until one succeeds or it runs out of credentials? What are the use cases for having multiple credentials?

True, environment vars would be a good way to deal with this.

Does the fact that the dockerRegistryCredentials setting returns a Seq mean that the login task should attempt all of them until one succeeds or it runs out of credentials? What are the use cases for having multiple credentials?

@marcuslonnberg

This comment has been minimized.

Show comment
Hide comment
@marcuslonnberg

marcuslonnberg Jun 22, 2015

Owner

The use case for multiple credentials is that you might push images to different registry, or you might pull from one registry and push to another. You can build many Docker images from the same sbt project.

All auths in dockerRegistryCredentials should be added to the client. If one DockerRegistryCredentials is not valid it is ok to fail the task (throw an exception).

Owner

marcuslonnberg commented Jun 22, 2015

The use case for multiple credentials is that you might push images to different registry, or you might pull from one registry and push to another. You can build many Docker images from the same sbt project.

All auths in dockerRegistryCredentials should be added to the client. If one DockerRegistryCredentials is not valid it is ok to fail the task (throw an exception).

@agemooij

This comment has been minimized.

Show comment
Hide comment
@agemooij

agemooij Jun 22, 2015

Wouldn't it make more sense to couple the credentials to the registry in some way? So you specify them together to prevent having to try a set of credentials meant for different registries on one registry?

Wouldn't it make more sense to couple the credentials to the registry in some way? So you specify them together to prevent having to try a set of credentials meant for different registries on one registry?

@marcuslonnberg

This comment has been minimized.

Show comment
Hide comment
@marcuslonnberg

marcuslonnberg Jun 22, 2015

Owner

As I see it DockerRegistryCredentials should be

case class DockerRegistryCredentials(url: String, email: String, password: String)

Then the email and password is coupled with the url to the registry.

Do you have another idea for it?

Owner

marcuslonnberg commented Jun 22, 2015

As I see it DockerRegistryCredentials should be

case class DockerRegistryCredentials(url: String, email: String, password: String)

Then the email and password is coupled with the url to the registry.

Do you have another idea for it?

@tfulton

This comment has been minimized.

Show comment
Hide comment
@tfulton

tfulton Oct 11, 2016

Hi. Did this by chance get resolved? We are using a private registry (Artifactory) and "docker login" is how we are currently authenticating against the repo. Any help would be great!

tfulton commented Oct 11, 2016

Hi. Did this by chance get resolved? We are using a private registry (Artifactory) and "docker login" is how we are currently authenticating against the repo. Any help would be great!

noelmarkham added a commit to scala-exercises/evaluator that referenced this issue Oct 25, 2016

Using the sbt-docker plugin.
Note, still need to use the `docker` service in Travis, as you cannot
programmatically log in to private repositories, like Heroku. See
marcuslonnberg/sbt-docker#28 for more details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment