云计算时代的自动化运维趋势
发布时间：2021-12-23 13:29:49 所属栏目：云计算 来源：互联网
导读：关于题目云计算时代的自动化运维，用通俗的话讲，就是应用的自动化部署。 云计算时代的自动化运维走向 第一个关键词是自动化，自动化代表高效率、低成本;第二个关键词是应用部署。即，不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。
|
关于题目“云计算时代的自动化运维”，用通俗的话讲，就是应用的自动化部署。 云计算时代的自动化运维走向 第一个关键词是自动化，自动化代表高效率、低成本;第二个关键词是应用部署。即，不涉及讲物理基础设施的运维(如机房基建、能源、消防、安保、布线等等)。 假设一个企业要做一个电商网站，典型的运维流程是这样： 1. 购买硬件设备：服务器、交换机。可能还有路由器、负载均衡器、防火墙，不一一穷举了。 2. 在服务器上安装操作系统 3. 在服务器上安装配置基础环境(数据库、Web服务器、搜索引擎等) 4. 在服务器上安装配置应用软件(用Java、PHP开发的电商软件) 5. 把硬件设备送进机房托管，开通公网访问 6. 监控运维中的业务，并做日常备份、扩容/缩容、迁移、升级 如果是使用公有云，则没有第1，2，5步，直接购买公有云的虚拟机、容器、平台服务(文件存储、关系数据库、内容分发等) 应用环境和应用软件部署是指第3步和第4步。 1 操作系统自动化部署 第2步是物理祼机的部署，现在市面上的主流服务器，都支持IPMI管理，通电接上管理端口就可以完成BIOS设置，再辅以DHCP, TFTP, KickStart可以实现无人值守的自动化安装操作系统。 目前虚拟化、私有云、公有云已经相当普及，除了一些对特殊硬件有要求的场合，和一些历史遗留场合，其它大部分场合都可以用虚拟机，物理机上安装的是宿主操作系统，应用软件装在虚拟机里，这样物理祼机就只需要安装宿主操作系统，需求相对简单，没有应用部署那么复杂。装完之后不会经常去改动，运行稳定。 2 应用部署 与操作系统部署相比，应用部署复杂性高得多，主要表现在： · 场景繁多 一个小型的B2C网站，有负载均衡器、Web服务器、应用服务器、缓存服务器、搜索引擎、分布式文件系统、监制中心、日志中心、VPN服务器等十多种服务器角色 · 依赖复杂 软件包之间有依赖，服务器之间有通信依赖 · 配置各异 除标准的ini,xml, yaml, json, properties文件外，iptables, sysctl, nginx, haproxy, pptpd等都有自己独特的配置文件格式，多达上百种。文档描述和运维脚本编写都有相当大的难度。 3 应用部署技术发展历程 下面以在CentOS上安装nginx为例，回顾一下应用部署技术的发展历程： 3.1 手工安装配置 这是最古老的部署方式，直到今天也被广大小规模团队广泛采用。部署过程往往会产生这样一份文档供日后参考： 云计算时代的自动化运维走向 3.1.1 优点 3.1.1.1 灵活性高 可以安装任何想要的版本，启用任何想要的模块(包括自行开发的私有模块) 3.1.1.2 学习门槛低 文档是自然语言写成，阅读和书写都很简单，不需要额外学习其它技术语言。安装配置用到的工具、命令也较少，主要是网络下载、解压缩、编译、文本编辑几种，容易掌握。 3.1.2 缺点 作为最古老的部署技术，缺点也是显而易见的： 3.1.2.1 文档不精确 由于文档是自然语言写的，是写给运维工程师阅读的，而不是给机器执行的。文档写的是什么，跟机器上实际执行的是什么，并不是100%一致的，需要人肉转换。在长期版本变更、人员更替中极容易出现疏漏。当然，可以从行政管理上解决这类隐患。很多大公司都喜欢搞流程，用测试审核流程来督促人少犯错。然而，只要是这个文档是给人看而不是给机器执行的，这个文档就会一直面临笔误、表达不精确、更新不及时等隐患，要用流程来彻底杜绝这些隐患，成本很高。 3.1.2.2 效率低 上述5个步骤都是串行的，必须做完一步才能进行下一步。第1步和第3步是比较耗时的，若网速不快，或者编译时间太长，运维工程师会浪费时间等待。 另一方面，若有多台机器需要执行同样的部署操作，也无法减少重复性操作。 3.2 自动化部署：shell脚本 若服务器稍有规模的团队里，上述手工部署就成了一个大问题。 人肉阅读的文档急需转换成机器执行的代码。最早也最广泛运用的自动化部署技术便是shell脚本。以bash为例，上述5步写成bash shell就像这样(示例代码，未经测试)： 云计算时代的自动化运维走向 直接运行这个脚本，就可以自动安装配置好nginx了。 相比手工部署，使用shell脚本的缺点只有两点：一是写代码需要一定学习门槛。二是维护的技术难度会略高。 3.2.1 优点 3.2.1.1 精确 由于shell脚本是给机器执行的，shell脚本自身就是一份精确的可执行的文档，所以，不存在笔误、表达不精确、更新不及时的问题。 3.2.1.2 效率高 运维工程师只要把脚本启动起来就可以做别的工作了。 3.2.2 bash的缺点 Bash是几乎所有linux发行版内置的，环境兼容性好，简洁易学。但它却不是运维编程的终极之选。具体来说有两大缺点： 3.2.2.1 缺少高级语言特性 Bash不是一门高级编程语言，和Perl/Python/Ruby/PHP这些同样可以用作shell编程的语言相比，缺少很多高级语言特性，而这些特性在运维部署工作中会用到。 3.2.2.1 工具链不丰富 由于不支持OOP，因此没有完整的单元测试框架。 开发框架、缺陷分析、性能分析工具也几乎是一片空白。IDE支持虽有(JetBrains公司IntelliJ就有bash shell插件)，但功能不多。 3.3 自动化部署：运维DSL 得益于虚拟化和公有云的快速普及，高效高质量地完成应用部署不再是大公司专有的需求，也成了中小企业的刚需，前面分析过了，bash shell不能胜任大规模的、复杂的应用部署，自动化运维编程语言DSL(Domain Specific Language)被发明出来，puppet, chef,ansible, saltstack是其中杰出的代表。 4 自动化运维技术发展趋势展望 4.1 部署工作代码化 无论是使用bash / python shell，还是使用puppet、chef等DSL，都可以完成代码化这个过程。把手工操作变成代码。 使用代码自动化部署应用环境和应用，才能保证无论在办公室测试环境，还是在机房生产环境，每次运行这个部署代码，都能得到相同的结果。这是一切自动化部署的基础。 4.2 运维代码版本化 运维代码要和Java,PHP等应用代码一样，纳入SVN、GIT代码仓库，执行严格的开发-测试-上线-回滚流程。 这样便可利用svn/git的成熟SCM功能，用于这样一些场景： 4.2.1 新建分支 运维代码由1.0升级到2.0，增加了缓存层。则可以从1.0复制出一个分支出来，命名为2.0，然后再在2.0的基础上修改。 4.2.2 差异比较 若要了解1.0和2.0的运维架构到底发生了什么变化，执行svn和git的diff即可查看每一行代码的变化。 4.2.3 历史归档 1.0版稳定运行了半年，升级到2.0版本，此时1.0版冻结写请求，归档留存。2.0上线运行一段时间，发现稳定性不够。可以从归档中找出1.0版本的部署代码，回滚到1.0版本。 4.3 测试环境高保真 很多公司的测试和生产环境存在操作系统不一致、软件版本不一致、配置项不一致的情况。这种不规范的运维有两大后果：一是bug在测试环境未能测出，导致线上故障;二是线上出现异常时，测试环境不能复现。 一个应用至少有两种环境：测试环境、生产环境。大一点的公司还会分成：开发环境、功能测试环境、性能测试环境、预发环境、生产环境。这么多的环境的自动化部署代码，原则上应该是90%以上都相同，只有少数地方不一样。 4.4 自动化测试 使用代码自动化部署完之后，服务器是否立即可用，需要测试验证。自动化测试能让整个运维过程更加高效。 在应用开发领域，自动化测试、单元测试已经非常普及了，运维开发也可以做一些类似的自动化验收测试工作： 4.4.1 终端应用测试 模拟一个客户端访问刚刚部署好的服务，例如：验证其RESTfulAPI是否得到预期的结果。 优点是，最接近实际用户，若此测试通过，则说明装软件、改配置、启服务各项工作都正确。缺点是，若测试不通过，不能立即定位出哪里出错了。定位问题需借助下面更底层的测试。 4.4.2 四层网络测试 使用nmap之类的工具检测目标端口是否正常响应(包括防火墙是否放行) 4.4.3 本机测试 · 用yum,apt检测包是否安装 · 用service status检测守护进程是否正常支持 · 用ps检测进程是否正在运行 · 用ls检测文件是否存在 · 用grep检查配置荐是否设置成了指定的值 （编辑：无锡站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |