概述

管理技术栈提供了灵活强大的系统和自定义技术栈能力，支持部署系统和任意的自定义技术栈及对已有技术栈的灵活扩展，以满足用户的定制需求。应用管理通过技术栈来管理应用在发布部署时需要安装的软件包以及要执行的部署脚本。目前已经提供了SpringCloud、Dubbo等常用的系统技术栈供用户使用。当然用户也可以通过自定义技术栈来定制更多个性化的需求。

本文档将以创建 STATIC_RESOURCE 技术栈为例，介绍如何自定义技术栈。

您可以在 技术栈管理 页面进行以下操作：

• 创建技术栈
• 发布技术栈
• 编辑技术栈
• 克隆技术栈
• 废弃技术栈
• 查看技术栈列表
• 查看技术栈详情

内置技术栈

MSAP提供了多达20多种的系统技术栈，按类型区分可以分为编程语言和中间件，其中编程语言又分为Java技术栈类型和非Java的技术栈类型，内置的系统技术栈不能修改，可以直接使用。

系统为用户提供了以下系统技术栈：

系统技术栈版本名称	技术栈类型	部署方式
1.0.0-j180-jar	SPRING_CLOUD	Ecs部署、容器部署
1.0.0-j180t818-war	SPRING_CLOUD	Ecs部署、容器部署
1.0.0-j180-jar	DUBBO	Ecs部署、容器部署
1.0.0-j180t818-war	DUBBO	Ecs部署、容器部署
1.24.0-static-resource-tar	STATIC_RESOURCE	Ecs部署
1.0.0-static-resource-image	STATIC_RESOURCE	容器部署
1.0.0-j180t704-jar	TONGWEB	容器部署
1.0.0-j180t704-war	TONGWEB	容器部署
1.0.0-php-image	PHP	容器部署
1.0.0-rocketMq-image	ROCKET_MQ	容器部署
1.0.0-postgreSql-image	POSTGRE_SQL	容器部署
1.0.0-zookeeper-image	ZOOKEEPER	容器部署
1.0.0-mongoDb-image	MONGO_DB	容器部署
1.0.0-nginx-image	NGINX	容器部署
1.0.0-nodeJs-image	NODE_JS	容器部署
1.0.0-mysql-image	MYSQL	容器部署
1.0.0-redis-image	REDIS	容器部署
1.0.0-kafka-image	KAFKA	容器部署
1.0.0-oracle-image	ORACLE	容器部署
1.0.0-hadoop-image	HADOOP	容器部署
1.0.0-springBoot-image	SPRING_BOOT	容器部署
1.0.0-tomcat-image	TOMCAT	容器部署
1.0.0-python-image	PYTHON_RUNTIME	容器部署
1.0.0-go-image	GO	容器部署
1.0.0-c-image	C	容器部署
1.0.0-c++-image	C++	容器部署
1.0.0-c#-image	C#	容器部署

自定义技术栈

概述

系统默认提供 SPRING_CLOUD、DUBBO、STATIC_RESOURCE、TONGWEB技术栈。如果面临比较紧急的业务需求，或默认技术栈无法满足特定场景下的业务需求，则可以制作自定义技术栈来解决上述问题。

创建技术栈

1. 登录微服务云应用控制台，选择“应用管理 > 技术栈管理”。
2. 点击“创建技术栈”。
3. 在弹出的新增技术栈框中，设置技术栈信息。

