Обратный прокси-сервер IIS ARR, запущенный в Docker под виртуальной машиной Azure, возвращает 404 - PullRequest
Новая
       103

Обратный прокси-сервер IIS ARR, запущенный в Docker под виртуальной машиной Azure, возвращает 404

0 голосов
/ 30 сентября 2019

Используя виртуальную машину Azure Server Core 2019, я настроил несколько док-контейнеров с ISS / ARR 3.0 в качестве обратного прокси.

Когда я получаю доступ к URL-адресу хоста: "http://[hostname]/deploy"я ожидаю, что RP перенаправит на http://[docker ip]: 81

81 - это незащищенный порт отдельного внутреннего контейнера док-станции, на котором запускается «развертывание». К вашему сведению: он сопоставлен с хост-портом 1322... доступ к имени хоста: 1322 через внешний браузер работает нормально.

(я также пытался использовать правило перезаписи для [hostname]: 1322 и [docker ip]: 1322)

Независимо от того, что я делаю, я всегда получаю 404 (не найдено)

Я не могу понять, почему. Есть ли что-то в самом Azure, что это портит? Единственная сеть, которая у меня есть, доступная для докера в Windowsэто NAT (через сеть Docker ls). У меня есть правильный IP-адрес целевого контейнера Docker через «Docker Inspect [container]», но я думаю, что это IP-адрес, отображаемый хосту, а не тот, который может быть видендругие контейнеры, работающие на хосте.

How знаю, какой IP-адрес внутренней док-станции доступен для других работающих док-контейнеров для правила ARR (или есть другой способ настроить его так, чтобы он знал правило динамически?)

моя сеть ARR. Конфигурация: 

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="deploy" stopProcessing="true">
                    <match url="^(.*)/deploy" />
                    <action type="Rewrite" url="http://172.23.60.148:81" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Мой файл Docker обратного прокси-сервера: 

FROM mcr.microsoft.com/windows/servercore/iis

# Download and install the required URL rewrite and Application Request Routing modules. Clean up after!
ADD http://go.microsoft.com/fwlink/?LinkID=615137 /install/rewrite_amd64.msi
ADD http://go.microsoft.com/fwlink/?LinkID=615136 /install/ARRv3_setup_amd64_en-us.msi
RUN msiexec.exe /i C:\install\rewrite_amd64.msi /qn /log C:\ms_install.log & \
    msiexec.exe /i C:\install\ARRv3_setup_amd64_en-us.msi /qn /log C:\arr_install.log & \
    rd /s /q c:\install

# Enable proxy feature for IIS. Allows us to act as a reverse proxy
RUN .\Windows\System32\inetsrv\appcmd.exe set CONFIG -section:system.webServer/proxy /enabled:"True" /commit:apphost

# The web config should contain our routing to other containers
ADD ./web.config /inetpub/wwwroot/web.config

1 Ответ

1 голос
/ 08 октября 2019

Итак, оказывается, что проблема вовсе не в докере, а в ARR.

Когда вы добавляете правило перезаписи, логично ожидать, что этот "^ (. *) / Deploy" будет соответствоватькритерий, т. е. «окончание / развертывание». Тестер правил перезаписи в IIS даже работает корректно, когда вы его пробуете.

Оказывается, IIS не передает / в механизм правил перезаписи. Он только передает текст «развернуть» ... поэтому правило никогда не совпадает, а затем передает его на базовый сайт IIS вместо целевого ... и, конечно, / развертывание не существует на базовом сайте, следовательно,404.

Связанные проблемы ARR здесь

...