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

nginx.conf does not get updated with overlay network IPs #304

Closed
schmunk42 opened this Issue Nov 29, 2015 · 66 comments

Comments

Projects
None yet
@schmunk42
Contributor

schmunk42 commented Nov 29, 2015

I created an overlay-network for my swarm and can ping and wget a hello-world webserver in the swarm from the reverseproxy container.

This is my /etc/hosts

10.0.1.7        mynetwork_hello_1

And this the relevant part of nginx.conf

upstream ~my.test.com {
                        # mynetwork_hello_1
                        server :80;
}

As you can see the IP is missing.

Looks like somewhere around here the IP does not get written correctly.

Any idea how to fix this or is this an issue with docker-gen?

Tested on: docker 1.9.1, docker-compose 1.5.1

@schmunk42 schmunk42 changed the title from nginx.conf to nginx.conf does not get updated with overlay network IPs Nov 29, 2015

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Nov 29, 2015

Contributor

Related issue: #97

Contributor

schmunk42 commented Nov 29, 2015

Related issue: #97

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Nov 29, 2015

Contributor

This could be related to the new networking in docker, where a container can be attached to multiple networks. Only the default "bridge" networking propagates the old fields for IP-address of the container, but custom networks will not, and the IP address is returned in a nested list, see jwilder/docker-gen#129

Contributor

thaJeztah commented Nov 29, 2015

This could be related to the new networking in docker, where a container can be attached to multiple networks. Only the default "bridge" networking propagates the old fields for IP-address of the container, but custom networks will not, and the IP address is returned in a nested list, see jwilder/docker-gen#129

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Nov 29, 2015

Contributor

@thaJeztah Thank you for the feedback. I am not a go-programmer (yet), but I looked a bit through the code and played around with docker-gen.

So it looks to me, that we first need support of the new networking feature from fsouza/go-dockerclient. Not until then we could use the VXLan IPs in the nginx template. Right?

I thought about an additional ENV variable like VIRTUAL_NETWORK to define which IP should be used, any thoughts about this?

Contributor

schmunk42 commented Nov 29, 2015

@thaJeztah Thank you for the feedback. I am not a go-programmer (yet), but I looked a bit through the code and played around with docker-gen.

So it looks to me, that we first need support of the new networking feature from fsouza/go-dockerclient. Not until then we could use the VXLan IPs in the nginx template. Right?

I thought about an additional ENV variable like VIRTUAL_NETWORK to define which IP should be used, any thoughts about this?

@md5

This comment has been minimized.

Show comment
Hide comment
@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Dec 1, 2015

Contributor

@thaJeztah @jwilder @md5 Some updates from my side.

  1. I updated the client and added a very basic struct for the networks. This is working as intended so far. These are my very first steps in Go, so don't be too harsh ;) jwilder/docker-gen@master...schmunk42:feature/docker-network
  2. With this template I am able to insert the correct IPs, but with some glitches ... I need to specify VIRTUAL_NETWORK and VIRTUAL_PORT at the moment. I think I could get rid of the port definition, but I think we need something which defines the network to use.
  3. I wasn't really able to put all the pieces together and use the current nginx template with my patched docker-gen, that was mainly because of the different structures of Network and Address.

My plan would be to connect the reverseproxy to all docker-compose networks of my applications.

So .. would love to hear some thoughts from your side about this.

Contributor

schmunk42 commented Dec 1, 2015

@thaJeztah @jwilder @md5 Some updates from my side.

  1. I updated the client and added a very basic struct for the networks. This is working as intended so far. These are my very first steps in Go, so don't be too harsh ;) jwilder/docker-gen@master...schmunk42:feature/docker-network
  2. With this template I am able to insert the correct IPs, but with some glitches ... I need to specify VIRTUAL_NETWORK and VIRTUAL_PORT at the moment. I think I could get rid of the port definition, but I think we need something which defines the network to use.
  3. I wasn't really able to put all the pieces together and use the current nginx template with my patched docker-gen, that was mainly because of the different structures of Network and Address.

My plan would be to connect the reverseproxy to all docker-compose networks of my applications.

So .. would love to hear some thoughts from your side about this.

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 Dec 2, 2015

Contributor

