云服务器内容精选

  • global与specs的协同关系 global文件夹:放置被所有规格目录所复用的配置文件。 global文件夹里面的微服务都可以被规格文件夹specs中的代码复用(可根据meta.yaml指定复用哪些微服务,取决于你在相应环境的部署规划)。 global文件夹的作用类似于Java中的父类,spec类似于继承了global的子类,实际部署时还是使用的specs中的文件,但specs中的文件可以继承和复用global文件。 meta.yaml:描述变更的组件与过程。 {microservice}:描述要变更的微服务。 resources.yaml:微服务变更的主体文件,其他所有的values.yaml、config文件夹中的yaml等文件都围绕此文件展开。文件名必须为resources.yaml。 其他文件:为变量配置文件,其定义的内容都会被resources.yaml引用,文件名称可自定义。 spec文件夹:同一个服务在不同用途环境下所需配置文件(基础设施)。这个文件目录是必须的。 specs是在环境上部署服务时,最终使用的配置文件,当部署服务时,第一关注点和入口就是specs。 specs目录下的规格文件夹,命名采用站点级Cloud Map的名称(cn_product_cbu、eu_product_cbu)。可以在环境管理界面查看可选的站点级Cloud Map名称列表。 当某个规格被选用于部署时,会先将该规格目录下所有文件与global目录进行合并,得到该规格目录最终的所有配置文件,再进行部署动作。
  • 目录结构介绍 表1 IaC Spec包结构说明 位置 类型 个数 描述 iacspec_{service}_{version}.zip 文件 1 IaC压缩包。 └── package.json 文件 1 包描述文件,相关说明请参见包描述文件介绍。 └── global/ 文件夹 1 全局默认的IaC描述,包含完整文件结构,放置被所有规格目录所复用的配置文件。 │ └── meta.yaml 文件 1 变更策略描述,相关说明请参见在IaC代码中定义流水线。 │ └── environment/ 文件夹 1 定义component1,公共资源。 │ └── resources.yaml 文件 1 公共资源列表,相关说明请参见在IaC代码中声明资源。 │ └── values.yaml 文件 1 公共资源参数值,在resources.yaml中通过$ref的方式来引用。 │ └── {microservice}/ 文件夹 0-N 定义component2,微服务资源。 │ └── resources.yaml 文件 1 微服务资源列表,相关说明请参见在IaC代码中声明资源。 │ └── values.yaml 文件 1 微服务资源参数值,在resources.yaml中通过$ref的方式来引用。 │ └── configs/ 文件夹 1 微服务配置目录。 │ └── config_schema.yaml 文件 1 声明微服务的业务配置项属性,敏感业务配置项需要声明,非敏感配置项可以不声明。在resources.yaml中通过$ref的方式来引用。 │ └── {cluster}_config_records.yaml 文件 0-N 微服务的业务配置项,在resources.yaml中通过$ref的方式来引用。 └── specs/ 文件夹 1 环境特定的IaC描述,结构与global相同,但仅包含与global有差异的文件。 │ └── cn_product_cbu/ 文件夹 1 中国区生产环境,命名采用站点级Cloud Map的名称,可以在环境管理界面查看可选的站点级Cloud Map名称列表。 │ └── environment/ 文件夹 0-1 环境公共资源。 │ └── values.yaml 文件 0-1 公共资源参数值。 │ └── {microservice}/ 文件夹 0-N 微服务资源。 │ └── values.yaml 文件 0-1 微服务资源参数值。 │ └── configs/ 文件夹 0-1 微服务配置目录。 │ └── {cluster}_config_records.yaml 文件 0-N 微服务的业务配置项。 │ └── aaa_product_cbu/ 文件夹 1 亚非拉生产环境。 │ └── eu_product_cbu/ 文件夹 1 欧洲生产环境。
  • IaC代码开发介绍 在一次完整的业务变更中,往往会涵盖多种类型、多个模块的变更,如集群扩容、申请ELB、创建数据库、软件升级等等。在IaC的语境下,每一个变更本质上都是IaC资源的变更。在一次完整的业务变更中,部分资源的变更依赖于其他资源的变更,如为一个微服务创建NUWA实例之前往往需要先创建该微服务的数据库。 通过IaC代码对各资源在具体变更过程中的依赖关系、先后顺序进行代码化描述。本质上就是描述各模块、各资源之间的依赖关系。在变更过程中,IaC将根据由依赖关系生成的有向无环图顺序执行各资源的变更过程。 IaC代码开发主要围绕声明资源和变更流程编排两个方面展开。 在IaC代码中声明资源 定义component:定义component是IaC将一个环境的资源组织起来的方式,将同一类资源组织起来成为一个component。 定义资源:一个component下可以定义多个资源,所有的资源描述都存放于resources.yaml中。 在IaC代码中定义流水线 component间的编排在spec包中的meta.yaml文件中描述,用户可以根据自己的需求定义整个环境在变更时的执行过程。
  • IaC简介 基础设施即代码(Infrastructure as Code,简称IaC)是一种以YAML作为输入,经由云原生环境管理服务、IaC执行引擎、Operator平台解析和执行,实现环境自动部署以及管理动态基础设施的方法。它强调一致,可重复的供给和变更系统及其配置。当代码发生变更后,可以进行自动化测试,测试完成后可自动化的应用变更到运行系统中。使用基础设施即代码的方法,可以使用敏捷工程的优秀实践(如测试驱动开发,持续集成,持续发布)来更加快速安全的变更基础设施。
  • IaC代码结构介绍 IaC代码支持单文件描述结构、多文件描述结构以及带global的多文件描述结构,具体介绍请参见IaC代码结构介绍。 单文件描述结构:在IaC主体描述文件meta.yaml中进行变更流程编排同时定义所有资源。 多文件描述结构:通过引入resources.yaml和文件引用语法,将单文件结构改造为多文件描述目录结构,避免诸多资源的描述都集中于meta.yaml,而造成文件内容过长难以管理。 带global的多文件描述结构:为解决不同规格目录间配置复用问题,IaC3.0支持带global的多文件描述结构。 带global的多文件描述结构为IaC3.0的典型目录结构,IaC Spec目录结构请参见IaC Spec包典型目录结构。