问题[bitnami](server)

我正在尝试通过 EKS 集群中的 Bitnami Helm 图表（https://github.com/bitnami/charts/tree/master/bitnami/rabbitmq）安装 RabbitMQ 集群，当我执行 Helm 安装时，我得到以下信息创建的第一个 pod 中的错误：

rabbitmq 13:41:15.99
rabbitmq 13:41:15.99 Welcome to the Bitnami rabbitmq container
rabbitmq 13:41:15.99 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-rabbitmq
rabbitmq 13:41:15.99 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-rabbitmq/issues
rabbitmq 13:41:15.99
rabbitmq 13:41:15.99 INFO  ==> ** Starting RabbitMQ setup **
rabbitmq 13:41:16.01 INFO  ==> Validating settings in RABBITMQ_* env vars..
rabbitmq 13:41:16.03 INFO  ==> Initializing RabbitMQ...
rabbitmq 13:41:16.03 DEBUG ==> Creating environment file...
rabbitmq 13:41:16.03 DEBUG ==> Creating enabled_plugins file...
rabbitmq 13:41:16.04 DEBUG ==> Creating Erlang cookie...
rabbitmq 13:41:16.04 DEBUG ==> Ensuring expected directories/files exist...
rabbitmq 13:41:16.05 INFO  ==> Starting RabbitMQ in background...
Waiting for erlang distribution on node '[email protected]' while OS process '51' is running
2022-04-19 13:41:19.198340+00:00 [info] <0.222.0> Feature flags: list of feature flags found:
2022-04-19 13:41:19.212884+00:00 [info] <0.222.0> Feature flags:   [ ] implicit_default_bindings
2022-04-19 13:41:19.212941+00:00 [info] <0.222.0> Feature flags:   [ ] maintenance_mode_status
2022-04-19 13:41:19.212965+00:00 [info] <0.222.0> Feature flags:   [ ] quorum_queue
2022-04-19 13:41:19.212985+00:00 [info] <0.222.0> Feature flags:   [ ] stream_queue
2022-04-19 13:41:19.213077+00:00 [info] <0.222.0> Feature flags:   [ ] user_limits
2022-04-19 13:41:19.213104+00:00 [info] <0.222.0> Feature flags:   [ ] virtual_host_metadata
2022-04-19 13:41:19.213124+00:00 [info] <0.222.0> Feature flags: feature flag states written to disk: yes
2022-04-19 13:41:19.637051+00:00 [noti] <0.44.0> Application syslog exited with reason: stopped
2022-04-19 13:41:19.637148+00:00 [noti] <0.222.0> Logging: switching to configured handler(s); following messages may not be visible in this log output
2022-04-19 13:41:19.656264+00:00 [noti] <0.222.0> Logging: configured log handlers are now ACTIVE
2022-04-19 13:41:19.904087+00:00 [info] <0.222.0> ra: starting system quorum_queues
2022-04-19 13:41:19.904200+00:00 [info] <0.222.0> starting Ra system: quorum_queues in directory: /bitnami/rabbitmq/mnesia/rabbit@rabbitmq-0/quorum/rabbit@rabbitmq-0
2022-04-19 13:41:19.995094+00:00 [info] <0.263.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered
2022-04-19 13:41:20.013384+00:00 [noti] <0.268.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables
2022-04-19 13:41:20.022921+00:00 [info] <0.222.0> ra: starting system coordination
2022-04-19 13:41:20.022987+00:00 [info] <0.222.0> starting Ra system: coordination in directory: /bitnami/rabbitmq/mnesia/rabbit@rabbitmq-0/coordination/rabbit@rabbitmq-0
2022-04-19 13:41:20.026371+00:00 [info] <0.276.0> ra: meta data store initialised for system coordination. 0 record(s) recovered
2022-04-19 13:41:20.026628+00:00 [noti] <0.281.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables
2022-04-19 13:41:20.032159+00:00 [info] <0.222.0>
2022-04-19 13:41:20.032159+00:00 [info] <0.222.0>  Starting RabbitMQ 3.9.8 on Erlang 24.1.2 [jit]
2022-04-19 13:41:20.032159+00:00 [info] <0.222.0>  Copyright (c) 2007-2021 VMware, Inc. or its affiliates.
2022-04-19 13:41:20.032159+00:00 [info] <0.222.0>  Licensed under the MPL 2.0. Website: https://rabbitmq.com

  ##  ##      RabbitMQ 3.9.8
  ##  ##
  ##########  Copyright (c) 2007-2021 VMware, Inc. or its affiliates.
  ######  ##
  ##########  Licensed under the MPL 2.0. Website: https://rabbitmq.com

  Erlang:      24.1.2 [jit]
  TLS Library: OpenSSL - OpenSSL 1.1.1d  10 Sep 2019

  Doc guides:  https://rabbitmq.com/documentation.html
  Support:     https://rabbitmq.com/contact.html
  Tutorials:   https://rabbitmq.com/getstarted.html
  Monitoring:  https://rabbitmq.com/monitoring.html

  Logs: /opt/bitnami/rabbitmq/var/log/rabbitmq/rabbit@rabbitmq-0_upgrade.log
        <stdout>

  Config file(s): /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf

  Starting broker...2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  node           : rabbit@rabbitmq-0
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  home dir       : /opt/bitnami/rabbitmq/.rabbitmq
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  config file(s) : /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  cookie hash    : d3Nfp8t690Ln1h811Tuxzw==
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  log(s)         : /opt/bitnami/rabbitmq/var/log/rabbitmq/rabbit@rabbitmq-0_upgrade.log
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>                 : <stdout>
2022-04-19 13:41:20.033907+00:00 [info] <0.222.0>  database dir   : /bitnami/rabbitmq/mnesia/rabbit@rabbitmq-0
2022-04-19 13:41:20.307590+00:00 [info] <0.222.0> Feature flags: list of feature flags found:
2022-04-19 13:41:20.307654+00:00 [info] <0.222.0> Feature flags:   [ ] drop_unroutable_metric
2022-04-19 13:41:20.307681+00:00 [info] <0.222.0> Feature flags:   [ ] empty_basic_get_metric
2022-04-19 13:41:20.307705+00:00 [info] <0.222.0> Feature flags:   [ ] implicit_default_bindings
2022-04-19 13:41:20.307792+00:00 [info] <0.222.0> Feature flags:   [ ] maintenance_mode_status
2022-04-19 13:41:20.307818+00:00 [info] <0.222.0> Feature flags:   [ ] quorum_queue
2022-04-19 13:41:20.307838+00:00 [info] <0.222.0> Feature flags:   [ ] stream_queue
2022-04-19 13:41:20.307908+00:00 [info] <0.222.0> Feature flags:   [ ] user_limits
2022-04-19 13:41:20.307947+00:00 [info] <0.222.0> Feature flags:   [ ] virtual_host_metadata
2022-04-19 13:41:20.307968+00:00 [info] <0.222.0> Feature flags: feature flag states written to disk: yes
Error: operation wait on node [email protected] timed out. Timeout value used: 5000
2022-04-19 13:41:23.299211+00:00 [info] <0.222.0> Running boot step pre_boot defined by app rabbit
2022-04-19 13:41:23.299295+00:00 [info] <0.222.0> Running boot step rabbit_global_counters defined by app rabbit
2022-04-19 13:41:23.299545+00:00 [info] <0.222.0> Running boot step rabbit_osiris_metrics defined by app rabbit
2022-04-19 13:41:23.299746+00:00 [info] <0.222.0> Running boot step rabbit_core_metrics defined by app rabbit
2022-04-19 13:41:23.300299+00:00 [info] <0.222.0> Running boot step rabbit_alarm defined by app rabbit
2022-04-19 13:41:23.304497+00:00 [info] <0.297.0> Memory high watermark set to 12695 MiB (13312088473 bytes) of 31738 MiB (33280221184 bytes) total
2022-04-19 13:41:23.308954+00:00 [info] <0.299.0> Enabling free disk space monitoring
2022-04-19 13:41:23.309007+00:00 [info] <0.299.0> Disk free limit set to 50MB
2022-04-19 13:41:23.312489+00:00 [info] <0.222.0> Running boot step code_server_cache defined by app rabbit
2022-04-19 13:41:23.312650+00:00 [info] <0.222.0> Running boot step file_handle_cache defined by app rabbit
2022-04-19 13:41:23.312958+00:00 [info] <0.302.0> Limiting to approx 65439 file handles (58893 sockets)
2022-04-19 13:41:23.313163+00:00 [info] <0.303.0> FHC read buffering: OFF
2022-04-19 13:41:23.313217+00:00 [info] <0.303.0> FHC write buffering: ON
2022-04-19 13:41:23.313829+00:00 [info] <0.222.0> Running boot step worker_pool defined by app rabbit
2022-04-19 13:41:23.313932+00:00 [info] <0.283.0> Will use 4 processes for default worker pool
2022-04-19 13:41:23.313982+00:00 [info] <0.283.0> Starting worker pool 'worker_pool' with 4 processes in it
2022-04-19 13:41:23.314583+00:00 [info] <0.222.0> Running boot step database defined by app rabbit
2022-04-19 13:41:23.314894+00:00 [info] <0.222.0> Node database directory at /bitnami/rabbitmq/mnesia/rabbit@rabbitmq-0 is empty. Assuming we need to join an existing cluster or initialise from scratch...
2022-04-19 13:41:23.314963+00:00 [info] <0.222.0> Configured peer discovery backend: rabbit_peer_discovery_k8s
2022-04-19 13:41:23.315110+00:00 [info] <0.222.0> Will try to lock with peer discovery backend rabbit_peer_discovery_k8s
2022-04-19 13:41:23.316998+00:00 [noti] <0.44.0> Application mnesia exited with reason: stopped