@schmunk42 That looks like a great start. Glad to see that the necessary changes have landed in fsouza/go-dockerclient. I think if you add the IPv6-related fields to the struct, your changes to docker-gen will be in good shape for a PR.

As for the changes to the nginx.tmpl in this repo, I haven't looked closely enough to see what the right approach is to making it work, but I imagine it should be doable without any significant changes to docker-gen. Off the top of my head, I think that Address will no longer be used and that some more complicated logic about which Network to pick will be needed. It may also allow some consolidation around how Swarm is being handled, though I haven't looked into how the Swarm networking information is exposed in the new Docker API.

Contributor

md5 commented Dec 2, 2015

@schmunk42 That looks like a great start. Glad to see that the necessary changes have landed in fsouza/go-dockerclient. I think if you add the IPv6-related fields to the struct, your changes to docker-gen will be in good shape for a PR.

As for the changes to the nginx.tmpl in this repo, I haven't looked closely enough to see what the right approach is to making it work, but I imagine it should be doable without any significant changes to docker-gen. Off the top of my head, I think that Address will no longer be used and that some more complicated logic about which Network to pick will be needed. It may also allow some consolidation around how Swarm is being handled, though I haven't looked into how the Swarm networking information is exposed in the new Docker API.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Dec 2, 2015

Contributor

I played around with it a little bit more today...

Here's another approach without any changes to docker-gen or nginx-proxy, updated nginx.tmpl

{{ define "upstream" }}
    {{ if .Address }}
        {{/* If we got the containers from swarm and this container's port is published to host, use host IP:PORT */}}
        {{ if and .Container.Node.ID .Address.HostPort }}
            # {{ .Container.Node.Name }}/{{ .Container.Name }}
            server {{ .Container.Node.Address.IP }}:{{ .Address.HostPort }};
        {{/* If there is no swarm node or the port is not published on host, use container's IP:PORT */}}
        {{ else }}
            {{ if .Container.Env.VIRTUAL_NETWORK }}
                # {{ .Container.Env.VIRTUAL_NETWORK }} - {{ .Container.Name }}
                server {{ .Container.Name }}:{{ .Address.Port }};
            {{ else }}
            # {{ .Container.Name }}
            server {{ .Address.IP }}:{{ .Address.Port }};
        {{ end }}
        {{ end }}
    {{ else }}
        # {{ .Container.Name }}
        server {{ .Container.IP }} down;
    {{ end }}
{{ end }}

This is the changed section # {{ .Container.Env.VIRTUAL_NETWORK }} - {{ .Container.Name }}.
It still uses VIRTUAL_NETWORK, but with true/false values, which could also be read as USE_CONTAINER_NAME_AS_ADDRESS :)

The glitch at the moment is, that we have to connect the proxy to the app-network before we start it, otherwise we get an error (host not found).

@md5 But in general that goes in the same direction as you mentioned - swarm handling can be consolidated.

Contributor

schmunk42 commented Dec 2, 2015

I played around with it a little bit more today...

Here's another approach without any changes to docker-gen or nginx-proxy, updated nginx.tmpl

{{ define "upstream" }}
    {{ if .Address }}
        {{/* If we got the containers from swarm and this container's port is published to host, use host IP:PORT */}}
        {{ if and .Container.Node.ID .Address.HostPort }}
            # {{ .Container.Node.Name }}/{{ .Container.Name }}
            server {{ .Container.Node.Address.IP }}:{{ .Address.HostPort }};
        {{/* If there is no swarm node or the port is not published on host, use container's IP:PORT */}}
        {{ else }}
            {{ if .Container.Env.VIRTUAL_NETWORK }}
                # {{ .Container.Env.VIRTUAL_NETWORK }} - {{ .Container.Name }}
                server {{ .Container.Name }}:{{ .Address.Port }};
            {{ else }}
            # {{ .Container.Name }}
            server {{ .Address.IP }}:{{ .Address.Port }};
        {{ end }}
        {{ end }}
    {{ else }}
        # {{ .Container.Name }}
        server {{ .Container.IP }} down;
    {{ end }}
{{ end }}

This is the changed section # {{ .Container.Env.VIRTUAL_NETWORK }} - {{ .Container.Name }}.
It still uses VIRTUAL_NETWORK, but with true/false values, which could also be read as USE_CONTAINER_NAME_AS_ADDRESS :)

