初步使用 Docker 后感

e2ex 9年前

来自：http://testerhome.com/topics/2549?from=groupmessage&isappinstalled=0

思寒的评论：

我们公司用到了docker. 说下我的感受吧.

目前测试环境是用docker构建的. 除了docker环境外, 也同时编写了一部分的自动化控制脚本搭建. 两者并行是因为历史原因. 在组内我是推荐用docker的. 也受到了质疑. 说下我的感受吧.
docker最大的特点

虚拟化.

这个虚拟机技术会为未来的运维和云中心节省很大一笔收入. 因为他没有了虚拟机OS这个很大的负担. 节省的资源很大. 这个肯定会被所有的云计算服务商重视.
容器技术是工作于进程. 是内核进行了资源隔离. 他的性能接近原生. 如果是单纯当成一个虚拟机软件. 那还不如virtualbox方便.. 他的这个性能提升对我们QA基本是没太大收益的. 对运维和全球的节省那可很大了. 所以几乎所有的云计算中心都在尝试或者已经使用容器技术. 未来更多可能是跟虚拟化融合.主体计算肯定会在容器中.

面向交付.

docker基于进程. 他发布出去后用户面对的也是进程入口. 这样的交付方式革命性的变化. 举个例子. 我要安装jira. 传统的方法是安装服务器, 安装tomcat, 下载jira. 配置jira,启动jira. 而在docker中. 所有过程就是一个docker run xxx/jira一行命令即可搞定. 其他软件也是如此. 它是面向交付的.比如复杂的ELK, 也只是几个命令就可以搭建起来. 很多细节都被封装起来了.

环境版本化管理.

新老版本更新的时候, 对于一家公司同时维护一套环境我觉得已经很吃力了.更别提是维护两套新老版本的环境. 这在测试中是很需要的. 但是维护起来却复杂. 环境大家要抢着用. 用坏了还得修复. 新老版本重新搭建费时费力. 架构复杂等都在制约QA. 而docker把持续交付变成了现实, 而且还大大的扩展了概念. 利用docker. 同时维护起来很多套完全不同环境不同分支的环境.

阻力

在推动docker使用的过程中 我收到了很多的阻力.
首先是我们的COO反对. 他是行业的一个大牛. 他推荐我使用vagrant来管理环境. 因为这个方案是成熟的. 支持所有平台. 支持多种虚拟化技术. 甚至还支持docker. 但是我发现vagrant的能力docker正在慢慢的具备完善, 而且更方便. 所以我没有用vagrant
第二个反对的是研发总监. 研发总监认为docker太超前了, 有技术风险. 经过对docker的摸索, 也发现的确是很多坑.不过COO和研发总监对我还是相对开放. 说你搞定就行. 他们要效果. 所以我得以继续的改进docker的应用方案.
第三个反对的是我们的测试经理. 他认为docker太超前, 还不成熟. 在我刚开始应用docker的时候, 的确一开始因为研发的架构有问题, 导致docker应用出现了一些问题. 比如研发的数据库在不同的分支上是不一样的. 这就需要数据库也要版本化和自动化. 前期没考虑到数据库的问题, 所以docker搭建出来的环境偶尔会有问题,导致测试经理觉得docker很不靠谱. 后来我发现了问题的根源并解决掉就没事了 到目前为止, 我们的测试经理仍然不信任. 他自己也单独维护了一套自动化脚本.

收益

前面介绍的docker后两大优点让我们公司受益很大. 我们的研发模式是分支开发主干发布. 这就意味着同时会有很多分支在进行开发测试. 共用一套环境很容易出错. 也存在资源争抢. 就是部署多套更新维护也很费劲.我的做法如下
1. 用docker实现环境的自动化部署.
2. 搭建一个每日构建的环境. 基于要发布的master分支
3. 对同时在开发的各个分支分别根据需要构建特定分支的环境.
4. 研发和测试通过jenkins上的一个job自动构建环境. 构建的时候需要协商不同模块的分支. 然后一个定制化的环境就出来了

这样环境的管理就变的非常有趣了, 环境开始跟代码一样进入了版本化管理了时代..
主干版本的环境一直存在. 每日构建. 构建的时候对环境建立一个tag标记. 可以跟研发的commit保持一致.
其他人测试只需要在自己的机器上动态的生成新环境即可.
每个人都有自己的一套或者多套环境.
docker可以随时决定启动某个老版本的环境进行验证. 也可以决定启动两个不同分支的环境进行对比.