• “技术栈类型”：下拉选择系统支持的技术栈类型。
• “技术栈版本”：技术栈版本命名规范：[技术栈的版本]-[依赖包版本][依赖包版本]，例：1.0.7-j180t2.1.0 (技术栈的版本1.0.7-依赖包版本j180依赖包版本t2.1.0)，版本号长度不能低于3个字符，不能超过30个字符。
• “支持操作系统”：下拉选择系统支持的ctyunos-2.0.1,centos-7两种操作系统。
• “来源”：默认都是自定义。
• “部署方式”：提供容器实例部署、Ecs实例部署、Ecs和容器实例部署，如果选择容器部署，只需填写镜像信息、如果选择Ecs实例部署，只需上传技术栈包(目前技术栈包只支持tar后缀类型文件)，如果选择Ecs和容器实例部署，则技术栈包和镜像信息都需要填写。
• “应用性能监控”：默认关闭，开启表示支持接入应用性能监控能力，在创建应用实例时如果订购了应用性能监控产品，则可以勾选开启应用性能监控。
• “微服务治理中心”：默认关闭，开启表示支持接入微服务治理能力，在创建应用实例时如果订购了微服务治理产品，则可以勾选开启微服务治理治理。
• “技术栈包”：上传技术栈压缩包。关于如何制作技术栈包，请参考技术栈使用指南，目前仅支持tar格式的文件。
• "ECS 实例部署环境变量”：支持Ecs实例部署选择技术栈版本时继承自该技术栈版本的环境变量。
  
• “镜像类型”：自购镜像表示用户购买的镜像，MSAP仓库镜像表示微服务云应用平台提供的系统公共镜像。
• “MSAP仓库镜像”：包括镜像名称、命名空间、类型、版本、Dockfile信息。
  

4. 单击“确定”，完成自定义技术栈创建。

说明
创建成功的技术栈处于未发布状态。

编辑技术栈

前提条件

已创建的自定义技术栈且状态为未发布的才能编辑。

1. 登录微服务云应用控制台，选择“应用管理 > 技术栈管理”。
2. 选择具体的技术栈类型，右侧点击“编辑”。
3. 在弹出的编辑技术栈框中，修改技术栈信息。
   

• “技术栈类型”：新增之后不能修改。
• “技术栈版本”：技术栈版本命名规范：[技术栈的版本]-[依赖包版本][依赖包版本]，例：1.0.7-j180t2.1.0 (技术栈的版本1.0.7-依赖包版本j180依赖包版本t2.1.0)，版本号长度不能低于3个字符，不能超过30个字符。
• “支持操作系统”：新增之后不能修改。
• “来源”：自定义，不能修改。
• 部署方式、技术栈包、镜像信息都可以修改。

发布技术栈

前提条件

未发布的自定义技术栈才能发布。

1. 进入微服务云应用控制台，单击左侧导航栏中的 技术栈管理，进入技术栈管理页面。
2. 在技术栈管理页面中，单击未发布状态的技术栈实例右侧的“发布“。
3. 在弹出框中，单击确定,发布成功的技术栈处于已发布状态。

克隆技术栈

1. 进入微服务云应用控制台，单击左侧导航栏中的 技术栈管理，进入技术栈管理页面。
2. 在技术栈管理页面中，单击未发布状态的技术栈实例右侧的“克隆“。
3. 在弹出框中单击确定，克隆成功的技术栈处于未发布状态。

废弃技术栈

前提条件

自定义技术栈为未发布、已发布状态的才能废弃，如果该技术栈版本下有已发布的应用实例，则不允许废弃。

1. 进入微服务云应用控制台，单击左侧导航栏中的 技术栈管理，进入技术栈管理页面。
2. 在技术栈管理页面中，单击发布状态的技术栈实例右侧的“废弃“
3. 在弹出框中单击确定，发布成功的技术栈处于已废弃状态。

删除技术栈

前提条件

只有已废弃的技术栈才能被删除。

1. 进入微服务云应用控制台，单击左侧导航栏中的 技术栈管理，进入技术栈管理页面。
2. 在技术栈管理页面中，单击发布状态的技术栈实例右侧的 “删除“。
3. 在弹出框中单击确定。

技术栈详情

1. 进入微服务云应用控制台，单击左侧导航栏中的技术栈管理，进入技术栈管理页面。
2. 在技术栈管理页面中，单击技术栈版本名称，

进入技术栈实例详情的只读页面，查看具体信息。

自定义技术栈使用指南

概述

在代码开发阶段，开发人员在开发环境中，通过特定的开发框架及特定的配置，完成了对预期功能的实现。在生产环境中，为了实现高效、低成本、更安全的部署，一般可以选择将应用部署到云端。云端通过技术栈为应用提供框架和 runtime 等运行环境支持，包括提供运行所需的脚本并且安装 JDK、Nginx 环境依赖等。

1. 什么是技术栈
   在微服务云应用平台上，技术栈 指一个应用程序所依赖的全部框架及附属资源的集合，它定义了应用发布部署和运维时的依赖信息，主要包括下述内容。

   1. 操作系统和版本。
   2. 开发框架类型和版本。
   3. 应用启动和部署脚本。
   4. 环境参数。

2. 技术栈命名规则
   发布应用时，一旦选定技术栈架构，则不可再更改，但可更新该架构下的技术栈版本号以获取最新功能。每个技术栈架构都有对应的技术栈，随着功能迭代和需求变更，该技术栈产生了各种不同的版本。以技术栈 发 1.0.0-j180-jar 为例，对 SOFABoot 技术栈的命名规则说明如下：

   1. 1.0.0：指技术栈的版本。
   2. j180：指 JDK 版本 1.8.0。
   3. jar：指支持jar包启动。

3. 技术栈目录结构
   这里以自定义静态资源技术栈为例说明静态资源技术栈static_resource目录包含以下子文件夹：

   1. lifecycle：存放生命周期代码。理论上您可以使用任何语言来编写这些生命周期脚本。
      这里我们规定必须使用shell脚本来作为生命周期启动命令，提供了以下生命周期脚本。
      1. publish.sh：技术栈依赖的安装脚本，同时部署应用程序，主要代码逻辑为读取 resources 目录下的文件，解压、安装、配置环境变量等，在脚本和环境配置好后启动部署用户应用程序。
      2. stop.sh：停止用户应用程序。
      3. start.sh：启动用户应用程序。
      4. rollback.sh: 回滚用户应用程序。
      5. delete.sh: 删除用户应用程序，并且清理技术栈的配置与脚本。
      6. checkService.sh：检测应用是否启动。
   2. resources：存放技术栈的依赖、生命周期代码的依赖等。如果您的技术栈足够简单，无需任何依赖，resources 文件夹可以为空。

4. 技术栈制品包统一存放路径

   制品包路径是系统指定用户上传的程序制品包存放目录，用户在制作技术栈包时需要知道运行程序包所在路径，这里系统指定了统一存放路径，即在当前脚本运行祖父目录同级的/tarTemp/app/实例uuid。
   用户可以拷贝该目录下所有文件到工作目录下运行。

   current_dir=$(pwd)  //当前工作目录的绝对路径
   parent_dir=$(dirname "$current_dir")  //获取父目录路径
   p_parent_dir=$(dirname "$parent_dir")  //当前目录的祖父目录
   package_dir="${p_parent_dir//temp/tarTemp}"  //替换祖父目录temp为/tarTemp 得到最终制品包目录./tarTemp/app/
   

示例

默认提供的系统静态资源技术栈包的文件结构如下：
static_resource

• lifecycle //生命周期代码
  • publish.sh
  • stop.sh
  • start.sh
  • rollback.sh
  • delete.sh
  • checkService.sh
  • ac_start.py
  • ac_setup.py
  • ac_shutdown.py
  • ac_deploy.py
  • clear_nginx.py
  • ac_check_service.py
• resources //技术栈和生命周期代码的依赖
  • ctyunos-2.0 //该技术栈在ctyunos-2.0 操作系统上的依赖
    • nginx-1.24.0.tar.gz //技术栈依赖的nginx安装包版本
  • nginx_back.conf //nginx配置文件
  • util.sh
  • util.py
  • stopApp.sh
  • startApp.sh
  • deploy.sh
  • nginx.sh

制作技术栈压缩包

技术栈打包的操作步骤如下：

1. 创建 技术栈目录结构。

2. 在目录下创建技术栈生命周期脚本和相关依赖。

3. 将目录下所有脚本和相关依赖压缩成 .tgz 文件，生成技术栈包。在以下示例中，假定技术栈目录名为 static_resource

   cd static_resource
   tar -cvf staticResource.tar ./*