The glitch at the moment is, that we have to connect the proxy to the app-network before we start it, otherwise we get an error (host not found).

@md5 But in general that goes in the same direction as you mentioned - swarm handling can be consolidated.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Dec 2, 2015

Contributor

And I think we need to wait for the fix here docker/swarm#1402 first

Contributor

schmunk42 commented Dec 2, 2015

And I think we need to wait for the fix here docker/swarm#1402 first

@modius

This comment has been minimized.

Show comment
Hide comment
@modius

modius Dec 15, 2015

@schmunk42 would your earlier suggestions jwilder/docker-gen@fdf2922 fix jwilder/nginx-proxy for local networking with docker network? ie #305

modius commented Dec 15, 2015

@schmunk42 would your earlier suggestions jwilder/docker-gen@fdf2922 fix jwilder/nginx-proxy for local networking with docker network? ie #305

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Dec 15, 2015

Contributor

I haven't continued working on the PR, because I found the above solution without changing the image.

See above, for the first lines from our modified nginx.tmpl.

If a container is started with VIRTUAL_NETWORK=1 the reverse proxy uses the container name to resolve the upstream IP.

This works fine in conjunction with docker-compose and overlay networking.

Any thoughts about this? Do we need the these changes in the PR at all?

[update] removed duplicated code

You could give the above template a try with local docker networking, I at least can't remember having problems with it.

Contributor

schmunk42 commented Dec 15, 2015

I haven't continued working on the PR, because I found the above solution without changing the image.

See above, for the first lines from our modified nginx.tmpl.

If a container is started with VIRTUAL_NETWORK=1 the reverse proxy uses the container name to resolve the upstream IP.

This works fine in conjunction with docker-compose and overlay networking.

Any thoughts about this? Do we need the these changes in the PR at all?

[update] removed duplicated code

You could give the above template a try with local docker networking, I at least can't remember having problems with it.

@fbender

This comment has been minimized.

Show comment
Hide comment
@fbender

fbender Dec 15, 2015

This should work automatically without an extra env var to be specified. Isn't the type of networking available via the container info? Though it probably requires knowing if the proxy container is on the same network as the app container …

fbender commented Dec 15, 2015

This should work automatically without an extra env var to be specified. Isn't the type of networking available via the container info? Though it probably requires knowing if the proxy container is on the same network as the app container …

@md5

This comment has been minimized.

Show comment
Hide comment
@md5

md5 Dec 19, 2015

Contributor

@fbender I don't think the preferred networking type is specified in the container info. The container will have NetworkSettings.Networks set in the underlying response from the Docker API and that will include all network addresses, including the bridge network as well as any others.

I haven't fully thought through this, but I think that instead of a VIRTUAL_NETWORK setting on each container, the jwilder/nginx-proxy container will instead need to be launched with a setting that indicates its preferred network(s) for connecting to all the containers it can see. This will imply that if some containers aren't connected to that network (or networks) they will not be included in the config regardless of whether they have a VIRTUAL_HOST environment variable

Contributor

md5 commented Dec 19, 2015

@fbender I don't think the preferred networking type is specified in the container info. The container will have NetworkSettings.Networks set in the underlying response from the Docker API and that will include all network addresses, including the bridge network as well as any others.

I haven't fully thought through this, but I think that instead of a VIRTUAL_NETWORK setting on each container, the jwilder/nginx-proxy container will instead need to be launched with a setting that indicates its preferred network(s) for connecting to all the containers it can see. This will imply that if some containers aren't connected to that network (or networks) they will not be included in the config regardless of whether they have a VIRTUAL_HOST environment variable

@josteinbf

This comment has been minimized.

Show comment
Hide comment
@josteinbf

josteinbf Jan 31, 2016

I think that instead of a VIRTUAL_NETWORK setting on each container, the jwilder/nginx-proxy container will instead need to be launched with a setting that indicates its preferred network(s) for connecting to all the containers it can see. This will imply that if some containers aren't connected to that network (or networks) they will not be included in the config regardless of whether they have a VIRTUAL_HOST environment variable