BOOT FAILED
===========
Exception during startup:

2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0> BOOT FAILED
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0> ===========
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0> Exception during startup:
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0> error:{badmatch,{error,enoent}}
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_peer_discovery_k8s:make_request/0, line 121
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_peer_discovery_k8s:list_nodes/0, line 41
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_peer_discovery_k8s:lock/1, line 76
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_peer_discovery:lock/0, line 190
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_mnesia:init_with_lock/3, line 104
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_mnesia:init/0, line 76
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_boot_steps:-run_step/2-lc$^0/1-0-/2, line 41
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>     rabbit_boot_steps:run_step/2, line 46
2022-04-19 13:41:23.317269+00:00 [erro] <0.222.0>
error:{badmatch,{error,enoent}}

    rabbit_peer_discovery_k8s:make_request/0, line 121
    rabbit_peer_discovery_k8s:list_nodes/0, line 41
    rabbit_peer_discovery_k8s:lock/1, line 76
    rabbit_peer_discovery:lock/0, line 190
    rabbit_mnesia:init_with_lock/3, line 104
    rabbit_mnesia:init/0, line 76
    rabbit_boot_steps:-run_step/2-lc$^0/1-0-/2, line 41
    rabbit_boot_steps:run_step/2, line 46

2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>   crasher:
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     initial call: application_master:init/4
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     pid: <0.221.0>
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     registered_name: []
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     exception exit: {{badmatch,{error,enoent}},{rabbit,start,[normal,[]]}}
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>       in function  application_master:init/4 (application_master.erl, line 142)
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     ancestors: [<0.220.0>]
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     message_queue_len: 1
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     messages: [{'EXIT',<0.222.0>,normal}]
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     links: [<0.220.0>,<0.44.0>]
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     dictionary: []
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     trap_exit: true
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     status: running
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     heap_size: 2586
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     stack_size: 29
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>     reductions: 186
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>   neighbours:
2022-04-19 13:41:24.318598+00:00 [erro] <0.221.0>
2022-04-19 13:41:24.319087+00:00 [noti] <0.44.0> Application rabbit exited with reason: {{badmatch,{error,enoent}},{rabbit,start,[normal,[]]}}
{"Kernel pid terminated",application_controller,"{application_start_failure,rabbit,{{badmatch,{error,enoent}},{rabbit,start,[normal,[]]}}}"}
Kernel pid terminated (application_controller) ({application_start_failure,rabbit,{{badmatch,{error,enoent}},{rabbit,start,[normal,[]]}}})

