开发与运维，除了相杀也可以相爱！

我还是各位IT兽们的可爱、博学、低调、人见人爱花见花开、谦虚但经常口不择言的微软云计算解决方案合作伙伴发展经理兼顾问兼微软认证云计算专家兼主播兼逗哏兼捧哏的——彭艳霞，好盆友们都叫我Grace~

今天的主题跟最近几年很流行的DevOps有关。

有人说DevOps好，有人说DevOps不实用不落地，说的我也好奇起来。

直到有一天，我家的技术专家GG给我说了一个故事，这个故事基于传统IT项目上线都会碰到的一个问题——开发和运维之间的断桥。

什么是 DevOps？

开发部落要开发一款新产品：

这款产品要使用最新最炫的技术，来保证客户的所有花俏的需求，从而给公司带来百万的利润。

这款产品被要求使用最新的技术和运行平台，什么微服务啊、Docker啊、Go语言啊、Python啊......还得马上交付！

于是开发部门没日没夜的加班、赶代码，终于如期完成了第一个版本。

然后他们把自己的“杰作”一股脑的甩给了运维部落。

运维部落苦恼了，他们心中充满了恐惧：

· 这款优秀的产品在目前的底层平台上无法运行，因为这个平台太古老，空间不足，不支持XX版本；

· 这款产品的体系结构跟我们的存储，网络，部署，安全模型不匹配；

· 这款产品的报告，安全，监视，备份，服务提供着实搞不懂 ，所以没法把它做成实际可用的产品。

正当运维部落花了两个礼拜加班加点好不容易把产品搬上运营服务器上，还在胆战心惊地看着各项服务指标是否满足运行要求时......

开发部落的第二个迭代版本又来了！

因为这次做了比较大的版本修改，数据库的访问方式、前端负载架构都有所变化，所以……

运维部落几乎要重来一次，重来一次，重来一次…

沮丧的运维部落一边按照开发部落给的——不知道是哪个版本的架构手册搭环境，一边开始记录各种问题，源源不断的给开发部落提问题。

而开发部门的回应基本上都是：

· 这不是我们的错！我们的代码非常完美，而是你们部署做的太差劲了；

· 运维部落比较笨，他们不懂新技术！为什么他们没法实现最新的技术呢？为什么他们这么落伍呢？

· 在我的机器上运行的没问题啊……

在物联网爆发的时代，这个断桥可能造成的潜在威胁已经不止是折磨运维部落这么简单了。

比如，谁都知道物联网的连接设备是像酱紫的增长吧：

然后Mirai、Hajime、BrickerBot就像推倒多米诺骨牌的手指，把一排排没有加密通讯、Admin为空、后台云不在Azure上…嘿嘿嘿，或者其他安全的云服务上的物联网设备们变成僵尸网络的肉鸡。

但既然是问题，就该有解决方案吧？

所以有人想出了这么个词：DevOps，顾名思义——就是要把开发和运维部落合二为一！

Dev和Ops合二为一的好处，来看某个报告的说法：

在DevOps大概念里有三个重要子项：①微服务、②容器（Container）、③Docker

微服务

即把应用拆成足够小的松耦合部件，部件之间按照一定规矩联合起来，为大目标服务。

于是，要对这个由好多个组件组成的应用来做迭代版本，就变得更加轻巧。

就好像一辆车，今天某轮胎被杀千刀的钉子扎了个洞，你肯定不是拿回原厂重新上产线，好点儿的去4S店，差点儿的随便找个路边摊就能换了，换好轮子大不了做一个定（ce）位（shi），司机就可以重新发车了。

不过这个微服务说起来也不是省油的灯，俺刚才说的“足够小“就是一个陷阱，究竟多小才叫足够小？

所以这事儿做起来又是莫衷一是，所以才有大牛们说落地难。

当然，也跟开发部落不了解——微软云Azure和开发工具上已经有可以简化微服务框架的服务有关哈哈。

容器

