apache - 在Apache上启用example.com:8080(Docker)上的https时，应用程序中的连接错误

Question

我将尽力解释我的情况，但我现在道歉，因为我前不久开始研究该主题，也许我不知道如何正确地提供所有细节。
最近，我有一个脚本(后端和两个Android应用程序)可以在http上完美运行，但是这些应用程序的付款网关仅适用于https。该代码的作者创建了一个文档，该文档教您如何以自动化方式在服务器上安装后端，只需安装Docker并使用wget http://authorsite/docker-compose.yaml && docker-compose up -d链接运行后端。
该安装为数据库和后端文件创建了容器，并创建了docker-compose.yaml文件:

 version: '3'

 services:
   mysql:
     image: mysql
     command: --default-authentication-plugin=mysql_native_password
     volumes:
       - mysqlvol:/var/lib/mysql
     environment:
       MYSQL_ROOT_PASSWORD: defaultpassword

   redis:
     image: redis
     volumes:
       - redisvol:/data

   taxi:
     image: author/taxi
     restart: always
     depends_on:
       - "redis"
       - "mysql"
     volumes:
       - ./img:/app/public/img
       - ./config:/app/config
       - taxiassets:/app/public/assets
     links:
       - mysql
       - redis
     ports:
       - "8080:8080"

 volumes:
    redisvol:
    mysqlvol:
    taxiassets:

后端页面以 http://example.com:8080开始工作，我只需要在config.kt文件中的应用程序中添加相同的url:

class Config {
    companion object {
        const val Backend = "http://example.com:8080/"
    }
}

一切正常，但正如我提到的，我需要https才能使支付网关在应用程序中正常工作，并摆脱http。作者没有提供此信息，因此我研究并找到了一些有关反向代理的教程，我已经在服务器上(Docker外部)安装了Apache，并遵循了与Apache相关的教程。
我的.conf文件(带有“让我们加密”)如下所示:

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin webmaster@localhost
    ServerName example.com
    ServerAlias www.example.com
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
    ProxyPreserveHost On
    ProxyPassReverseCookiePath / /

    <Proxy *>
        Order deny,allow
        Allow from all
        Allow from localhost
    </Proxy>

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>
</IfModule>
<IfModule mod_ssl.c>
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName example.com
    ServerAlias www.example.com
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
    
    ProxyPass / ws://127.0.0.1:8080/

</VirtualHost>
</IfModule>

我仍在学习，我肯定一定做错了什么，后端仍然可以在 http://example.com:8080上运行，但不能在 https://example.com:8080上运行，但是即使这样后端也可以在 https://example.com上正常工作。我可以使用https访问面板，但是尝试使用 https://example.com打开应用程序时，如示例所示:

class Config {
    companion object {
        const val Backend = "https://example.com/"
    }
}

要么

class Config {
    companion object {
        const val Backend = "https://example.com:8080/"
    }
}

应用开始显示连接错误，并且无法正常运行。
我不知道这是否正确，后端在 http://example.com:8080之前可以处理上述更改，现在可以在 https://example.com上访问它，但是这个新的网址使应用程序无法以相同的方式工作并且出现连接错误。如果我保留原始网址:

class Config {
    companion object {
        const val Backend = "http://example.com:8080/"
    }
}

应用已恢复正常运行。
我究竟做错了什么？

Answer 1

回答您的问题有两个方面:
1. TLS终止代理
您可能想对TLS反向代理进行docker化，这将增加可维护性的简便性(无需在Docker之外进行一些手动安装/配置)以及隔离。您的主机；参见例如that other SO question的指针。
2. Docker网络
在您的docker-compose.yml中，添加一个额外的服务(dockerized TLS终止代理)时，其名称为proxy，负责处理主机上的入站请求，您应该解决以下问题:

公开此服务的80和443端口:

services:
  proxy:
    image: …
    ports:
      - '80:80'
      - '443:443'
    …

注意:通常还包括标准HTTP端口80，以便对HTTPS实现permanent redirection (HTTP 301)。

从ports: ["8080:8080"]服务中删除taxi规范(否则仍然可以访问http://example.com:8080)。

不要使用links:属性，因为它是deprecated feature。

而是将必须相互通信的各种容器放在同一自定义网络中:

正在添加

  networks:
    - network-name

在docker-compose服务(taxi，mysql，redis)中，使用而不是

  links:
    - mysql
    - redis

正在添加

networks:
  network-name:
    driver: bridge

在docker-compose.yml的末尾。

在http://mysql:3306服务中指定URL，例如http://redis:6379或taxi。
理想情况下，应将这些URL设置为taxi服务的docker-compose环境变量。

同样，在http://taxi:8080服务中指定URL proxy(类似于您在问题中提到的最后一个代码段，即const val Backend = "http://taxi:8080/")，以便从taxi访问proxy服务。
为此，您可能还想创建另一个服务(proxy，taxi)通用的自定义docker-compose网络。

请注意，上面的URL以http:而不是https:开头，因为它们对应于容器之间的内部HTTP请求，并且这些URL中的域名是，是docker-compose服务名称。

有关这些docker-compose网络概念的更多详细信息，请参见 the official doc。
最后，这是一个示例组件图，总结了您考虑的应用程序中涉及的各种容器: