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

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

Projects

None yet
@schmunk42
Contributor

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
Contributor

Related issue: #97

@thaJeztah
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

@schmunk42
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?

@schmunk42
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.

@md5
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
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.

@schmunk42
Contributor

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

@modius
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
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.

@fbender
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
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

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
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
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

@Ant59
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
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
Ant59 commented Feb 17, 2016

Perfect. Older Compose config works. Thanks.

@meyer
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
wader commented Feb 22, 2016

@meyer no probleeeem 😄

@meetmatt

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

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
kop commented Mar 2, 2016

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

@kuhnroyal

Yes, the previous comment.

@spacediver spacediver added a commit to spacediver/nginx-proxy that referenced this issue Mar 3, 2016
@spacediver spacediver quickfix for jwilder#304 035ea43
@orifito
orifito commented Mar 4, 2016

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

@spacediver

Hi folks,

I've started fixing this (see spacediver@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
FCO commented Mar 8, 2016

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

@spacediver

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

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

@tomxtobin

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

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
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.

@tomxtobin

@schmunk42 I run nginx-proxy locally for development, too; I've caught a few issues that way (e.g., finding out that a different proxy didn't support Server-Sent Events). I've been holding off using v2 Compose files in production exactly because of what you describe: I can't be having the proxy depending on services that I'm spinning up and down. (Kinda defeats the whole modular idea.) :-)

@pascalandy

Hey guys!

I'm getting confuse with the volumes under the dockergen: YAML.
How should my docker-compose looks like? Here are the two containers.

nginx:
  image: nginx:latest #the standard Nginx image
  volumes:
    - /tmp/nginx:/etc/nginx/conf.d
    - /srv/nginx/certs:/etc/nginx/certs
  ports:
    - "80:80"
    #- "443:443" No SSL at the moment
dockergen:
  image: jwilder/docker-gen # This guy rocks
  environment:
    - DEFAULT_HOST=google.com
  volumes:
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - /srv/nginx-proxy:/etc/docker-gen/templates
    - /etc/docker-gen/templates/nginx.tmpl:/etc/nginx/conf.d/default.conf
  volumes_from:
    - nginx

Thanks in advance!

@fatk
fatk commented Mar 11, 2016

Hey,

Not sure this is the right place for this, but i think if you're gonna do it through compose, you should re-declare the entrypoint. If you look at the Dockerfile, you can see it's meant to receive arguments.

Since you're trying to run nginx-proxy using separate containers, you have to give the nginx container a name and feed it to docker-gen so that it knows which container to send signals.

This part of your compose file cannot work:

- /etc/docker-gen/templates/nginx.tmpl:/etc/nginx/conf.d/default.conf

It is docker-gen, that is going to use nginx.tmpl and generate default.conf for nginx to use. What you're doing here is simply mounting nginx.tmpl as default.conf as is and nginx will never understand it.

I would also advise to use compose v2, even though this thread is about the problems it may cause, it has already provided a solution that works. This way you won't get any bad surprises when v1 becomes legacy.

Here's what a a docker-compose.yml could look like:

version: "2"

services:
  nginx:
    image: nginx
    container_name: nginx_proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./volumes/conf.d:/etc/nginx/conf.d"
      - "./volumes/vhost.d:/etc/nginx/vhost.d"
      - "./volumes/certs:/etc/nginx/certs:ro"
      - "/usr/share/nginx/html"
    networks:
      - proxy-tier
  docker-gen:
    image: jwilder/docker-gen
    container_name: docker_gen
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "./data/templates:/etc/docker-gen/templates:ro"
    volumes_from:
      - nginx
    entrypoint: /usr/local/bin/docker-gen -notify-sighup nginx_proxy -watch -only-exposed -wait 5s:30s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf

networks:
  proxy-tier:
    external:
      name: nginx-proxy

This of course will not work as is. If you want a complete working example, have a look here

Like i said this is compose v2, with the revamped network support. So you'll want to create a host-wide (or swarm-wide through overlay) network first for your nginx-proxy container that will be configured by docker-gen to connect with your other nginx that will serve your sites (Unless you want to expose a new unique port for every site)

$ docker network create -d bridge nginx-proxy

I'd recommend using @almereyda 's upstream block (earlier in this thread), and have your sites' compose files look something like this:

version: "2"

services:
  nginx:
    image: nginx
    container_name: mysite-nginx
    volumes:
      - "./volumes/conf.d:/etc/nginx/conf.d:ro"
      - "./volumes/www:/opt/www/:ro"
    environment:
      - VIRTUAL_HOST=sub.domain.tld
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=nginx-proxy
    networks:
      - proxy-tier

networks:
  proxy-tier:
    external:
      name: nginx-proxy

Hope this helps.

@tomxtobin

I found a much better solution for the v2 Compose file breakage on container restart: in my derivative image with the v2 template tweaks, I also save a copy of the original /etc/nginx/conf.d/default.conf to /app and re-copy it back on container startup in the entrypoint.

Before this change, nginx would read the stale config file and bail when it couldn't find an old container's upstream host (which might not have come back up yet, or might not be coming back at all).