所谓容器，你可以想象这是一台Mac Pro，只是里面Office 365，Visual Studio啥都配置好了，你作为一个喜欢Mac的IT兽，拿来就可以开发。

有没有发现刚才毫无痕迹的广告植入？

是的，在上周的Build大会上，微软已经宣布Visual Studio可以跑在Mac上啦！

这意味着史上对DevOps支持最完善，工作效率最高的开发平台，可以跨平台满足全栈IT兽们的需要啦！

在2015年管震老师出版的《云，就该这么玩儿》里，就已经描述了容器这个东东。

容器的出现，跟集装箱出现的原因是一样的，把好多不规则的东西塞进一个规则的集装箱里。

在IT系统里，则说的是一个虚拟运行环境，这个箱子搬到哪里都行，开个窗口就能营业！

Docker

Docker，是用来组装／搬运／拆包容器的工具：

于是，基本的思路大概是这样的：

1. DevOps的同学们，一边用看板管理开发，一边把开发环境打个包，放在一个容器里面。

这个容器包含运行的所有东西：代码、运行环境、系统工具、数据库、服务之间的依存关系…

2. DevOps的同学们一旦开发完，这个容器就包含了所有运行这个应用所必要的环境。

所以根本不需要再让运维部落再照葫芦画瓢搭建一套运行环境，直接把这个版本施一个“分身术”丢到生产环境中，这个应用就开始逛吃逛吃地跑起来了~

3. 一旦用户有反馈问题，DevOps就开始在原来版本上改代码测试改代码测试，搞完之后又生成一个新版本。

这样一来，你看世界多么美好，再也没有开发部落和运维部落之争了，再也没有互相伤害了，当然也可能再没有运维部落了…...

好了，我再拿一个场景更通俗地818——

Docker、Container、微服务在DevOps里的作用

Docker，就像往集装箱里装货物的码头工人那样，它把应用打包成具有某种标准规格的集装箱。

用计算机领域语言来说，这种按照一定规格封装的集装箱叫「镜像」。

其实就是将你原来的代码加点额外的内容，格式啥的，摊在桌上拍个照；而且这个镜像也只能由Docker来解析。

集装箱减少了货物的运输工作量，那Docker镜像又有什么相似的优势呢？

首先可以看看Docker出现之前的应用部署是啥样的。

比如说我要部署一个django应用，要做哪些事情呢？

上面的描述可能有些夸张，但也绝不是不可能发生。

在Docker出现之前，这些正是运维人员很多时候都在做的事情，在不断的重复工作上，浪费了巨大的人力物力。

Docker出现之后，首先就有标准的交付件了。

 说Docker就像集装箱那样，关键作用就是「标准化」，它的具体产物其实就是「镜像」。

在Docker中，它指的就是：把你的应用本身，按照一定的格式封装（其实就是一些按规则执行的命令行）成一种具有某种标准规格的东西（就像集装箱把你的货物封装起来类似）。

但在Docker中，镜像是无法直接运行的。

怎么避免这个问题呢？就是再给他加一层！

多加的这一层，就叫容器（container），这个名字挺形象，它就像瓶子这样的容器一样，你的应用在里面运行，而且多了一层安全机制。

你想使用服务或把你的应用跑起来的话——只需要使用镜像新创建一个容器就可以了（也是一条命令搞定），而镜像还放在那里不动。

笼统地说，镜像分为两种：

Ⅰ. 简单的称之为基础独立镜像

它一般是一个独立的服务，最独立的服务镜像，莫过于各种精简的操作系统了。

它们被封装在镜像中，作为最基础的服务，基本上所有镜像都离不开它,但对于我们这些普通应用开发者来说，一般不会直接使用这种镜像。

如果要使用这种镜像，我们的Dockerfile一般类似于下面这样：

Ⅱ. 姑且称之为组合镜像

它建立在一个独立镜像的基础上，在上面组合了其他服务，比如python服务，或是MySQL之类的服务。

作为比较顶层的应用开发者，我们一般会直接使用这种组合好后的服务镜像。

