host not found in upstream php in
I have recently started migrating to Docker 1.9 and Docker-Compose 1.5’s networking features to replace using links.
However, if I run the docker-compose command again while the php and mongo containers are running (nginx exited), nginx starts and works fine from then on.
This is my docker-compose.yml file:
This is my default.conf for nginx:
How can I get nginx to work with only a single docker-compose call?
18 Answers 18
This can be solved with the mentioned depends_on directive since it’s implemented now (2016):
Successfully tested with:
Find more details in the documentation.
There is also a very interesting article dedicated to this topic: Controlling startup order in Compose
There is a possibility to use «volumes_from» as a workaround until depends_on feature (discussed below) is introduced. All you have to do is change your docker-compose file as below:
One big caveat in the above approach is that the volumes of php are exposed to nginx, which is not desired. But at the moment this is one docker specific workaround that could be used.
depends_on feature This probably would be a futuristic answer. Because the functionality is not yet implemented in Docker (as of 1.9)
There is a proposal to introduce «depends_on» in the new networking feature introduced by Docker. But there is a long running debate about the same @ https://github.com/docker/compose/issues/374 Hence, once it is implemented, the feature depends_on could be used to order the container start-up, but at the moment, you would have to resort to one of the following:
You can set the max_fails and fail_timeout directives of nginx to indicate that the nginx should retry the x number of connection requests to the container before failing on the upstream server unavailability.
You can tune these two numbers as per your infrastructure and speed at which the whole setup is coming up. You can read more details about the health checks section of the below URL: http://nginx.org/en/docs/http/load_balancing.html
sets the number of unsuccessful attempts to communicate with the server that should happen in the duration set by the fail_timeout parameter to consider the server unavailable for a duration also set by the fail_timeout parameter. By default, the number of unsuccessful attempts is set to 1. The zero value disables the accounting of attempts. What is considered an unsuccessful attempt is defined by the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, and memcached_next_upstream directives.
sets the time during which the specified number of unsuccessful attempts to communicate with the server should happen to consider the server unavailable; and the period of time the server will be considered unavailable. By default, the parameter is set to 10 seconds.
To be precise your modified nginx config file should be as follows (this script is assuming that all the containers are up by 25 seconds at least, if not, please change the fail_timeout or max_fails in below upstream section): Note: I didn’t test the script myself, so you could give it a try!
Also, as per the following Note from docker (https://github.com/docker/docker.github.io/blob/master/compose/networking.md#update-containers), it is evident that the retry logic for checking the health of the other containers is not docker’s responsibility and rather the containers should do the health check themselves.
If you make a configuration change to a service and run docker-compose up to update it, the old container will be removed and the new one will join the network under a different IP address but the same name. Running containers will be able to look up that name and connect to the new address, but the old address will stop working.
If any containers have connections open to the old container, they will be closed. It is a container’s responsibility to detect this condition, look up the name again and reconnect.
Setup nginx not to crash if host in upstream is not found
We have several rails apps under common domain in Docker, and we use nginx to direct requests to specific apps.
Config looks like this:
If one of these apps is not started then nginx fails and stops:
We don’t need them all to be up but nginx fails otherwise. How to make nginx ignore failed upstreams?
7 Answers 7
If you can use a static IP then just use that, it’ll startup and just return 503 ‘s if it doesn’t respond.
Use the resolver directive to point to something that can resolve the host, regardless if it’s currently up or not.
Resolve it at the location level, if you can’t do the above (this will allow Nginx to start/run):
For me, option 3 of the answer from @Justin/@duskwuff solved the problem, but I had to change the resolver IP to 127.0.0.11 (Docker’s DNS server):
But as @Justin/@duskwuff mentioned, you could use any other external DNS server.
The main advantage of using upstream is to define a group of servers than can listen on different ports and configure load-balancing and failover between them.
In your case you are only defining 1 primary server per upstream so it must to be up.
Instead, use variables for your proxy_pass (es) and remember to handle the possible errors (404s, 503s) that you might get when a target server is down.
Почему nginx не видит php-fpm:9000?
nginx: [emerg] host not found in upstream «php-fpm5.6» in /etc/nginx/conf.d/default.conf:25
WARNING: Nothing matches the include pattern ‘/etc/php/5.6/fpm/pool.d/*.conf’ from /etc/php/5.6/fpm/php-fpm.conf at line 31.
error_log = /proc/self/fd/2
daemonize = no
user = www-data
group = www-data
listen = [::]:9000
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 3
pm.max_requests = 200
catch_workers_output = yes
clear_env = yes
php_admin_value[sendmail_path] = /usr/local/bin/phpmailer
php_admin_value[open_basedir]= «/data:/srv:/var/tmp:/tmp»
php_admin_value[upload_tmp_dir] = «/var/tmp»
server <
listen 80;
server_name localhost;
root /var/www/html;
fastcgi_pass php-fpm5.6:9000;
fastcgi_index index.php;
>
>
# PHP
ENV PHP_MODS_DIR=/etc/php/5.6/mods-available
ENV PHP_CLI_DIR=/etc/php/5.6/cli
ENV PHP_CLI_CONF_DIR=$
ENV PHP_CGI_DIR=/etc/php/5.6/cgi
ENV PHP_CGI_CONF_DIR=$
ENV PHP_FPM_DIR=/etc/php/5.6/fpm
ENV PHP_FPM_CONF_DIR=$
ENV PHP_FPM_POOL_DIR=$
ENV TZ=Europe/Kiev
# WORKDIR
WORKDIR /var/www/html
# Expose port 9000 and start php-fpm server
EXPOSE 9000
# COMMAND
CMD [«php-fpm5.6»]
I’m trying to configure a deployed app on an EC2 instance I’m not able to get visit the application when it’s up on ec2 public IP. I’ve checked the security groups and allowed all inbound traffic to ports just to see If I can reach the homepage or admin page of django.
Say my ec2 IP address is 34.245.202.112 how do I map my application so nginx serves
The frontend(nuxt) at 34.245.202.112
The backend(django) at 34.245.202.112/admin
The API(DRF) at 34.245.202.112/api
When I try to do this the error I get from nginx is
nginx | 2020-11-14T14:15:35.511973183Z 2020/11/14 14:15:35 [emerg] 1#1: host not found in upstream «nuxt:3000» in /etc/nginx/conf.d/autobets_nginx.conf:9
docker-compose
nginx.conf
3 Answers 3
Look at this minimal example:
As you see from the example, each location has a URI prefix. NGINX will test all these ‘prefixes’ against location in incoming HTTP requests, finding the best match. Once the best match found NGINX will do whatever you wrote inside the block. In the example above all requests starting with /api/ or /django/ go to the django backend. Requests starting with /static/ are served from local files. Everything else goes to nuxt backend.
‘127.0.0.11’ is the Docker DNS. It resolves service and container names as well as ‘normal’ DNS records (for that is usesn host’s DNS configuration). You don’t have to assign an alias to a service or set a container_name because service name is a DNS record on its own. It resolves to all containers of that service. Using resolver wasn’t necessary in the basic configuration I’ve posted because I didn’t use upstream blocks.
Nginx will not start with host not found in upstream
I use nginx to proxy and hold persistent connections to far away servers for me.
I have configured about 15 blocks similar to this example:
I can temporarily afford to lose one server but not all 15.
Edit: Turns out nginx is not suitable for this use case. An alternative backend (upstream) keepalive proxy should be used. A custom Node.js alternative is in my answer. So far I haven’t found any other alternatives that actually work.
6 Answers 6
Earlier versions of nginx (before 1.1.4), which already powered a huge number of the most visited websites worldwide (and some still do even nowdays, if the server headers are to be believed), didn’t even support keepalive on the upstream side, because there is very little benefit for doing so in the datacentre setting, unless you have a non-trivial latency between your various hosts; see https://serverfault.com/a/883019/110020 for some explanation.
Basically, unless you know you specifically need keepalive between your upstream and front-end, chances are it’s only making your architecture less resilient and worse-off.
(Note that your current solution is also wrong because a change in the IP address will likewise go undetected, because you’re doing hostname resolution at config reload only; so, even if nginx does start, it’ll basically stop working once IP addresses of the upstream servers do change.)
Potential solutions, pick one:
The best solution would seem to just get rid of upstream keepalive as likely unnecessary in a datacentre environment, and use variables with proxy_pass for up-to-date DNS resolution for each request (nginx is still smart-enough to still do the caching of such resolutions)
Another option would be to get a paid version of nginx through a commercial subscription, which has a resolve parameter for the server directive within the upstream context.