Export non-container package

Scenario

Rainbond provides an application template export mechanism to solve application delivery problems.However, the previous application templates cannot be exempted from the requirements of the container running environment.Application templates extend the ability to export non-container packages and are specifically designed to address application delivery in scenarios where the final delivery environment does not have a container running environment.

Applicable scenarios include:

  • The delivery environment is completely offline, resulting in the failure to properly install Docker and other container runtime environments.
  • The delivery environment has high security requirements and does not allow container technology.

Requirements

  • The version of Rainbond is at least v5.10.0-Release.
  • The exported components are deployed based on source build.
  • Refer to the documentation to complete the application release and publish the application to the internal component library.

Export non-container package

Locate the published application template in the internal component library. On the Export page, click Export Export Non-container Packages.After the export is complete, you can download the exported non-container package.

The resulting non-container package is named in the format of {application name}-{aplication template version}-slug.tar.gz.The package can be decompressed in any Linux operating system, and the directory structure is as follows:

  1. non-docker-demo-0.1-slug
  2. ├── golang
  3. │   ├── golang.env
  4. │   ├── golang.sh
  5. │   └── golang-slug.tgz
  6. ├── java-demo
  7. │   ├── java-demo.env
  8. │   ├── java-demo.sh
  9. │   └── java-demo-slug.tgz
  10. └── non-docker-demo.sh
  • The service components contained in an application are divided into directories. The directory name format is the component name.
  • A global control script named application name.sh exists in the application directory.
  • In the service component directory, scripts that control components separately exist.
  • In the service component directory, there is an environment variable configuration file ending with {component name}.env,This includes custom environment variables, configuration group environment variables, connection information environment variables, and the variable PORT that defines the listening port.

Manage non-container packages

The global control script allows you to start, stop, and query the status of all components in an application.

  • Application start
  1. [root@localhost non-docker-demo-0.1-slug]# ./non-docker-demo.sh start
  2. Running app golang with process:  3984 go-demo ...  Done
  3. The environment variable $MEMORY_SIZE was not identified,The Java process will not be optimized....
  4. Running app java-demo with process:  11472 java ...  Done
  • Application status
  1. [root@localhost non-docker-demo-0.1-slug]# ./non-docker-demo.sh status
  2. AppName                        Status                         PID
  3. golang                         Active(Running)                3984
  4. java-demo                      Active(Running)                11472
  • Application stop
  1. [root@localhost non-docker-demo-0.1-slug]# ./non-docker-demo.sh stop
  2. Stopping app golang which running with pid 3984 ...  Done
  3. Stopping app java-demo which running with pid 11472 ...  Done

The control scripts in each service component folder allow you to manage the startup, shutdown, and status query operations of a single service component.

  • Component start
  1. [root@localhost golang]# ./golang.sh start
  2. Handling runtime environment ...  Done
  3. Handling custom environment ...  Done
  4. Running app golang, you can check the logs in file golang.log
  5. We will start your app with ==> go-demo
  6. Running app golang with process: 24033 go-demo ...  Done
  • Component status
  1. [root@localhost golang]# ./golang.sh status
  2. AppName                        Status                         PID
  3. golang                         Active(Running)                24033
  • Component stop
  1. [root@localhost golang]# ./golang.sh stop
  2. Stopping app golang which running with pid 24033 ...  Done

Configuration

The configuration of service components is still managed through environment variables.

Each component directory contains an environment variable configuration file of type {component name}.env, which the service component loads when it starts to configure itself.

{component name}.env contains environment variables from the following four sources:

  • When a service component is released, the component customizes the environment variable
  • The environment variables for the application-level global configuration defined in the configuration group when the service component is released
  • Connectivity information environment variables between service components
  • An environment variable used specifically to declare port information $PORT

Before the non-container package is started, users can customize the {component name}.env configuration file to modify the service component configuration.A common scenario is:Service components rely on other middleware when Rainbond is running. The referenced connection information environment variable contains configuration information such as MYSQL_HOST=127.0.0.1. The non-container package does not contain Mysql service components. You need to manually change the value of the MYSQL_HOST environment variable to the real IP address of Mysql in the current delivery environment and then start the service component.

Log

Once a component is started, its logs are output to the {component name}.log file in the component directory.

Pay attention

There are some restrictions on the use of non-container packages relative to applications running on Rainbond, which are explained in this section.

Component build Source

A non-container package will only export all the components in the application that are deployed from the source build feature.Components from other build sources, such as Docker image build, Helm creation, etc., will not be exported to non-container packages.

Non-container packages currently support the following source types:Java-Maven、Java-Gradle、Java-Jar、Java-War、Golang、NodeJS、NodeJS Static(VUE React)、Html static.

Python and PHP, due to their language characteristics, require users to process the operating system level library files on which the runtime depends.

Port conflicts

Components in non-container packages directly occupy server ports during startup. Therefore, the listening ports of service components must not conflict.It is recommended that the PORT that the component listens on at runtime be defined as the environment variable PORT, so that the configuration can be modified in the {component name}.env file.

Split

Each component directory in the non-container package directory can be unpacked and run separately on other servers. If users decide to do so, be careful to configure access addresses between different services to avoid missing connections.