skip to Main Content

I am attempting to set up an environment on AWS ECS with a React frontend served by Nginx, and two backend services (Django apps) that should communicate via Nginx as a reverse proxy. I’ve configured ECS Service Discovery for service-to-service communication but encounter errors when the Nginx container starts, indicating that the upstream hosts cannot be found.

error message from Task logs

What I’ve Tried:

  1. Configuring nginx.conf and default.conf to resolve the services using ECS Service Discovery names.
  2. Setting the resolver in nginx.conf to Docker’s default DNS resolver 127.0.0.11.
  3. Updating ECS Service Discovery settings for Nginx and the Django apps to ensure proper service registration.
  4. Rebuilding and redeploying Docker images after configuration changes.
  5. Examining ECS logs to find errors like [emerg] host not found in upstream.

In ECS, I’ve created the namespace and service discovery for the nginx and for my django app. Images are below;
Django-app

Nginx-React

This is the default.conf

upstream healthmanagement {
    server healthmanagement-service.glucocare-services:8000;
}

upstream chat {
    server chat-service.glucocare-services:8000;
}

server {

listen 80;

location /api/ {
    proxy_pass http://healthmanagement;
}

location /chat/ {
    proxy_pass http://chat;
}

# Serve Django static files
location /static/django {
    alias /app/healthcare_project/static/;  
}

# Static Django media files
location /media/ {
    alias /app/healthcare_project/media/;  
}

# Serve React static files
location /static/ {
    alias /usr/share/nginx/html/build/static/;  
}

# Main location block to serve the React app
location / {
    root /usr/share/nginx/html/build;  
    try_files $uri $uri/ /index.html;
}

}

nginx.conf

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;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    resolver 172.31.0.2 valid=30s;  

    include /etc/nginx/conf.d/*.conf;  # Include all conf files from conf.d directory
}

2

Answers


  1. You do not need nginx as a reverse proxy in this case. nginx is providing static files only.

    When using service discovery, the backend services can be configured with healthmanagement-service.glucocare-services:8000 and chat-service.glucocare-services:8000 directly.

    If you need a reverse proxy, have a look at how to distribute Amazon ECS service traffic using load balancing . When using a load balancer, service discovery gets optional also, as the load balancer comes with a unique DNS name and can be used instead of healthmanagement-service.glucocare-services:8000 and chat-service.glucocare-services:8000 .

    You might look into Use an Amazon CloudFront distribution to serve a static website
    to even remove the necessity for nginx and lower the costs of the static hosting.

    Login or Signup to reply.
  2. I had the same problem, and today eventually I resolved it!!!

    I hope that you adjusted properly your service discovery (e.g. all your services are in one namespace and services had registered in service discovery)

    I seems that you used inappropriate DNS (FQDN) name like: healthmanagement-service.glucocare-services

    I had the same case)))

    Navigate to the "Route 53 >> Hosted zones >> {Your-namespace}"

    and find record Type A like this ‘7e1329833ab5483fa924040c7414f581.healthmanagement-service.glucocare-services’

    In the end, your default.conf use such approach:

    upstream healthmanagement {
    server 7e1329833ab5483fa924040c7414f581.healthmanagement-service.glucocare-services:8000;
    

    }

    upstream chat {
    server some_id_of_this_record.chat-service.glucocare-services:8000;
    

    }

    It seems, that DNS record of SRV type don’t work.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search