Skip to content
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

include stopped containers #130

Merged
merged 1 commit into from
Feb 24, 2016
Merged

include stopped containers #130

merged 1 commit into from
Feb 24, 2016

Conversation

minhdoboi
Copy link
Contributor

It may be interesting to see stopped containers.
For example, my use case was to expose volumes mount points to nginx, that contains the results of a dockerized script.

@@ -97,7 +97,7 @@ func splitDockerImage(img string) (string, string, string) {
func getContainers(client *docker.Client) ([]*RuntimeContainer, error) {

apiContainers, err := client.ListContainers(docker.ListContainersOptions{
All: false,
All: true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it make sense to let the server do the filtering and make the All flag dependent on the value of includeStopped?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a case where a config file contains 2 configs, one needing the stopped containers, but not the other, and this method is called once for both configs. I agree it's not optimized in the case where nobody needs it, which is the most common use case, but I was not sure if it was worth optimizing it.
I can check if at least one config use it if you want. I don't know if there's a better solution.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like a fine solution to me.

I'd consider introducing a Generator struct that contains the docker.Client and the Config and moving the generate* functions to hang off of that.

@jwilder What do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this approach is fine as is for now. I'm not sure I understand how the Generator concept would work, but not opposed to that either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like a Generator type would pretty naturally fall out of the effort of turning docker-gen into a library that I mentioned over in nginx-proxy/nginx-proxy#254 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just opened #131 as a place to discuss the issue.

@punkstar
Copy link
Contributor

👍

I agree, this would be a really useful feature. Our use case is generating vhost definitions for stopped containers that point to an internal web service that will start those containers back up again when visited.

I'm sure this is already known, but a change in the returned structs will require an update to the "Templating" section of the documentation and the addition of the include-stopped switch will require an update to the "Usage" section.

I wasn't sure whether or not this was done as part of PRs on this project, or as a pre-release task.

@jwilder
Copy link
Collaborator

jwilder commented Jan 2, 2016

Can you rebase?

@minhdoboi
Copy link
Contributor Author

Yes, rebase is done.

jwilder added a commit that referenced this pull request Feb 24, 2016
@jwilder jwilder merged commit d48e1f3 into nginx-proxy:master Feb 24, 2016
@jwilder
Copy link
Collaborator

jwilder commented Feb 24, 2016

Thanks @minhdoboi!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants