CODEWITHSUNDEEP
dockerdocker-compose
walt_die
walt_die

Reputation: 630

docker vs docker-compose nginx: [emerg] host not found in upstream "httpstat.us" in /etc/nginx/nginx.conf:21

I have a very peculiar issue with this set of docker files:

docker run will do what I want whereas docker-compose will not

I'm quite noob'ed with Docker hence this probably rather simple question - and I apologise in advance!

docker run -p 80:8080 -i -t lakrids_devlakrids 172.17.0.1 - - [01/Feb/2017:23:29:36 +0000] "GET / HTTP/1.1" 200 6979 "-" "curl/7.29.0"

but if I start the same container with docker-compose I get

docker-compose up devlakrids Recreating devlakrids Attaching to devlakrids devlakrids | 2017/02/01 23:28:19 [emerg] 11#11: host not found in upstream "httpstat.us" in /etc/nginx/nginx.conf:21 devlakrids | nginx: [emerg] host not found in upstream "httpstat.us" in /etc/nginx/nginx.conf:21 devlakrids exited with code 1

Upvotes: 3

Views: 4241

Answers (3)

walt_die
walt_die

Reputation: 630

This is what made my day (am forever grateful to Mr C. Eastwood) :)

The nginx container doubles as a reverse proxy in my design - and handles the 443 security end of things - allowing 'ordinary' application servers to deal with the business logic:

# ./docker-compose.yml
version: '2'
services:
  proxy:
    build: ./shared/proxy
    networks:
    - sand
    links:
    - devlakrids:devlakrids
    ports:
    - 80:80
    - 443:443

  # sand[kassen]
  #
  devlakrids:
    build: ./sand/current/spark
    expose:
    - "4567"
    tmpfs: /tmp
    volumes:
    - ./sand/current/:/mnt/lakrids
    - ./shared/sand/:/shared
    links:
    - sandmysql
    networks:
    - sand
    - sanddb

# ./shared/proxy/services.conf

server {
        listen 80;
        listen 443 ssl http2;
        server_name dev.lakrids.xxxx.xxx;

        # Path for SSL config/key/certificate
        ssl on;
        ssl_certificate /etc/ssl/certs/nginx/xxx.crt;
        ssl_certificate_key /etc/ssl/certs/nginx/xxxx.pem;
        include /etc/nginx/includes/ssl.conf;
        add_header Strict-Transport-Security "max-age=31536000";

        location / {
                include /etc/nginx/includes/proxy.conf;
                proxy_pass http://devlakrids:4567;
        }

        access_log off;
        error_log  /var/log/nginx/error.log error;
}

# ./shared/proxy/includes/proxy.conf
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_request_buffering off;
proxy_http_version 1.1;
proxy_intercept_errors on;

With this – all that was left to do was docker-compose up by and large ;)

Upvotes: 1

BMitch
BMitch

Reputation: 265075

From the description, the image you are running outside of compose is likely to be different from the image you run inside compose, or you have different volume mounts. To resolve your error, I'd update your nginx.conf with an upstream definition:

daemon off;
worker_processes 1;
events { worker_connections 1024; }
http {
   upstream httpstat.us {
       least_conn;
       server httpstat.us:80 fail_timeout=60s max_fails=2;
   }

   sendfile on;
   server {
      listen 8080;
      server_name dev.lakrids.premier-is.dk;

      location / {
         proxy_pass http://httpstat.us/;
         proxy_set_header  X-Real-IP  $remote_addr;
      }
   }
}

Upvotes: 1

Oleg Sklyar
Oleg Sklyar

Reputation: 10092

Two possible culprits:

  • nginx is a funny beast: if the upstream goes down while nginx is already running, then nginx keeps running. However, if upstream is not reachable on nginx start, the latter will fail to start. To solve this you might need to add a startup script to you nginx container testing for upstreams to be up before starting nginx;

  • try to add links explicitly: somehow we had this issue that the nginx docker did not see other machines implicitly defined via compose service names.

Finally, one really forgotten option is: you do not specify anywhere in the files that you show where the httpstat.us service is started within the docker engine, so it is actually surprising that it works for you without compose.

Upvotes: 2

Related Questions