Use docker-compose configuration version 3 to fix hello-world

[createdbysk]

On a boot2docker instance through docker-machine from Docker Toolbox, the instructions on autopilotpattern/hello-world resulted in a page that displayed the following

404 Not Found
nginx/1.10.1

404 Not Found
nginx/1.10.1

Solution:
Change the docker-compose.yml to version 3 of the file format.

With this change, the output is

Hello World

which is the expected output.

Why does this work?:
This explanation is based on empirical evidence rather than any deep knowledge of the inner workings of docker-compose.

version "3" of the docker-compose configuration seems to handle networks differently. As a consequence this seems to fix the dns issue.

[tgross]

@satvidh I can't replicate what you're seeing. Can you give me the results of docker version and docker-compose as I have below? It might be helpful to dig into the Nginx logs as well.

$ docker version
Client:
 Version:      17.06.0-ce-rc5
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   b7e4173
 Built:        Tue Jun 20 07:14:13 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce-rc5
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   b7e4173
 Built:        Tue Jun 20 07:18:21 2017
 OS/Arch:      linux/amd64
 Experimental: true

$ docker-compose version
docker-compose version 1.14.0, build c7bdf9e
docker-py version: 2.3.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016

[dbriones]

I can replicate @satvidh's symptoms, with some interesting twists:

• I was able to view the page correctly the first time I ran docker-compose up. When I subsequently ran docker-compose down and docker-compose up again, the symptom manifested.
• The second time I started the system, I took a look at the Consul UI and noticed that neither hello, world, nor nginx were registered.
• The third time I tried starting the system (after applying @satvidh's changes), those apps were registered with Consul, but I still saw the 404's in the page being served by nginx.
• I'm using an older version of the Docker toolchain:

  $ docker version
  Client:
   Version:      17.05.0-ce
   API version:  1.29
   Go version:   go1.7.5
   Git commit:   89658be
   Built:        Thu May  4 21:43:09 2017
   OS/Arch:      darwin/amd64
  
  Server:
   Version:      17.05.0-ce
   API version:  1.29 (minimum version 1.12)
   Go version:   go1.7.5
   Git commit:   89658be
   Built:        Thu May  4 21:43:09 2017
   OS/Arch:      linux/amd64
   Experimental: true
  
  $ docker-compose version
  docker-compose version 1.13.0, build 1719ceb
  docker-py version: 2.2.1
  CPython version: 2.7.12
  OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
  

• I tried upgrading Docker, but that hasn't made a difference:

  $ docker version
  Client:
   Version:      17.06.1-ce-rc1
   API version:  1.30
   Go version:   go1.8.3
   Git commit:   77b4dce
   Built:        Fri Jul 14 07:38:15 2017
   OS/Arch:      darwin/amd64
  
  Server:
   Version:      17.06.1-ce-rc1
   API version:  1.30 (minimum version 1.12)
   Go version:   go1.8.3
   Git commit:   77b4dce
   Built:        Fri Jul 14 07:33:35 2017
   OS/Arch:      linux/amd64
   Experimental: true
  
  $ docker-compose version
  docker-compose version 1.14.0, build c7bdf9e
  docker-py version: 2.3.0
  CPython version: 2.7.12
  OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
  

In summary:

• Before applying the changes in this PR, I saw that none of the applications were registered in Consul
• After applying the changes in this PR, the applications were registered, but I still see the 404 messages originally reported.

[dbriones]

I just took a peek at the nginx error log and config file. The error log seems to suggest that the requests for the backend apps are being handled as requests for static content:

# cat error.log
2017/07/19 21:02:46 [error] 51#0: *12 open() "/usr/share/nginx/html/world" failed (2: No such file or directory), client: 172.19.0.1, server: _, request: "GET /world HTTP/1.1", host: "localhost", referrer: "http://localhost/"
2017/07/19 21:02:46 [error] 51#0: *13 open() "/usr/share/nginx/html/hello" failed (2: No such file or directory), client: 172.19.0.1, server: _, request: "GET /hello HTTP/1.1", host: "localhost", referrer: "http://localhost/"

...which makes sense, given that the config file is missing the conditional stanzas found in the template:

# cat /etc/nginx/nginx.conf
daemon off;
user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       80;
        server_name  _;

        root /usr/share/nginx/html;

        location /health {
            # requires http_stub_status_module
            stub_status;
            allow 127.0.0.1;
            deny all;
        }
    }
}

[dbriones]

The plot thickens:

I tried running the preStart hook for nginx and got a timeout:

#  consul-template \
>         -once \
>         -consul consul:8500 \
>         -template "/etc/containerpilot/nginx.conf.ctmpl:/etc/nginx/nginx.conf"
2017/07/19 21:51:04 [ERR] (view) "service(world)" health services: error fetching: Get http://consul:8500/v1/health/service/world?passing=1&stale=&wait=60000ms: dial tcp 10.65.208.140:8500: i/o timeout
2017/07/19 21:51:04 [ERR] (runner) watcher reported error: health services: error fetching: Get http://consul:8500/v1/health/service/world?passing=1&stale=&wait=60000ms: dial tcp 10.65.208.140:8500: i/o timeout

...but when I tried using curl to hit the same URL, it returned instantly:

# curl 'http://consul:8500/v1/health/service/world?passing=1&stale=&wait=60000ms'
[
    {
        "Node": {
            "ID": "62ef4704-734f-f038-6a57-c26ecce80717",
            "Node": "5ec9c6e2fad9",
	    ...
	    }
    }
]

I then tried resolving consul from the nginx container:

# nslookup consul
nslookup: can't resolve '(null)': Name does not resolve

Name:      consul
Address 1: 172.19.0.2 helloworld_consul_1.helloworld_default

...and noticed that the IP address that consul-template is using doesn't match the one returned by nslookup.

This project currently uses consul-template 0.15.0; the latest is 0.19.0. I think I'll try upgrading that next.