DevOps平台两种实现模式

我们需要一个DevOps平台

要讨论DevOps平台的实现模式，似乎就必须讨论它们的概念定义。然而，当大家要讨论它们的定义时，就像在讨论薛定谔的猫。

A公司认为它不过是自动化执行Shell脚本的平台，有些人认为它是一场运动，另一些人认为它是一种文化，还有CTO认为它的本质就是流水线（Pipeline）。

显然不论哪种定义，你无法挑出毛病，但是它们又都无法使所有人都信服。

所以，我总是避免谈DevOps的定义。

那么在DevOps定义不清的情况下，怎么谈它的实现模式呢？

当一个名词的定义不清时，我们应该回归它的目的。 DevOps的目的是改进和缩短系统开发生命周期。DevOps实现该目的的手段是融合开发（Dev）与运维（Ops）。至于怎么融合，大家似乎没有达到一致的看法，毕竟家家有本难念的经。

总之，大家为了实现DevOps，大概率会从以下三个选项进行选择：

1. 1. 自己开发一个DevOps平台；

2. 2. 买一套现成的DevOps平台；

3. 3. 直接使用云上的DevOps SaaS服务。

总之，就是要有一个平台！

DevOps平台的两种模式

由于大家对于DevOps的定义不清，所以，DevOps平台的功能的边界也就很模糊了。

但是，经过我的观察，不论它们使用了什么工具，包含了多少功能，是否包含界面，DevOps平台目前就两种实现模式：

1. 1. 基于命令式的模式；

2. 2. 基于声明式的模式。

命令式的DevOps平台

在手工运维和手工构建的阶段，人们都习惯将运维命令和构建命令一条条记录下来。

当要实现自动化的时候，人们很自然地想到要让DevOps平台自动化一条条命令的执行。

所以，人们在使用命令式的DevOps平台时，都是跟着平台的界面提示，一步步地增加命令（通常也称为命令节点）。最后完成一整条流水线。

命令式的DevOps平台为了让流水线支持更多的工具和命令，通常会通过运维开发人员对DevOps平台的命令节点进行扩展。

命令式DevOps平台，在用户的眼里就是一条条命令的流水线平台。这就好比你想要一台电脑，然后你跟电脑店的老板买了一堆的配件，自己拿回家，然后按照你的想法一个个配件的组装。

如果要在AWS云上部署一套简单的负载+机器，在命令式DevOps平台上的做法通常是：

• • 步骤1. 配置并购买负载均衡器；

• • 步骤2. 配置并购买机器；

• • 步骤3. 配置安全组并绑定到机器上；

• • 步骤4. 将机器挂载到负载均衡器中。

当然，命令式DevOps平台也知道当要部署的软件多的时候，用户操作起来很麻烦，所以，命令式DevOps平台也会提供一些模板操作来简化用户的操作。但是，用户通常会报怨模板不够灵活不能满足自己的需求。最终命令式DevOps平台都会实现用户自定义命令模板功能。

目前在国内的DevOps平台基本上就是这种实现模式。

声明式的DevOps平台

声明式的DevOps平台把大问题看出两个子问题：

1. 1. 用户该如何描述他们想要的软件的最终状态；

2. 2. 如何实现这个状态，即具体执行。

命令式DevOps平台同时将这两个问题扔给用户，而声明式的DevOps平台只让用户声明他们想要的最终状态，而具体执行的问题留给平台本身。

这就好比你只需要跟电脑店的老板说明你想到的电脑的配置和预算，电脑店的老板就按照行业里最高效的方式给你组装。

在用户的眼里，只要修改软件的最终状态的描述，声明式的DevOps平台就可以帮他们以最快的方式去实现。

这是命令式与声明式的最大区别。用户在命令式的平台下，通常很难知道整个软件的最终状态。就像你拿到部署文档，上面只告诉你要执行的一条条命令，最终状态是什么样，要等待执行完成才知道。

另一个很大的不同点是幂等性。用户可以在声明式的DevOps平台多次声明他想的最终状态，如果用户期望最终状态与实际状态一致，声明式DevOps平台就不会去执行。

如果要在AWS云上部署一套简单的负载+机器，以下以Terraform为声明式DevOps平台案例（不了解代码的可以跳过）：

resource "aws_lb" "default" {
    name = "example-lb"
    subnets = aws_subnet.public.*.id
    security_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.id
        type = "forward"
    }
}  
 
resource "aws_security_group" "hello_world_task" {
    name = "example-task-security-group"
    vpc_id = aws_vpc.default.id
    ingress {
        ...
        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.id
    task_definition = aws_ecs_task_definition.hello_world.arn 
    desired_count = var.app_count
    network_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的本质