此内容没有您所选择的语言版本。

8.4.5. Broker Web Application


Because the broker application is stateless, enabling redundancy is relatively easy. You can set up instances on multiple hosts with a standard HTTP/HTTPS load balancer, such as Apache HTTP Server, HAProxy, or any existing solution, to distribute requests. Enabling sticky sessions is not required.
However, if access to redundant brokers is implemented with a reverse proxy, verify that the request from the proxy is for the public address. The broker API document is generated with the Host: header by which it is addressed; this includes URLs to various functionality. Clients can be directed to private URLs by way of the API document if the reverse proxy request does not preserve the client's Host: header.
For example, if you have a proxy at broker.example.com that distributes loads to broker1.example.com and broker2.example.com, the proxy request to broker1.example.com should be https://broker.example.com. If a httpd proxy is used, for example, enable the ProxyPreserveHost directive. For more information, see ProxyPreserveHost Directive at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypreservehost.

Important

When multiple broker hosts are deployed, the authentication keys need to be the same for all broker hosts. Update /etc/openshift/server_pub.pem and /etc/openshift/server_priv.pem, and update the AUTH_SALT setting in the/etc/openshift/broker.conf file. Failure to synchronize these will result in authentication failures where gears make requests to a broker host while using credentials created by a different broker host in scenarios such as auto-scaling, Jenkins builds, and recording deployments.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat