自动化运营经历谈,当容器与CI

来源:http://www.smjxgs.com 作者:服务器&运维 人气:128 发布时间:2019-11-03
摘要:自动化运维经验谈,以及为什么Docker是革命性的 随着开发效率的提高,运维的自动化已经成为很多技术团队越来越重视的问题,否则部署的速度容易成为业务创新的瓶颈。在这个背景下

自动化运维经验谈,以及为什么Docker是革命性的

随着开发效率的提高,运维的自动化已经成为很多技术团队越来越重视的问题,否则部署的速度容易成为业务创新的瓶颈。在这个背景下,定位于给互联网公司做运维服务的云络科技公司接触了越来越多的客户,对国内互联网公司的运维水平有相当多的了解。他们看到的现状是怎样的?技术团队要实现运维自动化应该从哪里开始?像Docker这样的技术如何影响开发者与运维工程师?在本次采访中,云络科技CEO Steve Mushero谈论了这些话题。

4887王中王鉄算盘奖结果 1

嘉宾简介

Steve Mushero从硅谷来到中国,在全球范围内的广泛行业及从业企业中拥有超过25年的技术管理经验,其中包括IT运营、软件开发、物流、制造以及机械等领域。他曾在土豆网(中国)、Intermind、New Vine Logistics以及Advanced Management Systems等企业担任过CTO,拥有首席架构师工作经验,并以顾问身份为世界卫生组织、格莱珉银行基金会以及多家全球财富五百强企业的全球化项目提供指导。

自动化从构建和测试开始

运维自动化的关键在于标准化。当你有一个成熟的团队,有标准化的流程,那么运维自动化就水到渠成了。而如果你什么都没有,那就需要先设定优先级。

我们的目标当然是将所有的流程标准化,而哪些要放在前面做?做起来比较简单的,和比较重要的。我认为构建和测试的流程是最基本的第一步。这对于交付产品的公司来说容易一些,对互联网公司来说更复杂一些,而测试比构建也要复杂一些,但这是基础。构建和测试的流程标准化做好了,就可以准备做自动化的工作了。

不过我见过的很多公司连Git都还没有,仍然在用最原始的FTP push来更新代码。我的观点是,如果你还没有用上Git这样的工具,那根本就不用考虑什么自动化的问题,因为条件完全不成熟。

所以,我们假设你的团队能够很好的使用Git,然后你建立了构建和测试的标准化流程,然后你就可以用工具来实现自动化。这可能是Jenkins这样的工具,不过Jenkins比较复杂,如果你只是一个很简单的网站,那么自己写一些脚本来实现自动化是更合适的。

到此为止,我们说的还不是自动化运维,而是自动化工具链。工具链就是开发工具链,从IDE,到代码提交,代码审查,构建,到测试,仍然属于开发的范畴。在这之后才是运维的范畴,就是往生产环节部署。

部署

运维自动化最关键的部分是运行环境的定义。我们的目标是让各个阶段的代码完全一样,即开发者在自己笔记本上写的代码,到集成阶段的代码,到线上环境的代码,都是一致的。为什么Docker这么火,就是因为它帮助开发者很简单的就让自己的开发环境跟生产环境一致。环境的标准化,意味着目录、路径、配置文件、储存用户名密码的方式、访问权限、域名等种种细节的一致和差异处理的标准化。这涉及到很多方面,也是自动化运维最困难的一部分。

这里要注意的是,像Puppet这样的工具并不是魔法。你需要自己为你的环境定义一套描述的方式,工具是无法为你完成这项工作的。无论是Puppet还是Jenkins,都是根据你的定义来管理你的环境。你决定用户名和密码如何储存,你决定配置文件的路径。开发者很喜欢把各种配置和url之类的参数硬编码到代码里,这很快;他们还喜欢东搞西搞的用一些乱七八糟的手段让软件通过测试,但是如果要构建一个真正的系统,这些小把戏根本没用。你必须强迫他们采用标准的方式写代码,比如强制他们把用户名和密码写在固定的地方,然后你才能跟Puppet说,配置文件在这里,测试环境用这个配置,生产环节用那个配置。到这里就很简单了。

线上环境问题排查

