名词：

服务发现：

用来确保服务的位置无关性，通过服务名来查询获得服务的实际地址。

名字解析：

用来确保服务器位置无关性，通过机器名查询获得机器的实际IP地址。

场景一：

特点：

应用少，流量轻，数台机器，DevOps分离，手动基础设施管理，手动应用程序部署，监控非必要，面向机器，基于IP的配置，服务发现非必要，名字解析非必要。

流程：

DevOps分离。

方法：

各个环境的基础设施（网路，服务器，IP地址，操作系统，依赖包）事先由Ops人员搭建，完成后将各个环境最终的机器配置信息告知Dev。机器配置信息包括机器名，用途，规格（OS，CPU，内存，硬盘），IP地址，端口，预装软件信息等。

Dev开发完一个迭代后，将软件打包后交由Ops人员部署到QA环境，一旦QA环境测试通过再由Ops人员将软件包部署到PROD环境。Dev要根据Ops人员提供的各个环境的机器配置信息生成应用在各个环境的具体配置文件，并随软件包一起提交给Ops人员。

工具：

手动部署

场景二：

特点：

应用少，流量轻，数台机器，DevOps合作，手动基础设施管理，自动应用程序部署，监控非必要，面向机器，基于IP的配置，服务发现非必要，名字解析非必要。

流程：

DevOps合作。

方法：

各个环境的基础设施（网路，服务器，IP地址，操作系统）事先由Ops人员搭建，完成后将各个环境最终的机器配置信息告知Dev。机器配置信息包括机器名，用途，规格（OS，CPU，内存，硬盘），IP地址，端口，预装软件信息等。

Dev提交一个Commit到Git Repo后触发CI/CD执行Pipeline的第一个Stage Build，Build Stage从GitRepo下载代码（包含部署脚本）并编译，测试，打包，上传。

打包完成后自动触发CI/CD执行Pipeline的第二个Stage QA，QA Stage调用部署程序（Ansible）根据部署脚本（Playbook）将软件包部署到QA环境（Inventory），部署通常包括下载软件包，根据Inventory生成配置文件，部署程序，启动服务等。

一旦QA环境测试通过，需手动触发CI/CD执行Pipeline的下一个Stage Prod，Prod Stage调用部署程序（Ansible）根据部署脚本（Playbook）将软件包部署到Prod环境（Inventory）。

工具：CI/CD + Ansible

CI/CD- GoCD Pipeline：

Build

Prod

部署脚本- Ansible：

invetories

[web]

......

[db]

......

prod

[web]

......

[db]

......

playbooks

web.yml

db.yml

templates

Conf.j2

场景三：

特点：

应用少，流量轻，数台机器，DevOps合作，自动基础设施管理，自动应用程序部署，监控非必要，面向机器，基于IP的配置，服务发现非必要，名字解析非必要。

流程：

DevOps合作。

方法：

各个环境的基础设施（网络，服务器，IP地址，操作系统）由基础设施管理程序（Terraform）根据各个环境的基础设施配置自动配置，完成后自动生成各个环境最终的机器配置信息（Invetory）。

Dev提交一个Commit到Git Repo后触发CI/CD执行Pipeline的第一个Stage Build，Build Stage从GitRepo下载代码（包含部署脚本）并编译，测试，打包，上传。

打包完成后自动触发CI/CD执行Pipeline的第二个Stage QA，QA Stage调用基础设施管理程序（Terraform）根据基础设施配置自动完成QA环境基础设施配置并生成QA环境机器配置信息（Inventory）。再由部署程序（Ansible）根据部署脚本（Playbook）将软件包部署到QA环境（Inventory），部署通常包括下载软件包，根据Inventory生成配置文件，部署程序，启动服务等。

一旦QA环境测试通过，需手动触发CI/CD执行Pipeline的下一个Stage Prod，Prod Stage调用基础设施管理程序（Terraform）根据基础设施配置自动完成Prod环境基础设施配置并生成Prod环境机器配置信息（Inventory）。再由部署程序（Ansible）根据部署脚本（Playbook）将软件包部署到Prod环境（Inventory）。

工具：CI/CD + Terraform + Ansible

CI/CD- GoCD Pipeline：

Build

Prod

基础设施配置- Terraform：

input：

qa：

*.tf

*.tf_state

prod：

*.tf

*.tf_state

output: inventories

prod

部署脚本- Ansible：

invetories