This sounds like a good approach to me. It would allow other networks that are used by the proxied container to remain inaccessible to the nginx-proxy container, which I think is useful.

I think that instead of a VIRTUAL_NETWORK setting on each container, the jwilder/nginx-proxy container will instead need to be launched with a setting that indicates its preferred network(s) for connecting to all the containers it can see. This will imply that if some containers aren't connected to that network (or networks) they will not be included in the config regardless of whether they have a VIRTUAL_HOST environment variable

This sounds like a good approach to me. It would allow other networks that are used by the proxied container to remain inaccessible to the nginx-proxy container, which I think is useful.

@Ant59

This comment has been minimized.

Show comment
Hide comment
@Ant59

Ant59 Feb 17, 2016

Same issue with Docker 1.10 and Docker Compose 1.6. Missing IP address in upstream block. Using default network. Compose config version 2.

Ant59 commented Feb 17, 2016

Same issue with Docker 1.10 and Docker Compose 1.6. Missing IP address in upstream block. Using default network. Compose config version 2.

@gabriel403

This comment has been minimized.

Show comment
Hide comment
@gabriel403

gabriel403 Feb 17, 2016

Contributor

Yeh I just run into this too, same as @Ant59, it seems both the proxy and any webapp need starting in the singular way, with docker run rather than with docker-compose

Contributor

gabriel403 commented Feb 17, 2016

Yeh I just run into this too, same as @Ant59, it seems both the proxy and any webapp need starting in the singular way, with docker run rather than with docker-compose

@Ant59

This comment has been minimized.

Show comment
Hide comment
@Ant59

Ant59 Feb 17, 2016

Not using Compose isn't an option for me.

For some reason, docker-gen is no longer able to determine the IP address of the container when started using Compose.

Ant59 commented Feb 17, 2016

Not using Compose isn't an option for me.

For some reason, docker-gen is no longer able to determine the IP address of the container when started using Compose.

@wader

This comment has been minimized.

Show comment
Hide comment
@wader

wader Feb 17, 2016

@Ant59 the problem is that nginx-proxy does not yet support the new docker networking feature that docker compose version 2 uses. Try to use the previous compose config format instead.

wader commented Feb 17, 2016

@Ant59 the problem is that nginx-proxy does not yet support the new docker networking feature that docker compose version 2 uses. Try to use the previous compose config format instead.

@Ant59

This comment has been minimized.

Show comment
Hide comment
@Ant59

Ant59 Feb 17, 2016

Perfect. Older Compose config works. Thanks.

Ant59 commented Feb 17, 2016

Perfect. Older Compose config works. Thanks.

@meyer

This comment has been minimized.

Show comment
Hide comment
@meyer

meyer Feb 22, 2016

@wader thank yooooou. I wasted a few hours on this silly issue. Really needs to be mention in the README.

meyer commented Feb 22, 2016

@wader thank yooooou. I wasted a few hours on this silly issue. Really needs to be mention in the README.

@wader

This comment has been minimized.

Show comment
Hide comment
@wader

wader Feb 22, 2016

@meyer no probleeeem 😄

wader commented Feb 22, 2016

@meyer no probleeeem 😄

@meetmatt

This comment has been minimized.

Show comment
Hide comment
@meetmatt

meetmatt Feb 25, 2016

Didn't know that this is a confirmed issue. Should've searched better!
As a work around I just check for the Address.IP in returned Container structure, which allows to support both version 1 and 2 of docker-compose files:

{{ define "upstream" }}
    ...
    {{ if .Address.IP }}
        server {{ .Address.IP }}:{{ .Address.Port }};
    {{ else }}
        server {{ .Container.Name }}:{{ .Address.Port }};
    {{ end }}
    ...
{{ end }}

Didn't know that this is a confirmed issue. Should've searched better!
As a work around I just check for the Address.IP in returned Container structure, which allows to support both version 1 and 2 of docker-compose files:

{{ define "upstream" }}
    ...
    {{ if .Address.IP }}
        server {{ .Address.IP }}:{{ .Address.Port }};
    {{ else }}
        server {{ .Container.Name }}:{{ .Address.Port }};
    {{ end }}
    ...
{{ end }}
@almereyda

This comment has been minimized.