Crash dump is being written to: /opt/bitnami/rabbitmq/var/log/rabbitmq/erl_crash.dump...done
Waiting for erlang distribution on node '[email protected]' while OS process '51' is running
Error:
process_not_running
Waiting for erlang distribution on node '[email protected]' while OS process '51' is running
Error:
process_not_running

似乎 Erlang cookie 没有正确分发，但在检查了一些帖子后，我没有得出任何结论。

如果您有任何可能有用的信息，如果您与我分享，我将不胜感激。

编辑 1：我已经进入了必须创建的三个副本中的第一个也是唯一一个 pod，运行rabbitmq-diagnostics erlang_cookie_sources以找出 Erland cookie 文件存储在哪里（/opt/bitnami/rabbitmq/.rabbitmq/.erlang.cookie）和检查它是否与我在图表的 values.yaml 中指示的相同，并且完全相同，所以最后我认为分配密钥没有问题，但我仍然有同样的问题。再次查看日志我可以看到有一些进程没有运行，我不知道问题是否应该存在。

我使用 nginx ingress 作为负载均衡器部署了 bitnami/wordpress helm，就像这里一样。一切正常，但问题出在一些 pod 是手动创建或通过自动缩放自动创建时。其中一些（不是全部）一直处于“ContainerCreating”状态，日志如下所示：

  Normal   Scheduled    33m                  default-scheduler  Successfully assigned default/wordpress-69c8f65d96-wnkfv to main-node-d29388
  Warning  FailedMount  4m28s (x6 over 29m)  kubelet            Unable to attach or mount volumes: unmounted volumes=[wordpress-data], unattached volumes=[default-token-s4gdj wordpress-data]: timed out waiting for the condition
  Warning  FailedMount  0s (x9 over 31m)     kubelet            Unable to attach or mount volumes: unmounted volumes=[wordpress-data], unattached volumes=[wordpress-data default-token-s4gdj]: timed out waiting for the condition

