云服务器内容精选

  • 单文件描述结构 单文件描述结构样例如下: ├── package.json # 包描述文件(必须) └── specs # 规格总目录(必须) ├── cn_dev_default # cn_dev_default规格目录,可用于描述一个开发用途的服务环境所使用的基础设施 └── cn_product_default # cn_product_default规格目录,可用于描述一个生产用途的服务环境所使用的基础设施 └── meta.yaml # IaC主体描述文件 IaC主体描述文件meta.yaml type: WiseCloud::Environment # 描述环境类型,当前仅支持 WiseCloud::Environment components: # 定义服务环境所包含的组件列表,每个组件包含一个资源列表 - name: environment # 组件名称 resources: # 资源列表 - name: fgc_cloudmap # 资源名称,同类型的资源的名称在整个服务环境中唯一 type: WiseCloud::Endpoint::CloudMap # 资源类型 properties: # 资源属性:具体包含哪些属性,由资源类型决定 ... - name: FGCActionInvokerService resources: ... - name: FGCAbilityCenterService resources: ... applyPipeline: default # 默认选用名为default的组件编排流水线 pipelines: # 定义可用的组件编排流水线 - name: default # 流水线的名称,作为流水线被引用的唯一标识 action: Serial # 串行编排 tasks: # 串行编排的任务列表 - name: apply-environment # 任务名称 action: Apply # 应用变更 component: # 变更组件的相关约束 name: environment # 变更的组件名称 - name: parallel-others action: Parallel # 并行编排 tasks: # 并行编排的任务列表 - name: apply-FGCActionInvokerService # 任务名称 action: Apply # 应用变更 component: # 变更组件的相关约束 name: FGCActionInvokerService # 变更的组件名称 - name: apply-FGCAbilityCenterService # 任务名称 action: Apply # 应用变更 component: # 变更组件的相关约束 name: FGCAbilityCenterService # 变更的组件名称 以上示例清晰地展示了IaC3.0的资源组织结构: Nuwa,CloudMap等资源,依照业务需要,可划分到不同的组件中。 一个组件可对应于一个微服务,或是服务内共享的中间件集合。 全体组件的集合,则汇总描述了整个服务环境的期望部署状态。 组件编排流水线,则是以组件为最小粒度来描述服务环境是如何做部署状态的迁移的。其可以处理组件间的升级依赖关系,以及通过多阶段方式提供灰度升级能力。
  • 多文件描述结构 为了避免诸多资源的描述都集中于meta.yaml,而造成文件内容过长难以管理。通过引入resources.yaml和文件引用语法,可以将单文件结构改造为多文件描述目录结构,样例如下: ├── package.json # 包描述文件(必须) └── specs # 规格总目录(必须) ├── cn_dev_default # cn_dev_default规格目录,可用于描述一个开发用途的服务环境所使用的基础设施 └── cn_product_default # cn_product_default规格目录,可用于描述一个生产用途的服务环境所使用的基础设施 └── meta.yaml └── VirtualAppManangerService ├── config │ └── business_config.yaml │ └── nginx.conf ├── db │ └── schema.sql ├── values.yaml └── resources.yaml
  • 带global的多文件描述结构 Spec包通过不同规格目录来描述同一个服务在不同用途环境下所需的基础设施。但是,同一服务的不同的规格仍然存在大量相同的配置,需要一种机制来完成不同规格间配置的复用。因此,IaC支持放置一个global目录,其与specs目录同级,用于放置被所有规格目录所复用的配置文件。而各具体规格目录,只需包含与 global 目录的增量差异文件即可。 当某个规格被选用于部署时,会先将该规格目录下所有文件与global目录进行合并,得到该规格目录最终的所有配置文件,再进行部署动作。 合并策略:若文件的相对路径相同,则规格目录下的文件保留, global目录下的文件被覆盖,其他文件则共存。 带global的多文件描述结构样例如下: ├── package.json # 包描述文件(必须) ├── global # global目录:放置所有规格目录所复用的配置文件 │ │ │ ├── meta.yaml # IaC 主体描述文件,内容不包含 components │ ├── WiseEyeChaosMonkeyMgrService # 组件一:ChaosMonkey 管理服务,名称需要为该服务下的微服务名称。 │ │ └── resources.yaml # 组件一的资源列表 │ ├── WiseEyeChaosMonkeyPortal # 组件二:ChaosMonkey 网页服务 │ │ └── resources.yaml # 组件二的资源列表 │ ├── environment # 组件三:环境 │ │ └── resources.yaml # 组件三的资源列表 │ └── functions # 组件四:函数 │ ├── resources.yaml # 组件四的资源列表 │ └── values.yaml # 组件四的values.yaml │ └── specs # 规格总目录(必须) ├── cn_dev_default # cn_dev_default 规格目录,一般可用于描述一个开发用途的服务环境所使用的基础设施 └── cn_product_default # cn_product_default 规格目录,一般可用于描述一个生产用途的服务环境所使用的基础设施 └── functions # 与global下functions目录的相对路径一致 └── values.yaml # 用于覆盖global下functions目录的values.yaml
  • 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包典型目录结构。