Show comment
Hide comment
@almereyda

almereyda Feb 28, 2016

I am now also using the following declaration to get working results:

{{ define "upstream" }}
        {{ if .Address }}
                {{/* If we got the containers from swarm and this container's port is published to host, use host IP:P$
                {{ if and .Container.Node.ID .Address.HostPort }}
                        # {{ .Container.Node.Name }}/{{ .Container.Name }}                                             
                        server {{ .Container.Node.Address.IP }}:{{ .Address.HostPort }};
                {{/* If there is no swarm node or the port is not published on host, use container's IP:PORT */}}
                {{ else if .Address.IP }}
                        # {{ .Container.Name }}
                        server {{ .Address.IP }}:{{ .Address.Port }};
                {{ else }}
                        # {{ .Container.Name }}
                        server {{ .Container.Name }}:{{ .Address.Port }};
                {{ end }}
        {{ else }}
                # {{ .Container.Name }}
                server {{ .Container.IP }} down;
        {{ end }}
{{ end }}

I am now also using the following declaration to get working results:

{{ define "upstream" }}
        {{ if .Address }}
                {{/* If we got the containers from swarm and this container's port is published to host, use host IP:P$
                {{ if and .Container.Node.ID .Address.HostPort }}
                        # {{ .Container.Node.Name }}/{{ .Container.Name }}                                             
                        server {{ .Container.Node.Address.IP }}:{{ .Address.HostPort }};
                {{/* If there is no swarm node or the port is not published on host, use container's IP:PORT */}}
                {{ else if .Address.IP }}
                        # {{ .Container.Name }}
                        server {{ .Address.IP }}:{{ .Address.Port }};
                {{ else }}
                        # {{ .Container.Name }}
                        server {{ .Container.Name }}:{{ .Address.Port }};
                {{ end }}
        {{ else }}
                # {{ .Container.Name }}
                server {{ .Container.IP }} down;
        {{ end }}
{{ end }}
@kop

This comment has been minimized.

Show comment
Hide comment
@kop

kop Mar 2, 2016

So is there any temporary solution to make nginx-proxy work with compose version 2 configs?

kop commented Mar 2, 2016

So is there any temporary solution to make nginx-proxy work with compose version 2 configs?

@kuhnroyal

This comment has been minimized.

Show comment
Hide comment
@kuhnroyal

kuhnroyal Mar 2, 2016

Yes, the previous comment.

Yes, the previous comment.

pavel64-sutyrin added a commit to pavel64-sutyrin/nginx-proxy that referenced this issue Mar 3, 2016

@orifito

This comment has been minimized.

Show comment
Hide comment
@orifito

orifito Mar 4, 2016

@almereyda thanks for that, just checked and it works fine with compose v2 🔝 😃

orifito commented Mar 4, 2016

@almereyda thanks for that, just checked and it works fine with compose v2 🔝 😃

@pavel64-sutyrin

This comment has been minimized.

Show comment
Hide comment
@pavel64-sutyrin

pavel64-sutyrin Mar 4, 2016

Hi folks,

I've started fixing this (see pavel64-sutyrin@035ea43, copypasted from @almereyda comment), but my mileage reports syntax error in nginx.tmpl.

Could someone please test my image, or drop here a link to a working image.

Some "version 2 only" support will work too (as I design compose files from scratch with latest compose).

Thanks!

Hi folks,

I've started fixing this (see pavel64-sutyrin@035ea43, copypasted from @almereyda comment), but my mileage reports syntax error in nginx.tmpl.

Could someone please test my image, or drop here a link to a working image.

Some "version 2 only" support will work too (as I design compose files from scratch with latest compose).

Thanks!

@FCO

This comment has been minimized.

Show comment
Hide comment
@FCO

FCO Mar 8, 2016

@SpaceDiver: unable to parse template: template: nginx.tmpl:17: unexpected {{else}} in define clause

FCO commented Mar 8, 2016

@SpaceDiver: unable to parse template: template: nginx.tmpl:17: unexpected {{else}} in define clause

@pavel64-sutyrin

This comment has been minimized.

Show comment
Hide comment
@pavel64-sutyrin

pavel64-sutyrin Mar 8, 2016

