（已解决）通过nginx反向代理和haproxy路由到Openshift CRC应用程序-我很绝望：-）

Question

在搜索了网络，尤其是堆栈溢出之后，我现在决定在这个平台上写我的第一篇文章。

我正在Linux Mint 20下的项目笔记本上运行OCP CRC。我创建了一个基本的类似 hello 的 Python/Flask 应用程序，运行得很好。从笔记本本地调用此应用程序当然没有问题 hello.apps-crc.testing.

为了使这个应用程序在我的本地网络中可用，我在笔记本上安装了ha代理和bind9。bind9定义了crc.testing和apps-crc.testing域，然后指向ha代理绑定到的虚拟网络设备，将所有请求从局域网转发到本地OCP CRC。

然后，这个本地DNS由我的中央本地DNS引用，因此这两个域都可以在本地网络中的任何地方解析。

我不得不把它弄得复杂一些，因为这个项目笔记本也应该可以单独用于演示。然后，它还提供了一个WiFi接入点和一个dhcpd来连接客户机器。

我使用虚拟网络设备来保持一些整洁，因为在虚拟机中笔记本上也有一些其他服务在运行-每个服务都有自己的虚拟网络接口，然后由haproxy绑定。。。

到目前为止一切都很好-工作得很好，两个域的所有连接（80、443、6443）都可以在整个LAN上工作，以便通过Web控制台和oc工具访问集群。

现在，该应用程序应该可以从互联网访问。所以我有一个公共领域——我们称之为mydomain。org-在这里我定义了一个子域ocp4apps.mydomain。org，它指向DSL路由器，该路由器将所有传入流量重定向到充当反向代理的nginx实例。

这适用于在我的 LAN 中的不同主机上运行并通过所述 nginx 反向代理分配给相应子域的许多应用程序。

现在，我定义了一个站点ocp4apps.mydomain.org，它应该将对https://ocp4apps.mydomain.org/hello的外部调用代理到内部主机hello.apps-crc.testing

接下来发生的是，在远程浏览器上，https://ocp4apps.mydomain.org/hello被https://hello.apps-crc.testing/hello取代，这当然没有任何意义。

我猜，我的问题不是CRC，而是我的nginx配置。不幸的是，我是一个开发人员，而不是网络专家:-(

下面是配置文件的摘录——尽可能简短:

NGINX配置

server {
    server_name ocp4apps.mydomain.org;

    listen 80;

    # redirect all incoming requests to https...
    return 301 https://ocp4apps.mydomain.org$request_uri;
}

server {
    server_name ocp4apps.mydomain.org;

    listen 443 ssl;

    root /var/www/html;
    error_page 403 404 500 502 503 504 /error.html;

    location / {
        # doesnt matter in this scenario
    }

    location /hello {
        set $hello_host hello.apps-crc.testing;
        proxy_pass http://$hello_host;
    }
}

我在我所有的站点定义上使用这种将所有内容重定向到https的模式，到目前为止效果很好。从https代理到内部超文本传输协议对其他站点也没有问题。我将后端主机名放在一个变量中，以避免后端离线时出现问题。https所需的tgh证书是为整个反向代理及其所有站点全局定义的——运行良好。

羟基构型

frontend crc_apps
    bind 192.168.2.11:80
    option tcplog
    mode tcp
    default_backend crc_apps

backend crc_apps
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server crcserver 192.168.130.11:80 check

frontend crc_apps_ssl
    bind 192.168.2.11:443
    option tcplog
    mode tcp
    default_backend crc_apps_ssl

backend crc_apps_ssl
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server crcserver 192.168.130.11:443 check

frontend crc_api
    bind 192.168.2.11:6443
    option tcplog
    mode tcp
    default_backend crc_api

backend crc_api
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server crcserver 192.168.130.11:6443 check

如前所述，这部分工程完美无缺...我本可以将CRC的ip地址放在一个环境变量中，但是因为它从不改变，所以这样做也可以。

然后，我尝试将这一行添加到nginx配置中的位置定义中：

        proxy_set_header Host $host;

到目前为止，这改变了行为，我现在显然得到了CRC的响应，请求的应用程序不可用，因为主机不存在：

来自CRC的错误消息

所以我尝试为外部域设置一个入口：

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: overall-project-ingress
  namespace: overall-project-name
spec:
  rules:
    - host: ocp4apps.mydomain.org
      http:
        paths:
          - path: /hello
            pathType: Prefix
            backend:
              service:
                name: hello-service
                port:
                  number: 8080

这会导致一条新的错误消息，即在服务器上找不到请求的URL（可能是因为没有TLS定义，而外部调用被nginx重新路由到https？）

我迷路了，真的很感激一些有用的提示，可以从互联网上访问crc中运行的应用程序：-）

最好的问候

阿克塞尔

Answer 1

我想我解决了这个问题-但老实说，我不太明白为什么：-）

我更换了

server {
    server_name ocp4apps.mydomain.org;
    # ...
    location /hello {
        set $hello_host hello.apps-crc.testing;
        proxy_pass http://$hello_host;
    }
}

与

server {
    server_name ocp4apps.mydomain.org;
    # ...
    location /hello/ {
        set $hello_host hello.apps-crc.testing;
        proxy_pass http://$hello_host/;
    }
}

所以，基本上我只是添加了这些尾随斜杠 - 这确实起作用了，但我很高兴理解为什么。我瞥见了，这可能与文本替换有关，但我不明白... ：-）

如果有人能指出一本关于所有这些配置如何真正工作的好手册，我会非常感激...

问候

阿克塞尔