我部署了 bitnami/wordpress，然后使用以下设置进行了升级：

helm install wordpress bitnami/wordpress --set service.type=ClusterIP --set ingress.enabled=true --set ingress.certManager=true --set ingress.annotations."kubernetes\.io/ingress\.class"=nginx --set ingress.annotations."cert-manager\.io/cluster-issuer"=letsencrypt-prod --set ingress.hostname=DOMAIN.com --set ingress.extraTls[0].hosts[0]=DOMAIN.com --set ingress.extraTls[0].secretName=wordpress.local-tls --set wordpressPassword=PASSWORD --set autoscaling.enabled=true --set autoscaling.minReplicas=1 autoscaling.maxReplicas=30

kubectl get pods 看起来像这样

ingress-nginx-ingress-controller-84bff86888-f4tpb                 1/1     Running             0          2d3h
ingress-nginx-ingress-controller-default-backend-c5b786dbbqw5xz   1/1     Running             0          2d3h
load-generator                                                    1/1     Running             0          71s
wordpress-69c8f65d96-48jd9                                        0/1     ContainerCreating   0          18m
wordpress-69c8f65d96-66ftt                                        0/1     ContainerCreating   0          56m
wordpress-69c8f65d96-dq7xq                                        1/1     Running             0          100m
wordpress-69c8f65d96-fbnt6                                        1/1     Running             0          101m
wordpress-69c8f65d96-wnkfv                                        0/1     ContainerCreating   0          56m
wordpress-mariadb-0                                               1/1     Running             0          8h

怎样做才能使新 pod 没有这个问题并让它们启动？

我正在将https://github.com/bitnami/charts/tree/master/bitnami/postgresql部署到 k8s 中，并想知道如何自动执行以下操作

• 创建数据库
• 使用密码创建一个角色作为上述数据库的所有者

我已经看到了extraDeploy https://github.com/bitnami/charts/blob/master/bitnami/postgresql/values.yaml#L43 参数，但这似乎会创建一个 k8s 特定资源（不涉及 pg）。

我利用的唯一想法extraDeploy是创建一个部署自定义 pod 的作业，该 pod 将连接到 pg 并创建数据库、角色和密码......

谢谢！

