DevOps的几个场景

名词:

服务发现:

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

名字解析:

用来确保服务器位置无关性,通过机器名查询获得机器的实际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

QA

Prod

部署脚本- Ansible:

invetories

qa

[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

QA

Prod

基础设施配置- Terraform:

input:

qa:

*.tf

*.tf_state

prod:

*.tf

*.tf_state

output: inventories

qa

prod

部署脚本- Ansible:

invetories

qa - created from terraform

prod - created from terraform

playbooks

web.yml

db.yml

templates

Conf.j2

场景四:

特点:

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

流程:

DevOps合作。

方法:

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

工具:

自动基础设施管理系统(面向机器,伸缩,部署,监控)

自动应用程序管理系统(面向容器,伸缩,部署,监控)

服务发现

名字解析

配置管理

时间: 2024-12-14 19:04:38

DevOps的几个场景的相关文章

翻译-DevOps究竟是什么?

原文地址:http://www.drdobbs.com/architecture-and-design/what-exactly-is-devops/240009147 作者:Neil Garnichaud 软件开发目前的最新趋势是DevOps文化,即开发人员和运营人员一起确保软件以最低的故障率运行. 很多组织发现他们面临这样的挑战,即随着云的Web应用程序的发展,要求快速发布以便及时响应来自用户社区的问题或请求.及时响应用户需求是每个软件开发团队的目标,但是会给组织内的功能团队造成压力.压力往

容器公司拿到5千万A+轮,搞明白了传统企业生意经

(上图为数人云创始人及CEO王璞) 2016年11月,中国开源云容器工作组发布了<容器技术及其应用白皮书 V1.0>.<白皮书>指出,继虚拟化技术出现后,容器技术逐渐成为对云计算领域具有深远影响的变革技术.容器技术的发展和应用,为各行业应用云计算提供了新思路,同时容器技术也将对云计算的交付方式.效率.PaaS平台的构建等方面产生深远影响. 容器技术从2014年开始风靡全球,美国以 2013年Docker公司成立为标志.中国以2014年底的一批Docker容器公司为标志,出现了一波D

浅谈运维规模化可持续构建实战

如今的互联网时代,运维早已不再是被动的那一方.过去的运维,由于种种限制,工作繁重.复杂,效率低下,很难适应目前互联网产品快速的迭代节奏.而如今,随着虚拟化.容器技术以及持续构建技术的成熟,运维工作的模式有了很大的变化,通过自动化技术的应用使得更少的人为参与,有更高的效率.为了确保项目高质量的快速迭代,必须构建一套高效的可持续构建的运维管理体系. 互联网项目最大的特点是版本迭代节奏快(同一个系统一天上线数次都有可能),需求变化频繁,且每天可能都有项目新增.服务维护.运维架构调整等需求.而常见的运维

DataOps Reading Notes

质量.效率.成本.安全,是运维工作核心四要素. AIOps 技术会涉及到数据收集方面的基础监控,服务监控和业务监控,甚至会涉及到与持续交付流水线的数据和状态整合(比如在软件发布的阶段会自动关闭某些监控项.异常判断时会参考流水线目前的状态).数据存储与人工智能技术,其中人工智能包括机器学习算法与深度学习模型(用于模式识别). 引入 AIOps 之后,是否能对 AIOps 的模型或数据进行不断优化也是一个新的挑战.人工智能在一开始都不是很完美的,需要不断优化才能达到实际应用的要求.对于发现问题和问题

DevOps Workshop 研发运维一体化第一场(微软亚太研发集团总部)

准备了近两周,写了大量的操作手册,设计了大量的动手实验场景,终于在中关村的微软大厦完成了两天的DevOps培训. 最初报名160人,按照之前的培训经验,一般能到一半就不错了,没想到这次现场登记人员就超过140人,再加上没有登记的人员,现场基本爆棚,由四个大会议室组成的MPR会议室人满为患,大家对DevOps这个全新的软件开发运维一体化的的理论和实践充满期待. 第一天对软件开发的需求管理.项目计划和源代码管理进行的全面而深入的介绍,并且为到会的所有开发人员提供现场动手实验的机会,大家兴致高涨,按照

微软构建高效DevOps团队培训总结

9.21和9.22这两天参加了微软DevOps的培训,主要是围绕TFS2015的不少新功能来讲的,相比较之前我们一直使用TFS2013来管理团队,确实强大了不少,也更加实用了. 首先,什么是DevOps? 运维说主要是发布管理.CI持续集成的,开发说是开发测试一体化的,项目经理说是项目流程管理的...其实都没错,只是都不全面.百度百科上较严格的定义,不过它的似乎就是像开源社区一样,是经过大家集思广益,各自的经验方法总结而形成的一套覆盖软件开发运维流程的经验论. 目标人群 (第1天)企业研发经理,

DevOps热门发展趋势中的十大误区

如今的IT企业全部是自动化.新一代的代码和应用将我们带进一个融合了基础设施和云计算的时代,企业原有系统正在遭到这些新赶上的庞大的新环境的挑战. 因此,DevOps(Development和Operations的组合)作为一项新的业务脱颖而出,它的出现旨在解决复杂的系统管理员和开发者每天要面对的信息技术问题.尽管有一些组织也在实施DevOps 的方法,但还是有很多人不能完全理解DevOps 具体是什么,他们要么是抗拒,要么是意识不到这种部署的优点. DevOps是一组方法.过程与系统的统称,用于促

优维DevOps系列沙龙全回顾:DevOps+SRE落地实践+DevOps最后一棒

5月6日,优维科技和数人云联合主办的DevOps&SRE系列活动<DevOps&SRE 超越传统运维之道>在深圳顺利举行. 优维科技CEO王津银.数人云CEO王璞.腾讯SNG运维负责人梁定安分别分享了<DevOps与传统的融合落地实践及案例分享><SRE在传统企业中的落地实践><DevOps最后一棒,有效构建海量运营的持续反馈能力>,为大家带来了一场异彩纷呈的技术盛宴. △场面爆满 除了DevOps.SRE相关的经验,还有具体落地的案例分享,

[转载]持续交付和DevOps的前世今生

作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新概念风起云勇的时代. 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”... ... OK,就这四个啦: “敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”. 先让我们在Wikiped