Yep, the same thing. Do you know how to fix that? I'm puzzled, syntax seems correct, and the same code was reported as working.

Yep, the same thing. Do you know how to fix that? I'm puzzled, syntax seems correct, and the same code was reported as working.

@tomxtobin

This comment has been minimized.

Show comment
Hide comment
@tomxtobin

tomxtobin Mar 8, 2016

You need to close a comment you left open. (Check my note on spacediver@035ea43819ffb535c1898ed88c9b4b600176559b and you should be set.) :-)

You need to close a comment you left open. (Check my note on spacediver@035ea43819ffb535c1898ed88c9b4b600176559b and you should be set.) :-)

@tomxtobin

This comment has been minimized.

Show comment
Hide comment
@tomxtobin

tomxtobin Mar 8, 2016

I've been successfully using @almereyda's changes for a few days with v2 Compose files — except that if I stop compose and bring the app back up, nginx-proxy dies:

Starting myapp_proxy_1
Starting myapp_web_1
proxy_1 | forego     | starting nginx.1 on port 5000
proxy_1 | forego     | starting dockergen.1 on port 5100
proxy_1 | nginx.1    | 2016/03/08 17:57:18 [emerg] 14#14: host not found in upstream "myapp_web_1:3000" in /etc/nginx/conf.d/default.conf:35
proxy_1 | forego     | starting nginx.1 on port 5100
proxy_1 | forego     | sending SIGTERM to nginx.1
proxy_1 | forego     | sending SIGTERM to dockergen.1
myapp_proxy_1 exited with code 0

This doesn't happen with v1 Compose files. I can work around it in v2 by removing myapp_proxy_1 before restarting with docker-compose.

I've been successfully using @almereyda's changes for a few days with v2 Compose files — except that if I stop compose and bring the app back up, nginx-proxy dies:

Starting myapp_proxy_1
Starting myapp_web_1
proxy_1 | forego     | starting nginx.1 on port 5000
proxy_1 | forego     | starting dockergen.1 on port 5100
proxy_1 | nginx.1    | 2016/03/08 17:57:18 [emerg] 14#14: host not found in upstream "myapp_web_1:3000" in /etc/nginx/conf.d/default.conf:35
proxy_1 | forego     | starting nginx.1 on port 5100
proxy_1 | forego     | sending SIGTERM to nginx.1
proxy_1 | forego     | sending SIGTERM to dockergen.1
myapp_proxy_1 exited with code 0

This doesn't happen with v1 Compose files. I can work around it in v2 by removing myapp_proxy_1 before restarting with docker-compose.

@tomxtobin

This comment has been minimized.

Show comment
Hide comment
@tomxtobin

tomxtobin Mar 8, 2016

I just found another workaround for the v2 Compose file restart problem I mentioned: setting depends_on in nginx-proxy's service definition for any other services it's proxying to.

I just found another workaround for the v2 Compose file restart problem I mentioned: setting depends_on in nginx-proxy's service definition for any other services it's proxying to.

@schmunk42

This comment has been minimized.

Show comment
Hide comment
@schmunk42

schmunk42 Mar 8, 2016

Contributor

@tomxtobin IMHO, depends_on should not be required for the proxy, since it uses Docker events via docker-gen. But I've also experiencing issues with docker events on a swarm.

Don't you have also just one proxy running for all your stacks? Or how you set depends_on for external services?

I just needed depends_on: php for the (standard)-nginx services in my stacks, otherwise they throw a similar error.

Contributor

schmunk42 commented Mar 8, 2016

@tomxtobin IMHO, depends_on should not be required for the proxy, since it uses Docker events via docker-gen. But I've also experiencing issues with docker events on a swarm.

Don't you have also just one proxy running for all your stacks? Or how you set depends_on for external services?

I just needed depends_on: php for the (standard)-nginx services in my stacks, otherwise they throw a similar error.

@sergeyklay

This comment has been minimized.

Show comment
Hide comment
@sergeyklay

sergeyklay Mar 21, 2016

@wader Thank you for the explanation

@wader Thank you for the explanation

@duck1123

This comment has been minimized.

Show comment
Hide comment
@duck1123

duck1123 Mar 21, 2016