qa - created from terraform

prod - created from terraform

playbooks

web.yml

db.yml

templates

Conf.j2

场景四：

特点：

应用多，流量巨，万台机器，DevOps合作，自动基础设施管理，自动应用程序管理，监控，面向容器，服务发现，名字解析，配置管理。

流程：

DevOps合作。

方法：

各个环境的基础设施（网络，服务器，IP地址，操作系统）由基础设施管理系统根据需求信息（由高层提供）自动配置。各个服务的用途也由基础设施管理系统根据需求信息（由高层提供）自动决策。因基础设施并非事先设定，故应用的配置不能依赖服务和机器的物理地址，需采用服务发现配合名字解析来实现系统的集成和配置。

工具：

自动基础设施管理系统（面向机器，伸缩，部署，监控）

自动应用程序管理系统（面向容器，伸缩，部署，监控）

服务发现

名字解析

配置管理

转载于:https://www.cnblogs.com/zanxiaofeng/p/6558673.html

DevOps的几个场景相关推荐

Serverless 时代 DevOps 的最佳打开方式
作者 | 许成铭(竞霄) 来源 | 阿里巴巴云原生公众号 DevOps 简析传统软件开发过程中,开发和运维是极其分裂的两个环节,运维人员不关心代码是怎样运作的,开发人员也不知道代码是如何运行的. 而 ...
如何建设移动 DevOps？
简介:DevOps这一优秀的软件交付理念在服务端已经有很多相关的实践,那么是否也可以应用到移动端进行交付呢?基于移动端和服务端场景的差异,移动DevOps跟服务端DevOps又有哪些不同和挑战?本文分 ...
交付效率提升40%，珍爱网基于微服务的DevOps落地指南
2015-2016年,珍爱线下门店已新增覆盖城市9个,与此同时,CRM系统大小故障却发生了数十起... ... 珍爱网是以"网络征选+人工红娘"模式提供婚配服务的婚恋相亲平台.CR ...
EMAS 移动 DevOps 解决方案 —— Mobile DevOps
阿里云云原生应用研发平台EMAS 彭钊(州牧) DevOps这一优秀的软件交付理念在服务端已经有很多相关的实践,那么是否也可以应用到移动端进行交付呢?基于移动端和服务端场景的差异,移动DevOps跟 ...
EMAS移动DevOps解决方案-Mobile DevOps
一.Mobile DevOps 介绍 1. 什么是移动 DevOps 1)大家所熟知的DevOps 在2020年这个时间节点上,DevOps已经不再是什么新鲜概念,相信大家或多或少都有些自己的理解,但 ...
加快云原生技术转型，智能调度登陆华为云DevOps: 增速，节源
本文分享自华为云社区<加快云原生技术转型, 智能调度登陆华为云DevOps: 增速,节源>,作者: DevAI. 1. 背景随着云计算.微服务.容器等技术的蓬勃发展,以及云原生的敏捷,适 ...
DevOps 的分与合
抽象的 DevOps DevOps 是使软件开发和 IT 团队之间的流程自动化的一组实践,以便他们可以更快,更可靠地构建,测试和发布软件. DevOps的概念建立在建立团队之间协作文化的基础上,这些团 ...
走进云研发时代阿里云发布云原生DevOps解决方案
2020年10月21日,阿里云云效DevOps平台联合云原生应用平台共同举办"阿里云云原生DevOps解决方案重磅发布"云端发布会,正式发布基于阿里巴巴最佳研发实践的云原生DevO ...
超融合走向红海，下一代超融合是新蓝海？
<中智观察>第1633篇推送作者:赵满满编辑:小瑞瑞头图来源:摄图网以前,搭建一个云应用环境,可能需要用户分别购买计算.存储.网络设备,配置管理软件.这样不但麻烦,系统利用率,而且 ...

DevOps的几个场景

名词：

服务发现：

名字解析：

场景一：

特点：

流程：

方法：

工具：

场景二：

特点：

流程：

方法：

工具：CI/CD + Ansible

CI/CD- GoCD Pipeline：

部署脚本- Ansible：

场景三：

特点：

流程：

方法：

工具：CI/CD + Terraform + Ansible

CI/CD- GoCD Pipeline：

基础设施配置- Terraform：

部署脚本- Ansible：

场景四：

特点：

流程：

方法：

工具：

DevOps的几个场景相关推荐

最新文章

热门文章