我们需要一个DevOps平台
要讨论DevOps平台的实现模式,似乎就必须讨论它们的概念定义。然而,当大家要讨论它们的定义时,就像在讨论薛定谔的猫。
A公司认为它不过是自动化执行Shell脚本的平台,有些人认为它是一场运动,另一些人认为它是一种文化,还有CTO认为它的本质就是流水线(Pipeline)。
显然不论哪种定义,你无法挑出毛病,但是它们又都无法使所有人都信服。
所以,我总是避免谈DevOps的定义。
那么在DevOps定义不清的情况下,怎么谈它的实现模式呢?
当一个名词的定义不清时,我们应该回归它的目的。 DevOps的目的是改进和缩短系统开发生命周期。DevOps实现该目的的手段是融合开发(Dev)与运维(Ops)。至于怎么融合,大家似乎没有达到一致的看法,毕竟家家有本难念的经。
总之,大家为了实现DevOps,大概率会从以下三个选项进行选择:
1. 自己开发一个DevOps平台;
2. 买一套现成的DevOps平台;
3. 直接使用云上的DevOps SaaS服务。
总之,就是要有一个平台!
DevOps平台的两种模式
由于大家对于DevOps的定义不清,所以,DevOps平台的功能的边界也就很模糊了。
但是,经过我的观察,不论它们使用了什么工具,包含了多少功能,是否包含界面,DevOps平台目前就两种实现模式:
1. 基于命令式的模式;
2. 基于声明式的模式。
命令式的DevOps平台
在手工运维和手工构建的阶段,人们都习惯将运维命令和构建命令一条条记录下来。
当要实现自动化的时候,人们很自然地想到要让DevOps平台自动化一条条命令的执行。
所以,人们在使用命令式的DevOps平台时,都是跟着平台的界面提示,一步步地增加命令(通常也称为命令节点)。最后完成一整条流水线。
命令式的DevOps平台为了让流水线支持更多的工具和命令,通常会通过运维开发人员对DevOps平台的命令节点进行扩展。
命令式DevOps平台,在用户的眼里就是一条条命令的流水线平台。这就好比你想要一台电脑,然后你跟电脑店的老板买了一堆的配件,自己拿回家,然后按照你的想法一个个配件的组装。
如果要在AWS云上部署一套简单的负载+机器,在命令式DevOps平台上的做法通常是:
• 步骤1. 配置并购买负载均衡器;
• 步骤2. 配置并购买机器;
• 步骤3. 配置安全组并绑定到机器上;
• 步骤4. 将机器挂载到负载均衡器中。
当然,命令式DevOps平台也知道当要部署的软件多的时候,用户操作起来很麻烦,所以,命令式DevOps平台也会提供一些模板操作来简化用户的操作。但是,用户通常会报怨模板不够灵活不能满足自己的需求。最终命令式DevOps平台都会实现用户自定义命令模板功能。
目前在国内的DevOps平台基本上就是这种实现模式。
声明式的DevOps平台
声明式的DevOps平台把大问题看出两个子问题:
1. 用户该如何描述他们想要的软件的最终状态;
2. 如何实现这个状态,即具体执行。
命令式DevOps平台同时将这两个问题扔给用户,而声明式的DevOps平台只让用户声明他们想要的最终状态,而具体执行的问题留给平台本身。
这就好比你只需要跟电脑店的老板说明你想到的电脑的配置和预算,电脑店的老板就按照行业里最高效的方式给你组装。
在用户的眼里,只要修改软件的最终状态的描述,声明式的DevOps平台就可以帮他们以最快的方式去实现。
这是命令式与声明式的最大区别。用户在命令式的平台下,通常很难知道整个软件的最终状态。就像你拿到部署文档,上面只告诉你要执行的一条条命令,最终状态是什么样,要等待执行完成才知道。
另一个很大的不同点是幂等性。用户可以在声明式的DevOps平台多次声明他想的最终状态,如果用户期望最终状态与实际状态一致,声明式DevOps平台就不会去执行。
如果要在AWS云上部署一套简单的负载+机器,以下以Terraform为声明式DevOps平台案例(不了解代码的可以跳过):
resource "aws_lb" "default" {name = "example-lb"subnets = aws_subnet.public.*.idsecurity_groups = [aws_security_group.lb.id]
}resource "aws_lb_target_group" "hello_world" {name = "example-target-group"vpc_id = aws_vpc.default.id...
}resource "aws_lb_listener" "hello_world" {load_balancer_arn = aws_lb.default.id...default_action {target_group_arn = aws_lb_target_group.hello_world.idtype = "forward"}
} resource "aws_security_group" "hello_world_task" {name = "example-task-security-group"vpc_id = aws_vpc.default.idingress {...security_groups = [aws_security_group.lb.id]}...
}resource "aws_ecs_cluster" "main" {name = "example-cluster"
}resource "aws_ecs_service" "hello_world" {name = "hello-world-service"cluster = aws_ecs_cluster.main.idtask_definition = aws_ecs_task_definition.hello_world.arn desired_count = var.app_countnetwork_configuration {security_groups = [aws_security_group.hello_world_task.id]subnets = aws_subnet.private.*.id}load_balancer {target_group_arn = aws_lb_target_group.hello_world.id...}depends_on = [aws_lb_listener.hello_world]
}
以上是用户使用HCL语言描述期望的最终软件的状态。具体的执行交给Terraform和云厂商实现。
Terraform会根据HCL的描述决定哪些资源的创建可以并行,哪些已经创建了不需要再创建等。用户不再关心步骤1是先创建负载均衡,还是先创建EC2。
这在行业里另有一个名字:Infrastructure as Code。
的确,IaC是实现声明式DevOps平台的最低成本方式,你不需要另外开发界面。还有大量开源社区(Terraform的生态)工具给你使用,如:InfraCost(云成本diff工具,高级点叫FinOps)、Terratest(对Infra进行测试)等。
值得一提的是,对于多云的支持,命令式的DevOps平台通常需要通过各个云的SDK集成到自己的平台,这个开发成本非常大。
而使用类似Terraform这样的声明式的平台,多云原生就支持。
那么,声明式的DevOps是不是只能选择使用代码来描述软件的最终状态?其实并不是,声明式的DevOps平台也应该可以提供界面进行描述。
最后
作为用户,你倾向于使用哪种模式的DevOps平台呢?为什么?
往期好文推荐:
探讨基础设施即代码所带来的挑战
Kubernetes包管理器Helm的本质