《DevOps实战：VMware管理员运维方法、工具及最佳实践》是一本以结合VMware技术使用DevOps工具与实践为焦点的书籍。本书综合了DevOps的基础概念和流行的工具，并详细讲解了改变管理系统和交付服务的方法。书中涵盖了DevOps环境配置、维护、编排、管理的各个环节，并提供了丰富的实例来说明概念。这本书对于想要深入了解如何将DevOps和VMware结合应用的管理员来说，是一本非常有价值的参考书。
DevOps实战电子书封面
读者评价
DevOps是大趋势，搞IT的必备啊，同志们抓紧学吧！
用了一个下午粗略地翻了一下，感觉是本高不成，低不就的书。DevOps的基本原理没怎么讲，介绍的一些基本工具的用法，可是太浅，还不如网上搜搜入门教程呢，翻译也很一般。
介绍了一系列DevOps工具，其中介绍Docker、jenkin、CI概念的部分对自己有帮助
内容介绍
本书由VMware技术专家撰写，是一本写给VMware管理员的DevOps权威指南。书中既系统介绍了DevOps的基础概念和流行的工具，涵盖DevOps环境配置、维护、编排、管理的各个环节，又详细讲解改变管理系统和交付服务的方法，并且包含大量实例，可以帮助你快速了解并掌握DevOps工具、方法及*实践。
全书共19章，第1章讨论DevOps的概念；第2章介绍DevOps从业人员的一些流行工具；第3章介绍测试环境的建立；第4~6章介绍Puppet配置管理解决方案；第7~9章介绍Chef配置管理解决方案；第10章和第11章介绍Ansible配置管理和编排解决方案，第12章介绍Powershell预期状态配置；第13章探索VMware管理员在其环境中实施PowerShell DSC的方法；第14章讨论Linux容器的使用；第15章进一步讨论Linux容器，介绍Google Kubernetes；第16章描述如何安装、配置和使用Razor；第17章介绍Elasticsearch、Logstash和Kibana（ELK）栈；第18章介绍用于持续集成的Jenkins，讨论在代码提交到源代码库之后如何自动交付；第19章讨论VMware自身的DevOps倡议。
目录
- 译者序
- 前言
- 致谢
- 关于作者
- 关于评审人员
- 关于贡献者
- 第一部分 DevOps概述
- 第1章 DevOps简介 2
- 参考文献 7
- 第2章 DevOps工具 8
- 参考文献 12
- 第3章 建立DevOps配置管理测试环境 13
- 参考文献 24
- 第二部分 Puppet
- 第4章 Puppet简介 26
- 参考文献 42
- 第5章 Puppet系统管理任务 43
- 参考文献 54
- 第6章 用Puppet进行VMware vSphere管理 55
- 参考文献 63
- 第三部分 Chef
- 第7章 Chef简介 66
- 第8章 使用Chef完成系统管理任务 77
- 参考文献 94
- 第9章 用Chef管理VMware vSphere 95
- 第四部分 Ansible
- 第10章 Ansible简介 108
- 参考文献 121
- 第11章 Ansible系统管理任务 122
- 参考文献 132
- 第五部分 PowerShell
- 第12章 PowerShell预期状态配置简介 134
- 参考文献 144
- 第13章 PowerShell DSC实施策略 145
- 参考文献 152
- 第六部分 利用容器进行应用程序部署
- 第14章 Docker应用容器简介 154
- 参考文献 16
对于Devops本人真的是所知甚少。由于长期从事的是开发工作，对Devops的认知仅停留在自动化测试，自动化运维方面。最近公司组织了一场凤凰沙盘的活动，有幸得以参加。在参加前也搜索了一些相关内容，对Devops有了一些更广泛的认识。DevOps是一种文化，是一种跨团队(Cross-Team)的团队协作，通过单件流(one-piece-flow)，JKK的理论，在保证业务连续性(Business Continuity) 的前提下，实现持续集成(Continuous Integration)、持续交付(Continuous Delivery)的要求，最终实现提升业务产量(Business Outcome)的目标。 本次凤凰项目沙盘个人觉得更像是将公司的整个流程压缩到了一个桌游中，更偏向的是通过实践快速暴露工作中的问题，反思再实践再反思的过程。通过多次(4次)迭代帮助团队找出问题，并通过反思总结问题，找出解决方案。毕竟一千个人眼中有一千个哈姆雷特，每个团队有每个团队的问题，如果讲师按照固有的解决方案进行培训可能是最好的方案，但不一定是最适合这个团队的方案，只有通过实践暴露出问题并且团队自治解决问题才是最好的方案。 还有一点是看到网上有人说这个沙盘以客户价值为中心，这一点不太认同。这场沙盘是完全围绕盈利展开的，所有的工作都指向为本公司创造更多的价值，提高公司的盈利，提高公司的股价。这一点在商业中也无可厚非，毕竟大家都是以盈利为目的，而不是慈善。但是如果披上以客户价值为中心，就有点瞎扯淡的意思了。 在这场桌游中，我的Role是IT Test Team,团队有三个人，也得益于这样，让我有更多的时间不只是参与在自己的角色中，也观察并体验了其他角色的工作。得出了一点自己的心得和感悟。
通过对DevOps进行一段时间的学习，对自己负责的测试模块有了一点点自己的小想法。通过对整个研发流程的重新认识和理解，思考测试在整个研发流程中扮演的角色，应该做的主要工作，以及涉及到的影响因素进行思考。最后思考对测试管理、数据管理主要做的具体工作是什么，通过怎样的方式，来保证研发质量。对于测试主要工作，在当前CI/CD下应该怎么有效的进行，在后面将进行持续的学习和思考。一、研发体系的理解 整个研发体系是按照DevOps的方式进行，service mesh 能够提高研发的效率，让研发关注业务本身，解决微服务带来的服务上下游关系、路由、监控、动态配置……，一系列研发功能时需要考虑的问题。二、测试职责通过分享知道对于DevOps的研发过程，应该在持续交付的过程中，做好测试管理、数据管理。为了保证测试管理和数据管理更好的执行，涉及到配置管理、构建与持续集成、部署与发布管理、环境管理、度量与反馈。1.主要职责 对于这些过程中具体的细化工作如下：测试管理：测试分层策略：分层方法、分层策略、测试时机代码质量管理：质量规约、检查方式、反馈处理自动化测试：自动化设计、自动化开发、自动化执行、自动化分析数据管理：测试数据管理：数据来源、数据覆盖、数据独立性数据变更管理：变更过程、兼容回滚、数据监控
在我看来： 1.主要就是为了整合资源，使资源充分利用.让开发人员像使用水电一样的使用资源，让开发人员聚焦在更有价值的事情身上，让整个开发阶段中不同的工具串联在一起，形成一条完整的流水线。 2.可视化可跟踪，通过一系列的工具可以对开发需求进行持续的跟踪，很明确的且客观看到任务的当前状态，而且出了问题之后可以追溯，让你能精准的定位到哪个环节出现了问题。 3. 在运维方面，尽可能的通过监控工具，收集数据，通过大数据，深度学习等手段，来解放运维人员，而且数据不断的可视化，也有利于实时监控（其实我没做过运维，在这方面理解得比较浅，慢慢好好学习吧）