Dockerfile则类似于这样：

其实像上面的python服务，其本身也是建立在一个基础的操作系统之上的。

如果我们查看dockerhub上的python的Dockerfile，就可以明确这一点：

而我们自己构建的镜像，也可以称之为一种组合镜像。

我们一般使用Dockerfile将自己的应用代码，加上上面的某些具体的服务镜像（比如python）再组合起来，就可以构建我们自己的应用了。

Docker 究竟做了什么简化？

Docker正是在部署过程中，将上面那些重复的部分，由Docker自动化完成。

只需要在第一次部署时，构建完可用的Docker镜像。

然后在以后使用的过程中，短短的几行命令，就可以直接拉取镜像，根据这个镜像创建出一个容器，把服务跑起来了。

所需要的仅仅是安装了Docker的服务器，一个Dockerfile文件，以及比较流畅的网络而已。

· 需要python3环境？

直接 from python:3.x 搞定；

· 需要迁移服务器？ 

直接把应用连带Dockerfile，volumes数据拷贝到新服务器上，几条命令又搞定；

· 需要作为服务给别人使用？

Dockerfile即是最清晰的部署文档，维护一个官方镜像即可，谁需要就直接拉下来几条命令部署上就行了。

说到这儿，大家理解了DevOps、Docker、Container、微服务了木有？

前排有IT兽举手：

这位托，哦不是，这位看官你真是问到点子上了。

Docker最早由DotCloud公司发布于2013年3月，作为一个开源项目，在仅仅1个月的时间里下载量就超过10000次。

2014年6月，Docker发布了1.0版本，这时Docker的下载量已经超过275万，到今天这个数字已经超过了10亿。

然后，微软就和Docker相爱了。

在Visual Studio 2015里就有Docker Support：

当然，Visual Studio Code 的 Docker 插件也有哦，为开发人员提供跨平台的 Dockerfile 和Docker compose file 编写支持，可以在Windows/Mac/Linux 这3大操作系统上使用，包括自动语法补全和帮助信息的鼠标悬停显示

然后，Visual Studio Team Service / Team Foundation Server 上基于Docker的持续集成和发布管道任务——直接在CI/CD过程中完成容器的构建，Registry的注册上传和部署：

既然DevOps是贯穿开发和运维的，当然云端支持也少不了

Docker Datacenter on Azure可以直接通过 Azure 的软件市场一键创建企业级的容器数据中心；

这里包括：用于进行统一调度的UCP，用于容器注册和托管的 Trusted Registry 和提供企业级支持的 Docker Engine 用于运行应用负载。

这基本上意味着，你可以在1个小时内建立一个托管在云端的，基于容器的数据中心，同时还可以获得Docker和微软所提供的企业级支持。

运行于Docker容器中的 SQL Server on Linux 版本：SQL Server不仅仅可以跑在Linux上，现在也可以跑在Docker 容器里面。

SQL Server这种核心产品都搬到Linux和Docker上面去了，可见微软开源和开放战略的决心。

混合模式的Docker数据中心支持：借助 Azure Stack 私有云解决方案，你可以在自己本地的数据中心中搭建一套与Azure同样技术架构的私有云，并且将它们打通作为统一的企业云平台使用。

很多企业都在自己的数据中心中投入了上亿的资产，能够将这些计算资源与公有云打通，使用同样的技术架构，同时提供容器化支持对于企业的吸引力是相当大的。

我们今天不可能说完整个微软为DevOps提供的无论从流程、人员协作、又或是工具上的贡献和实践，因为工具上大概会有下面这…很多点可以跟大家分享：

拎出来Azure Container Services也有好多要讲：

从配置，到宿主管理，到容器编排到监控，Azure都有对应的技术在支持。

最后加一句：微软最近宣布Azure Service Fabric SDK的源代码已经开源。

Azure Service Fabric是一个分布式平台，用于微服务的打包、部署和管理；

SDK开放了Service Fabric平台中与.NET应用集成的Service Fabric API。