我在 AWS 上使用 Bitnami NodeJS 实例。我在 Bitnami 文档]( https://docs.bitnami.com/aws/get-started-lightsail/ ) 中发现我必须手动更新 Wordpress 安装。但是对于操作系统，我找不到它是否保持更新，或者我是否需要更新包和通过sudo apt-get update && sudo apt-get upgrade定期手动运行来更新发行版。有谁知道并可以提供参考？

我们将来可能需要升级 Lightsail Bitnami WordPress Multisite 实例，所以我正在测试它。

在我拍摄快照，然后从中创建一个新的更大的实例，然后将静态 IP 切换到它之后，站点无法加载，原因是：

Your connection is not private
Attackers might be trying to steal your information from (etc..)
NET::ERR_CERT_AUTHORITY_INVALID
Subject: www.example.com
Issuer: www.example.com
Expires on: 7 Nov 2030
Current date: 18 Nov 2020
PEM encoded chain:
-----BEGIN CERTIFICATE-----
(cert details etc...)

请注意www.example.com和 2030 年的到期日期。

SSL 证书（使用 Bitnami HTTPS 配置工具制作）是否仅适用于原始实例，即使新实例是精确副本？我猜他们会的。

是使用相同的 Bitnami 工具在新实例上创建新证书的唯一解决方案吗？

谢谢

我刚刚意识到我网站的某些链接会导致“502 Bad Gateway”错误。例如https://v2a.10studio.tech/10studio/auth/google、https://v2a.10studio.tech/auth/google、https://v2a.10studio.tech/10studio/auth/microsoft、https ://v2a.10studio.tech/auth/microsoft。我很确定这些链接几周前有效，我不知道发生了什么。

网站https://v2a.10studio.tech/仍在运行。https://v2a.10studio.tech/#/sign?next=/包含点击导致链接断开的按钮。

这里是docker-compose.yml：

version: "3"
services:
  frontend:
    restart: unless-stopped
    image: staticfloat/nginx-certbot
    ports:
      - 80:80/tcp
      - 443:443/tcp
    environment:
      CERTBOT_EMAIL: [email protected]
    volumes:
      - ./conf.d:/etc/nginx/user.conf.d:ro
      - letsencrypt:/etc/letsencrypt
  10studio:
    image: bitnami/nginx:1.16
    restart: always
    volumes: 
      - ./build:/app
      - ./default.conf:/opt/bitnami/nginx/conf/server_blocks/default.conf:ro
      - ./configs/config.prod.js:/app/lib/config.js
    depends_on: 
    - frontend

volumes:
  letsencrypt:

networks:
  default:
    external:
      name: 10studio

并且conf.d/v2.conf：

gzip on;
gzip_proxied any;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/rss+xml text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/jpeg image/png image/svg+xml image/x-icon;

upstream funfun {
   server www.funfun.io:443;
}


server {
    listen              443 ssl;
    ssl_certificate     /etc/letsencrypt/live/v2a.10studio.tech/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/v2a.10studio.tech/privkey.pem;
    server_name v2a.10studio.tech;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 1d;
    ssl_stapling on;
    ssl_stapling_verify on;
    add_header Strict-Transport-Security max-age=15768000;
    add_header X-Frame-Options "";
    
    
    location ~ /socialLoginSuccess {                                                                                            
        rewrite ^ '/#/socialLoginSuccess' redirect;
     }

    location ~ /auth/(.*) {                                                                                            
        proxy_pass  https://funfun/10studio/auth/$1?$query_string;
        proxy_set_header Host v2a.10studio.tech;
     }

    location / {
        proxy_set_header    Host                $host;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto   $scheme;
        proxy_set_header    Accept-Encoding     "";
        proxy_set_header    Proxy               "";
        proxy_pass          http://10studio:8080/;

        # These three lines added as per https://github.com/socketio/socket.io/issues/1942 to remove socketio error
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection "upgrade";
    }
}

有人可以帮忙吗？

PS：几周前我在 CloudFlare 中更改了 funfun.io 的一些设置（尤其是 SSL 证书），如果它相关，我不知道。我不知道这Proxy status（DNS only或Proxied）是否有影响。

编辑 1：这里有一些 docker 日志：

2020-08-18T20:19:15.667934708Z 2020/08/18 20:19:15 [error] 42#42: *310 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://104.27.153.135:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.667995550Z 2020/08/18 20:19:15 [warn] 42#42: *310 upstream server temporarily disabled while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://104.27.153.135:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.738088121Z 2020/08/18 20:19:15 [error] 42#42: *310 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://104.27.152.135:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.738135701Z 2020/08/18 20:19:15 [warn] 42#42: *310 upstream server temporarily disabled while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://104.27.152.135:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.803843403Z 2020/08/18 20:19:15 [error] 42#42: *310 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://172.67.193.92:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.803890220Z 2020/08/18 20:19:15 [warn] 42#42: *310 upstream server temporarily disabled while SSL handshaking to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /auth/github HTTP/1.1", upstream: "https://172.67.193.92:443/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:15.803908241Z 176.144.215.193 - - [18/Aug/2020:20:19:15 +0000] "GET /auth/github HTTP/1.1" 502 559 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36" "-"
2020-08-18T20:19:21.284333260Z 2020/08/18 20:19:21 [error] 42#42: *310 no live upstreams while connecting to upstream, client: 176.144.215.193, server: v2a.10studio.tech, request: "GET /10studio/auth/github HTTP/1.1", upstream: "https://funfun/10studio/auth/github?", host: "v2a.10studio.tech"
2020-08-18T20:19:21.285121395Z 176.144.215.193 - - [18/Aug/2020:20:19:21 +0000] "GET /10studio/auth/github HTTP/1.1" 502 559 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36" "-"

我们有一个 Amazon Linux（不是 Amazon Linux 2）实例，运行一个相当旧的 Bitnami Trac/SVN 堆栈，还运行一个 Tomcat 服务器。它有两个 httpd 实例：一个是 Bitnami 堆栈的一部分，另一个是操作系统附带的。Tomcat 独立运行。Lego 已经存在，bncert-tool 也是如此，但 Bitnami 目录不是“/opt/bitnami”，而是“/opt/trac-1.2.3-11”。

操作系统 httpd 在启动时会监听 80，不安全。Bitnami httpd 监听 8000，安全，也可以监听 81。Tomcat 服务器独立于 httpd 运行，并监听 8443，安全（使用来自 443 的 iptables 重定向）和 7443（也安全）。

在现场实例上工作，从实时服务器的最新备份克隆，在 Route 53 中映射到它的域，以及在分配的安全组之一中向世界开放的端口 80 和 443，我一直在尝试按照https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach页面上“替代方法”下的说明进行操作，但未成功。

跳过过程中的第 1 步，因为乐高已经存在，直接进入第 2 步，我用“ctlscript.sh stop”停止了 Bitnami。然后，我（在 root 权限下运行）尝试使用程序中给出的命令获取证书，并根据情况进行调整。（注意域名已更改，“保护无辜”。）

sudo /opt/trac-1.2.3-11/letsencrypt/lego --tls --email="[email protected]" --domains="test.bar.net" --path="/opt/trac-1.2.3-11/letsencrypt" run

我懂了：

2020/08/04 18:01:29 No key found for account [email protected]. Generating a P384 key.
2020/08/04 18:01:29 Saved key to /opt/trac-1.2.3-11/letsencrypt/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2020/08/04 18:01:30 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
Do you accept the TOS? Y/n
Y
2020/08/04 18:01:43 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!

        Your account credentials have been saved in your Let's Encrypt
        configuration directory at "/opt/trac-1.2.3-11/letsencrypt/accounts".
        You should make a secure backup of this folder now. This
        configuration directory will also contain certificates and
        private keys obtained from Let's Encrypt so making regular
        backups of this folder is ideal.
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Obtaining bundled SAN certificate
2020/08/04 18:01:43 [INFO] [test.bar.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: use tls-alpn-01 solver
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Trying to solve TLS-ALPN-01
2020/08/04 18:01:50 [INFO] Unable to deactivated authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:50 Could not obtain certificates:
    acme: Error -> One or more domains had a problem:
[test.bar.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url: 

然后我尝试关闭操作系统 httpd 实例，并重复该命令。从“获取捆绑的 SAN 证书”消息开始，我得到了相同的结果。

然后，我尝试关闭 Tomcat。这一次，我在最后一行收到了不同的信息：

[test.bar.net] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Connection refused, url:

显然这里出了点问题，但我的下一步是什么？

我用 docker 和bitnami/nginx镜像部署了一个网站：https ://www.10studio.tech/demo 。部署后，我意识到像这样的文件analyzejs.js没有被压缩：

这里是docker-compose.yml：

version: "3"
services:
  docusaurus:
    image: bitnami/nginx:1.16
    restart: always
    volumes:
    - ./build:/app
    - ./certs:/certs:ro
    - ./my_server_block.conf:/opt/bitnami/nginx/conf/server_blocks/my_server_block.conf:ro
    ports:
    - "3001:3001"
    - "3002:3002"

这里是my_server_block.conf：

server {
  listen  3002;
  absolute_redirect off;
  root  /app;

  location = / {
    rewrite ^(.*)$ https://$http_host/docs/introduction redirect;
  }

  location / {
    try_files $uri $uri/ =404;
  }
}

server {
  listen  3001 ssl;

  ssl_certificate      /certs/server.crt;
  ssl_certificate_key  /certs/server.key;

  ssl_session_cache    shared:SSL:1m;
  ssl_session_timeout  5m;

  ssl_ciphers  HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers  on;

  location / {
    proxy_pass http://localhost:3002;
    proxy_redirect off;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Ssl on;
  }
}

这是/opt/bitnami/nginx/conf/nginx.conf，其中 gzip 似乎已启用：

I have no name!@8317023de7ec:/app$ cat /opt/bitnami/nginx/conf/nginx.conf
# Based on https://www.nginx.com/resources/wiki/start/topics/examples/full/#nginx-conf
# user              www www;  ## Default: nobody

worker_processes  auto;
error_log         "/opt/bitnami/nginx/logs/error.log";
pid               "/opt/bitnami/nginx/tmp/nginx.pid";

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    log_format    main '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status  $body_bytes_sent "$http_referer" '
                       '"$http_user_agent" "$http_x_forwarded_for"';
    access_log    "/opt/bitnami/nginx/logs/access.log";
    add_header    X-Frame-Options SAMEORIGIN;

    client_body_temp_path  "/opt/bitnami/nginx/tmp/client_body" 1 2;
    proxy_temp_path        "/opt/bitnami/nginx/tmp/proxy" 1 2;
    fastcgi_temp_path      "/opt/bitnami/nginx/tmp/fastcgi" 1 2;
    scgi_temp_path         "/opt/bitnami/nginx/tmp/scgi" 1 2;
    uwsgi_temp_path        "/opt/bitnami/nginx/tmp/uwsgi" 1 2;

    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        off;
    gzip               on;
    gzip_http_version  1.0;
    gzip_comp_level    2;
    gzip_proxied       any;
    gzip_types         text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
    keepalive_timeout  65;
    ssl_protocols      TLSv1 TLSv1.1 TLSv1.2;

    include  "/opt/bitnami/nginx/conf/server_blocks/*.conf";

    # HTTP Server
    server {
        # port to listen on. Can also be set to an IP:PORT
        listen  8080;

        location /status {
            stub_status on;
            access_log   off;
            allow 127.0.0.1;
            deny all;
        }
    }
}

有谁知道这里出了什么问题以及如何启用 gzip？

我最近（我认为是在 ServerFault、StackOverflow 或其他一些 StackExchange 论坛上）发现 Bitnami 堆栈提供了一种使用 Let's Encrypt 的工具，该工具显然使用了 certbot 以外的东西（称为“乐高”，是吗？ ？）。

我们有一个在 AWS EC2 实例（原始 Amazon Linux）上运行的 Bitnami Trac/SVN 堆栈。我注意到盒子上显然有两个单独的 httpd 实例；Bitnami 堆栈中的一个是活动的，托管 Trac 和 SVN。（我想我几个月前开始了另一个，与尝试使 certbot 工作失败有关，并且可能已经放弃了它，但它实际上并没有做任何事情。）

Bitnami httpd 在端口 81（目前无法从外部访问）上设置 HTTP，在端口 8000（可访问）上设置 HTTPS，并且当前使用 Comodo 的证书，该证书将于 7 月到期。

而且我不记得 Bitnami 堆栈中 httpd 的原始“交付”端口配置是什么。

我一直在阅读这个“bncert-tool”的说明，我想知道它是否适用于我们的设置。从我对 certbot 的失败实验中，我的印象是 Let's Encrypt 期望在 80 上找到打开的 http。

任何人都可以对此有所了解吗？

5月18日更新

我终于在我真正可以投入一些时间的时候想起了这个项目。我将该实例克隆到一个现场实例，然后（1）禁用 Linux 附带的“stock”httpd，（2）将 Bitnami 堆栈中的 httpd 更改为监听 80。当我运行 bncert-tool 时，我得到了这个：

使用 Let's Encrypt 创建证书时出错：

acme: Error -> One or more domains had a problem:
[test.wintouch.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized 
:: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url:

怎么办？

（我已经保存了日志文件。）

5月22日更新

我突然想到，由于当前配置了服务器，因此没有密码就不可能访问任何内容。

所以我尝试了另一个现场实例。经过一番折腾，我对其进行了配置，使其无需密码即可侦听 80，并在该端口上提供静态页面，该端口远离 SVN 和 Trac 数据。

但结果和以前完全一样。和以前一样，我终止了现场请求并删除了 Route 53 A 记录作为清理的一部分。

在一天的实验之后，我研究了设置原始实例时使用的任何我的 Spot 实例，并发现了一些相当奇怪的东西：我能看到的所有 Bitnami SVN 和 Trac AMI 都是 Debian 或 Ubuntu。但这是在Amazon Linux（原始版本，而不是 Amazon Linux 2）上。因此，要么它来自一个不再存在的 AMI，要么我从一个“普通”Amazon Linux AMI 启动实例，然后在其上安装 Bitnami SVN/Trac 堆栈。

我会注意到，包括 bncert-tool 在内的堆栈不在/opt/bitnami 中，而是在 /opt/trac-1.2.3-11

因此，由于无法检查“交付时”的配置，我环顾四周，想知道 bncert-tool 使用什么来查找堆栈，最终我找到了 /opt/trac-1.2.3-11/properties.ini

hostname=
[Support]
installed_components=apache
apache_logs=apache{,2}/logs/error*log logs/error_log
apache_conf=apache{,2}/conf/{*.conf,bitnami/*.conf} etc/httpd.conf apps/*/conf/ht*.conf
apache_acl=apache apache2
[Apache]
apache_server_port=81
apache_user=daemon
apache_group=daemon
apache_server_ssl_port=443
apache_root_directory=/opt/trac-1.2.3-11/apache2
apache_htdocs_directory=/opt/trac-1.2.3-11/apache2/htdocs
apache_domainname=ip-172-31-8-195.us-east-2.compute.internal
apache_configuration_directory=/opt/trac-1.2.3-11/apache2/conf
apache_version=2.4.39
[Subversion]
subversion_port=3690
subversion_root_directory=/opt/trac-1.2.3-11/subversion

自安装以来似乎没有变化（/opt/trac-1.2.3-11 中的所有内容都具有 2019 年 6 月 6 日的日期戳）。

可能是 bncert-tool 使用了该配置文件，并且已经告诉 Let's Encrypt 使用端口 81 而不是 80？

我会注意到，与上述配置文件相反，httpd 的 Bitnami 实例在 8000 上侦听 SSL/TLS，而不是 443，Tomcat 服务器（独立于 Bitnami 堆栈）在 8443 上侦听（并显示在 netstat -l -- numeric-ports as) 8443，通过 iptables 映射到 443，没有任何东西直接监听 443 端口。

我正在尝试在 aws lightsail 实例上配置 apache2。该实例是 aws wordpress + aws linux 的默认设置。我有一个 node.js 服务器在此实例的端口 5000 上运行。

apache 服务器位于/opt/bitnami/apache2.

首先，我尝试将非 http 请求的端口重定向到 5000，它运行良好。

这是 .conf 文件：

<VirtualHost *:80>
  ProxyPreserveHost On
  ProxyRequests Off
  ServerName example.com
  ServerAlias www.example.com

  # setup the proxy
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>

  ProxyPass / http://example:5000/
  ProxyPassReverse / http://example:5000/
</VirtualHost>

然后我用 bitnami bncert-tool 配置了 ssl 证书。我在配置 ssl 时打开了强制 https 重定向。

然后我配置example-https.conf如下：

<VirtualHost *:80>
  ProxyPreserveHost On
  ProxyRequests Off

  ServerName example.com
  ServerAlias www.example.com

  SSLEngine on
  SSLCertificateFile "/opt/bitnami/apache2/conf/example.com.crt"
  SSLCertificateKeyFile "/opt/bitnami/apache2/conf/example.com.key"

  # setup the proxy
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>

  ProxyPass / http://example.com:5000/
  ProxyPassReverse / http://example.com:5000/
</VirtualHost>

但这一次它不起作用。请求被重定向到 https 并且响应来自 wordpress，而不是我的 node.js 服务器。

这些conf文件在/var/www其中，我已将它们包含在httpd.conf使用中

Include "/var/www/*.conf"