Access components that provide HTTP services through domain names

This article is for application developers and operators

How the components deployed to Rainbond that provide HTTP protocol services are accessed is the focus of this description.Rainbond’s gateway service is designed to be directly oriented to the public network environment, so using the Rainbond gateway can directly manage the flow of public network traffic for all businesses of the enterprise.In the scenario of providing external services, the most common way to access HTTP services is to use domain names.Enterprises usually have only one external network IP address to the outside world, and port resources, especially 80/443 port resources, are very limited. The use of domain names can effectively reuse ports.

Next we start to bind a domain name to the Rainbond gateway and access the deployed components.

Preconditions

  1. Accessible components that provide HTTP services have been successfully deployed, such as deploying any Demo based on source code.
  2. Prepare a usable domain name and do a good job of DNS resolution (local resolution can be done in the test case, please configure the correct DNS resolution for official use)

Operating procedures

  1. Confirm that the prerequisites are ready Assume that the prepared domain name is www.example.com
  2. Configure the gateway policy In order to facilitate the user to configure the gateway policy, there are three entrances for managing and adding policies, namely：team view/gateway/access policy management page; application view/gateway policy management page; component management panel, port management Below; different management pages mainly manage different policy scopes, and the way of adding them is the same.Adding a policy is mainly divided into two parts: configuration：`routing rules`and`access target`.We fill in the domain name `www.example.com` in the routing rule, and select the deployed Demo component in the access target to confirm and save.
  3. Verify whether the policy takes effect Directly click the added policy to initiate access, and the component page is opened normally, and the configuration is successful.

Understand the principle and more configuration parameters

Rainbond gateway implementation can be considered as an ingress-controller, based on openresty 1.19.3.2version implementation.User-configured policies are translated into Kubernetes Ingress resources, and then automatically take effect in the Rainbond gateway.How to generate Kubernetes Ingress resources is that Rainbond’s internal implementation is transparent to users, so I will not explain it in detail here. Here, I will mainly explain the parameters supported by the configuration policy except the domain name.

route parameter

  • Domain name: The most important routing parameter. In the above example, we only set this parameter. The same domain name can be set repeatedly to route access to different component targets to serve the grayscale publishing scenario.
  • Request path: In the case of the same domain name, different component services can be requested according to different request paths.
  • Path Rewrite: You can use variables, combine regular expressions and flags to implement URL rewriting and redirection.
  • request header: Use request headers to distinguish different request routes, mainly used in grayscale publishing scenarios.
  • HTTPs certificate: Select to configure the HTTPs certificate to upgrade the current policy to HTTPS, and support the configuration of HTTP transfer policy, including HTTPS/HTTP coexistence and HTTP forced to HTTPS.The HTTPs certificate needs to be uploaded and added in the certificate management in advance. The Rainbond Cloud version currently supports automatic certificate issuance, that is, the existing certificate is automatically matched according to the configured domain name. If it does not exist, the third-party platform is called to automatically complete the issuance, and then complete the certificate binding.
  • Weight: When the above routing parameters of multiple policies are all the same, the weight can take effect.Setting different weights to access different components (generally, different versions of the same business deploy multiple components at the same time), which is suitable for grayscale publishing scenarios.

Proxy parameter settings

The proxy parameters need to be changed by clicking the parameter settings in the management list after the policy is added, which supports dynamic effect.

  • connection timeoutdefines the timeout for establishing a connection with the upstream server (upstream). The unit is seconds, default: 75.
  • request timeoutSet the timeout for transferring requests to the upstream server (upstream). The unit is seconds, default: 60. Set the timeout only between two consecutive write operations, not for the transfer of the entire request. If the upstream server server does not receive anything within this time, the connection is closed.
  • response timeoutdefines the timeout for reading responses from the upstream server (upstream). The unit is seconds, default: 60. Set the timeout only between two consecutive read operations, not for the transmission of the entire response. If If the upstream server does not transmit anything within this time, the connection is closed.
  • limitthe maximum limit of the upload content (or request body), set the size to 0, there will be no limit. The unit is Mb, default: 1.
  • request headerssetting custom request headers, each request sent to the upstream server (upstream) will bring these request headers.
  • The backend response buffercorresponds to the proxy_buffering parameter of Nginx, which is disabled by default. If the backend response buffer is closed, Nginx will immediately send the response content received from the backend to the client; if the backend is enabled Response buffer, then Nignx will put the content returned by the backend into the buffer first, and then return it to the client; and this process is to transmit while receiving, not all received and then transmitted to the client.
  • WebsoketThe WebSocket supported by the gateway is different from the pure WebSocket. It uses the HTTP Upgrade mechanism to upgrade the connection from HTTP to WebSocket on the basis of HTTP. This HTTP Upgrade mechanism adds two custom request headers to the request. They are ‘Upgrade \$http_upgrade’ and ‘Connection “Upgrade”‘, when Websoket is checked, the gateway will automatically add these two request headers for the current policy.

Default Domain Name Mechanism

When the component of the HTTP protocol opens the external access permission of the port, if no access is configured, a default domain name is automatically assigned to it.The default domain name generation strategy is as follows：

  1. {port}.{service-alias}.{team-alias}.{default_domain_suffix}
  2. # eg. http://5000.gr6f1ac7.64q1jlfb.17f4cc.grapps.cn

The default_domain_suffix can be specified by the user or automatically assigned by Rainbond during each cluster installation.

Reference video

Use the domain name to access the component operation reference video: https://www.bilibili.com/video/BV1Wz411q7Rm/

common problem

  • Why can’t I access after the domain name is configured?

    There may be several reasons for the inaccessibility：DNS resolution error; the component is not in normal operation; the component port configuration is inconsistent with the actual listening port; the component is not an HTTP service provided.You can follow the above priorities to troubleshoot faults in sequence.

  • Can the default assigned domain name be modified?

    The domain name assigned by default can be deleted first, and then the suffix assigned by the default domain name can be modified by modifying the cluster properties. The allocation policy does not currently support modification.

  • Whether to support the pan-domain policy

    Yes, the domain name configuration can directly use the generic domain name, such as*.example.com, then no matter accessing a.example.comorb.example.com, it can be routed to the specified component.