对于线上环境的问题发现与解决,大部分基础的问题都能用工具来自动发现并提醒,比如磁盘空间不够,比如MySQL崩溃,比如访问网站的时候出现错误页面等等,有很多现成的工具可以抓到它们错误的信息。

比较困难的是排查网站为什么变慢这样的性能问题。我们经常看到客户的开发团队提交新代码后引入问题。在测试做得不好的时候这很常见,事实上很多东西是很难测试的,尤其是性能;而互联网公司又尤其没有测试的文化,互联网开发人员大多关注特性的实现,而不像传统企业级开发那样有很多测试的工具和流程。

理想的情况下,每个人提交代码前都应该测试。但既然反正也没人这样做,那么用工具来帮忙还是很有用的。比如New Relic这样的工具就很强大,它可以发现代码层面的问题。我们有时候也用我们的工具帮客户做测试,包括负载测试。性能测试是挺困难的一件事,既不容易用起来,也不容易让别人用起来,一般来说你需要一个专门的团队才能做性能测试,但互联网公司基本没有(除了Google、Facebook这样的),就算想有也找不到人。所以要善用工具。

Docker的意义

Docker很有意思,很火,很新,当然也很多问题。它目前没多少大型部署案例,所以人们不断的发现问题也是很正常的事情。

总体来说,Docker是一个对开发者非常友好的东西:简单的实现不同机器上的环境标准化,可以轻松拿来拿去,而且在不同的云平台上都支持。而把Docker用起来对运维而言则是很大的挑战,我们帮一个客户做一个规模较大的Docker部署,一个有经验的DevOps团队也花费了几个月的时间。为什么?

Docker容器就跟VM差不多,从运维的角度,会希望像管理VM那样管理Docker容器,但是Docker容器很难troubleshooting,因为默认来说它没有SSH,你要怎么登陆到一个容器里去查看里面发生了什么问题?Troubleshooting,这是一个最大的问题。

默认来说,Docker容器也无法运行cron任务或者batch任务,意味着你没法儿让它自动做备份之类的工作,而这是最基本的运维任务,这是另一个必须解决的问题,否则你根本无法构建一个自动化管理的云环境,而要解决这个问题,你需要搞一些手段,比如改造它的架构,但是你一折腾,又引入了很多新的问题要解决。

Docker有很好的网络机制,但是也很复杂,所以我们bypass了所有的Docker网络,而这也引入了一些问题。Docker容器也没有好的重启方法,因为你很难看到哪个是哪个,需要做一些好的命名映射的管理系统。总之,要在大型部署中把Docker玩好,你需要各个方面的专家,还需要时间。

我并不怀疑Docker是趋势,它的概念非常好,会极大的改善开发者的世界。如果你的系统比较简单,不是很大,那么用Docker是完全没问题的。而且它的文档很好,这也是很赞的地方。我相信它会引领未来。它只是还需要时间来完善。而这也不奇怪:想想KVM,其实KVM做的事情很简单,就关注系统层和CPU、内存、存储、网络的交互,并不难理解,但即使是目标如此简单的项目也多年处于问题层出不穷的状态,人们不断的围绕它开发工具,改进它,才到了今天的可用状态。Docker则复杂的多,有很多层:它是一个环境管理系统,它是个打包系统,它是个文件系统,它包含一套网络机制,它是一个repo系统,它是个代码系统,等等。基本上,Docker想要把所有的东西都扔到一个小盒子里,五脏俱全。当你用Docker提交代码时,你做的事情跟以前是完全不同的。在以前我们只是把代码提交上去,而在Docker中我们把整台计算机(虚拟机)提交上去。想象一下,这就好像是交换电脑一样,开发者把整台电脑交给运维,电脑里面的环境和代码都有了,是不变的;而运维需要把所有的电源网线什么的都插回去,需要处理很多变化的东西,比如变更的IP、用户名、文件系统等等。这是全新的方式。


4887王中王鉄算盘奖结果 2


随着开发效率的提高,运维的自动化已经成为很多技术团队越来越重视的问题,否则部署的...

数人云:Docker是CI/CD的早期采用者,通过利用如GIT等源代码控制机制的正确集成,Jenkins可以在开发者每次提交代码时启动构建过程,此过程生成新的Docker镜像,可以在整个环境中立即生效,因此团队可以快速构建共享和部署应用。

在云栖大会开源专场,来自阿里云的高级开发工程师莫源为现场听众带来了题为《Dev Oops ? No , DevOps!》的分享。在分享中,莫源从持续交付之禅、持续交付系统JenKins以及Derrick助力开发者轻松容器化三个方面由浅入深地讲述了DevOps是如何通过选择合适的工具降低等待和技术成本,提高企业自动化。

用途:根据开发需求,自动配置环境及基础设施,并配备拥有自助服务的自动化工具。

以下内容根据现场分享和幻灯片整理而成。

  • 企业所面临的挑战:
  • 不可用的环境
  • 缺乏环境配置所需技能
  • 缺乏环境配置所需时间

4887王中王鉄算盘奖结果 3

什么是CI(持续集成)

CI是一种开发实践,开发者每天将代码集成到共享存储库中几次,支持将新功能与现有代码集成在一起,此集成的代码还可以确保运行时环境中没有错误,允许检查它与其他变更的反应。

目前用于CI最流行的工具是“Jenkins”,GIT用于源代码控制存储库,Jenkins可以从GIT存储库中提取最新的代码修订,并生成可以部署到服务器上的构建版本。

DevOps越发被开发者所提及,尤其在与Docker相关的领域,DevOps被认为是开发者快速部署的最佳实践。从2016年统计结果来看,74%的开发者已经开始使用DevOps,而这一数据在15年只有66%;企业界已有81%的企业已采用DevOps,而这一数据在15年只有70%。然而,统计数据表明62%的开发者在使用DevOps时需要他人指导;44%的开发者仍处于调研和测试DevOps的初级阶段。由此可见,DecOps是一种势不可挡的趋势,但同时也是“尸横遍野”的战场。

什么是持续交付

持续交付是指在给定的时间内将软件部署到任何环境的能力,包括二进制文件、配置和环境变更。

为了更好地了解DevOps,下面分别来看一下两个常见的最简化持续交付流程——传统应用的持续交付流程和容器化应用持续交付流程。

4887王中王鉄算盘奖结果,什么是持续部署(CD)

持续部署是开发团队在短周期内发布应用的一种方法,开发人员所做的任何变更都会被部署到生产环境中。

4887王中王鉄算盘奖结果 4

什么是Docker?

Docker是一个容器化平台,以容器的形式将应用及所有依赖项打包在一起,确保应用能够在任何环境中无缝地工作。

传统应用的持续交付流程是从代码开发提交代码到代码仓库;代码仓库触发构建后,由持续集成系统测试、预发并正式环境部署。

Docker如何帮助CI/CD

Docker可以帮助开发者构建代码并在任何环境中进行测试,以便尽早地在开发生命周期中获取BUG。Docker的优势在于:帮助简化流程、节省构建时间、并允许开发者并行地运行测试。

Docker还可以集成源代码控制管理工具,如GitHub和Jenkins等集成工具,开发者将代码提交到GitHub,测试使用Jenkins创建影响自动触发构建的代码,可以将此影响添加到Docker registry,以处理不同环境类型之间的不一致。

4887王中王鉄算盘奖结果 5

技术解决方案

没有Docker参与的典型CI:

Markdown

开发者将代码提交到存储库,这些代码通常会在持续集成服务器上触发构建,构建过程可能会根据所构建的应用而不同,一般情况下,可以进行编译、运行测试用例、构建应用,然后将应用部署到服务器中。

通过Docker进行的CI:

Markdown

在CI过程中安装Docker的方法是让CI服务器在构建应用后再构建Docker镜像,应用进入镜像内部,将镜像推到Docker Hub,在另一台主机上或QA/DEV/生产环境,从Docker Hub提取即将完成的构建,并运行应用的容器,在CI服务器中,甚至可以将编译和测试作为镜像构建的一部分运行。

容器化应用持续交付流程如上图所示,相比于传统应用的持续交付流程,容器化应用在持续集成系统中新增了镜像构建与推送,之后再通过分发编排模板完成部署。

好处:

  • 消除不一致的环境设置问题
  • 任何运行Docker的机器都可以使用Docker镜像
  • 节省构建和设置过程中的时间
  • 允许并行测试
  • DevOps模式,开发可以专注于开发应用,而运维可以专注于部署
  • 改进版本控制,通过改变Docker镜像来规范环境

本文作者有多年的持续部署(CD)经验,帮助很多公司实践及优化CD,以下是一些关于CI/CD的经验及建议:

4887王中王鉄算盘奖结果 6

No.1 使用工具:

虽然使用工具听起来很平常,但仍有一些公司没有使用工具,这对公司或个人没有益处,推荐使用Circle类似的工具,工作流方面也应该有一定的工具使用规划。

很多开发者从各类演讲或者社区中拿到上述类似的方案后就回到公司开始进行DevOps实践。然而,在企业实现过程中,DevOps的实施变得越加复杂,有的企业在实施DevOps时引入了新的架构、新的部署环境(PaaS、Docker、Serverless);有的企业引入了新的工具链、新的流程以及新的“职位”。这新引入的一切给企业带来了更多生产运营的成本。但这并不是DevOps想要的结果!

No.2 做单元测试:

需时刻提醒团队成员,持续部署只是应用于部署的持续集成,因此需要良好的单元测试覆盖率,如果还没有一个坚实的单元测试和持续集成的基础,那就是准备尚不完善。

4887王中王鉄算盘奖结果 7

No.3 做好监控:

BUG和回滚是不可避免的,通过查看生产中的数据,将系统放在适合的位置,可以知道何时进行了回滚或BUG传递,将其绑定到自动化回滚,因此如果有关键功能或指标出错,那么CD系统会自动回滚到稳定版本。

DevOps不是让你成为全能忍者(既懂开发又懂运维,还能兼顾测试),而是消除“等待”与“浪费”。在传统的服务流开发模式中,从前期的需求分析、设计、实现、验证到后期的运维部署,每一个流程都是由不同的角色负责,例如产品经理负责需求分析和设计、开发工程师负责实现、验证是由测试工程师负责,而后期的维护是运维工程师的职责。因此,也就产生了“等待”与“浪费”,“等待”与“浪费”出现在项目流转过程中,不同角色交替职责时,比如说等待基础架构的设计、等待应用程序部署、等待其他团队的反馈,甚至有时需要等待漫长的审核流程。

No.4 团队信任:

选择相信团队成员,容忍开发人员的错误,在认为合适的时候进行部署,并互相检查代码,将持续部署与分层权限的区域性结合在一起。

那么DevOps是怎样消除这些“等待”造成的“浪费”呢?首先一点是消除不必要的流程;第二消除不必要的特性;第三消除不必要的人工;第四消除不必要的返工。

No.5 简化代码评审过程:

与上面所说的团队信任类似,团队应该检查代码变更,选择最有资格和洞察力的人去检查开发人员的代码。

4887王中王鉄算盘奖结果 8

No.6 让开发人员紧密参与生产操作:

没有成功地过度到持续部署的公司最常见的问题是开发团队是独立的,开发和运维应该在适合的时候互相参与到对方的工作当中,要让开发团队深入参与CD基础设施的建设和规划。

那么DevOps到底是怎么解决上述提到的等待和浪费呢?答案就是分而治之,将大的目标分成不同的、小的目标,每一个子类目标可以进行快速的设计、开发、测试和交付。利用分而治之分方式让每一个步骤可验证、可交付。先分而治之,让一个大的开发周期变成小的开发周期再进行快速开发是DevOps之禅,一味地追求自动化部署反而违背了持续交付的初心。

No.7 尽早测试:

团队需要不断地反馈,把测试目标看做是在正确的时间获得正确的反馈,因此在部署时才能知道什么是有效或错误的,越早发现BUG,就越容易修复,持续部署做的极好的公司都会有全面的单元测试和集成测试覆盖率。

DevOps热门的领域

结论:

持续测试也是一种开发实践,在一天的测试计划中,开发需要不断地将代码集成到共享存储库中,为了让开发团队能够检测出问题,自动化构建可以用来验证每个测试,若不遵循连续的方式,那么集成和修复BUG会消耗更长的时间。

为了提高应用开发过程的敏捷性,在企业中使用Docker简化和稳定了CI/CD,Docker容器的轻量级特性使其快速运转,并有助于快速测试,并且可以使用可重复的流程,创建类似环境产品。

