Lifecycle Management

This document introduces the basic properties of Rainbond components, including component lifecycle, basic operations, etc.

Component Status

After a component is created, it enters its lifecycle, during which it will go through a series of statuses. The following explains each status.Most statuses have a preset timeout period. Regardless of whether it times out, after 3 minutes, all lifecycle operations can be performed on the component again.

Status	Description
Creating	A newly created service component is in the setup phase.
Building	The setup of the newly created service component is complete, and the first version of the service component is being built.The timeout for source code building is 1 hour, and for Dockerfile building is 30 minutes.Timeout does not mean build failure, refer to the build log to understand the current progress.
Scheduling	Once the service component is built, it enters the scheduling status, the instance color turns yellow.This process involves K8s allocating host machines to schedule the instancesIf it remains in this status for a long time, it may be because there are no host nodes available to run the component.
Starting	The service component is starting, the instance color turns yellow.Temporarily inaccessible, starting is divided into two phases, process startup and business startup. If no startup health check is configured, as long as the process startup is completed, it is considered a successful startup.The startup timeout is 40 seconds * number of instances.Startup timeout does not mean startup failure
Waiting to start	The waiting to start status and the starting status will not appear at the same time. Once entering the waiting to start status, the instance color turns yellow.It indicates that other service components on which the current service component depends have not completed startup.The current service component will enter the starting status only after the other service components it depends on have completed startup.
Running	All running instances of the service component are in the running status, the instance color turns green.Normally, service components in the running status can be accessed, but the application may be temporarily inaccessible due to slow business startup
Abnormal operation	If the number of normally running instances of the service component is less than the total number of instances, it indicates abnormal operation, the abnormal instance color turns red.For multi-instance service components, as long as there are normal instances, the service component in an abnormal state can still provide services.Instance abnormalities are mostly due to the service component itself exiting abnormally or exiting due to OOM caused by insufficient memory.The platform will automatically try to restart abnormal instances.You can view the service component logs or use command-line tools to view more application information
Upgrading	The service component is in the process of rolling update, the instance color turns yellow.Service components in this status on multiple nodes can be accessed normally.The upgrade timeout is 3 minutes * number of instances.Upgrade timeout does not mean upgrade failure
Closed	The service component has stopped running, but persistent data still exists.The shutdown timeout is 40 seconds * number of instances.If it remains in the shutting down status for a long time, the instance color turns black, please contact the operation and maintenance colleagues.
Unknown	The instance color turns light blue, the service component is in this status possibly due to network obstruction, failure to obtain the service component status, or backend service abnormality.You can try refreshing the page. If it cannot be resolved, please contact the operation and maintenance colleagues.

Basic Operations

Build Operations

For different types of components, triggering the build operation has different meanings. The following table explains for different types of components:

Component Type	Description
Components built from source code	Pull the latest source code, build the component version according to the pre-identified language type, and perform a rolling upgrade
Components built from Docker images	Re-pull the image from the specified image address, build a new version of the component, and perform a rolling upgrade
Components built from the application market	If there is no updated version in the application market, the build operation will remind the user that no operation is needed. If there are multiple updated versions, the user will be prompted to select the version number that needs to be obtained.Obtain the component media according to the selected version to generate a build version and perform a rolling upgrade

Update Operations

When the running attributes of a component such as dependencies, storage, environment variables, features, health checks, etc., change, the update operation must be manually triggered to apply the latest attribute configuration to the component's running environment. During this update process, the rolling upgrade strategy is used by default to upgrade the component instances.

There are two types of control strategies for rolling upgrades:

• Stateless components: For stateless components, an unordered strategy of starting new versions before stopping old versions is adopted, that is, first start the running instances of the new version, and when they are in a healthy running state, close the running instances of the old version.It should be noted that there will be a situation where multiple versions work at the same time during this process. If your business component cannot tolerate multiple versions working at the same time, please use the restart strategy.

• Stateful components: For stateful components, an orderly stop-then-start strategy is adopted, which means starting from the first instance according to the running instance number, the instance is stopped first and then the new version instance is started.This control is crucial for components like databases, so do not deploy database components as stateless.

Start operation

The start operation will start the last successfully built version of the component. After starting, you can see the detailed operation log of the platform scheduling and processing the component in the Operation Log on the component overview page. When the scheduling is completed, the component enters the startup phase, and you can view the component's startup log on the Logs page.

Stop operation

After triggering the stop operation, all running instances will be stopped, and cluster resources will be released.

Restart operation

After triggering the restart operation, the platform will stop all existing running instances of the component and start them after the stop is completed.If a stop timeout occurs, the restart operation will exit, and the control of the component startup will be handed over to the user.

• Restarting the component does not update the component code or image, which needs to be distinguished from the Build operation.
• Restart operation will interrupt the component

Access operation

For components of different protocols, the command triggered after clicking the access button is also different:

Component protocol	Operation after clicking the access button
HTTP	Open a new browser window to open the default domain name of the component. If multiple domain names are bound, a domain name list will be displayed for the user to choose
TCP	Pop up the access information window