FWIW, I got it to work using rckrdstrgrd/nginx-proxy in my config here: https://github.com/duck1123/jiksnu/blob/feature/cucumber/docker-compose.yml

FWIW, I got it to work using rckrdstrgrd/nginx-proxy in my config here: https://github.com/duck1123/jiksnu/blob/feature/cucumber/docker-compose.yml

@pascalandy

This comment has been minimized.

Show comment
Hide comment
@pascalandy

pascalandy Mar 22, 2016

Me too 😙 !!

FWIW, I got it to work using rckrdstrgrd/nginx-proxy in my config here: https://github.com/duck1123/jiksnu/blob/feature/cucumber/docker-compose.yml

Thank you @duck1123 for letting us know! @fatk do you confirm ?

Me too 😙 !!

FWIW, I got it to work using rckrdstrgrd/nginx-proxy in my config here: https://github.com/duck1123/jiksnu/blob/feature/cucumber/docker-compose.yml

Thank you @duck1123 for letting us know! @fatk do you confirm ?

@hadim

This comment has been minimized.

Show comment
Hide comment
@hadim

hadim Mar 22, 2016

Someone knows if the @duck1123 fork will be integrated in this repo at some point ?

hadim commented Mar 22, 2016

Someone knows if the @duck1123 fork will be integrated in this repo at some point ?

@pascalandy

This comment has been minimized.

Show comment
Hide comment
@pascalandy

pascalandy Mar 24, 2016

I feel that the issue has been resolve. It just needs to be merged from @duck1123.

Cheers!
Pascal

I feel that the issue has been resolve. It just needs to be merged from @duck1123.

Cheers!
Pascal

almereyda added a commit to ecobytes/docker-nginx-gen-letsencrypt that referenced this issue Mar 25, 2016

noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016

noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016

noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016

@llitfkitfk

This comment has been minimized.

Show comment
Hide comment
@llitfkitfk

llitfkitfk Apr 14, 2016

For local dev

...
    volumes:
      - ./conf.d:/etc/nginx/conf.d
      - /var/run/docker.sock:/tmp/docker.sock:ro
...

just change default.conf to

...
upstream subdomain.domain.com {
            # dockersummerweb_app_1
            server your-proxy-container-name:8080;
}
...

For local dev

...
    volumes:
      - ./conf.d:/etc/nginx/conf.d
      - /var/run/docker.sock:/tmp/docker.sock:ro
...

just change default.conf to

...
upstream subdomain.domain.com {
            # dockersummerweb_app_1
            server your-proxy-container-name:8080;
}
...
@nikashitsa

This comment has been minimized.

Show comment
Hide comment
@nikashitsa

nikashitsa Apr 21, 2016

Created PR #425 from @duck1123 code. Please, check.

Created PR #425 from @duck1123 code. Please, check.

@orlade

This comment has been minimized.

Show comment
Hide comment
@orlade

orlade May 3, 2016

If #425 is merged, is this issue resolved?

orlade commented May 3, 2016

If #425 is merged, is this issue resolved?

@mickaelperrin

This comment has been minimized.

Show comment
Hide comment
@mickaelperrin

mickaelperrin May 5, 2016

Hi,

Just ran into the same issue as the OP with the latest version of all containers, but only when using a decoupled version of docker-gen and nginx. I provide a test configuration at https://github.com/mickaelperrin/docker-nginx-proxy-icc-bug/tree/bug304.

Hope it helps.

Hi,

Just ran into the same issue as the OP with the latest version of all containers, but only when using a decoupled version of docker-gen and nginx. I provide a test configuration at https://github.com/mickaelperrin/docker-nginx-proxy-icc-bug/tree/bug304.

Hope it helps.

@tanzaho

This comment has been minimized.

Show comment
Hide comment
@tanzaho

tanzaho May 5, 2016

Hi @mickaelperrin , thanks for the example repo. I learned a new way to organize my services/networks.

tanzaho commented May 5, 2016

Hi @mickaelperrin , thanks for the example repo. I learned a new way to organize my services/networks.

@artjomzab

This comment has been minimized.

Show comment
Hide comment
@artjomzab

artjomzab May 19, 2016

👍 same problem here with docker 1.10 and latest nginx-proxy

👍 same problem here with docker 1.10 and latest nginx-proxy