4887王中王鉄算盘奖结果 9

DevOps最近几年的热门领域主要是Cloud Native、Microservices、Docker和Serverless,这四个领域经常和DevOps结合在一起。DevOps的本身并不是一个技术问题,但是技术的变革需要DevOps来填平带来的技术成本。DevOps实现是一个适配器,封装了本地开发与远程交付之间的实现。

近年来,DevOps的工具链变得越发繁多和复杂。因此,选择适合企业业务的工具链尤为重要。传统应用和容器化应用交付的过程中,其核心都是持续集成服务器。换句话说,持续集成服务器是DevOps最重要的一环,是交付流程的发动机。在开源领域,持续集成服务器最为有名的是Jenkins,也是最适合的持续集成产品。

Jenkins

Jenkins可以在非常多的场景中和其他的持续交付工具进行集成。

4887王中王鉄算盘奖结果 10

上图展现了Jenkins的几大特性,首先Jenkins具有非常强大的插件支持,目前大概有1000左右的插件可用;第二,可以与100多个DevOps工具无缝集合使用;第三,它还可以和DevOps的工具链集成;最后,它还可以和DevOps的Pipeline集成,上图也给出了不同阶段下,Jenkins可以集成的工具。

Jenkins固然很好,但其也存在自身的问题。大家对Jenkins1.0有所诟病,主要是Jenkins1.0其老派的设计和功能。

4887王中王鉄算盘奖结果 11

而在今年新发布的Jenkins2.0版本中,我们可以看到如下5个方面的更新:

UI 更新,新版的UI界面如上图所示。

Pipeline as code (Pausable,Durable)

Servlet3.1 and WebSocket

Docker Support in Pipeline

Blue Ocean beta

为了让开发者更好地使用Jenkins,阿里云在在Jenkins相关的领域做了一系列的增强:

目前,阿里云提供一键部署Jenkins及Slaves的能力:

·提供Go、Java、Python、PHP、Node.js的slave镜像;

·基于docker-compose一键部署master与slave集群;

·基于容器服务的运行时管理,可以动态生成任务构建容器。

提供更多针对阿里云环境的部署插件:

·阿里云容器服务插件。

提供Jenkins基于阿里云场景的DevOps方案:

·惠及云计算的能力,实现CloudOps、ContainerOpS;

·蓝绿无宕机发布、弹性扩容应对尖峰流量等。

Jenkins容器服务解决方案

4887王中王鉄算盘奖结果 12

阿里云结合云服务的管理能力、Docker的标准化交付能力与Jenkins的强大的插件系统与任务分发引擎,为开发者提供云原生的Jenkins ContainerOps解决方案。

下面分享一个客户利用DevOps改造Docker的真实案例。

4887王中王鉄算盘奖结果 13

该客户原来的结构分为本地开发、测试环境测试、集成环境、预发部署测试、线上部署、运维与报警。其中前两个过程是开发感知,中间两个过程是测试感知,最后两个过程是运维感知,而整体过程是由架构师感知。

当其进行DevOps改造之后,中间的步骤基本都采用自动化的方式,自动化整体设计是由架构师负责完善地。改造完成之后,DevOps节约了大量时间和成本,让架构师更多的感知架构的改造;让开发专注在本地的开发上;运维更专注于线上运维与部署。

基于Docker的DevOps的难点从来不是如何搭建持续集成服务器,也不是如何通过容器管理平台进行运维。而是Docker带来的学习成本(Dockerfile是第一大门槛)。从四个角色来讲,运维工程师和架构师是不可能不感知Docker的,那么我们是否可以让开发者尽量少的感知Docker的存在?

答案是必须的——Derrick!

4887王中王鉄算盘奖结果 14

Derrick主要解决的就是让开发者专注本地开发,降低Docker的学习成本;它通过独特的机制自动生成Dockerfile,让开发者无感知Docker的情况下在本地调试容器化的应用;此外,Derrick现已支持Node.js、Python、Java等多种语言,并将于近期开源,敬请期待。

本文由4887王中王鉄算盘奖结果发布于服务器&运维,转载请注明出处:自动化运营经历谈,当容器与CI

关键词:

最火资讯