我搭建了一个docker distribution. 也就是原来的docker registry. 公司内任何人都是随时利用docker命令直接同步完整的过去并启动使用

对于docker,我也很开放. 我告诉所有人, 不管我们用不用docker, OneAPM的客户很多已经开始用docker了, 他们希望我们的监控产品可以支持docker. 甚至在docker里面运行, 所以docker本身就是我们应该测试的一种场景.
最重要的是, 我们要观察docker和传统环境管理两条路的效果, 让组员去选择他们喜欢的技术体系. 经过不断的观察和验证, 我发现在使用了docker之后组内的人都倾向于用docker. 至于研发, 则是强烈赞同用docker. 研发还想上Mesos管理, 这次则是轮到我反对了, 我觉得目前整个公司都还刚用上docker, 很多人还没概念, 不要走的太超前....
说话的时候我都感觉到我也快成了一种阻碍生产力发展的因素了.

现状

目前我仍然在不断的研究如何让docker跟持续交付, 环境版本化, 甚至是更多的测试技术融合在一起 ,比如新老版本的变更diff, 问题自动定位. 数据库和接口diff测试. 以及新老版本的性能对比等. 我总体很看好docker的发展.

docker的最新现状

  1. docker已经支持windows, 微软已经发布了支持IIS的docker
  2. docker已经在所有大公司里面都开始用起来了, 目前主要是运维.
  3. 原来越多的产品在使用docker作为发布方式
  4. Jenkins+mesos+docker已经成为新一代的架构选型.

此处开始是原来的水贴。。。

这几天在尝试用 docker 来配置 appium 源码环境和 ELK，虽然还没完成，但感受到了一些 docker 的特点，觉得挺不错的，在这里分享一下。

这个纯属水贴，主要是让对 docker 没有了解的人了解一下 docker 是神马，关于 docker 的原理及深入了解请查看 docker 官方网站的介绍

什么是 docker

docker 是一种基于 linux 容器技术的虚拟化技术。相比虚拟机，容器虚拟化减少了操作系统这个庞大的部分，但相应地，它只能运行 Linux 上的程序。

虚拟技术早就有了，但为何现在 docker 能如此流行

在 docker 出来之前，我们用的虚拟化技术主要是虚拟机。对于个人用途，虚拟机已经能满足大部分需要了。但当遇上需要配置大量虚拟机的环境时，虚拟机就显得比较臃肿了。

下面我们看看在 windows 下用 docker 和用虚拟机搭建一个基于 Ubuntu 的 LAMP 服务器有什么不同：

虚拟机：

  1. 安装虚拟机软件，如 Virtualbox
  2. 建立一个虚拟机，在里面安装 Ubuntu 系统
  3. 安装 apache
  4. 安装配置 MySql
  5. 安装配置 PHP

Docker：

  1. 安装虚拟机软件 boot2docker
  2. 安装 docker
  3. 使用docker run -d -p 80:80 -p 3306:3306 tutum/lamp下载并启动 LAMP

使用 Docker ，你节省了：

  1. 数百兆甚至 1G 的空间
  2. 虚拟机的安装镜像（某些时候获取这些镜像所花的时间很可观）
  3. 一个完整的 Ubuntu 系统

所以，docker 相比虚拟机，最大的优势在于快速部署和使用，同时由于 docker 不是完整的虚拟机，它的开启和关闭速度要比虚拟机快的多（一般 10s 内）。

除此之外呢？

Docker 把容器镜像做成了类似代码库的形式，并把它们放到 DockerHub 上供所有人自由下载。从此之后，部署服务器环境变成了在 DockerHub 上寻找合适的镜像并下载使用，我们再也不用按着各种官方文档来慢慢配置服务器啦。

悄悄告诉你： Docker 还支持版本管理呢。

这么好的东西为啥我们都没怎么用过？

是的，对各种环境部署来说， Docker 是一个好东西。但对于对运维领域接触较少的人，没用过 docker 是正常的。因为 docker 运行的程序都没有 GUI 界面，而且 docker 只能运行基于 Linux 的程序（感谢思寒补充，docker 也可以运行 .net 程序，详细请看 Running ASP.NET 5 applications in Linux Containers with Docker）。在这个操作系统界面还要比颜值的时代，没有图形化界面的虚拟化技术普罗大众怎么会感兴趣呢？