@Nepoxx

This comment has been minimized.

Show comment
Hide comment
@Nepoxx

Nepoxx May 25, 2016

What's the status on this issue?

#425 was closed and #337 was merged

Nepoxx commented May 25, 2016

What's the status on this issue?

#425 was closed and #337 was merged

@suizman

This comment has been minimized.

Show comment
Hide comment
@suizman

suizman May 27, 2016

I've tested the changes from #425 and it works like a charm xD nginx-proxy

suizman commented May 27, 2016

I've tested the changes from #425 and it works like a charm xD nginx-proxy

@artjomzab

This comment has been minimized.

Show comment
Hide comment
@artjomzab

artjomzab May 27, 2016

@Nepoxx looks like this has not beed published on docker hub yet

@Nepoxx looks like this has not beed published on docker hub yet

noisy added a commit to noisy/SpisTresci that referenced this issue Jun 3, 2016

Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.

noisy added a commit to noisy/SpisTresci that referenced this issue Jun 3, 2016

Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.
@jonas-wilhelm

This comment has been minimized.

Show comment
Hide comment
@jonas-wilhelm

jonas-wilhelm Jun 10, 2016

Any news on this? Or do you plan to integrate #425 at all?

Any news on this? Or do you plan to integrate #425 at all?

@jwilder

This comment has been minimized.

Show comment
Hide comment
@jwilder

jwilder Jun 10, 2016

Owner

Fixed via #425 #337

Owner

jwilder commented Jun 10, 2016

Fixed via #425 #337

@jwilder jwilder closed this Jun 10, 2016

@Nepoxx

This comment has been minimized.

Show comment
Hide comment
@Nepoxx

Nepoxx Jun 10, 2016

The README should be updated accordingly (it refers to this issue).

Nepoxx commented Jun 10, 2016

The README should be updated accordingly (it refers to this issue).

noisy added a commit to noisy/SpisTresci that referenced this issue Jun 15, 2016

Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.
@murbanowicz

This comment has been minimized.

Show comment
Hide comment
@murbanowicz

murbanowicz Feb 16, 2017

@mickaelperrin did you solve it? I am using nginx,nginx-gen and companion and I have no host...

@mickaelperrin did you solve it? I am using nginx,nginx-gen and companion and I have no host...

SteveLTN added a commit to SteveLTN/https-portal that referenced this issue May 6, 2017

@arefaslani

This comment has been minimized.

Show comment
Hide comment
@arefaslani

arefaslani Mar 10, 2018

my compose file looks like this:

version: "3.1"

services:
  app:
    image: registry.gitlab.com/arefaslani/influencer-marketing-platform
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/usr/src/app
    ports:
      - 3000:3000
    environment:
      - VIRTUAL_HOST=api.myapp.dev

  nginx:
    image: jwilder/nginx-proxy:alpine
    ports:
      - 80:80
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    depends_on:
      - app

when I deploy the stack using docker stack deploy command, my upstream is look like this:

upstream api.influencer2.dev {
		## Can be connected with "chanka_default" network
		# my_app.1.xqykftg8k3ba74e3ovchlqhql
			server 10.0.2.5 down;
}

According to
https://github.com/jwilder/nginx-proxy/blob/master/nginx.tmpl#L5-L8
it's possible to use overlay networks for nginx-proxy image. But why my server cant get a correct IP and Port?

my compose file looks like this:

version: "3.1"

services:
  app:
    image: registry.gitlab.com/arefaslani/influencer-marketing-platform
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/usr/src/app
    ports:
      - 3000:3000
    environment:
      - VIRTUAL_HOST=api.myapp.dev

  nginx:
    image: jwilder/nginx-proxy:alpine
    ports:
      - 80:80
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    depends_on:
      - app

when I deploy the stack using docker stack deploy command, my upstream is look like this:

upstream api.influencer2.dev {
		## Can be connected with "chanka_default" network
		# my_app.1.xqykftg8k3ba74e3ovchlqhql
			server 10.0.2.5 down;
}

According to
https://github.com/jwilder/nginx-proxy/blob/master/nginx.tmpl#L5-L8
it's possible to use overlay networks for nginx-proxy image. But why my server cant get a correct IP and Port?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment