Shulou(Shulou.com)05/31 Report--

Today, I would like to talk to you about the improvements brought about by the update of Rainbond V5.1.7, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something from this article.

On Sept. 08, 2019, Rainbond released version 5.1.7. This version update brings new services, instance status control and UI visualization, and real-time feedback of service running background events, making it easier for developers to grasp the running status of the service.

Rainbond: the whole process of supporting the development, architecture, delivery and operation and maintenance of enterprise applications, seamlessly connects all kinds of enterprise applications through the "non-intrusive" architecture, and the underlying resources can dock and manage IaaS, virtual machines and physical servers. What is Rainbond?

Release: 5.1.7

Version update: recommended

Update scope: service status control, operation audit records, log push and storage

The service upgrade process is transparent

The key feature of Rainbond is to complete the full cycle from code acquisition to construction and packaging with one click, which is a good experience to pursue. However, the construction process of the code is limited by whether the code is standardized or incorrect, and the rolling launch process still depends on uncertain factors such as whether the service build version can work properly, whether the cluster status is normal or not. In previous versions, users can only focus on a final state but can not easily see the details of this process. How to provide a definite process in many uncertainties to form a good "man-machine" complementarity is a difficult problem. In order to solve this problem without causing too much complexity to our users, we still adhere to the one-click deployment process starting from the source code or image, but distinguish the three stages of visualization experience in UI during the process:

If the build phase service stays on the operation page after the build is triggered, Rainbond will directly pop up the log real-time refresh box to restore the shape of the log displayed on the terminal as much as possible (here is a challenge), so that developers can more clearly and directly judge whether an exception has occurred, and there is no need to take other actions.

After the upgrade phase service is built, it automatically enters the upgrade phase. The UI will show the rolling upgrade process of an instance, which reflects the process of an instance from creation, scheduling, initialization, and startup status. If an exception occurs in any of these links, the user can quickly locate it. At the same time, Rainbond will give suggestions on how to handle the exception in the details. In 90% of the cases, there is still no need for users to learn and understand the complex concepts of Kubernetes.

The service instance in the runtime phase is monitored by Rainbond in real time. Event logs are recorded in detail in case of abnormal exit, OOM or failure of health check. Users can easily query the event log from UI.

Operational audit records (beta)

The modification and operation of each attribute of the service is intuitively important to the life cycle of the service, and it is also a clear expression of responsibility. In this update, we have modified the operation event recording architecture of the service. From the unified adjustment of events recorded by the console in the past to full event recording in the data center The full volume here includes all kinds of attribute modifications, life weekend operations and system maintenance operations and records in the service running state. Unfortunately, the cycle of this release is limited, and the recording of events has not been extended to the application level and tenant level, of course, this is one of our community programs. In future versions, we will speed up the GA process of this feature and fully record the operation records of all resources, which is beneficial for users to implement detailed permission control and audit.

Easier to use log query

Querying the service log is a key way for users to check whether the running service is working properly. We still insist on the experience of real-time push of the service log to the user in the unit of service. The difference is that in this version, we reconstruct the WebSocket implementation of log push to ensure that the log is accurate and timely pushed to the front desk UI. At the same time, the persistence of log storage layer is also more timely (in order to reduce the IO possession of management nodes, log storage adopts the mechanism of delay and batch storage, with a maximum delay of 1 minute. Restore the log style as much as possible in the front-end UI, such as preserving the color and format, which is similar to the log query at the end of the system.

Other feature improvements and BUG fixes

Apply the gateway to increase the legitimacy of the mandatory check policy, enhance the fault tolerance of the gateway, and reduce the frequency of configuration reset. # 321

Fixed BUG # 356 with duplicate compilation commands and parameters generated by Java multi-module code detection

Fixed BUG # 350 where the rbd-monitor module abnormally stopped service discovery for some monitoring targets

Remove a large number of error logs generated by the performance analysis plug-in when analyzing the websocket protocol # 354

Fix BUG that can no longer be collected after the service log exceeds the maximum limit. # 371

Add the ability to set subdirectories when creating services based on source code # 219

Fixed BUG # 225 whose source code address is too long (more than 100 characters) and cannot be set

Fixed BUG # 218 that failed webhook image name verification based on Ali Cloud Image Warehouse

Fixed "application information processing error" exception error # 203 when sharing application

Fix disk detection error # 113 during installation

Fixed a problem with poor compatibility of upgrade scripts with service profiles

Installation

Refer to the Rainbond installation documentation guide

Upgrade requirements and considerations for version upgrade

V5.1.7 supports upgrading from V5.1.2 to V5.1.6. If you have not already upgraded to V5.1.2, refer to the V5.1.x upgrade documentation and upgrade to V5.1.2 first:

Grctl version, for example, version 5.1.6 is shown as follows: Rainbond grctl v5.1.6-release-e98f87c-2019-08-12-01

The upgrade process will restart the management service, so only the cluster of a single management node will temporarily affect the console operation and application access. Please select a reasonable upgrade period.

The upgrade process script needs to obtain node data from the cluster, so be sure to upgrade under normal working conditions of the cluster.

Back up the console and data center databases before upgrading.

The main time-consuming point of the upgrade process is the process of extracting the upgrade package and importing the service image, depending on the write speed of your server.

If you manually adjust the service profile under / opt/rainbond/conf and cause the upgrade to fail, please consult the community.

Download the 5.1.7 update package

The image size of the offline package is about 1.3GB. You need to ensure that the free space of the current cluster disk is at least 2 GB.

# Rainbond component upgrade package wget https://pkg.rainbond.com/offline/5.1/rainbond.images.2019-09-03-5.1.7.tgz-O / grdata/services/offline/rainbond.images.upgrade.5.1.7.tgz# upgrade script package wget https://pkg.rainbond.com/offline/5.1/rainbond-ansible.upgrade.5.1.7.tgz-O / grdata/services/offline/rainbond-ansible.upgrade.5.1.7 The first management node of .tgz executes the following command to upgrade the platform

Once again, the system is running normally before the upgrade, and the upgrade process takes time depending on the disk writing speed of your system. Do not actively terminate the upgrade until the script is successful.

Rm-rf / tmp/rainbond-ansiblerm-rf / grdata/services/offline/upgrademkdir-p / tmp/rainbond-ansibletar xf / grdata/services/offline/rainbond-ansible.upgrade.5.1.7.tgz-C / tmp/rainbond-ansiblecd / tmp/rainbond-ansible/scripts/upgrade/bash. / upgrade.sh platform upgrade verification completed

Execute grctl cluster to make sure that all services and nodes are functioning properly

Grctl version confirms that the version has been upgraded to 5.1.7, and the running component image version is v5.1.7-release

Plug-in upgrade

The performance analysis plug-in has been updated in this version. After the platform has completed the upgrade, upgrade the plug-in as follows:

The upgrade script has automatically updated the plug-in image goodrain.me/tcm

Enter the platform, different teams enter the plug-in management, select the performance analysis plug-in, and click on the build plug-in.

Update the service that uses the current plug-in, and the plug-in will take effect.

After reading the above, do you have any further understanding of the improvements brought about by the Rainbond V5.1.7 update? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.