(解决)路由到Openshift CRC应用程序通过nginx反向代理和haproxy -我变得绝望:-)

Question

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

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

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

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

我不得不把它弄得那么复杂，因为这个项目笔记本也应该单独工作用于演示。它还提供了一个WiFi接入点和一个dhcpd来连接来宾机器。

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

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

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

这对于在我的局域网中运行在不同主机上的许多应用程序并通过所说的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到内部http是没有问题的其他网站。我将后端主机名放在一个变量中，以避免后端脱机时出现问题。https所需的证书是为整个反向代理及其所有站点全局定义的-工作良好。

haproxy配置

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定义可能，而外部调用被重新路由到https由nginx?)

我迷路了，真的很感激一些有用的提示，让应用程序运行在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/;
}
}

所以，基本上我只是添加了这些尾斜杠-这就行了，但我很乐意了解为什么。我瞥了一眼，那可能与文本替换有关，但我不明白……: -)如果有人能指出一个好的手册，关于所有这些配置是如何真正工作的，我将非常感谢…

对

阿克塞尔