After the change, nginx is happy to read the original config file and gets signaled by docker-gen when other containers have come up and the new config is ready.

Here's my Dockerfile:

FROM jwilder/nginx-proxy:latest

# Back up the original nginx conf so we can restore it on startup
RUN cp /etc/nginx/conf.d/default.conf /app/default.conf

# Add a new entrypoint that restores the default nginx conf on startup; this
# fixes breakage on container restart from the below tweaked template, since
# nginx can't find the old hosts
RUN mv /app/docker-entrypoint.sh /app/original-docker-entrypoint.sh
ADD docker-entrypoint.sh /app/docker-entrypoint.sh
RUN chmod a+x /app/docker-entrypoint.sh

# Add tweaked template to support v2 Compose files
ADD nginx.tmpl /app/nginx.tmpl

And my docker-entrypoint.sh:

#!/bin/bash
cp /app/default.conf /etc/nginx/conf.d/default.conf
exec ./original-docker-entrypoint.sh "$@"

The nginx.tmpl includes the changes @almereyda provided above.

@antoinemichea

:( work for me.
I use in my docker-compose v2 file :
ports:
- 127.0.0.2:9991:8081

@pascalandy

Hey Karl cc @fatk ,

Thank you so much for your detailed answer. It was dense! You made me discovered many things and I read your explanations more than 10x times.

The first part "1) a docker-compose for: FrontEnd (proxy/servers/firewalls)" is working thanks to your compose setup.

Now, I have some issues integrating the network into my "2) a docker-compose for: production apps". I still need to test my stuff.

WARNING: Some networks were defined but are not used by any service: proxy-tier
ERROR: Service "ghost" uses an undefined network "Front_N"

It's Friday night and my girlfriend is calling 👯 I'll continue my home work and come back !

Cheers!

@pascalandy pascalandy referenced this issue in JrCs/docker-letsencrypt-nginx-proxy-companion Mar 12, 2016
Closed

Launching those 3 containers into a docker-compose #33

@fatk
fatk commented Mar 13, 2016

Can you post your docker-compose.yml as a gist?

@pascalandy

@fakt,

As I mentioned before, my docker-compose (v2) for: "FrontEnd", works perfectly. https://gist.github.com/pascalandy/b13fcbc69fed69a883db

Reminder. It's all running smoothly and the Ghost instances are dicovered by Docker-gen when I docker run:

docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx` and then

followed with:

docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx

But ...

Because we introduced the network component in the mix, I still have a challenge to have my Ghost instances to be discovered by the "docker-gen" component using compose v2. I tried for a while to understand the subtleties but I'm stocked.

When I run my docker-compose (v2) for: "production instances"

version: "2"

services:
  ghost:
    build: ./ghost
    container_name: blog-instance-1
    ports:
      - "80:2368"
    networks:
      - proxy-tier
    environment:
      - "URL=http://dockercluster.tk"
      - "VIRTUAL_HOST=dockercluster.tk"
      - "VIRTUAL_NETWORK=nginx-proxy"
      - "VIRTUAL_PORT=80"
      - "NODE_ENV=production"
    restart: always
networks:
  proxy-tier:
    external:
      name: nginx-proxy

The system returns this error:

ERROR: failed to create endpoint ghost_blog-instance-1 on network nginx-proxy: Bind for 0.0.0.0:80 failed: port is already allocated

Damm!

$ docker ps
The system returns https://gist.github.com/pascalandy/6ad0264d446b00c18c36

Now I am really confused :-/ My Ghost container can't listen on port 80 and send the traffic into 2368 !?

Here is how I see our setup (picture):
cddl3gluuaavnj-

Because we use the indicator the ENV "VIRTUAL_HOST=yoursite1.com" and "VIRTUAL_HOST=yoursite2.com" in our "production instances" instance, they configure the reverse-proxy Nginx service for us.

Also their ports should always be to listing on port 80 right? It's working in the "none compose" setup mentioned in my reminder above.

Hope you can enlighten me. I sure we are close to close the topic here :)

Cheers!
Pascal

P.S. I'm super pumped as I just build my Raspberry Pi3 setup and I can't wait to have this discovery service running on swarm! Some pics :) https://twitter.com/_pascalandy/status/708752861426008065

@pascalandy

Maybe this can help us ... #387 (comment)

@jeremejevs

@wader @Ant59 @meyer Just in case, it isn't necessary to downgrade to version 1 compose file, just add network_mode: bridge to each service instead (which is the old default).

@fatk
fatk commented Mar 15, 2016

@pascalandy

Glad it could be useful!

As for your compose file, it's actually much more simple now with the new docker networks.
You can remove the

    ports:
      - "80:2368"

portion of your files altogether. You nginx-proxy container and sites will be on the same network, no need to expose ports, just listen on your ghost instances and define the VIRTUAL_PORT and you'll be good to go.

As for the first part of your message, i didn't get what you use docker run for and why it's the same command twice.

Have a look at this gist for an extensive example for Nginx + PHP + MySQL. To add SSL, you'd just need to add

LETSENCRYPT_HOST=xxxxx.com
LETSENCRYPT_EMAIL=xxx@xxxx.com
@pascalandy

I was only comparing two methods. If I use the "docker run method" it's working well but not with the docker compose v2 (yet.)

As for the first part of your message, i didn't get what you use docker run for and why it's the same command twice.

Let me test the setup without assigning the ports.

@fatk
fatk commented Mar 18, 2016

@pascalandy check out this repository, it may help you solve some issues.

@sergeyklay

Hey guys could you please explain what I'm doing wrong?

$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy
5d993d8089c8550d86cc147def81e20f5aa15f524b00545383b5db56e504404b

My docker-compose.yml file:

version: '2'

services:
  application:
    build: containers/core # nothig interested here
    container_name: app_container
    volumes:
      - ./application:/var/www/site.local
    tty: true

  nginx:
    restart: always
    image: nginx
    container_name: app_nginx
    expose:
      - "80"
      - "443"
    depends_on:
      - application
    volumes:
      - ./conf/nginx/vhost:/etc/nginx/sites-enabled # virtual host here
    volumes_from:
      - application
    environment:
      VIRTUAL_HOST: site.local
$ docker-compose -p project_name up -d
Starting app_container
Starting app_nginx
$ docker-compose -p project_name ps
    Name              Command          State        Ports      
--------------------------------------------------------------
app_container   sh                     Up                      
app_nginx       nginx -g daemon off;   Up      443/tcp, 80/tcp
$ cat /etc/hosts | grep site.local
127.0.0.1       site.local
$ netstat -tulpn | grep :80
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp6       0      0 :::80                   :::*                    LISTEN      - 
$ curl -I site.local
HTTP/1.1 503 Service Temporarily Unavailable
Server: nginx/1.9.9
Date: Mon, 21 Mar 2016 19:39:06 GMT
Content-Type: text/html
Content-Length: 212
Connection: keep-alive

Forgive me if I ask stupid question, but after accepting jwilder/docker-gen#144 still not possible to use docker-compose v2? From the documentation (first of all from README.md) for me it is not clear, should I run another container with Nginx?
Please explain what I need to fix :)


Docker version 1.10.3, build 20f81dd
docker-compose version 1.6.2, build 4d72027

@wader
wader commented Mar 21, 2016

@sergeyklay It does not work with docker-compose v2 yet. Support for the default network mode used by v2 is this PR. But if you really need to use v2 there seems to be some workarounds like @jeremejevs network_mode: bridge mentioned above or some fork like @spacediver spacediver/nginx-proxy but i haven't tried any of them myself.

@sergeyklay

@wader Thank you for the explanation

@duck1123

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

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 ?

@pascalandy pascalandy referenced this issue in fatk/docker-letsencrypt-nginx-proxy-companion-examples Mar 22, 2016
Closed

Got a version of nginx-compose-v2.tmpl working #1

@hadim
hadim commented Mar 22, 2016

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

@pascalandy

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

Cheers!
Pascal

@almereyda almereyda added a commit to ecobytes/docker-nginx-gen-letsencrypt that referenced this issue Mar 25, 2016
@almereyda almereyda update fetch template to be compatible with docker networking used by…
… compose v2 files

* jwilder/nginx-proxy#304 (comment)
afe943b
@noisy noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016
@noisy noisy Because of jwilder/nginx-proxy#304, right now docker-compose.prod.yml…
… is ported back to version 1
9585b24
@noisy noisy referenced this issue in SpisTresci/SpisTresci Apr 12, 2016
Closed

Migrate docker-compose.prod.yml to compose2 #12

@noisy noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016
@noisy noisy Because of jwilder/nginx-proxy#304, right now docker-compose.prod.yml…
… is ported back to version 1
50c1dbe
@noisy noisy added a commit to SpisTresci/SpisTresci that referenced this issue Apr 12, 2016
@noisy noisy Because of jwilder/nginx-proxy#304, right now docker-compose.prod.yml…
… is ported back to version 1
0b2cfa5
@llitfkitfk

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

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

@orlade
orlade commented May 3, 2016

If #425 is merged, is this issue resolved?

@mickaelperrin

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
tanzaho commented May 5, 2016

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

@ArtworkAD

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

@Nepoxx
Nepoxx commented May 25, 2016

What's the status on this issue?

#425 was closed and #337 was merged

@suizman
suizman commented May 27, 2016

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

@ArtworkAD

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

@noisy noisy added a commit to noisy/SpisTresci that referenced this issue Jun 3, 2016
@noisy noisy Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.
4bd861a
@noisy noisy added a commit to noisy/SpisTresci that referenced this issue Jun 3, 2016
@noisy noisy Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.
85ac26c
@jonas-wilhelm

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

@jwilder
Owner
jwilder commented Jun 10, 2016 edited

Fixed via #425 #337

@jwilder jwilder closed this Jun 10, 2016
@Nepoxx
Nepoxx commented Jun 10, 2016

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

@noisy noisy added a commit to noisy/SpisTresci that referenced this issue Jun 15, 2016
@noisy noisy Revert "Because of jwilder/nginx-proxy#304, right now docker-compose.…
…prod.yml is ported back to version 1"

This reverts commit 0b2cfa5.
8abd35c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment