Use reverse proxy in Azure Container Apps Environment

Question

Use reverse proxy in Azure Container Apps Environment

Fabian Kaimer 5

I'm currently trying to set up a multi-container application in Azure Container Apps with the GUI being a containerized single-page application and the API being a containerized Node back-end. I would like to have one central public endpoint to bundle all inbound and outbound traffic (for logging purposes, to use a custom domain name, etc). I have therefore created a containerized nginx server and configured it as a reverse proxy to proxy_pass all incoming requests to the FQDN of the GUI (for requests coming in on "/" URI). I also added a static index file (under "/public") just for testing purposes.

My nginx.conf:

nginx3

The nginx is deployed to its own container and also serves the static index file as intended. However, it does not redirect any request to the GUI. I either get HTTP "502 - Bad Gateway" or "HTTP 426 - Upgrade Required" (when using http instead of https). I have tried all possible combinations (http/https/no protocol, ports 80/443/no port, ingress set to internal, ingress set to external) but nothing has worked.

My Ingress configuration for the GUI:

ingress1

Every help would be very appreciated since I've been struggling with this issue for a few days now and have no more ideas where it might be coming from.

Fabian Kaimer 5 Reputation points

2023-03-02T08:54:33.81+00:00

I have also built the whole architecture locally with Docker and it works perfectly fine there. All requests are properly proxied there. The only (and major) difference there is that I'm not using a FQDN but instead proxy the requests to localhost. So my assumption is that there are any issues with resolving the FQDN in my container?
Fabian Kaimer 5 Reputation points

2023-03-02T09:11:57.3566667+00:00

I have built the whole architecture in Docker as well for testing purposes and it works perfectly fine there. My requests are properly forwarded by the reverse proxy to the GUI container. The only (and major difference) between my containers in Azure and my Docker containers is that Docker proxies the requests to localhost and the container apps try to identify them by resolving the FQDN. My assumption is that the container has some sort or problem resolving the FQDN?
MughundhanRaveendran-MSFT 12,511 Reputation points

2023-03-08T13:34:14.1066667+00:00

@Fabian Kaimer Looks like this would need deep and offline troubleshooting. Please open a support ticket with MS support
Dragoș Viuleț 0 Reputation points

2023-03-31T08:17:15.8333333+00:00

Was a solution found? I trying to migrate a small 4 component app that runs well on AKS. But on ACA i am getting the 426 from my API. I am sure there is a huge difference between our setup, but maybe a solution was suggested to you?
Spyros Psarras 1 Reputation point

2023-05-09T07:38:21.23+00:00
I hope my solution will help you out.
My approach is a little bit different than yours. I am using an App service with a container as source code. The image is the nginx:latest.

Since I am using a proxy pass, I am using upstream blocks

upstream bak { server $BAK_HOST:$BAK_PORT; }

The variables are been replaced by the entrypoint automagically during deployment and the variables are set on the App service configuration. You can use static host and ports in your case. The value of the variables is the FQDN nameservice of the backend in my scenario. <bak>.azurewebsites.net

I am using a map block as well, to use variables when needed, to keep it clean

map $proxy_x_server $server { bak $BAK_HOST; }

Then, the actual server block

server { listen 80; server_name *.yourdomain.com; location /api { try_files /dev/null @bak; } ... #some other locations location @bak { set $proxy_x_server "bak"; include conf.d/bak.headers; }

My conf.d/bak.headers includes some of the following configurations which you will probably need as well.

proxy_cache_bypass $http_upgrade; proxy_hide_header X-Powered-By; proxy_pass https://$proxy_x_server; proxy_redirect https://$server https://$host; proxy_set_header Connection keep-alive; proxy_set_header Host $server; proxy_set_header Upgrade $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;

In the bak.headers file I am adding a bunch of headers, so in your case you probably will have to do that yourself as well.

example

add_header Access-Control-Allow-Headers "Access-Control-Allow-Origin, Origin, Content-Type, Authorization, X-Account"; add_header Access-Control-Allow-Methods "OPTIONS, POST, GET"; add_header Access-Control-Expose-Headers "WWW-Authenticate, Content-Disposition, X-Query-Token-Expired";

I hope I was helpful :D

1 answer

Your answer

Fabian Kaimer 5 Reputation points

2023-03-02T08:54:33.81+00:00

I have also built the whole architecture locally with Docker and it works perfectly fine there. All requests are properly proxied there. The only (and major) difference there is that I'm not using a FQDN but instead proxy the requests to localhost. So my assumption is that there are any issues with resolving the FQDN in my container?
Fabian Kaimer 5 Reputation points

2023-03-02T09:11:57.3566667+00:00

I have built the whole architecture in Docker as well for testing purposes and it works perfectly fine there. My requests are properly forwarded by the reverse proxy to the GUI container. The only (and major difference) between my containers in Azure and my Docker containers is that Docker proxies the requests to localhost and the container apps try to identify them by resolving the FQDN. My assumption is that the container has some sort or problem resolving the FQDN?
MughundhanRaveendran-MSFT 12,511 Reputation points

2023-03-08T13:34:14.1066667+00:00

@Fabian Kaimer Looks like this would need deep and offline troubleshooting. Please open a support ticket with MS support
Dragoș Viuleț 0 Reputation points

2023-03-31T08:17:15.8333333+00:00

Was a solution found? I trying to migrate a small 4 component app that runs well on AKS. But on ACA i am getting the 426 from my API. I am sure there is a huge difference between our setup, but maybe a solution was suggested to you?
Spyros Psarras 1 Reputation point

2023-05-09T07:38:21.23+00:00

I hope my solution will help you out.
My approach is a little bit different than yours. I am using an App service with a container as source code. The image is the nginx:latest.

Since I am using a proxy pass, I am using upstream blocks

upstream bak { server $BAK_HOST:$BAK_PORT; }

The variables are been replaced by the entrypoint automagically during deployment and the variables are set on the App service configuration. You can use static host and ports in your case. The value of the variables is the FQDN nameservice of the backend in my scenario. <bak>.azurewebsites.net

I am using a map block as well, to use variables when needed, to keep it clean

map $proxy_x_server $server { bak $BAK_HOST; }

Then, the actual server block

server { listen 80; server_name *.yourdomain.com; location /api { try_files /dev/null @bak; } ... #some other locations location @bak { set $proxy_x_server "bak"; include conf.d/bak.headers; }

My conf.d/bak.headers includes some of the following configurations which you will probably need as well.

proxy_cache_bypass $http_upgrade; proxy_hide_header X-Powered-By; proxy_pass https://$proxy_x_server; proxy_redirect https://$server https://$host; proxy_set_header Connection keep-alive; proxy_set_header Host $server; proxy_set_header Upgrade $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;

In the bak.headers file I am adding a bunch of headers, so in your case you probably will have to do that yourself as well.

example

add_header Access-Control-Allow-Headers "Access-Control-Allow-Origin, Origin, Content-Type, Authorization, X-Account"; add_header Access-Control-Allow-Methods "OPTIONS, POST, GET"; add_header Access-Control-Expose-Headers "WWW-Authenticate, Content-Disposition, X-Query-Token-Expired";

I hope I was helpful :D

Answer 1

Fabian Kaimer 5

Microsoft could resolve my issue after getting in contact with their support. It wasn't actually a problem with container apps but rather with nginx (which I use for reverse-proxying).

I had to add the line proxy_ssl_server_name on; to my nginx.conf , thus enabling to use the FQDN with https:// and not getting any protocal errors:

events{}
http {

    include "/etc/nginx/mime.types";      

    server {

	large_client_header_buffers 4 32k;

        listen 80;
       
        location /public {    
            root /usr/share/nginx/html/;
            autoindex on;
        }  

        location / {
            proxy_pass https://[PUT FQDN HERE];
            proxy_ssl_server_name on;
            proxy_http_version 1.1;
        }  
    }
}

Fabian Kaimer 5 Reputation points

2023-03-31T14:18:00.34+00:00

@MughundhanRaveendran-MSFT could you maybe set my answer as the accepted answer? I cannot accept my own answer.

Share via

Use reverse proxy in Azure Container Apps Environment

1 answer

Your answer