导出非容器包

    适用的场景包括：

    • 交付环境完全离线，导致无法正常安装 Docker 等容器运行时环境。
    • 交付环境安全要求极高，不允许使用容器技术。

    前提要求

    • 导出的组件基于 源码构建 部署。
    • 参考文档，完成 流程，将应用发布到内部组件库。

    在内部组件库中找到已经发布好的应用模板，在 页面中，点击导出 导出非容器包 。导出完成后，即可下载导出的非容器包。

    得到的非容器包，命名格式为 {应用名称}-{应用模板版本号}-slug.tar.gz 。该包可以在任意 Linux 操作系统中解压，解压后的目录结构如下：

    • 应用中包含的服务组件，以目录的形式分割，目录命名格式为组件的名字。
    • 应用目录下，存在以应用名称命名的全局控制脚本。
    • 服务组件目录下，存在单独控制组件的脚本。
    • 服务组件目录下，存在以 {服务组件名}.env 结尾的环境变量配置文件，其中包含自定义环境变量、配置组环境变量、连接信息环境变量以及定义监听端口的变量 PORT。

    管理非容器包

    通过全局控制脚本，可以批量控制应用下所有组件的启动、关闭、状态查询操作。

    • 全局启动
    1. [root@localhost non-docker-demo-0.1-slug]# ./non-docker-demo.sh start
    2. Running app golang with process:  3984 go-demo ...  Done
    4. Running app java-demo with process:  11472 java ...  Done
    • 组件状态查询
    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
    • 启动服务组件
    • 查询服务组件状态
    1. [root@localhost golang]# ./golang.sh status
    2. AppName                        Status                         PID
    • 关闭服务组件

    服务组件的配置依然通过环境变量来进行管理。

    每个服务组件目录中，会包含 {服务组件名}.env 类型的环境变量配置文件，服务组件在启动时会加载其中的变量对自身进行配置。

    {服务组件名}.env 文件会包含以下四种来源的环境变量：

    • 服务组件在发布时，组件自定义的环境变量
    • 服务组件在发布时，配置组中定义的应用级全局配置的环境变量
    • 服务组件之间的连接信息环境变量

    在非容器包启动之前，用户可以自定义 {服务组件名}.env 配置文件来修改服务组件的配置。一种常见的场景是：服务组件在 Rainbond 运行时依赖其他中间件，引用的连接信息环境变量中会包含 MYSQL_HOST=127.0.0.1 这样的配置信息，在非容器包中并不包含 Mysql 服务组件，需要用户手动将 MYSQL_HOST 环境变量的值，修改为当前交付环境中 Mysql 的真实 IP 地址，再启动服务组件。

    日志查询

    相对于在 Rainbond 上运行的应用，非容器包的使用有一些限制，特此在本章节说明。

    非容器包，只会导出应用中所有由 源码构建 功能部署而来的服务组件，来自其他构建源，如 Docker 镜像构建、Helm 创建等方式的服务组件，将无法被导出到非容器包中去。

    非容器包目前支持的源码类型包括： Java-Maven、Java-Gradle、Java-Jar、Java-War、Golang、NodeJS、NodeJS 前端项目(VUE React)、Html静态语言。

    Python 与 PHP 语言，由于其语言特性，需要用户自行处理运行时所依赖的操作系统级的库文件。

    非容器包目录中的每个服务组件目录，都可以单独拆解到其他服务器上运行，如果用户决定这么做，那么请注意配置不同服务之间的访问地址，避免连接不到的情况。