IaC

关于 IaC IaC 的历史 2000 年之后，随着 IT 技术发展，用户的需求越来越复杂，软件系统以及基础设施也变的越来越复杂。最早的运维都是手工式的，面临着几个问题： 交互式变更所引入的人的因素太大，导致了变更的不可控性 基础设施变化越来越快，手工操作成本高且效率低 交互式变更难以管控，且无法实现版本控制 IaC 就是在这个时期出现的想要解决这些问题的概念，维基百科定义的 IaC 指通过 machine-readable 的定义文件，而不是物理硬件配置或交互式配置工具来管理和配置计算机数据中心的过程。该过程管理的 IT 基础设施包括物理设备（如 Bare-metal 或 VM），以及相关的配置资源。定义文件可能在版本控制系统 VCS 中，文件中代码可能使用脚本或者声明式定义，但IaC 通常使用声明式方法管理基础设施。 IaC 有几个核心特征： 最终产物为 machine-readable 的文件，可以是脚本、声明式代码或者配置文件。 基于最终产物，可以利用 VCS（Git、SVN） 实现版本管理。 利用 CI/CD 系统（如 Jenkins、GitLab CI）实现持续集成/持续交付。 基于同样的定义文件，最终表现出来的行为是一致且幂等的。 这个时期出现了一些 IaC 工具，典型的如 Puppet、Chef、Ansible，实际上这些工具，可能设计上各有所取舍（比如 Pull/Push 模型的取舍），但是其核心的特征不会变化： 框架内部提供了常见的比如 SSH 链接管理，多机并行执行，auto retry 等功能。 基于上面描述的这一套基础功能，提供了一套 DSL 封装。让开发者更专注于 IaC 的逻辑，而非基础层面的细节。 其开源开放，并形成了一套完善的插件机制。社区可以基于这一套提供更丰富的生态。比如 SDN 社区基于 Ansible 提供了各种交换机的 playbook；Ansible 官方提供的 AWS playbook 等。 云上资源编排 2006 年 8 月 Amazon 正式发布了 EC2 服务，从这时整个基础设施开始快步向 Cloud 时代迈进。截止目前，各家云厂商提供了各种各样的服务，经过十多年的演进，诞生出了诸如 IaaS，PaaS，DaaS，FaaS 等等各种各样的服务模式。这些服务模式，让我们的基础设施的构建，变得更加的简单，更加的快速。但是这些服务模式，也带来了一些问题：...

简介 Upjet 是一个代码生成框架，支持开发者构建用于生成 Crossplane 控制器的代码生成管道。Upiet主要由三部分组成: 构建代码生成器管道的框架。 所有自动生成 CRD 使用的通用 Reconciler 实现 为所有自动生成 CRD 提取文档的工具。 相关名词: MR: Managed Resource， Crossplane 管理的托管资源 CR: Custom Resource，自定义资源，Kubernetes API的扩展 CRD: Custom Resource Definition: 自定义资源定义。 资源配置 Upjet 使用 Terraform Resource Schema 中的信息尽可能多的生成 Provider 中的相关信息，包括符合XRM 模式的 Resource SchemaController 逻辑、延迟加载、敏感数据处理等。然后仍然有一些信息，需要通过查阅 Terraform 文档后手动输入配置: 外部名称 | External Name 跨资源引用 | Cross Resource Referencing 敏感字段及自定义连接详情 | AdditionalSensitive Fields and Custom Connection Details 延迟初始化行为 | Late lnitialization Behavior 覆盖 | Terraform Resource Schema 初始化器 | Initializers 外部名称 External Name 简介 Crossplane 使⽤ Managed Resource 中的 Annotation 来识别 Crossplane 管理的外部资源， Annotation key 为crossplane....

简介 Pulumi 是一个基础设施即代码（IaC，Infrastructure as Code）平台，支持使用如 Go、Java、Python、JavaScript、C# 等常见编程语言及相关工具，以实现云基础设施的构建、部署和管理。 使用及基本结构 基本概念 Project：包含 Pulumi.yaml 配置文件的目录。可以通过 pulumi new 使用各个语言的模板创建新的 project。 Stack：每个 Pulumi 程序都部署到一个 Stack。Stack 是 Pulumi 程序的一个相互隔离、可独立配置的实例，Stack 通常用于表示不同的开发阶段（如 dev、staging、production）或功能分支（如 feature-x-dev）。一个 Project 下可以有多个 Stack，当使用 pulumi new 创建 project 时，默认会创建一个 dev Stack。 Program：Project 中包含的资源编排代码以及运行程序的元数据信息。在 project 目录中执行pulumi up命令，pulumi 会创建一个隔离、可配置的 stack 实例，Stack 类似在测试和线上应用程序使用的不同部署环境。 示例 安装 pulumi 插件 brew install pulumi/tap/pulumi 初始化 project，第一次使用会要求登陆 Pulumi Cloud（状态等元数据默认存储在 Pulumi Cloud） mkdir pulumi-example && cd pulumi-example pulumi new go 执行完成后，pulumi 会创建一个 pulumi-example project，同时默认创建一个名为 dev的 stack。...

简介 Crossplane 是一种开源 Kubernetes 扩展，可将 Kubernetes 集群转换为通用控制平面。借助 Crossplane，平台团队可以利用 Kubernetes 策略、命名空间、基于角色的访问控制等的全部功能创建新的抽象和自定义 API， Crossplane 将所有非 Kubernetes 资源集中管理。 控制平面创建和管理资源的生命周期。控制平面不断检查预期资源是否存在，当预期状态与现实不符时报告并采取行动纠正错误。Crossplane 将 Kubernetes 控制平面扩展为通用控制平面，可以在任何地方检查、报告和处理任何资源。 基本概念 Package：OCI 镜像标准的包，包含 Provider CRDs、Provider 镜像、ServiceAccount 权限等信息。 Provider：云提供商插件，由一组 CRD 和 Controller 组成，CRD 定义了资源信息，Controller 通过 SDK 连接外部云服务，根据资源字段变更，执行相关操作。 Managed Resource：Provider 内部 CRD 定义的资源，创建并由 Crossplane 托管之后，称为 Managed Resource。 Compositions：Managed Resource 集合的模板，用于需要多个资源组合使用的场景，类似 Terraform Module。如 ECS + VPC + EBS。 Composite Resource（XR）：使用 Composition 模板创建的一组 Managed Resource。 Claims：开发人员与 Crossplane 交互的主要方式，开发人员通过 Claim 声明由 SRE 团队定义的 XRD 中的自定义字段值，最终在 XR 定义中引用。 和 Terraform 对比，XRD 比较类似 Terraform Module 中的 variables块；Composition 是模块的 HCL 代码的其余部分，它描述了如何使用这些变量来创建一堆资源；XR 和 Claim 类似为模块提供输入的 tfvars 文件。...