terraform篇01:基础设施即代码,初识terraform,用代码减少沟通成本

原创 吴就业 160 0 2023-07-15

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/ffd207abb1334bd783eace6e8968efad

作者:吴就业
链接:https://wujiuye.com/article/ffd207abb1334bd783eace6e8968efad
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

通常申请基础设施,我们需要向运维描述我们需要什么基础设施、什么规格,运维根据我们的描述去检查是否已经申请过这样的资源,有就会直接给我们使用基础设施的信息,没有再帮我们申请,然后告诉我们使用基础设施的信息,例如mysql的jdbc和用户名、密码。

如果将描述代码化,基础设施的申请自动化,就能实现“基础设施即代码”。而terraform就是实现“将描述代码化”的工具软件。

将描述代码化

回忆我们部署一个中间件的步骤,少不了需要跟运维沟通申请云资源。以往我们部署网关都是使用虚拟机部署,最先要做的事情就是需要申请几台一样规格的虚拟机,假设我们使用的基础设施资源提供商是AWS,我们需要这样跟运维描述:“申请两台规格为m5.large(2核8G)的EC2实例”,运维同事则根据描述去帮我们申请EC2实例,申请完后告诉我们虚拟机的内网ip地址。

terraform要做的事情就是让我们能够用代码的方式去描述“申请两台规格为m5.large的EC2实例,并告诉我ip地址”,并且不需要找运维沟通,就能自动的根据代码描述去申请资源。而这个事情也能够通过代码记录一下。

让我们用HCL语言描述这一需求。为了便于理解,简化一下需求,假设只需要申请一台规格为m5.large的EC2实例:

resource "aws_instance" "ec2instance" {
  instance_type = "m5.large"
}

output "ip" {
  value = aws_instance.ec2instance.ip
}

当然,实际申请一台ec2实例需要填非常多的参数,而这里为了便于入门理解,假设申请一台ec2实例只需要传规则,即instance_type。

现在我们来解读一下这几行代码。

一、资源的描述:

resource "aws_instance" "ec2instance" {
  instance_type = "m5.large"
}

通过resource声明需要申请一个资源,接着“aws_instance”为资源的类型,“ec2instance”则是我们自己为这个资源定义的一个变量名,这个名字只在当前hcl代码中使用。{}里面是描述资源,例如instance_type= "m5.large"就是描述资源的规则为m5.large。

二、输出的描述:

output "ip" {
  value = aws_instance.ec2instance.ip
}

通过output声明输出变量,接着“ip”是输出的变量名,{}里面声明value,value = aws_instance.ec2instance.ip指变量的值来源于资源aws_instance.ec2instance的ip字段。引用一个资源需要通过“资源类型.资源名称”引用。

Terraform介绍

Terraform是用于实现基础设施即代码的工具软件。它将基础设施抽象成资源,并提供自定义的HCL语言,用于描述期望申请的资源,terraform既是HCL语言的编译器,同时也提供插件化的能力为各云厂商提供接入的扩展插件,核心引擎实现根据HCL的代码描述,通过gRPC调用插件去申请/更新/删除资源。

Terraform插件的底层逻辑就是通过调用云产商的基础设施API,实现资源的增删改查。

terraform架构图

上图为官方的terraform工作原理图。图中Terraform Core就是terraform cli工具,包括terraform核心引擎。假设图中的Target Apis就是我们的私有云/混合云;那么CLIENT LIBRARY就是私有云平台提供给用户用于操作IaC资源的HTTP接口的封装,即私有云SDK。PLUGINS就是插件能力集合,每个插件就是一个PROVIDER,我们需要为私有云/混合云开发我们自己的PROVIDER。

Terraform还提供状态持久化,实现类似k8s的控制器调协能力。对于已经申请过的资源,先对比输入参数是否有改变,以及查询资源的输出是否有改变,调协资源达到期望状态。但开源版的terraform并不具备k8s的自动监听调协资源的能力,需要人为的执行apply命令,或者实现定时任务定期去apply。

Terraofrm的核心概念: - Resource:基础设施资源的管理,定义具体资源的属性。 - DataSource:基础设施资源的查询。

#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

KubeVela篇01:部署即代码-编写yaml在KubeVela上交付第一个应用

“部署即代码”即用代码描述一个应用的部署计划。KubeVela就是实现这一目标的平台,让我们可以编写一个符合OAM模型的yaml来描述应用的部署。

terraform篇03:terraform provider开发避坑指南

Go sdk本地开发调试sdk依赖问题;关于复杂嵌套结构体的schema声明;状态死循环监听,以及terraform命令终止时如何终止死循环;资源创建接口的默认可选字段不填遇到的坑;HCL代码输入变量的复杂校验。

terraform篇02:为私有云开发一个terraform provider

很多企业内部为了不与云厂商绑定,避免上云容易下云难的尴尬,以及企业内部可能也会做私有云,或者封装一个混合云平台,因此不能直接用云厂商提供的provider。

Operator实战4:如何获取已经被删除的pod的日记

在Job场景,如果Job达到backoffLimit还是失败,而且backoffLimit值很小,很快就重试完,没能及时的获取到容器的日记。而达到backoffLimit后,job的controller会把pod删掉,这种情况就没办法获取pod的日记了,导致无法得知job执行失败的真正原因,只能看到job给的错误:"Job has reached the specified backoff limit"。

Operator实战3:Operator开发过程遇到的问题

kubebuilder使用helm代替kustomize;代码改了但似乎没生效-镜像拉取问题; 使用ConfigMap替代Apollo配置中心的最少改动方案;环境变量的注入以及传递;Kubebuilder单测跑不起来;Helm chart和finalizer特性冲突问题。

Operator实战2:实现webhook修改Job的最大重试次数

terraform-controller默认Job会一直重试,导致重复申请资源。