深圳网站设计 深圳信科,装修工人,郑州做公司网站的,四种营销模式我们需要一个DevOps平台 要讨论DevOps平台的实现模式#xff0c;似乎就必须讨论它们的概念定义。然而#xff0c;当大家要讨论它们的定义时#xff0c;就像在讨论薛定谔的猫。 A公司认为它不过是自动化执行Shell脚本的平台#xff0c;有些人认为它是一场运动#xff0c;另… 我们需要一个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-lbsubnets aws_subnet.public.*.idsecurity_groups [aws_security_group.lb.id]
}resource aws_lb_target_group hello_world {name example-target-groupvpc_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-groupvpc_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-servicecluster 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的本质
