Docker Hub

Docker Hub

游戏开发  Laradock应用Docker实现开发环境

mrkelly 发表了文章 • 0 个评论 • 3372 次浏览 • 2017-02-22 10:27 • 来自相关话题

简单点 最近,跟一个大学金融系的同学交流,发现他对科技发展的动态非常了解,然而对于一些技术关键字的应用并不是很理解。 对于普通不懂技术的小白来说,如果去咨询一些IT行业技术大牛,他们往往会获得一个一脸懵逼的回答。比如说,他 ...查看全部
简单点
最近,跟一个大学金融系的同学交流,发现他对科技发展的动态非常了解,然而对于一些技术关键字的应用并不是很理解。

对于普通不懂技术的小白来说,如果去咨询一些IT行业技术大牛,他们往往会获得一个一脸懵逼的回答。比如说,他问我“云计算”是什么?百度百科:

云计算[1] (cloud computing)是基于互联网的相关服务的增加、使用和交付模式,通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。



01.png

别说一个技术小白了,就算现在我看完这句话,我也是一脸懵逼,难为大家了。站在技术小白的角度,去看看网上的一些“云计算”的解释,你会发现,还是那么的难以理解。

用产品的口吻来说:用户体验不好。

我尝试给他作出类比:

“古时候,人们家里做一口井,水从井里打出来,而现在,我们扭开水龙头,水就来了; 10年前,你要装软件,得跑去电脑城买光碟,而现在,连上网打开应用商店,软件尽在眼前——这就是云计算”。



当然了,本来“云计算”就是一个很广的问题,这样的解释无非是拿出其中之一的应用场景作类比。但是它能帮助普通人更好的理解。

我觉得这是一个非常有趣的过程:用跨界思维,用拟物或拟人的方式,去提炼简化一些看起来很复杂、枯燥的技术关键词。


Docker是什么?

回归正题,我们讨论Docker。估计喜欢浏览技术新闻资讯站的同学,都会知道Docker——传说中改变世界的东西,它改变了应用的部署运维。那么Docker是什么?来看看百度百科:

Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。



当初,看完它的解释后,我的第一反应依旧是懵逼,因为它跟我们脑海中常见的物理机、虚拟机的概念相比,是一种未曾想象过的新事物。

鉴于所在工作环境周围,还没见过应用Docker在开发环境的同学(希望大牛云集的项目不要鄙视),而我又觉得用通俗化的思路去解释Docker思维是有价值的一件事,这也是本文的成文目的。
02.png

这是Docker的官方图标——一只大鲸鱼,上面有各种各样的集装箱;鲸鱼就像一个操作系统,上面装着各种各样的集装箱——软件

也许你会问,这不跟我们iPhone应用一样吗?手机操作系统(鲸鱼),里面有各种各样的App(集装箱)。

但是,仔细想想,iPhone上的App,Android上能运行吗?——不行。因为iPhone使用IPA格式的App包装方法,而Android使用APK格式的App包装方法,两者部署上是非常的不一样的。

能不能在Android上,运行iPhone应用,而又不使用损耗资源的虚拟机技术? 这就是Docker——它应用在PC平台上的,可以让不同的操作系统平台,占用很少的资源,运行同样的软件程序

03.png



它就像一个提供开发型软件的应用商店。以往,我们需要安装MySQL数据库,我们首先要想,我的操作系统是Windows?我的CPU是64位? 然后我们找到了MySQL Windows 64位版本进行下载,然后开始安装,安装在C盘?安装完成后,把数据库账号密码设置好?

而在Docker时代,我们只需要下载MySQL的Docker镜像安装就可以了。

这个思路推而广之,Android上利用Docker运行iPhone应用什么时候可以做到?这是技术上可行的,但这里不作过多幻想了。

Docker不是什么新生事物,早在2013年就诞生了,而它的核心技术cgroup早在2006年就写进Linux内核了,直到这2年,才渐渐开始广泛的应用。

Docker常见的场景,是部署和运维。今天,我们抛开技术细节、理论、运维需求,简单谈谈Docker怎么应用到我们日常游戏开发环境当中,并让团队的工作流程起到什么样的优化。

快速搭建MySQL+Redis开发环境

Laradock是一个PHP的Docker开发环境,使用它可以极其方便的快速搭建PHP开发环境。 它不但包含了PHP语言执行环境,还包括了一系列相关工具,其中包括我们非常常用的MySQL、Redis。

在Laradock的官方文档中,就有这样的一句话:

Use Docker first and learn about it later.
> 先使用Docker,然后再学习它。



是的,先使用它,然后再深入学习Docker的一些很原理,一个自上而下的学习过程,可以让你更加快速的理解和应用Docker。应用Laradock是一个很好的Docker学习起点。

要使用Laradock,首先你得安装Docker。 一般有可以选择下载Windows版Docker
下载Mac版Docker,跟着安装步骤安装即可。

而在国内,访问Docker的镜像仓库非常的慢,因此,需要设置国内的加速镜像仓库。
04.png

安装好Docker以后,会有小鲸鱼的图标出现在系统托盘上。右击出现菜单(macOS系统则是左击),并选择“Settings”。
05.png

Windows环境时,选中“Docker Daemon”界面,往"registry-mirrors"字段里添加镜像仓库的地址。

为什么要配置镜像仓库地址?像前面所说的,Docker有点像应用商店——把需要的开发软件,下载并安装。因此镜像仓库()上储存着各种各样的“镜像”,可理解成别人预先制作好的开发软件。包括我们常见的MySQL、CentOS,其官方都会维护一份Docker镜像。

使用Laradock,你可以使用它在GitHub上托管的源码:
bash
git clone https://github.com/laradock/laradock
cd laradock
docker-compose up -d nginx mysql redis memcached

或者,如果连命令都不想输入(或者git都还没安装),下载https://github.com/mr-kelly/laradock/archive/master.zip ,解压后,在安装好Windows环境双击执行start.bat批处理。
06.png

这样的一条命令,呼叫Laradock下载、启动了nginx、MySQL、redis、memcached四个主要容器。这几个不同的Docker容器互相组合,并映射端口到本地。比如把localhost:80端口映射到nginx容器的80端口,把localhost:3306端口映射到MySQL容器的3306端口。

这时候,使用你的MySQL数据库工具(比如Navicat),输入连接地址localhost,账号root,密码root,你就能连上了MySQL容器中的MySQL数据库程序了。


# 为什么我会使用Laradock?

在以往,我一般会使用XAMPP来当作我的PHP HTTP开发环境——它内置了Apache、MySQL等开发组件,并且能以“绿色”软件的方式安装运行在我的电脑上。 直到有一次,XAMPP在我的macOS上,出现phpredis扩展无法访问Redis的问题,折腾很久也没找到具体的原因,最终转而使用Docker搭建开发环境。

在日常的工作中,我们其实经常遇到这种情况:因为一些跟业务工作的一些小问题,比如装系统啊、环境配置的坑啊等等,会耗费我们非常多的精力。

要真正的应用Docker到您的开发环境,需要根据项目业务、技术选型,来自定义Docker镜像,比如说,一个使用Java+MySQL的项目,除了MySQL镜像外,还需要Java运行时镜像,多个镜像互相组合。

可能你会疑惑,为什么要弄成多个镜像?使用一个Linux发行版镜像,然后在上面安装好Java、MySQL,再制作一个完整的镜像不就行了吗? 是的,这也是可行的,只是说这样做法,类似于编程开发中的“耦合度高”,就是当这样一个完整的开发环境镜像在某一天需要修改时,比如说其中的MySQL版本更新了,就需要对这个镜像进行重新制作。而拆分成多个镜像互相组合,则只需要使用官方对应版本的新镜像即可。

怎么使用Docker进行镜像的制作,官方的文档很多,这里就不重复“造轮子”了。Laradock的Github地址https://github.com/laradock/laradock ,上面有其更加详细的使用方法。

应用Docker开发环境的场景

# 一个新人入职

新人工程师走进公司,会有一个熟悉工作环境的过程,其中一个耗时的环节,就是安装开发环境。这是一个非常折腾人的过程,如果你是使用大型IDE的开发者,比如说安装MySQL、SQLServer、Android SDK等大型开发软件,这将是一个耗时的过程——首先你得找到软件包,然后再进入漫长的安装过程。最常见的实践是公司内部共享,把这些常用软件都共享出来,让大家安装。然而大家的习惯不同的,操作系统也不同,过程中依然会遇到种种兼容问题。

曾经一个做Android开发的朋友,在入职公司的第一周内——花了一周的时间,终于把开发环境搭建完成,让Java工程编译通过。

# 游戏策划跑单服

游戏团队开发的过程中,免不了出现非技术人员需要在自己机器上启动游戏服务器进行测试的情况。因此,“搭建开发环境”这个技能,会出现非技术人员身上。跟程序员相比,非技术人员“搭建开发环境”或“配置服务器环境”是相对更加难的事情,他们最需要的是有一种“双击就能运行”的单服运行体验。 有一些非技术人员和程序员之间对话,是我们经常听见的:

“嗯,这个功能我提交前测试是正常的——你的环境干净吗?需要的数据都干净地重新生成了吗?第三方库的二进制文件更新了吗?你们几个人测试的版本一致吗?要不你 Cleanup / 重启 / 重新保存 / 重新建个账号试试?”



(引自厚积薄发 | 游戏引擎技术点滴

然而实际的开发过程中,程序、策划之间是缺乏换位思考的,程序员更喜欢直接在自己的工作上开码,而不是为非自己工作范围内的体验进行优化。因此,“技术流”策划甚是常见,不但了解软连接硬链接的创建删除、还熟悉各种各样的SQL数据库、还会通过Visual Studio编译程序,甚至有很多都能直接编程的。

# 开发软件

那么能不能把装好软件的开发机整个做一个Ghost系统镜像?

这确实是我前两年项目所使用的方法:在一台电脑上,装好所有开发环境软件,然后使用Ghost打包一个系统镜像。想法很美好,但是实际过程却很难执行。一个镜像大小动辄10多GB的占用,克隆慢,恢复镜像也慢;更要命的是,开发环境在研发过程中经常的变化,比方说想把旧有镜像中的MySQL 4升级成MySQL 5,怎么做? 不停的重新构建虚拟机镜像? 太艰难。

后来我为了达到这样的目的,完整的MySQL执行程序、MongoDB执行程序直接放到SVN上传。从程序员角度来看,这是肮脏的,把一些无关重要的二进制文件进入到了代码库;但是从用户体验的角度来看,这是提高了非技术人员的使用体验。

类似这个情况如果应用Docker后,我们大可以只需要把MySQL或MongoDB的Dockerfile定义文件上传到SVN,非技术人员在首次启动时就会自动从容器仓库(内网或外网均可)拉取到对应的容器并启动,快速并且规避兼容性问题。

# 一些Linux-only的程序

redis对Windows的支持非常有限,skynet游戏框架不支持Windows平台,但是对于使用Windows的人来说,会使用一台虚拟机来进行开发。

而使用Docker,则可以改善这样的开发环境:部署一个Linux容器,并把本地代码文件映射到容器中,做到使用本地环境编辑代码、使用Docker运行程序;Redis官方提供Docker版本,体积非常小,让Windows下运行不再困难。

# 导入真实玩家数据

在项目运营中,出现的一些BUG,我们希望能模拟玩家的数据进行测试,这时候需要把一些玩家的数据导入,进行测试。一般来说,我们需要把数据库的数据导出,然后再在开发环境中导入。

而如果运营的项目是使用Docker容器进行部署的,那我们只需要把这个容器整个拖回到本地执行,我们就能完整的模拟到真实数据环境了。 同样,应用这样的思路也可以进行数据库的备份。


# DevOps

说起Docker,总是免不了DevOps——开发运维一体化。这是一个很大很抽象的思想话题,但我们这里只简单的介绍其中一种应用:开发所使用的Docker容器,直接丢到生产服务器,极简部署

比方说,我所在项目使用C#进行游戏服务器的开发,在Windows上使用.net Framework跑,实际运维环境则使用Mono。也就是说,实际运维环境中,如果出现了有.net Framework和Mono不同兼容性的BUG,这些BUG对开发人员来说都是前所未见、难以理解的——因为开发环境,跟运营环境,是完全不一样的,这会引领开发人员进入另一场爬坑游戏。

其他

# Docker原理
07.png

Docker的两大核心基础技术是namespace和cgroup,它们早在2006年的就被写进如Linux内核。

抽象来说,跟虚拟机不一样的是,虚拟机技术,把CPU、内存等所有硬件用软件化进行虚拟,形成一个虚拟的计算机环境;而Docker,则有点像“CPU中的虚拟CPU”、“内存中的虚拟内存”来对计算机进行资源隔离。
# Vagrant
在使用Docker之前,我一直使用Vagrant来进行开发环境快速部署。它们的目的很相像,但是又不是那么一回事。

Vagrant说白了,就是一个VirtualBox虚拟机的快速管理工具。以往使用虚拟机,我们需要安装VirtualBox,需要下载Linux发行版镜像,需要安装,安装后再安装各种开发软件。

而使用Vagrant,就像Docker一样,只需要一条命令,就可以完成以上所有的工作了。 只是,说白了,Vagrant就是一个虚拟机管理工具,它就类似于你使用了一个CentOS Docker容器,然后在里面安装好所有的开发软件。


--------------

在Web开发领域,看到很多程序员已经应用上Docker用于开发环境了;目前身边的游戏开发中还没看到,也希望Docker慢慢普及开来。

本文只是非常片面的展现了Docker应用的冰山一角——搭建简单开发环境。谨供你参考。

Docker生态系统一览

徐笑笑 发表了文章 • 0 个评论 • 10674 次浏览 • 2016-04-01 16:50 • 来自相关话题

【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Cen ...查看全部
【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Center,文章会详细介绍这些工具的功能,以及怎样能够更好地将这些工具结合起来。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网、华为等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

在过去的18个月内参加任何技术相关的活动或者阅读任何技术相关的文章时,你可能已经听说过Docker并且对Docker是什么以及它是用来做什么的略有所知。

简单来说,Docker是建立在过去的一些概念之上,但是对这些概念进行了更好的封装。Docker是一个用来创建“容器”的工具,这些容器仅仅包含你所需要的一个独立的应用或者技术堆栈。与虚拟机不同的是,这些容器共享相同的资源来管理容器与主机之间的相互作用。这一点使得Docker容器快速、轻量、安全并且共享。

“Docker建立在过去的概念之上但又对这些概念进行了更好的封装。”via @ChrisChinch
>
CLICK TO TWEET



就我个人而言,作为一个技术作家和主持人,我发现Docker对于创建演示文稿是非常宝贵的。我可以组装一堆我需要的组件,运行它们,然后再摧毁我不再需要的包和数据,以保持我的系统干净整洁。

许多开发人员在开发和测试过程中能够看到一个清晰的Docker用例,但是仍然想要了解Docker在生产中如何最好地工作。一系列第三方工具和服务的出现用来帮助开发人员从开发到生产过程中部署、配置和管理他们的Docker工作流程。

Docker已经通过一系列收购和产品发布建立了自己的“官方”工具包。众所周知,Orca项目在去年美国的DockerCon大会上公布了,虽然细节有点模糊。在我看来,与其说Orca是一个实际的项目或者产品,还不如说它其实是Docker不断增长的产品组合的巩固策略。

所以在这篇文章中,我会提出关于当前可用的Docker生态系统有哪些部分,它们如何帮助你,以及怎样更好地组合它们的一个总结。

“让我们讨论一下Docker生态系统的组成部分以及这些组成部分是如何配合在一起的。”



CLICK TO TWEET



#Docker Hub
任何使用Docker的项目的核心是一个Dockerfile文件。这个文件包含Docker如何创建一个镜像的指示说明。让我们来看一个简单的例子:
FROM python:2.7
ADD . /code
WORKDIR /code
RUN pip install -r requirements.txt

在这个例子中,该Dockerfile文件拉取一个特定版本的现有镜像,将当前本地目录复制进容器的文件系统,并设置它为工作目录,然后通过pip命令从一个文本文件下载Python依赖。

Docker Hub是预先写好的Dockerfile官方资源,提供公共的(免费的)和私人的(付费的)镜像存储库。如果你正在寻找一个Dockerfile来满足你的需求,首先在Docker Hub上搜索,使用项目文档、下载量和镜像等级来帮助指导你的决定。
1.png

#Docker Engine
Docker Engine创建Dockerfile文件并把它们转化为可用的容器。Docker Engine是Docker的核心,如果没有Docker Engine那么什么也运行不了。依据你的操作系统不同有几种下载Docker Engine的方案,你可以在这里发现更多的细节

依据Docker Hub中的一个镜像开启一个容器,应该首先拉取这个镜像并运行它。继续以Python为例:
docker pull python
docker run -it --rm --name script-name -v "$PWD":/usr/src/appname -w /usr/src/appname python:3 python app.py

这样就会拉取最新的Python镜像然后开启一个容器运行一个Python脚本并且运行完后退出容器。run命令提供了更多的选项设置,你可以在这里阅读完整的指南
当一个Docker run命令开始变得更为复杂,它可以创建自己的自定义Dockerfile文件或许是一个更好的主意。开启一个基于本地Dockerfile文件的容器,运行以下里面包含文件的目录:
docker build -t my_image .

这个命令将会创建一个名为my_image的镜像。运行以下命令开启一个基于这个镜像的容器:
docker run -name my_image_container -i -t my_image

这个命令会开启一个基于自定义的my_image镜像的容器,这个容器命名为my_image_container。
#Kitematic
对于那些宁愿避免命令行的用户来说,Kitematic是Mac OS X和Windows的一个伟大的GUI。搜索你需要的镜像,创建一个容器,你最好去Kitematic。Kitematic提供了基本的配置选项,但对于更高级的设置,你可能需要进入命令行。
2.png

你的容器出现在左手边,在那里它们可以被启动、停止、重启,更有用的是,你可以在那里找到容器日志和直接SSH(exec按键)访问。
3.png

#Docker Machine和Swarm
生产中使用Docker的第一步是了解Machine和Swarm,它们为各种虚拟化和云服务提供商提供了一套简单的工具集用以移动和缩放他们的本地项目。

“生产中使用Docker的第一步是了解Machine和Swarm。”



CLICK TO TWEET



例如,在Azure上创建一个Docker实例:
docker-machine create -d azure --azure-subscription-id="XXX" --azure-subscription-cert="/mycert.pem" ecodemo

这个命令使用预装的Docker创建一个Ubuntu 12.04-based虚拟机并命名为ecodemo。每个供应商都需要不同的参数和认证方法,这些默认设置可以被重写。在这个文档中可以阅读到更多的细节。

当与Swarm结合后,Machine可以创建Docker实例的集群,这个集群被视为一个单一的、大的Docker实例。每一个Swarm集群都需要一个master实例,这个master实例可以用下面的命令来创建:
docker-machine create
-d virtualbox
--swarm
--swarm-master
--swarm-discovery token://TOKEN_ID
swarm-master

这样就会在VirtualBox中创建一个Docker实例并且设置这个Docker实例为Swarm集群的一个master节点。TOKEN_ID非常重要,因为它可以帮助集群中的所有节点识别彼此。除了手动创建TOKEN_ID标识以外,Swarm也有发现系统来帮助你管理这个过程。

下面的命令使用相同的TOKEN_ID标识添加Docker实例到Swarm集群:
docker-machine create
-d virtualbox
--swarm
--swarm-discovery token://TOKEN_ID
swarm-node-n

swarm-node-n对于集群中的每一个节点来说都是一个唯一的名字。

现在,代替从单个虚拟机中开启容器,你可以在集群中开启容器,master节点将会把这个容器分配给最可用的和最有能力的节点。
#Docker Compose
Compose使得由多个组件(像容器)组成的应用程序更加简单,你可以开始使用一个命令在一个单一的配置文件中声明所有这些组件。

下面是一个Compose文件(称为docker-compose.yml)的例子,这个例子创建三个Crate数据库实例和一个Laravel(用一些额外的配置)PHP框架实例。最重要的是,容器与Links配置选项相连。
crate1:
image: crate
ports:
- "4200:4200"
- "4300:4300"
crate2:
image: crate
crate3:
image: crate
volumes:
- ./data:/importdata
laravelcomposer:
image: dylanlindgren/docker-laravel-composer
volumes:
- /laravel-application:/var/www
command: --working-dir=/var/www install
links:
- crate1
laravelartisan:
image: dylanlindgren/docker-laravel-artisan
links:
- crate1
volumes_from:
- laravelcomposer
working_dir: /var/www
command: serve --host=0.0.0.0:8080
ports:
- "8000:8000"
- "8080:8080"

所有这些实例和它们的配置现在可以通过运行以下在同一目录中的docker-compose.yml文件的命令来开始:
docker-compose up

4.png

你可以使用相同的子命令作为Docker的命令来影响所有以docker-compose开始的容器。例如,docker-compose stop命令可以停止以docker-compose开始的容器。
5.png

#Docker Cloud
容器的自动化管理和编排是Docker的主要功能,但却一直由第三方服务来提供,直到去年Docker获得了Tutum(它支撑着Docker云)。虽然没有完整的命令行工具(还没有),Docker云服务允许Docker Compose文件设置应用程序栈,所以它不是来自于生态型的其它部分的一个大的导流。

“容器的自动化管理是Docker的重要组成,但知道最近一直由第三方来提供。”



CLICK TO TWEET



例如:
crate1:
image: crate
ports:
- "4200:4200"
- "4300:4300"
command: crate -Des.network.publish_host=_ethwe:ipv4_
crate2:
image: crate
command: crate -Des.network.publish_host=_ethwe:ipv4_
crate3:
image: crate
command: crate -Des.network.publish_host=_ethwe:ipv4_

这样就创建了同一个镜像的三个实例,其中一个手动设置主机与Docker之间的端口分配,其他的端口分配是自动的。我将很快重新访问command。

如果你想在超过一个节点(节点能够运行它可以管理的足够多的容器和一个私有仓库上扩展应用程序,Docker Cloud是有偿服务。这对于实验目的来说足够了。记住,Docker Cloud默认管理托管在第三方托管服务器上的容器,所以你也需要支付费用。使得Docker Cloud代理运行在任何你管理的Linux主机上是可能的,你可以在这里找到操作指南
6.png

上面的截图显示了三个使用预先设定的规则运行在跨越两个数字海洋的实例上的Docker容器,这个预先设定的规则是根据你设置的参数来将容器分配给主机。它会自动确保你指定数量的容器始终在运行。

在之前的Docker Compose例子中,你可能已经注意到_ethwe:ipv4_。这是Docker Cloud的另外一个重要特征。许多分布式应用和服务依赖“服务发现”来找到同一服务的其他实例并进行通信。当在数据中心和物理机器上传播服务时,这往往需要实例的手动说明或者需要另一种方式来找到彼此。

Docker Cloud包括支持Weave在你的实际网络中创建一个“软”网络;所有的容器和应用都可以发现彼此,无论它们被托管在哪里。在上面的例子中,我们重写了向容器发出的默认命令,以确保它接收它需要使用此功能的信息。
#Data Center
到目前为止,本文涉及的大部分工具都是你安装,主机,和支持的工具。对企业用户来说,他们寻找安全性、性能和支持较高的保证,Docker提供了数据中心

它使用了覆盖这里的许多相同的工具包,但是增加了一个放置你的镜像的私有仓库,一个私有云,高级支持,和供应商可能吸引企业用户的第三方集成。这些包括LDAP and Active Directory用户管理,容器检测,和日志记录。
#总结
正如你从我的截图和你的实验中看到的这些工具,它们仍然感觉像是一套有关系但却松散耦合的产品,而不是一个紧密结合的“套件”。Orca项目似乎试图把重点放在建立所有这些项目之间的一致性上,使每一个项目都成为下一个项目的逻辑铺垫,而且所有这些项目都来自于同一个GUI或者CLI。其目的不仅仅是回答“为什么我应该使用Docker?”,而是回答“为什么我不使用Docker呢?”

“Docker的这些工具仍然感觉像是一组松散耦合的产品,而不是一个紧密结合的套件。”



CLICK TO TWEET



原文链接:Understanding the Docker Ecosystem(翻译:徐婷)

Docker Datacenter(DDC)介绍

ozbillwang 发表了文章 • 0 个评论 • 3763 次浏览 • 2016-02-28 15:07 • 来自相关话题

Docker 公司最近推出针对公司内部部署Docker容器的管理平台 Docker Datacenter (DDC)。 我上传几个关键的图表,可以方便的理解这个新产品。 图表一 ...查看全部
Docker 公司最近推出针对公司内部部署Docker容器的管理平台 Docker Datacenter (DDC)。

我上传几个关键的图表,可以方便的理解这个新产品。

图表一
Screen_Shot_2016-02-27_at_3.14_.26_PM_.png

DDC 是由DTR(Docker trusted registry)和 UCP(Docker universal Control Plane)这两个产品组成。对应 docker cloud 的产品就是 docker Hub(hub.docker.com)和Tutum by Docker 。 也就是说DDC针对的是企业用户在内部部署,Tutum 针对的是网络用户,在线部署。 市场定位完全不同。

图表二
Screen_Shot_2016-02-27_at_11.40_.31_AM_.png

这个图表说明DDC是如何工作的。 DTR (docker trusted registry)替代了我们常用的镜像注册服务。 增加了安全性。其后的UCP 基本上和tutum类似的功能。主要是针对私有容器的管理。当然安全性也提高很多。

图表三
Screen_Shot_2016-02-27_at_4.40_.49_PM_.png

这个是Docker hub 和 DTR 之间的对比。DTR 增加了ldap 和 active directory 的集成,使得用户管理变得方便。可以添加组织,赋予各组织不同的成员,和权限。 增加了对镜像的安全管理,有个签名的功能。 支持多方的存储方式。 还增加了日志输出功能,软删除镜像以及GC的收集。

图表四
Screen_Shot_2016-02-27_at_4.47_.33_PM_.png

这个是 UCP 和 Tutum 的对比。UCP主要是增加了TLS 和HA (高可用性)的支持,需要Swarm 的支持,可以管理网络和目录卷,也继承了ldap/AD。
图表五
Screen_Shot_2016-02-27_at_4.30_.48_PM_.png

最后这个图表有些牵强。Docker试图通过它告诉大家,他们家是最正统的,支持是最正宗的。但是,大家要记住的是Docker是一家带 .com的公司,也就是说,他不是非盈利组织,所以Docker Hub、Tutum、DTR、UCP 都不开源。DTR 和 UCP 都是需要购买 服务的。 否则只能试用一个月。但是就算购买了他们家的 “business day“ 支持,也只是美国工作时间支持,对中国或者亚洲用户没用。一定要买最高级别的 "business critical “才会有 7 X 24 服务。

我能介绍的就这些了。 DDC使用下来和Tutum 的感觉稍有不同。DDC 里的 证书,权限的管理也不简单,或者说具有挑战。需要对Docker Compose、Docker Machine、Docker Swarm 全面的理解才能用好这个产品。

备注:

Docker UCP 需要 最新的 Docker engine v1.10 版本支持。

推荐链接:

UCP产品介绍
https://www.docker.com/products/docker-universal-control-plane
https://blog.docker.com/2016/02/docker-datacenter-caas/

价格
https://www.docker.com/pricing

Q:请问DDC需要使用Docker的数据中心,还是可以和企业自己的数据中心整合,做混合云,或私有云?

A:  DDC里没谈到混合云。Node 管理部分非常的简单,可能以后会增加混合云的支持吧。

Docker Hub的镜像安全吗?会不会有人留个后门啊,如何辨别呢?

noprom 回复了问题 • 7 人关注 • 4 个回复 • 8697 次浏览 • 2015-11-30 21:11 • 来自相关话题

Docker Hub彻底放弃Registry V1,灵雀云镜像市场国内率先支持V2

灵雀云 发表了文章 • 2 个评论 • 3850 次浏览 • 2015-10-26 16:07 • 来自相关话题

10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端: 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 i ...查看全部
10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端

  • 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 image push 到 Docker Hub,仍然能够 pull image;
  • 截至2015年12月7日,版本 1.5 和更早版本的客户端 pull image 也将被禁用,只支持 1.6 或更高版本。


registry_alauda.jpg


在这之前,随着 Docker 官方宣布 v1 的 registry 不再进行开发,灵雀云的小伙伴们就积极的投入了 v2 版 registry 工作的对接中,经过几个月的相关开发调试以及小规模的内测后,灵雀云的镜像市场服务已经正式敞开怀抱拥抱 v2 版本的 registry, 来为大家提供更加优质的服务。

下面我们就来看下,新版本的 registry 会带来哪些体验提升:

安全

v1 版的 registry 一直存在着安全漏洞,存在着镜像造假的隐患,由于 v1 无法对镜像的内容和正确性进行校验,从 v1 pull 镜像会有着 pull 到伪造镜像的风险,可以类比一下之前下载到带木马的 Xcode 的事件。v2 版提供了服务器短内容校验的功能,可以杜绝这种客户端伪造镜像的欺骗方法,并且 1.6 之后版本的 docker 也可以利用这种方式在本地进行校验,保证了上传和下载到镜像的一致。这也是 docker 官方主推高版本 docker 以及 v2 registry 的原因。我们也建议大家升级到高版本的 docker 来使用更安全的 v2 服务,不过目前我们可能是国内第一个全面支持 v2 的公有镜像市场 :)
性能

新版本的 registry 在性能方面有了大幅提升,并且支持并行 pull,以后再 pull 镜像就是这个样子了,可以感受一下 pull 镜像飞起是一种怎样的体验了。

1.pic_.jpg


灵雀云的 CaaS 平台也已经全面对接了 v2 registry,相应服务的性能也会得到提升,可以进一步加速用户持续化集成和部署的速度,我们之后也会持续优化这部分的性能。

兼容性

Docker Hub 已经宣布即将停止对 v1 的支持,很快就无法通过 1.6 之前的版本从 Docker Hub 上传下载任何镜像。灵雀云没有那么任性,还会对各个版本的 docker 提供服务支持,并对不同的客户端做了透明的兼容。由于 docker 客户端的限制,只有 1.6 之后的版本可以使用 v2 registry,不过 1.6 版本之前的小伙伴也无需担心,我们在后端服务做了大量的工作,使得同一个 registry 地址兼容两套 registry,并会做两者之间的镜像实时同步,不管你使用哪个版本的 docker 或者升级或者降级版本都可以无感知的使用到对应版本registry,并找到自己对应的镜像。

相关的技术文章可以点击这里查看。当然我们还是推荐大家升级到更高版本的 docker,这样即能够获得更好的镜像市场使用体验,也可以享用到 docker 新版本的其他特性,何乐而不为呢?

简讯 | Docker Hub将不再支持1.5和更早版本的客户端

田浩浩 发表了文章 • 1 个评论 • 3109 次浏览 • 2015-10-19 10:35 • 来自相关话题

【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。 亲爱的Docke Hub用户: 去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Reg ...查看全部
【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。

亲爱的Docke Hub用户:

去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Registry。引入了具有更快镜像传输的推送/拉取协议、简化了镜像定义并且提高了安全性。Docker社区一直在积极采纳他们,结果显示超过99%Docker Hub的使用是基于这些较新版本的。这样一来,我们准备在Docker Hub上不再支持版本`1.5`和更早版本的客户端。

* 截止到2015年11月19号,版本`1.5`和更早版本的Docker客户端将无法将镜像推送到Docker Hub。他们仍然能够拉取镜像。当然较新版本的Docker客户端可以完全访问Docker Hub的仓库。
* 截止到2015年12月7日,版本`1.5`和更早版本的客户端拉取镜像也将被禁用。只支持`1.6`或更高版本。

处理这种迁移非常简单。您所需要做的是升级你的Docker客户端到`1.6`或更高版本。请务必要升级从你的Docker Hub仓库推送或者拉取镜像的客户端,他们包括那些在开发机器、线上的服务器或者是CI和CD工作流程中的部分的客户端。

如果您有任何问题,请及时与我们联系。

诚挚的问候,

Docker Hub团队

原文链接:Docker Hub deprecation for clients 1.5 and earlier (翻译:田浩浩

一周 Docker 镜像精选(第三期)

tenxcloud 发表了文章 • 0 个评论 • 4369 次浏览 • 2015-10-06 22:38 • 来自相关话题

本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。 《一周 Docke ...查看全部
本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。

《一周 Docker 镜像精选》 是一份专为 Docker 爱好者打造的容器技术周刊。我们会为您精选一周的优秀 Docker 镜像,每周一期,完全免费。也欢迎极客们向我们投稿:service@tenxcloud.com
# 1.GitLab 代码管理系统

GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。

wangh/gitlab
3期镜像11.png

# 2.KODExplorer 芒果云 资源管理器

KodExplorer是一款开源的基于Web的在线文件管理、代码编辑器。它提供了类windows经典用户界面,一整套在线文件管理、文件预览、编辑、上传下载、在线解压缩、音乐播放功能。让你直接在浏览器端实现web开发、源码文件预览、网站部署。同时拥有与本地操作一样方便、快捷、安全的体验。

chenlilian/kode
3期镜像2.png

# 3.Hadoop Database,高可靠、高性能、面向列、可伸缩的分布式存储系统

HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

sdvdxl/hadoop
3期镜像3.png

# 4.Web-terminal 基于网页的命令行终端

Docker Web Terminal 一个基于网页的命令行终端。运行容器 docker run -d -p 5000:5000 name/web-terminal:latest 在浏览器中访问 open http://`boot2docker ip`:5000。

wangh/web-terminal
3期镜像4.png

# 5.用于编排 Spark 集群的简单 Docker 容器

一个用于编排Spark集群的简单Docker容器 Apache Spark 是一种与 Hadoop 相似的开源集群计算环境,但是两者之间还存在一些不同之处,这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越,换句话说,Spark 启用了内存分布数据集,除了能够提供交互式查询外,它还可以优化迭代工作负载。

sczyh30/docker_spark
3期镜像5.png

# 6.Gitblog 一个简单,易用,高效的Markdown博客系统

GitBlog是一个简单易用的Markdown博客系统,它不需要数据库,没有管理后台功能,更新博客只需要添加你写好的Markdown文件即可。它摆脱了在线编辑器排版困难,无法实时预览的缺点,一切都交给Markdown来完成,一篇博客就是一个Markdown文件。同时也支持评论,代码高亮,数学公式,页面PV统计等常用功能。GitBlog提供了不同的主题样式,你可以根据自己的喜好配置,如果你想自己制作博客主题,也是非常容易的。GitBlog还支持整站静态导出,你完全可以导出整站静态网页部署到Github Pages。

dockerxman/docker-gitblog
3期镜像6.png

#7.NodeBB 基于nodejs的响应式论坛

NodeBB是Design Create Play开发的一款使用Node.js构建的论坛系统,使用redis或mongoDB数据库,采用web socket技术实现。支持响应式布局,兼容IE8,将论坛的体验带向一个新的高度。nodeBB的优点:基于socket.io,界面高度简约,丰富插件和主题提供,提供实时聊天功能,新消息消息声音提醒,可以恢复上次浏览页面的具体位置,丰富的管理模式,中文支持,高度开放控件和页面编辑。

csuhp007/nodebb
3期镜像7.png

# 8.轻量级的开源社区系统 ThinkSAAS

ThinkSAAS是一个轻量级的开源社区系统,是一个可以用来搭建讨论组,bbs和圈子的社区系统。ThinkSAAS是将sns社会化网络元素,人和圈子(讨论组)结合在一起的新型的社交系统。系统特点:开发简单,php新手也可以开发强大功能;单一入口;扩展强大,支持应用扩展和wordpress式插件扩展 APP可单独配置独立数据库;WEB端和server端API接口统一;多端自适应,集成bootstrap;底层加载速度快,抗压和并发能力强;集成ueditor,内容编辑异常强大;适合个人和团队协作开发;集群、分布式部署、各种缓存、数据库读写分离等各种针对大数据和高并发的策略都在实践中

jechiy/thinkssas
3期镜像8.png

# 9.Discuz! 论坛(BBS)系统 - Docker版

Discuz! 论坛(BBS),是一个采用 PHP 和 MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台,是全球市场占有率第一的社区论坛(BBS)软件。

tenxcloud/discuz
3期镜像9.png

# 10.JIRA 项目与事务跟踪工具

JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富,其超过150项特性得到了全球115个国家超过19,000家客户的认可。JIRA推出云服务和下载版,均提供30天的免费试用期。云服务无需安装可直接试用,下载版采用一键式评估安装,在用户自己的服务器上运行。

wenzizone/jira
3期镜像10.png

有人说Docker Hub上三成的镜像包含漏洞?扯吗不是?

kurtzhong 发表了文章 • 0 个评论 • 5795 次浏览 • 2015-06-04 12:00 • 来自相关话题

【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用We ...查看全部
【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用Web安全审查进行检查,如果想让Docker更加安全,建议用dockerbench来评估。文中额外阐述了容器究竟有什么用。

这个数字太神奇了!并不是因为这个比例过高或者过低,而是因为居然存在这个比例。既然存在(相对容易地)计算出这个比例的可能性,也就意味着存在(相对容易地)改善这个比例的可能性。

声明:我是Docker官方人员,然而我写这篇文章并未受到公司批准,所以最好带着批判的思维来读本文。

这个数字来源于BanyanOps的博客

漏洞的计算
-----------

首先,来看看怎么才能计算出原文中的数据。这过程比较简单:

  • 获取Docker注册表的一个列表
  • 下载列表中的镜像
  • 检查镜像中的漏洞
这步骤看起来似乎太简单,我们稍微深入下细节。# 列举镜像列举官方的镜像是容易的。这些镜像是基于一个叫bashbrew的自动化系统构建而来的,使用的都是公布于众的方法。顺便一提,这意味着如果你想重建官方的镜像,做起来也会很容易。(记住那些方法中涉及一些blobs或者tar包,是在启动的时候用到的;因而有时你要多费一点力,重建这些blobs或者tarbal)。构建官方镜像的方法在Github上的docker-library仓库可以找到。要列出其他的镜像(即属非官方的用户和机构所有的镜像)要困难点。Docker Hub目前没有提供什么方法来列举他们,所以一个暂时可行的方法是搜索一个十分宽泛的关键字,然后对其结果进行提取。当然,这需要一些抓取的工作;抓取到的结果可能会漏掉一些用户的数据,但是你拿到的结果已经会十分接近了。(虽然这么做肯定可行, 我也听说新的注册表接口有一些十分好的特性,可以让这一步完成起来容易点)。# 下载镜像下载镜像是一个繁琐的任务。如果你想安安静静的做这件事情,运行一个docker的守护者进程,然后执行`docker pull username/imagename:tag`即可。如果你想拿到容器的文件系统的一个tar包,也很容易:只需要运行`docker export username/imagename:tag`就行。(记得把标准输出重定向到其他地方,否则你的终端会抓狂的)如果你不十分相信Docker的守护者进程,你可以检查registry的接口(v1v2)并且通过接口来下载层,然后把层文件重组成镜像文件。一些细节我想留给你自己去做,但是层文件只是普通的tar包,你只需要在彼此之上解包(需要保持正确的顺序)就可以重组成镜像文件。没有什么特别难的步骤;唯一需要留心的地方就是“留白”(whiteout)。“留白”是特殊的标记文件,用来表明“此处曾经有文件存在于此,但目前没有了”。换句话说,如果一个层包含文件`/etc/foo.conf`,但是之上的层把其删除了,上一层就会包含一个`/etc/.wh.foo.conf`文件,并且`foo.conf`不会出现在容器里面。这个文件相当于被留白文件加上了蒙板。我后来发现,了不起的Tianon已经为此写好了一个脚本,如果感兴趣你可以去看看。# 检查镜像在这个阶段你有几件事情需要做。细节繁琐,本文无法全部叙述;但是在一个全面的安全检查中,下面这些步骤你可能需要做:
  • 运行`yum-security`或者类似的命令,保证在此刻没有安全更新;
  • 或者更好的做法是:列举出所有安装的包及其版本,然后检查软件包在该版本是否包含漏洞;
  • 计算系统中的每一个文件的hash值,然后去跟已知的有漏洞的文件的hash集合去做比较;
  • 执行自动化工具(如`chkrootkit`)寻找可疑的文件;
  • 运行一定数量的专门为某些漏洞而打造的漏洞测试。这些测试的目标是尝试利用某些漏洞,然后告诉你,“你的系统有漏洞,因为我已经设法利用了这个漏洞”或者“我无法利用这个漏洞,所以你的系统很可能没有此漏洞”。
事情到了容器的环境中变得很有趣,因为用Docker来自动化这些步骤容易且便捷。例如,你可以将你的漏洞分析工具包放在`/tmp/toolkit`中,然后对于每一个镜像`$I`,执行`docker run -v /tmp/toolkit:/toolkit $I /toolkit/runall.sh`。(注意:这里假设你的工具包是静态链接并且/或者是自包含的,如不依赖你容器镜像中的任何地方,因为这又可能让你的工具包收到蒙骗。我这里主要想说的是,如果你想用一系列的测试来检查你的容器镜像,你可以用容器让这个步骤变得很简单,并且整个过程会更加的快速,因为对于每一个测试你不需要单独做一个检查的机器的拷贝)提升指标----------那么在我们运行完这些测试,然后发现出奇高比例的镜像包含有漏洞的包。我们怎么来改善这个指标呢?对于官方的镜像,最容易的方法是遵循Docker的安全指南。以后随着官方镜像数的增长,Docker也会改善这个机制,达到自动提示官方镜像的上游安全列表的效果。对于非官方的镜像,你可以检查镜像中的`Author`字段:
$ docker inspect --format '{{.Author}}' bin/ngrepJerome Petazzoni 
如果该镜像是自动构建出来的,你可以找到其来源的仓库,并且直接联系他们。如果你直接受到了漏洞的影响,想事情进展的更加快速,你可以自己重建镜像,并且/或者研究怎么才能修复这个漏洞,然后提交一个包含相应修复的PR。这里的意图不是把安全的责任推卸到镜像的使用者身上,而是让有意愿和有能力修复这些漏洞的人能对Docker镜像的安全做贡献。在将来,这些步骤会完善,并且流式化。会有自动化的过程构建出来减少需要联系相关机构的烦琐,然后尽量降低发布包含漏洞补丁版本的时间。# 但是30%还是太高了,对不对?30%的“有漏洞的镜像”可能听起来非常多。我第一次听到也是这么想。但是如果你细看,你会发现其中一大部分的镜像是老的镜像,它们是__故意不被更新__的。什么?__故意不被更新__?是的,并且对此有一些好的解释。第一个是(其中的一部分)照顾其他的媒介。有的发行版想`XYZ`想在CD/DVD,网络安装,VM镜像,和容器都保持一致。第二个原因是(这也解释了第一个原因)可重复的构建。设想你有一个服务器跑着12.04,但是你用一个新的Ubuntu 12.04的版本(更别提14.04)却重现不出来。在更加深入的研究后发现,这个问题只存在于那些在某特定时间安装的机器,其版本是12.04.02。如果一个容器镜像有12.04.02的版本,你可以重现出这个bug;否则,你得从其他地方得到这个特定版本。这就是为什么Docker Hub有很多老的镜像,它们保持着发行时的状态 - 同时包含当时发行时的安全问题。尽管这么说,我们已经放置了安全警示说“历史的镜像 - 保持远离”,所以我们比较希望这些镜像在计算出这些安全的指标的时候不应该被包含进去。让我们希望下次有人在计算安全指标的时候他们能意识到这一点。在本地采取措施 ---------------我们可能跑着有漏洞的镜像!求救!怎么办,怎么办?事情没有其看起来那么糟。当你(或者其他人)做完对于这些镜像(官方的,公开的,私有的)的审查,结果是一个镜像的列表(以一个唯一的hash串),并且包含“PASS”或者“FAIL”的状态。(对于“FAIL”的镜像,你可能想知道一些其为何不通过的细节,如:“好像有ShellShock/CVE-2014-7187和其他漏洞”或者“包含软件包OpenSSL 1.0.1c / CVE-2014-0160”。)# Web规模的安全审查你可以拿着这个列表,然后与你本地的镜像做比较。这里就是事情变得有趣的地方。根据本地镜像和这个列表做一个简单而廉价的匹配结果,你就马上能知道你是否运行着有漏洞的镜像。这可以很容易的扩展到成千上百万的主机。这也意味着事情可以很好的解耦:你的安全审查员不需要访问你的生产环境(甚至不需要访问你的开发环境中的系统)。他们甚至不需要要知道你运行着什么镜像:他们只需大面积的对镜像做分析,然后得出结果给你。你甚至可以从几个安全公司那里拿到结果然后比较他们的结果。# 我的镜像在创建后修改过怎么办?对于新手,你不应该这么做。如果你像更新容器中的某些东西,你应该创建一个新的镜像然后运行该新的镜像。好吧,但是我已经这么做了该怎么办?那真是什么都说不准,但是至少我们能知道你这么做了。安全审查的一部分,你可以在运行的容器上运行docker diff来知道是否他们被修改了。(通常docker diff是没有结果的。注意你已经用shell启动了一个容器,或者在容器内执行过docker exec,你可能会看到少许的更改。但是生产环境的容器不应该出现任何的更改结果。)专业的Tip:你甚至可以防止更改,通过在容器中使用`--read-only`的标记来达到这一点。这会让容器的文件系统只读,保证`docker diff`的结果为空。如果你想用一条命令来检查所有的容器,可以执行:
docker ps -q | xargs -I {} dockr diff {}
(感谢@diogomonica提供命令!)# 我已经构建了自定义的容器怎么办如果你构建了自己的容器,我建议你把他们上传到一个仓库里面。如果这是一个公共的,我们就会到最初讨论的情形。如果这是一个私有的,让我们看下一个部分!私有的镜像和注册表该怎么办?----------------------如果你上传的是私有的镜像怎么办?如果你上传的地方是一个本地的注册表,或者Docker Hub的企业版怎么办?事情显然变得更加复杂了。你可能会看见有人告诉你“设想ABC有CVE-XYZ的漏洞”如果他们从来没有看到过镜像ABC。这里是一些可能会发生的事情:
  • 安全提供商可以提供镜像的扫描器,你可以用在自己的镜像上;
  • 安全提供商可以更进一步,将其集成到Docker的注册表中。这可以通过分配读权限(访问Docker Hub上的私有镜像)或者部署前置(on-prem)的安全扫描器(对于Docker Hub企业版的情形)来实现。在两个情形中,都能达到一旦镜像上传就会被自动扫描的效果,并且立即报告任何可能包含的漏洞。
结论---有两点我想强调,因为我相信这能在安全领域产生好的结果。[list=1]
  • 得出数字是好的。一旦我们得到了量化的数据,我们可以提升他们。Docker对于安全问题十分延严肃,你可以很肯定我们会和社区及镜像的维护者一期来改善这些量化数据。
  • [list=1]
  • 有类似这样的围绕着Docker和Docker Hub的生态环境和社区,让他们成为一个树立标准的地方。正如Soloman在一些keynote里面指出的,Docker里面最重要的一点不是技术,而是让人在某事上达成一致。
  • 后一点意味着Docker现在有足够的批评群体来校正横向的工具(包括安全审查)来让这个生态环境受益。其结果会是更加完善的安全机制,让每一个人受益。# Docker注重安全如果有Docker公司不在乎安全的印象,那真相离你就太远了。正如上面指出的,我们有一个负责的披露安全的政策,并且我们总是很快的解决我们意识到的问题。没有哪个软件是没有bug的。Docker也是由人类编写出来的,即时他们有些人十分的了优秀,但是还是会犯错。重要的是我们对待安全报告的严肃态度如何,我们解决这些问题的速度如何;我想我们在这些方面都一直做的很好。如果你想让你的Docker的环境更加安全,我推荐你看下dockerbench。我参与了其编写,该软件包含了一个自动化的评估工具可以用来评估Docker的主机,使用的是CIS Docker 1.6 Benchmark。它会检查很多事情(如是否SELinux和AppArmor是启用了的)然后生成一个报告。这是Docker会推出或者参与的一大批软件的第一批,目的是让你可以在没有Docker容器安全方面的Ph.d的证书的情形下,或者在没有聘请一个Taylor Swift的情形下,安全地运行Docker。并且,我们鼓励公开的讨论,安全的担忧也不例外。Docker Library的仓库里面有一个十分有趣的有关于这个话题的讨论# 额外的提示有人问我阐释下容器究竟为什么有用,如果我们不反复的检查我们运行的所有的东西的来源。这里是一些例子:
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如著名的`curl ... | sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(比如一个商用软件的`install.sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个npm,pip,gem等等的包,但是我们不清楚其来源),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个deb,rpm或者其他的发行版的包),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个危险的squid包),并且可以查看到底能产生结果,这得益与`docker diff`。

    我猜想你能看出这个模式。仅仅因为事情以一种熟悉的形式呈现给你并不代表它们是安全的。但是我们可以使用Docker来提升安全性。


    原文链接:Someone said that 30% of the images on the Docker Registry contain vulnerabilities(翻译:钟最龙)

    Docker Hub中超过30%的官方镜像包含高危漏洞

    kurtzhong 发表了文章 • 1 个评论 • 7380 次浏览 • 2015-05-28 15:40 • 来自相关话题

    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。 Dock ...查看全部
    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。

    Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险(如:Shellshock、Heartbleed、Poodle等)。对于普通的镜像,即那些被Docker用户上传的,没有经过任何权威机构验证过的镜像,这个比例高达40%(样本的错误大约在3%)。
    1.jpg

    [图:多姿多彩的容器,图片来源自VSMagazine]

    为了开展这次研究,我们下载了Docker Hub中的的镜像,然后分析其中的软件包和版本。然后我们使用来自Mitre、NVD(美国国家漏洞数据库)和Linux发行版自己的数据库来分析哪些镜像易于受到攻击。我们开发一个开源的工具 Banyan Collector,并且使用一个叫做Banyan Insights的服务来生成这个研究中的数据。

    尽管我们的分析是基于公共的Docker Hub进行的,我们预估这结果与那些使用私有容器注册中心的企业会类似。企业通常会不断基于那些口碑较好镜像来部署容器,依赖这些镜像的周期更新来获取最新的软件包。尽管有这些措施,企业仍然有漏洞的威胁;更加严格的运维管理加上实时的监控对于保证安全必不可少。

    在本文的剩余部分,我们简单的从高层次介绍下安全漏洞是如何分类,描述基于分析Docker Hub上官方和普通镜像中漏洞得到的结果,然后讨论下这份研究对于运维管理的意义。


    安全漏洞的指定和分类
    -----------------------

    Mitre作为一个不以盈利为目的机构,指定并维护一份CVE(常见安全漏洞和威胁)的列表,每一个CVE描述了在广泛发布的软件中的漏洞。由美国政府维护的NVD数据库列出了每一个CVE的影响,包含其波及的软件和相应的修复措施(或者尚未采取修复措施的)。每一个Linux发行版也都维护了一个发行版特定的影响和提供修复该漏洞的软件包版本。

    每一个漏洞都会被NVD和Linux的发行版指定一个分值。分值的范围从0到10,7.0到10.0属于高危漏洞,4.0-6.9之间的属于中危漏洞,0-3.9的属于低危漏洞。这个分类考虑了一系列因素,包括利用该漏洞攻破系统所需要的复杂度(复杂度越低,分数越高)和该漏洞可能会造成的影响(影响越大,分值越高)。下面是一些例子:

    1. 高危漏洞:如:ShellShock(bash)、Heartbleed(OpenSSL)
    2. 中危漏洞:如:Poodle(OpenSSL)
    3. 低危漏洞:如内存中数组的内存的分配可能会导致整形溢出

    把漏洞划分为高中低漏洞的做法带有主观性,一些公司也可能会根据自己的情况来重新分类。而且,NVD指定的分值可能跟Linux发行版中的分值不一致,并且可能会随着时间推移而更改。我们的研究中使用的漏洞的分值来源于Ubuntu和CentOS发行版指定的分值,对于Debian我们直接使用了NVD数据库中分值,因为我们找不到任何关于Debian发行版对漏洞分类比较好的数据源。我们对Docker Hub在2015的5月20日的镜像做了一个快照,然后进行分析。我们也试了一下其他日期,得出的结论十分相近。

    对于Docker Hub中官方仓库的评估
    ------------------------------------

    Docker维护着一个官方的仓库的列表,为软件厂商和机构(如Canonical、Debian、Redhat等)提供了一个即时更新它们最新容器镜像的渠道。官方仓库可以从他们的路径体现出来,他们的路径在`library`的命名空间下。举几个例子:`library/ubuntu`,`library/redis`等。Docker Hub包含大约75个官方的仓库(在我们写这篇文章的时候),大概包含约1600的不同的标签,指向约960个不同的镜像。
    2.png

    [图一:官方有漏洞的镜像]

    图一展示了根据分析Docker Hub上所有官方的镜像的得出的主要结果。超过1/3的镜像有高危漏洞,接近2/3的有高或中级危漏洞。这些统计数据让人无法平静,因为这些镜像中一些也是下载量最多的镜像(一些有几十万的下载量)。

    如果我们只看今年创建的镜像,有高危漏洞的镜像的比例仍然超过1/3,但是含有高和中级危漏洞的镜像接近了75%。换句话说,今年创建的镜像,每四个中就有三个存在较容易被利用的漏洞,并且潜在影响非常大。

    如果我们将范围缩小到哪些标注了`lastest`(最新)的镜像,这比例分别下降到了23%和47%,这比例显然还是很高。这更小的数据说明,Docker的用户和维护者们,倾向于将镜像保持到最新,但是老一些的镜像却被忽略;创建容器数量之大和速度之快,让老的镜像在更新的时候被忽略。

    为了理解这些漏洞,特别是排名靠前的,我们做了一个详细的影响Docker Hub的镜像漏洞的分析:
    3.png

    [图二: Docker Hub官方镜像中有高危漏洞的镜像]

    图二展示了该分析的主要结果,并且表一列举了跟这些软件包相关的主要的CVE。最近发布的存在于mercuarial的漏洞在很多镜像中都有(大约20%)。著名的OpenSSL漏洞如Heartbleed和Poodle,在近10%的官方镜像中存在。一些镜像还包含bash的ShellShock(如Centos5.11镜像中)漏洞,这个漏洞在7个月前就被发布了。即便一些机构不使用这些包,但是如果不手动将这些包从容器中移除掉也会成为恶意攻击的羔羊。
    4.png

    对于Docker Hub中普通仓库的评估
    --------------------------

    除了一些官方的仓库,Docker Hub包含了一大部普通仓库(在写本文的时候大约有95000个),并且有数十万不一样的镜像。我们实验中随机选择了1700个镜像,然后对他们的内容的内容进行分析(误差约百分之三)。
    5.png

    [图三:有漏洞的普通镜像]

    图三显示了在分析了普通镜像后得到的主要结果。大体上,漏洞的出现概率比官方镜像的相比大很多。这个结果合乎预期,因为目前尚没有措施可以在将镜像上传到Docker Hub前可以过滤并检查这些普通的镜像。

    大约40%的普通镜像有高危的漏洞。即便我们只是看今年创建的镜像,并且只看那些有`latest`标签的,包含漏洞威胁的镜像的比例仍然在30-40%之前徘徊。如果我们包含那些含有中危漏洞的镜像,比例会迅速升到70%以上,不管哪个时间段都是如此。尽管你可能会说,这些镜像比起官方镜像下载次数太少了,但是考虑到它们庞大的数量(几十万的规模)可以预想它们跟官方镜像一样使用甚广。

    我们又分析了影响普通镜像中的高危漏洞,图4展示了主要的结果:
    6.png

    [图四:普通镜像中含有高危漏洞的软件包]


    有趣的是,不同于官方镜像中首要祸源在于mercurial,在这些普通的镜像中,openSSL、bash、和apt成了祸源的榜首。我们怀疑官方的和普通这种数字上的差异来源于发行版的差异,他们占据了这些镜像的大部分。官方镜像通常基于Debian,并且其中一一大部分包含mercurial包。而普通的镜像,却通常基于Ubuntu因而有bash、apt和/或openssl相关的漏洞。


    延伸
    ---

    容器技术带来软件开发中的变革,它提供了一个十分高效的方法,可以将开发者开发的软件在数分钟或者几小时内搬上生产环境运行,而传统的方式可能需要几天甚至数月。但是我们的数据显示这种优势有其弊端,没有谨慎的运维和安全管理的措施,我们冒着让我们的软件生态环境更容易被攻击的危险。

    容器为运行于不同容器之间的运行程序提供了一层安全隔离,因而提高了安全性。然而容器还是需要和其他的容器和系统进行通讯,因此,由于镜像中存在的安全漏洞,它们还是很容易被远程攻击,包含那些我们没有分析到的漏洞。再者,在多种多样的环境中启动大量的容器的轻便与快捷,如在你的共有云上,私有云上,笔记本上,都让追踪和防护有安全漏洞的容器变得更加困难。部署容器的高效性,大大的加速了部署软件的多样性,结果让环境中的新的漏洞越来越多。

    使用容器的另外一个根本点在于,包管理已经被转移到了容器的内部,而传统的方式是仅仅是基于安装在虚拟或者实体机的操作系统层面上。这种改变主要根源于虚拟机和容器提供的抽象处于不同的层面。虚拟机提供的是以主机为中心的抽象,其特点是长期不停机一直运行,包含的软件包供不同应用所需。与之相对的,容器提供的是一个更加以进程为主的抽象,其特点是短暂性,可以到处运行,构建后不会改变,仅仅包含运行一个应用所必须的软件包。任何更新都需要重新构建容器,从而保持容器的不可修改性,这让任何的漏洞同时被复制。

    另外,向DevOps模式的转变,开发者开始为他们开发的应用的软件包负责,这意味着现在开发者开始负起了维护软件包的责任。除了操作系统的软件包,开发者在容器中可以包含应用层面中的模块,如pip(Python)、npm(Node.JS)和maven(Java)等,而这些都在我们的研究之外,然而它们也可能带来新的安全问题。因为开发者更加关注快速的开发出新的功,这让保持老的镜像更新变得更加困难,正如我们的研究呈现的一样(如官方的与201年4月发布的CentOS 5.11镜像仍然包含Shellshock漏洞,该漏洞是八个月前,2014年9月被爆出的)。

    一个很好的避免这些问题的方式是经常用最新的更新重新构建镜像。重新构建的过程必须使用发布商发布的最新的基础镜像,并且不能使用任何缓存的镜像层(如:使用在apt-get upgrade的时候加上`-no-cahce`)。但是在一旦发现漏洞从头重新构建,并且重新部署所有的容器的开销太大,十分不切实际了—— 漏洞出的频率太高,每天都会爆出好几次,并且很难评估每一个安全漏洞的的影响范围。加之,更新容器的软件包很可能给容器中的应用带来负面影响和不稳定性,而这即使用复杂的测试也未必能捕捉到,这让人更加不情愿经常更新。


    结论
    ---

    我们的研究结果鼓励使用严格的运维管理流程,实时的分析镜像中的内容,清楚其中的内容和包含的漏洞。镜像应该经过安全漏洞的扫描,并且根据漏洞的严重程度来标记是否需要更新。任何重大的漏洞都应该被及时的发现,并且应该可以触发对这些有隐患的镜像进行隔离机制。镜像不仅仅应只从操作系统层面进行扫描,也应从应用的层面的安全漏洞进行扫描。这些流程应该被集成到持续构建的框架中,这样在享受容器带来的全面福利的同时,仍然保持着好的安全实践。

    原文链接:Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities(翻译:钟最龙 审校:魏小红)

    Docker收购Kitematic:一个非常棒的GUI工具

    叶可强 发表了文章 • 3 个评论 • 36407 次浏览 • 2015-03-12 23:32 • 来自相关话题

    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持 ...查看全部
    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持Windows。本文翻译自Docker官方博客。

    image2015-2-23-16-36-9-300x78.png

    我们非常高兴地宣布我们收购了Kitematic,它是Mac上最快、最易使用的Docker工具。Docker 是一款面向开发者的工具,我们也发现生态系统中的开发者为 Docker 构建了最酷的工具。Orchard 的 Fig(现在是 Compose)以及 SocketPlane 都是产生于生态圈中的最佳案例,它们提升了开发者体验并为分布式应用提供了灵活性操作。

    今天,Kitematic在简化开发者体验这一步上更上一层楼。它可以让Docker更易使用:Kitematic进一步增长和丰富了社区和生态系统。
    ## Kitematic 是什么?
    Screenshot-2015-02-23-16.27_.27-1024x752_.jpg

    Kitematic 完全自动化了 Docker 安装和设置过程,并提供了一个直观的图形用户接口(GUI)来在 Mac 上运行 Docker。Kitematic 集成了 Docker Machine 来在 Mac 上分发一个虚拟机并安装 Docker 引擎。

    一旦安装成功,Kitematic GUI 便会启动,紧接着你可以立刻运行控制台中的镜像。你仅仅只需要在 Kitematic 搜索框键入镜像名就可以搜索任何在 Docker Hub 上存在的镜像。通过 GUI 你可以非常容易的创建、运行和管理你的容器,不需要使用命令行或者是在 Docker CLI 和 GUI之间来回切换。
    image2015-2-23-18-43-5.jpg

    Kitematic 也让Docker的一些高级特性使用更加方便,比如管理端口和配置 volumes。你可以方便的修改环境变量、查看日志,单机终端就可以进入容器,这些特性GUI都支持。
    ## 未来将会怎样?
    自从测试版发布后,仅短短几个月,Kitematic 就拥有了成千上万的用户,都是积极的反馈并有上千的 GitHub stars。同时,我们相信,一个关于开发者如何与 Docker 交互并运行他们的容器的伟大旅程即将开始。

    你可以通过我们在 GitHub 上的路线图来获取更多信息 ,同时你也可以为你想看到的任何东西提交 pull request。我们会扩大团队处理路线图上的功能,接下来将包含一个新的 Windows 客户端以便更多的开发者能更快速、更容易的在他们的机器上运行 Docker。

    ## 免费尝试下 Kitematic,它是开源的

    当然,Kitematic 将继续保持开源和免费,所有人都可以通过 GitHub获取。团队希望得到你的反馈和支持,好啦,就从 kitematic.com 下载最新版的 Kitematic 开始吧?
    image2015-2-23-16-41-45.png


    ## 学习更多关于 Kitematic 的知识



    原文链接:KITEMATIC A DOCKER GUI JOINS THE DOCKER FAMILY(翻译:叶可强 校对:李颖杰)

    ===========================
    译者介绍
    叶可强,目前在唯品会上海分公司从事应用运维工作。业余时间专注Docker的学习与研究,希望通过DockerOne把最新最优秀的译文贡献给大家,一起促进国内 Docker 的发展。
    条新动态, 点击查看
    你的考虑是有道理的。目前在Hub上已经有一个Trust的标志, 比如 https://registry.hub.docker.com/_/centos/ 你会在左上角看到一个“OFFICIAL REPO”,这说明是可以信赖的(严格意思上你只是信赖它的人品,而不... 显示全部 »
    你的考虑是有道理的。目前在Hub上已经有一个Trust的标志, 比如 https://registry.hub.docker.com/_/centos/ 你会在左上角看到一个“OFFICIAL REPO”,这说明是可以信赖的(严格意思上你只是信赖它的人品,而不是这个镜像真的是安全的。安全应该是由第三方测试后才能保证。安全总是相对的)。还有我们可以看到下载最多的一个镜像:https://registry.hub.docker.com/u/phusion/baseimage/ ,即使它的下载非常多,但仍然不是认证的。所以,最稳妥的办法是自己做一个baseimage用。

    Docker生态系统一览

    徐笑笑 发表了文章 • 0 个评论 • 10674 次浏览 • 2016-04-01 16:50 • 来自相关话题

    【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Cen ...查看全部
    【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Center,文章会详细介绍这些工具的功能,以及怎样能够更好地将这些工具结合起来。

    @Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网、华为等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

    在过去的18个月内参加任何技术相关的活动或者阅读任何技术相关的文章时,你可能已经听说过Docker并且对Docker是什么以及它是用来做什么的略有所知。

    简单来说,Docker是建立在过去的一些概念之上,但是对这些概念进行了更好的封装。Docker是一个用来创建“容器”的工具,这些容器仅仅包含你所需要的一个独立的应用或者技术堆栈。与虚拟机不同的是,这些容器共享相同的资源来管理容器与主机之间的相互作用。这一点使得Docker容器快速、轻量、安全并且共享。

    “Docker建立在过去的概念之上但又对这些概念进行了更好的封装。”via @ChrisChinch
    >
    CLICK TO TWEET



    就我个人而言,作为一个技术作家和主持人,我发现Docker对于创建演示文稿是非常宝贵的。我可以组装一堆我需要的组件,运行它们,然后再摧毁我不再需要的包和数据,以保持我的系统干净整洁。

    许多开发人员在开发和测试过程中能够看到一个清晰的Docker用例,但是仍然想要了解Docker在生产中如何最好地工作。一系列第三方工具和服务的出现用来帮助开发人员从开发到生产过程中部署、配置和管理他们的Docker工作流程。

    Docker已经通过一系列收购和产品发布建立了自己的“官方”工具包。众所周知,Orca项目在去年美国的DockerCon大会上公布了,虽然细节有点模糊。在我看来,与其说Orca是一个实际的项目或者产品,还不如说它其实是Docker不断增长的产品组合的巩固策略。

    所以在这篇文章中,我会提出关于当前可用的Docker生态系统有哪些部分,它们如何帮助你,以及怎样更好地组合它们的一个总结。

    “让我们讨论一下Docker生态系统的组成部分以及这些组成部分是如何配合在一起的。”



    CLICK TO TWEET



    #Docker Hub
    任何使用Docker的项目的核心是一个Dockerfile文件。这个文件包含Docker如何创建一个镜像的指示说明。让我们来看一个简单的例子:
    FROM python:2.7
    ADD . /code
    WORKDIR /code
    RUN pip install -r requirements.txt

    在这个例子中,该Dockerfile文件拉取一个特定版本的现有镜像,将当前本地目录复制进容器的文件系统,并设置它为工作目录,然后通过pip命令从一个文本文件下载Python依赖。

    Docker Hub是预先写好的Dockerfile官方资源,提供公共的(免费的)和私人的(付费的)镜像存储库。如果你正在寻找一个Dockerfile来满足你的需求,首先在Docker Hub上搜索,使用项目文档、下载量和镜像等级来帮助指导你的决定。
    1.png

    #Docker Engine
    Docker Engine创建Dockerfile文件并把它们转化为可用的容器。Docker Engine是Docker的核心,如果没有Docker Engine那么什么也运行不了。依据你的操作系统不同有几种下载Docker Engine的方案,你可以在这里发现更多的细节

    依据Docker Hub中的一个镜像开启一个容器,应该首先拉取这个镜像并运行它。继续以Python为例:
    docker pull python
    docker run -it --rm --name script-name -v "$PWD":/usr/src/appname -w /usr/src/appname python:3 python app.py

    这样就会拉取最新的Python镜像然后开启一个容器运行一个Python脚本并且运行完后退出容器。run命令提供了更多的选项设置,你可以在这里阅读完整的指南
    当一个Docker run命令开始变得更为复杂,它可以创建自己的自定义Dockerfile文件或许是一个更好的主意。开启一个基于本地Dockerfile文件的容器,运行以下里面包含文件的目录:
    docker build -t my_image .

    这个命令将会创建一个名为my_image的镜像。运行以下命令开启一个基于这个镜像的容器:
    docker run -name my_image_container -i -t my_image

    这个命令会开启一个基于自定义的my_image镜像的容器,这个容器命名为my_image_container。
    #Kitematic
    对于那些宁愿避免命令行的用户来说,Kitematic是Mac OS X和Windows的一个伟大的GUI。搜索你需要的镜像,创建一个容器,你最好去Kitematic。Kitematic提供了基本的配置选项,但对于更高级的设置,你可能需要进入命令行。
    2.png

    你的容器出现在左手边,在那里它们可以被启动、停止、重启,更有用的是,你可以在那里找到容器日志和直接SSH(exec按键)访问。
    3.png

    #Docker Machine和Swarm
    生产中使用Docker的第一步是了解Machine和Swarm,它们为各种虚拟化和云服务提供商提供了一套简单的工具集用以移动和缩放他们的本地项目。

    “生产中使用Docker的第一步是了解Machine和Swarm。”



    CLICK TO TWEET



    例如,在Azure上创建一个Docker实例:
    docker-machine create -d azure --azure-subscription-id="XXX" --azure-subscription-cert="/mycert.pem" ecodemo

    这个命令使用预装的Docker创建一个Ubuntu 12.04-based虚拟机并命名为ecodemo。每个供应商都需要不同的参数和认证方法,这些默认设置可以被重写。在这个文档中可以阅读到更多的细节。

    当与Swarm结合后,Machine可以创建Docker实例的集群,这个集群被视为一个单一的、大的Docker实例。每一个Swarm集群都需要一个master实例,这个master实例可以用下面的命令来创建:
    docker-machine create
    -d virtualbox
    --swarm
    --swarm-master
    --swarm-discovery token://TOKEN_ID
    swarm-master

    这样就会在VirtualBox中创建一个Docker实例并且设置这个Docker实例为Swarm集群的一个master节点。TOKEN_ID非常重要,因为它可以帮助集群中的所有节点识别彼此。除了手动创建TOKEN_ID标识以外,Swarm也有发现系统来帮助你管理这个过程。

    下面的命令使用相同的TOKEN_ID标识添加Docker实例到Swarm集群:
    docker-machine create
    -d virtualbox
    --swarm
    --swarm-discovery token://TOKEN_ID
    swarm-node-n

    swarm-node-n对于集群中的每一个节点来说都是一个唯一的名字。

    现在,代替从单个虚拟机中开启容器,你可以在集群中开启容器,master节点将会把这个容器分配给最可用的和最有能力的节点。
    #Docker Compose
    Compose使得由多个组件(像容器)组成的应用程序更加简单,你可以开始使用一个命令在一个单一的配置文件中声明所有这些组件。

    下面是一个Compose文件(称为docker-compose.yml)的例子,这个例子创建三个Crate数据库实例和一个Laravel(用一些额外的配置)PHP框架实例。最重要的是,容器与Links配置选项相连。
    crate1:
    image: crate
    ports:
    - "4200:4200"
    - "4300:4300"
    crate2:
    image: crate
    crate3:
    image: crate
    volumes:
    - ./data:/importdata
    laravelcomposer:
    image: dylanlindgren/docker-laravel-composer
    volumes:
    - /laravel-application:/var/www
    command: --working-dir=/var/www install
    links:
    - crate1
    laravelartisan:
    image: dylanlindgren/docker-laravel-artisan
    links:
    - crate1
    volumes_from:
    - laravelcomposer
    working_dir: /var/www
    command: serve --host=0.0.0.0:8080
    ports:
    - "8000:8000"
    - "8080:8080"

    所有这些实例和它们的配置现在可以通过运行以下在同一目录中的docker-compose.yml文件的命令来开始:
    docker-compose up

    4.png

    你可以使用相同的子命令作为Docker的命令来影响所有以docker-compose开始的容器。例如,docker-compose stop命令可以停止以docker-compose开始的容器。
    5.png

    #Docker Cloud
    容器的自动化管理和编排是Docker的主要功能,但却一直由第三方服务来提供,直到去年Docker获得了Tutum(它支撑着Docker云)。虽然没有完整的命令行工具(还没有),Docker云服务允许Docker Compose文件设置应用程序栈,所以它不是来自于生态型的其它部分的一个大的导流。

    “容器的自动化管理是Docker的重要组成,但知道最近一直由第三方来提供。”



    CLICK TO TWEET



    例如:
    crate1:
    image: crate
    ports:
    - "4200:4200"
    - "4300:4300"
    command: crate -Des.network.publish_host=_ethwe:ipv4_
    crate2:
    image: crate
    command: crate -Des.network.publish_host=_ethwe:ipv4_
    crate3:
    image: crate
    command: crate -Des.network.publish_host=_ethwe:ipv4_

    这样就创建了同一个镜像的三个实例,其中一个手动设置主机与Docker之间的端口分配,其他的端口分配是自动的。我将很快重新访问command。

    如果你想在超过一个节点(节点能够运行它可以管理的足够多的容器和一个私有仓库上扩展应用程序,Docker Cloud是有偿服务。这对于实验目的来说足够了。记住,Docker Cloud默认管理托管在第三方托管服务器上的容器,所以你也需要支付费用。使得Docker Cloud代理运行在任何你管理的Linux主机上是可能的,你可以在这里找到操作指南
    6.png

    上面的截图显示了三个使用预先设定的规则运行在跨越两个数字海洋的实例上的Docker容器,这个预先设定的规则是根据你设置的参数来将容器分配给主机。它会自动确保你指定数量的容器始终在运行。

    在之前的Docker Compose例子中,你可能已经注意到_ethwe:ipv4_。这是Docker Cloud的另外一个重要特征。许多分布式应用和服务依赖“服务发现”来找到同一服务的其他实例并进行通信。当在数据中心和物理机器上传播服务时,这往往需要实例的手动说明或者需要另一种方式来找到彼此。

    Docker Cloud包括支持Weave在你的实际网络中创建一个“软”网络;所有的容器和应用都可以发现彼此,无论它们被托管在哪里。在上面的例子中,我们重写了向容器发出的默认命令,以确保它接收它需要使用此功能的信息。
    #Data Center
    到目前为止,本文涉及的大部分工具都是你安装,主机,和支持的工具。对企业用户来说,他们寻找安全性、性能和支持较高的保证,Docker提供了数据中心

    它使用了覆盖这里的许多相同的工具包,但是增加了一个放置你的镜像的私有仓库,一个私有云,高级支持,和供应商可能吸引企业用户的第三方集成。这些包括LDAP and Active Directory用户管理,容器检测,和日志记录。
    #总结
    正如你从我的截图和你的实验中看到的这些工具,它们仍然感觉像是一套有关系但却松散耦合的产品,而不是一个紧密结合的“套件”。Orca项目似乎试图把重点放在建立所有这些项目之间的一致性上,使每一个项目都成为下一个项目的逻辑铺垫,而且所有这些项目都来自于同一个GUI或者CLI。其目的不仅仅是回答“为什么我应该使用Docker?”,而是回答“为什么我不使用Docker呢?”

    “Docker的这些工具仍然感觉像是一组松散耦合的产品,而不是一个紧密结合的套件。”



    CLICK TO TWEET



    原文链接:Understanding the Docker Ecosystem(翻译:徐婷)

    Docker Hub彻底放弃Registry V1,灵雀云镜像市场国内率先支持V2

    灵雀云 发表了文章 • 2 个评论 • 3850 次浏览 • 2015-10-26 16:07 • 来自相关话题

    10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端: 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 i ...查看全部
    10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端

    • 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 image push 到 Docker Hub,仍然能够 pull image;
    • 截至2015年12月7日,版本 1.5 和更早版本的客户端 pull image 也将被禁用,只支持 1.6 或更高版本。


    registry_alauda.jpg


    在这之前,随着 Docker 官方宣布 v1 的 registry 不再进行开发,灵雀云的小伙伴们就积极的投入了 v2 版 registry 工作的对接中,经过几个月的相关开发调试以及小规模的内测后,灵雀云的镜像市场服务已经正式敞开怀抱拥抱 v2 版本的 registry, 来为大家提供更加优质的服务。

    下面我们就来看下,新版本的 registry 会带来哪些体验提升:

    安全

    v1 版的 registry 一直存在着安全漏洞,存在着镜像造假的隐患,由于 v1 无法对镜像的内容和正确性进行校验,从 v1 pull 镜像会有着 pull 到伪造镜像的风险,可以类比一下之前下载到带木马的 Xcode 的事件。v2 版提供了服务器短内容校验的功能,可以杜绝这种客户端伪造镜像的欺骗方法,并且 1.6 之后版本的 docker 也可以利用这种方式在本地进行校验,保证了上传和下载到镜像的一致。这也是 docker 官方主推高版本 docker 以及 v2 registry 的原因。我们也建议大家升级到高版本的 docker 来使用更安全的 v2 服务,不过目前我们可能是国内第一个全面支持 v2 的公有镜像市场 :)
    性能

    新版本的 registry 在性能方面有了大幅提升,并且支持并行 pull,以后再 pull 镜像就是这个样子了,可以感受一下 pull 镜像飞起是一种怎样的体验了。

    1.pic_.jpg


    灵雀云的 CaaS 平台也已经全面对接了 v2 registry,相应服务的性能也会得到提升,可以进一步加速用户持续化集成和部署的速度,我们之后也会持续优化这部分的性能。

    兼容性

    Docker Hub 已经宣布即将停止对 v1 的支持,很快就无法通过 1.6 之前的版本从 Docker Hub 上传下载任何镜像。灵雀云没有那么任性,还会对各个版本的 docker 提供服务支持,并对不同的客户端做了透明的兼容。由于 docker 客户端的限制,只有 1.6 之后的版本可以使用 v2 registry,不过 1.6 版本之前的小伙伴也无需担心,我们在后端服务做了大量的工作,使得同一个 registry 地址兼容两套 registry,并会做两者之间的镜像实时同步,不管你使用哪个版本的 docker 或者升级或者降级版本都可以无感知的使用到对应版本registry,并找到自己对应的镜像。

    相关的技术文章可以点击这里查看。当然我们还是推荐大家升级到更高版本的 docker,这样即能够获得更好的镜像市场使用体验,也可以享用到 docker 新版本的其他特性,何乐而不为呢?

    简讯 | Docker Hub将不再支持1.5和更早版本的客户端

    田浩浩 发表了文章 • 1 个评论 • 3109 次浏览 • 2015-10-19 10:35 • 来自相关话题

    【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。 亲爱的Docke Hub用户: 去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Reg ...查看全部
    【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。

    亲爱的Docke Hub用户:

    去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Registry。引入了具有更快镜像传输的推送/拉取协议、简化了镜像定义并且提高了安全性。Docker社区一直在积极采纳他们,结果显示超过99%Docker Hub的使用是基于这些较新版本的。这样一来,我们准备在Docker Hub上不再支持版本`1.5`和更早版本的客户端。

    * 截止到2015年11月19号,版本`1.5`和更早版本的Docker客户端将无法将镜像推送到Docker Hub。他们仍然能够拉取镜像。当然较新版本的Docker客户端可以完全访问Docker Hub的仓库。
    * 截止到2015年12月7日,版本`1.5`和更早版本的客户端拉取镜像也将被禁用。只支持`1.6`或更高版本。

    处理这种迁移非常简单。您所需要做的是升级你的Docker客户端到`1.6`或更高版本。请务必要升级从你的Docker Hub仓库推送或者拉取镜像的客户端,他们包括那些在开发机器、线上的服务器或者是CI和CD工作流程中的部分的客户端。

    如果您有任何问题,请及时与我们联系。

    诚挚的问候,

    Docker Hub团队

    原文链接:Docker Hub deprecation for clients 1.5 and earlier (翻译:田浩浩

    一周 Docker 镜像精选(第三期)

    tenxcloud 发表了文章 • 0 个评论 • 4369 次浏览 • 2015-10-06 22:38 • 来自相关话题

    本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。 《一周 Docke ...查看全部
    本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。

    《一周 Docker 镜像精选》 是一份专为 Docker 爱好者打造的容器技术周刊。我们会为您精选一周的优秀 Docker 镜像,每周一期,完全免费。也欢迎极客们向我们投稿:service@tenxcloud.com
    # 1.GitLab 代码管理系统

    GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。

    wangh/gitlab
    3期镜像11.png

    # 2.KODExplorer 芒果云 资源管理器

    KodExplorer是一款开源的基于Web的在线文件管理、代码编辑器。它提供了类windows经典用户界面,一整套在线文件管理、文件预览、编辑、上传下载、在线解压缩、音乐播放功能。让你直接在浏览器端实现web开发、源码文件预览、网站部署。同时拥有与本地操作一样方便、快捷、安全的体验。

    chenlilian/kode
    3期镜像2.png

    # 3.Hadoop Database,高可靠、高性能、面向列、可伸缩的分布式存储系统

    HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

    sdvdxl/hadoop
    3期镜像3.png

    # 4.Web-terminal 基于网页的命令行终端

    Docker Web Terminal 一个基于网页的命令行终端。运行容器 docker run -d -p 5000:5000 name/web-terminal:latest 在浏览器中访问 open http://`boot2docker ip`:5000。

    wangh/web-terminal
    3期镜像4.png

    # 5.用于编排 Spark 集群的简单 Docker 容器

    一个用于编排Spark集群的简单Docker容器 Apache Spark 是一种与 Hadoop 相似的开源集群计算环境,但是两者之间还存在一些不同之处,这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越,换句话说,Spark 启用了内存分布数据集,除了能够提供交互式查询外,它还可以优化迭代工作负载。

    sczyh30/docker_spark
    3期镜像5.png

    # 6.Gitblog 一个简单,易用,高效的Markdown博客系统

    GitBlog是一个简单易用的Markdown博客系统,它不需要数据库,没有管理后台功能,更新博客只需要添加你写好的Markdown文件即可。它摆脱了在线编辑器排版困难,无法实时预览的缺点,一切都交给Markdown来完成,一篇博客就是一个Markdown文件。同时也支持评论,代码高亮,数学公式,页面PV统计等常用功能。GitBlog提供了不同的主题样式,你可以根据自己的喜好配置,如果你想自己制作博客主题,也是非常容易的。GitBlog还支持整站静态导出,你完全可以导出整站静态网页部署到Github Pages。

    dockerxman/docker-gitblog
    3期镜像6.png

    #7.NodeBB 基于nodejs的响应式论坛

    NodeBB是Design Create Play开发的一款使用Node.js构建的论坛系统,使用redis或mongoDB数据库,采用web socket技术实现。支持响应式布局,兼容IE8,将论坛的体验带向一个新的高度。nodeBB的优点:基于socket.io,界面高度简约,丰富插件和主题提供,提供实时聊天功能,新消息消息声音提醒,可以恢复上次浏览页面的具体位置,丰富的管理模式,中文支持,高度开放控件和页面编辑。

    csuhp007/nodebb
    3期镜像7.png

    # 8.轻量级的开源社区系统 ThinkSAAS

    ThinkSAAS是一个轻量级的开源社区系统,是一个可以用来搭建讨论组,bbs和圈子的社区系统。ThinkSAAS是将sns社会化网络元素,人和圈子(讨论组)结合在一起的新型的社交系统。系统特点:开发简单,php新手也可以开发强大功能;单一入口;扩展强大,支持应用扩展和wordpress式插件扩展 APP可单独配置独立数据库;WEB端和server端API接口统一;多端自适应,集成bootstrap;底层加载速度快,抗压和并发能力强;集成ueditor,内容编辑异常强大;适合个人和团队协作开发;集群、分布式部署、各种缓存、数据库读写分离等各种针对大数据和高并发的策略都在实践中

    jechiy/thinkssas
    3期镜像8.png

    # 9.Discuz! 论坛(BBS)系统 - Docker版

    Discuz! 论坛(BBS),是一个采用 PHP 和 MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台,是全球市场占有率第一的社区论坛(BBS)软件。

    tenxcloud/discuz
    3期镜像9.png

    # 10.JIRA 项目与事务跟踪工具

    JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富,其超过150项特性得到了全球115个国家超过19,000家客户的认可。JIRA推出云服务和下载版,均提供30天的免费试用期。云服务无需安装可直接试用,下载版采用一键式评估安装,在用户自己的服务器上运行。

    wenzizone/jira
    3期镜像10.png

    有人说Docker Hub上三成的镜像包含漏洞?扯吗不是?

    kurtzhong 发表了文章 • 0 个评论 • 5795 次浏览 • 2015-06-04 12:00 • 来自相关话题

    【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用We ...查看全部
    【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用Web安全审查进行检查,如果想让Docker更加安全,建议用dockerbench来评估。文中额外阐述了容器究竟有什么用。

    这个数字太神奇了!并不是因为这个比例过高或者过低,而是因为居然存在这个比例。既然存在(相对容易地)计算出这个比例的可能性,也就意味着存在(相对容易地)改善这个比例的可能性。

    声明:我是Docker官方人员,然而我写这篇文章并未受到公司批准,所以最好带着批判的思维来读本文。

    这个数字来源于BanyanOps的博客

    漏洞的计算
    -----------

    首先,来看看怎么才能计算出原文中的数据。这过程比较简单:

    • 获取Docker注册表的一个列表
    • 下载列表中的镜像
    • 检查镜像中的漏洞
    这步骤看起来似乎太简单,我们稍微深入下细节。# 列举镜像列举官方的镜像是容易的。这些镜像是基于一个叫bashbrew的自动化系统构建而来的,使用的都是公布于众的方法。顺便一提,这意味着如果你想重建官方的镜像,做起来也会很容易。(记住那些方法中涉及一些blobs或者tar包,是在启动的时候用到的;因而有时你要多费一点力,重建这些blobs或者tarbal)。构建官方镜像的方法在Github上的docker-library仓库可以找到。要列出其他的镜像(即属非官方的用户和机构所有的镜像)要困难点。Docker Hub目前没有提供什么方法来列举他们,所以一个暂时可行的方法是搜索一个十分宽泛的关键字,然后对其结果进行提取。当然,这需要一些抓取的工作;抓取到的结果可能会漏掉一些用户的数据,但是你拿到的结果已经会十分接近了。(虽然这么做肯定可行, 我也听说新的注册表接口有一些十分好的特性,可以让这一步完成起来容易点)。# 下载镜像下载镜像是一个繁琐的任务。如果你想安安静静的做这件事情,运行一个docker的守护者进程,然后执行`docker pull username/imagename:tag`即可。如果你想拿到容器的文件系统的一个tar包,也很容易:只需要运行`docker export username/imagename:tag`就行。(记得把标准输出重定向到其他地方,否则你的终端会抓狂的)如果你不十分相信Docker的守护者进程,你可以检查registry的接口(v1v2)并且通过接口来下载层,然后把层文件重组成镜像文件。一些细节我想留给你自己去做,但是层文件只是普通的tar包,你只需要在彼此之上解包(需要保持正确的顺序)就可以重组成镜像文件。没有什么特别难的步骤;唯一需要留心的地方就是“留白”(whiteout)。“留白”是特殊的标记文件,用来表明“此处曾经有文件存在于此,但目前没有了”。换句话说,如果一个层包含文件`/etc/foo.conf`,但是之上的层把其删除了,上一层就会包含一个`/etc/.wh.foo.conf`文件,并且`foo.conf`不会出现在容器里面。这个文件相当于被留白文件加上了蒙板。我后来发现,了不起的Tianon已经为此写好了一个脚本,如果感兴趣你可以去看看。# 检查镜像在这个阶段你有几件事情需要做。细节繁琐,本文无法全部叙述;但是在一个全面的安全检查中,下面这些步骤你可能需要做:
    • 运行`yum-security`或者类似的命令,保证在此刻没有安全更新;
    • 或者更好的做法是:列举出所有安装的包及其版本,然后检查软件包在该版本是否包含漏洞;
    • 计算系统中的每一个文件的hash值,然后去跟已知的有漏洞的文件的hash集合去做比较;
    • 执行自动化工具(如`chkrootkit`)寻找可疑的文件;
    • 运行一定数量的专门为某些漏洞而打造的漏洞测试。这些测试的目标是尝试利用某些漏洞,然后告诉你,“你的系统有漏洞,因为我已经设法利用了这个漏洞”或者“我无法利用这个漏洞,所以你的系统很可能没有此漏洞”。
    事情到了容器的环境中变得很有趣,因为用Docker来自动化这些步骤容易且便捷。例如,你可以将你的漏洞分析工具包放在`/tmp/toolkit`中,然后对于每一个镜像`$I`,执行`docker run -v /tmp/toolkit:/toolkit $I /toolkit/runall.sh`。(注意:这里假设你的工具包是静态链接并且/或者是自包含的,如不依赖你容器镜像中的任何地方,因为这又可能让你的工具包收到蒙骗。我这里主要想说的是,如果你想用一系列的测试来检查你的容器镜像,你可以用容器让这个步骤变得很简单,并且整个过程会更加的快速,因为对于每一个测试你不需要单独做一个检查的机器的拷贝)提升指标----------那么在我们运行完这些测试,然后发现出奇高比例的镜像包含有漏洞的包。我们怎么来改善这个指标呢?对于官方的镜像,最容易的方法是遵循Docker的安全指南。以后随着官方镜像数的增长,Docker也会改善这个机制,达到自动提示官方镜像的上游安全列表的效果。对于非官方的镜像,你可以检查镜像中的`Author`字段:
    $ docker inspect --format '{{.Author}}' bin/ngrepJerome Petazzoni 
    如果该镜像是自动构建出来的,你可以找到其来源的仓库,并且直接联系他们。如果你直接受到了漏洞的影响,想事情进展的更加快速,你可以自己重建镜像,并且/或者研究怎么才能修复这个漏洞,然后提交一个包含相应修复的PR。这里的意图不是把安全的责任推卸到镜像的使用者身上,而是让有意愿和有能力修复这些漏洞的人能对Docker镜像的安全做贡献。在将来,这些步骤会完善,并且流式化。会有自动化的过程构建出来减少需要联系相关机构的烦琐,然后尽量降低发布包含漏洞补丁版本的时间。# 但是30%还是太高了,对不对?30%的“有漏洞的镜像”可能听起来非常多。我第一次听到也是这么想。但是如果你细看,你会发现其中一大部分的镜像是老的镜像,它们是__故意不被更新__的。什么?__故意不被更新__?是的,并且对此有一些好的解释。第一个是(其中的一部分)照顾其他的媒介。有的发行版想`XYZ`想在CD/DVD,网络安装,VM镜像,和容器都保持一致。第二个原因是(这也解释了第一个原因)可重复的构建。设想你有一个服务器跑着12.04,但是你用一个新的Ubuntu 12.04的版本(更别提14.04)却重现不出来。在更加深入的研究后发现,这个问题只存在于那些在某特定时间安装的机器,其版本是12.04.02。如果一个容器镜像有12.04.02的版本,你可以重现出这个bug;否则,你得从其他地方得到这个特定版本。这就是为什么Docker Hub有很多老的镜像,它们保持着发行时的状态 - 同时包含当时发行时的安全问题。尽管这么说,我们已经放置了安全警示说“历史的镜像 - 保持远离”,所以我们比较希望这些镜像在计算出这些安全的指标的时候不应该被包含进去。让我们希望下次有人在计算安全指标的时候他们能意识到这一点。在本地采取措施 ---------------我们可能跑着有漏洞的镜像!求救!怎么办,怎么办?事情没有其看起来那么糟。当你(或者其他人)做完对于这些镜像(官方的,公开的,私有的)的审查,结果是一个镜像的列表(以一个唯一的hash串),并且包含“PASS”或者“FAIL”的状态。(对于“FAIL”的镜像,你可能想知道一些其为何不通过的细节,如:“好像有ShellShock/CVE-2014-7187和其他漏洞”或者“包含软件包OpenSSL 1.0.1c / CVE-2014-0160”。)# Web规模的安全审查你可以拿着这个列表,然后与你本地的镜像做比较。这里就是事情变得有趣的地方。根据本地镜像和这个列表做一个简单而廉价的匹配结果,你就马上能知道你是否运行着有漏洞的镜像。这可以很容易的扩展到成千上百万的主机。这也意味着事情可以很好的解耦:你的安全审查员不需要访问你的生产环境(甚至不需要访问你的开发环境中的系统)。他们甚至不需要要知道你运行着什么镜像:他们只需大面积的对镜像做分析,然后得出结果给你。你甚至可以从几个安全公司那里拿到结果然后比较他们的结果。# 我的镜像在创建后修改过怎么办?对于新手,你不应该这么做。如果你像更新容器中的某些东西,你应该创建一个新的镜像然后运行该新的镜像。好吧,但是我已经这么做了该怎么办?那真是什么都说不准,但是至少我们能知道你这么做了。安全审查的一部分,你可以在运行的容器上运行docker diff来知道是否他们被修改了。(通常docker diff是没有结果的。注意你已经用shell启动了一个容器,或者在容器内执行过docker exec,你可能会看到少许的更改。但是生产环境的容器不应该出现任何的更改结果。)专业的Tip:你甚至可以防止更改,通过在容器中使用`--read-only`的标记来达到这一点。这会让容器的文件系统只读,保证`docker diff`的结果为空。如果你想用一条命令来检查所有的容器,可以执行:
    docker ps -q | xargs -I {} dockr diff {}
    (感谢@diogomonica提供命令!)# 我已经构建了自定义的容器怎么办如果你构建了自己的容器,我建议你把他们上传到一个仓库里面。如果这是一个公共的,我们就会到最初讨论的情形。如果这是一个私有的,让我们看下一个部分!私有的镜像和注册表该怎么办?----------------------如果你上传的是私有的镜像怎么办?如果你上传的地方是一个本地的注册表,或者Docker Hub的企业版怎么办?事情显然变得更加复杂了。你可能会看见有人告诉你“设想ABC有CVE-XYZ的漏洞”如果他们从来没有看到过镜像ABC。这里是一些可能会发生的事情:
    • 安全提供商可以提供镜像的扫描器,你可以用在自己的镜像上;
    • 安全提供商可以更进一步,将其集成到Docker的注册表中。这可以通过分配读权限(访问Docker Hub上的私有镜像)或者部署前置(on-prem)的安全扫描器(对于Docker Hub企业版的情形)来实现。在两个情形中,都能达到一旦镜像上传就会被自动扫描的效果,并且立即报告任何可能包含的漏洞。
    结论---有两点我想强调,因为我相信这能在安全领域产生好的结果。[list=1]
  • 得出数字是好的。一旦我们得到了量化的数据,我们可以提升他们。Docker对于安全问题十分延严肃,你可以很肯定我们会和社区及镜像的维护者一期来改善这些量化数据。
  • [list=1]
  • 有类似这样的围绕着Docker和Docker Hub的生态环境和社区,让他们成为一个树立标准的地方。正如Soloman在一些keynote里面指出的,Docker里面最重要的一点不是技术,而是让人在某事上达成一致。
  • 后一点意味着Docker现在有足够的批评群体来校正横向的工具(包括安全审查)来让这个生态环境受益。其结果会是更加完善的安全机制,让每一个人受益。# Docker注重安全如果有Docker公司不在乎安全的印象,那真相离你就太远了。正如上面指出的,我们有一个负责的披露安全的政策,并且我们总是很快的解决我们意识到的问题。没有哪个软件是没有bug的。Docker也是由人类编写出来的,即时他们有些人十分的了优秀,但是还是会犯错。重要的是我们对待安全报告的严肃态度如何,我们解决这些问题的速度如何;我想我们在这些方面都一直做的很好。如果你想让你的Docker的环境更加安全,我推荐你看下dockerbench。我参与了其编写,该软件包含了一个自动化的评估工具可以用来评估Docker的主机,使用的是CIS Docker 1.6 Benchmark。它会检查很多事情(如是否SELinux和AppArmor是启用了的)然后生成一个报告。这是Docker会推出或者参与的一大批软件的第一批,目的是让你可以在没有Docker容器安全方面的Ph.d的证书的情形下,或者在没有聘请一个Taylor Swift的情形下,安全地运行Docker。并且,我们鼓励公开的讨论,安全的担忧也不例外。Docker Library的仓库里面有一个十分有趣的有关于这个话题的讨论# 额外的提示有人问我阐释下容器究竟为什么有用,如果我们不反复的检查我们运行的所有的东西的来源。这里是一些例子:
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如著名的`curl ... | sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(比如一个商用软件的`install.sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个npm,pip,gem等等的包,但是我们不清楚其来源),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个deb,rpm或者其他的发行版的包),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个危险的squid包),并且可以查看到底能产生结果,这得益与`docker diff`。

    我猜想你能看出这个模式。仅仅因为事情以一种熟悉的形式呈现给你并不代表它们是安全的。但是我们可以使用Docker来提升安全性。


    原文链接:Someone said that 30% of the images on the Docker Registry contain vulnerabilities(翻译:钟最龙)

    Docker Hub中超过30%的官方镜像包含高危漏洞

    kurtzhong 发表了文章 • 1 个评论 • 7380 次浏览 • 2015-05-28 15:40 • 来自相关话题

    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。 Dock ...查看全部
    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。

    Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险(如:Shellshock、Heartbleed、Poodle等)。对于普通的镜像,即那些被Docker用户上传的,没有经过任何权威机构验证过的镜像,这个比例高达40%(样本的错误大约在3%)。
    1.jpg

    [图:多姿多彩的容器,图片来源自VSMagazine]

    为了开展这次研究,我们下载了Docker Hub中的的镜像,然后分析其中的软件包和版本。然后我们使用来自Mitre、NVD(美国国家漏洞数据库)和Linux发行版自己的数据库来分析哪些镜像易于受到攻击。我们开发一个开源的工具 Banyan Collector,并且使用一个叫做Banyan Insights的服务来生成这个研究中的数据。

    尽管我们的分析是基于公共的Docker Hub进行的,我们预估这结果与那些使用私有容器注册中心的企业会类似。企业通常会不断基于那些口碑较好镜像来部署容器,依赖这些镜像的周期更新来获取最新的软件包。尽管有这些措施,企业仍然有漏洞的威胁;更加严格的运维管理加上实时的监控对于保证安全必不可少。

    在本文的剩余部分,我们简单的从高层次介绍下安全漏洞是如何分类,描述基于分析Docker Hub上官方和普通镜像中漏洞得到的结果,然后讨论下这份研究对于运维管理的意义。


    安全漏洞的指定和分类
    -----------------------

    Mitre作为一个不以盈利为目的机构,指定并维护一份CVE(常见安全漏洞和威胁)的列表,每一个CVE描述了在广泛发布的软件中的漏洞。由美国政府维护的NVD数据库列出了每一个CVE的影响,包含其波及的软件和相应的修复措施(或者尚未采取修复措施的)。每一个Linux发行版也都维护了一个发行版特定的影响和提供修复该漏洞的软件包版本。

    每一个漏洞都会被NVD和Linux的发行版指定一个分值。分值的范围从0到10,7.0到10.0属于高危漏洞,4.0-6.9之间的属于中危漏洞,0-3.9的属于低危漏洞。这个分类考虑了一系列因素,包括利用该漏洞攻破系统所需要的复杂度(复杂度越低,分数越高)和该漏洞可能会造成的影响(影响越大,分值越高)。下面是一些例子:

    1. 高危漏洞:如:ShellShock(bash)、Heartbleed(OpenSSL)
    2. 中危漏洞:如:Poodle(OpenSSL)
    3. 低危漏洞:如内存中数组的内存的分配可能会导致整形溢出

    把漏洞划分为高中低漏洞的做法带有主观性,一些公司也可能会根据自己的情况来重新分类。而且,NVD指定的分值可能跟Linux发行版中的分值不一致,并且可能会随着时间推移而更改。我们的研究中使用的漏洞的分值来源于Ubuntu和CentOS发行版指定的分值,对于Debian我们直接使用了NVD数据库中分值,因为我们找不到任何关于Debian发行版对漏洞分类比较好的数据源。我们对Docker Hub在2015的5月20日的镜像做了一个快照,然后进行分析。我们也试了一下其他日期,得出的结论十分相近。

    对于Docker Hub中官方仓库的评估
    ------------------------------------

    Docker维护着一个官方的仓库的列表,为软件厂商和机构(如Canonical、Debian、Redhat等)提供了一个即时更新它们最新容器镜像的渠道。官方仓库可以从他们的路径体现出来,他们的路径在`library`的命名空间下。举几个例子:`library/ubuntu`,`library/redis`等。Docker Hub包含大约75个官方的仓库(在我们写这篇文章的时候),大概包含约1600的不同的标签,指向约960个不同的镜像。
    2.png

    [图一:官方有漏洞的镜像]

    图一展示了根据分析Docker Hub上所有官方的镜像的得出的主要结果。超过1/3的镜像有高危漏洞,接近2/3的有高或中级危漏洞。这些统计数据让人无法平静,因为这些镜像中一些也是下载量最多的镜像(一些有几十万的下载量)。

    如果我们只看今年创建的镜像,有高危漏洞的镜像的比例仍然超过1/3,但是含有高和中级危漏洞的镜像接近了75%。换句话说,今年创建的镜像,每四个中就有三个存在较容易被利用的漏洞,并且潜在影响非常大。

    如果我们将范围缩小到哪些标注了`lastest`(最新)的镜像,这比例分别下降到了23%和47%,这比例显然还是很高。这更小的数据说明,Docker的用户和维护者们,倾向于将镜像保持到最新,但是老一些的镜像却被忽略;创建容器数量之大和速度之快,让老的镜像在更新的时候被忽略。

    为了理解这些漏洞,特别是排名靠前的,我们做了一个详细的影响Docker Hub的镜像漏洞的分析:
    3.png

    [图二: Docker Hub官方镜像中有高危漏洞的镜像]

    图二展示了该分析的主要结果,并且表一列举了跟这些软件包相关的主要的CVE。最近发布的存在于mercuarial的漏洞在很多镜像中都有(大约20%)。著名的OpenSSL漏洞如Heartbleed和Poodle,在近10%的官方镜像中存在。一些镜像还包含bash的ShellShock(如Centos5.11镜像中)漏洞,这个漏洞在7个月前就被发布了。即便一些机构不使用这些包,但是如果不手动将这些包从容器中移除掉也会成为恶意攻击的羔羊。
    4.png

    对于Docker Hub中普通仓库的评估
    --------------------------

    除了一些官方的仓库,Docker Hub包含了一大部普通仓库(在写本文的时候大约有95000个),并且有数十万不一样的镜像。我们实验中随机选择了1700个镜像,然后对他们的内容的内容进行分析(误差约百分之三)。
    5.png

    [图三:有漏洞的普通镜像]

    图三显示了在分析了普通镜像后得到的主要结果。大体上,漏洞的出现概率比官方镜像的相比大很多。这个结果合乎预期,因为目前尚没有措施可以在将镜像上传到Docker Hub前可以过滤并检查这些普通的镜像。

    大约40%的普通镜像有高危的漏洞。即便我们只是看今年创建的镜像,并且只看那些有`latest`标签的,包含漏洞威胁的镜像的比例仍然在30-40%之前徘徊。如果我们包含那些含有中危漏洞的镜像,比例会迅速升到70%以上,不管哪个时间段都是如此。尽管你可能会说,这些镜像比起官方镜像下载次数太少了,但是考虑到它们庞大的数量(几十万的规模)可以预想它们跟官方镜像一样使用甚广。

    我们又分析了影响普通镜像中的高危漏洞,图4展示了主要的结果:
    6.png

    [图四:普通镜像中含有高危漏洞的软件包]


    有趣的是,不同于官方镜像中首要祸源在于mercurial,在这些普通的镜像中,openSSL、bash、和apt成了祸源的榜首。我们怀疑官方的和普通这种数字上的差异来源于发行版的差异,他们占据了这些镜像的大部分。官方镜像通常基于Debian,并且其中一一大部分包含mercurial包。而普通的镜像,却通常基于Ubuntu因而有bash、apt和/或openssl相关的漏洞。


    延伸
    ---

    容器技术带来软件开发中的变革,它提供了一个十分高效的方法,可以将开发者开发的软件在数分钟或者几小时内搬上生产环境运行,而传统的方式可能需要几天甚至数月。但是我们的数据显示这种优势有其弊端,没有谨慎的运维和安全管理的措施,我们冒着让我们的软件生态环境更容易被攻击的危险。

    容器为运行于不同容器之间的运行程序提供了一层安全隔离,因而提高了安全性。然而容器还是需要和其他的容器和系统进行通讯,因此,由于镜像中存在的安全漏洞,它们还是很容易被远程攻击,包含那些我们没有分析到的漏洞。再者,在多种多样的环境中启动大量的容器的轻便与快捷,如在你的共有云上,私有云上,笔记本上,都让追踪和防护有安全漏洞的容器变得更加困难。部署容器的高效性,大大的加速了部署软件的多样性,结果让环境中的新的漏洞越来越多。

    使用容器的另外一个根本点在于,包管理已经被转移到了容器的内部,而传统的方式是仅仅是基于安装在虚拟或者实体机的操作系统层面上。这种改变主要根源于虚拟机和容器提供的抽象处于不同的层面。虚拟机提供的是以主机为中心的抽象,其特点是长期不停机一直运行,包含的软件包供不同应用所需。与之相对的,容器提供的是一个更加以进程为主的抽象,其特点是短暂性,可以到处运行,构建后不会改变,仅仅包含运行一个应用所必须的软件包。任何更新都需要重新构建容器,从而保持容器的不可修改性,这让任何的漏洞同时被复制。

    另外,向DevOps模式的转变,开发者开始为他们开发的应用的软件包负责,这意味着现在开发者开始负起了维护软件包的责任。除了操作系统的软件包,开发者在容器中可以包含应用层面中的模块,如pip(Python)、npm(Node.JS)和maven(Java)等,而这些都在我们的研究之外,然而它们也可能带来新的安全问题。因为开发者更加关注快速的开发出新的功,这让保持老的镜像更新变得更加困难,正如我们的研究呈现的一样(如官方的与201年4月发布的CentOS 5.11镜像仍然包含Shellshock漏洞,该漏洞是八个月前,2014年9月被爆出的)。

    一个很好的避免这些问题的方式是经常用最新的更新重新构建镜像。重新构建的过程必须使用发布商发布的最新的基础镜像,并且不能使用任何缓存的镜像层(如:使用在apt-get upgrade的时候加上`-no-cahce`)。但是在一旦发现漏洞从头重新构建,并且重新部署所有的容器的开销太大,十分不切实际了—— 漏洞出的频率太高,每天都会爆出好几次,并且很难评估每一个安全漏洞的的影响范围。加之,更新容器的软件包很可能给容器中的应用带来负面影响和不稳定性,而这即使用复杂的测试也未必能捕捉到,这让人更加不情愿经常更新。


    结论
    ---

    我们的研究结果鼓励使用严格的运维管理流程,实时的分析镜像中的内容,清楚其中的内容和包含的漏洞。镜像应该经过安全漏洞的扫描,并且根据漏洞的严重程度来标记是否需要更新。任何重大的漏洞都应该被及时的发现,并且应该可以触发对这些有隐患的镜像进行隔离机制。镜像不仅仅应只从操作系统层面进行扫描,也应从应用的层面的安全漏洞进行扫描。这些流程应该被集成到持续构建的框架中,这样在享受容器带来的全面福利的同时,仍然保持着好的安全实践。

    原文链接:Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities(翻译:钟最龙 审校:魏小红)

    Docker收购Kitematic:一个非常棒的GUI工具

    叶可强 发表了文章 • 3 个评论 • 36407 次浏览 • 2015-03-12 23:32 • 来自相关话题

    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持 ...查看全部
    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持Windows。本文翻译自Docker官方博客。

    image2015-2-23-16-36-9-300x78.png

    我们非常高兴地宣布我们收购了Kitematic,它是Mac上最快、最易使用的Docker工具。Docker 是一款面向开发者的工具,我们也发现生态系统中的开发者为 Docker 构建了最酷的工具。Orchard 的 Fig(现在是 Compose)以及 SocketPlane 都是产生于生态圈中的最佳案例,它们提升了开发者体验并为分布式应用提供了灵活性操作。

    今天,Kitematic在简化开发者体验这一步上更上一层楼。它可以让Docker更易使用:Kitematic进一步增长和丰富了社区和生态系统。
    ## Kitematic 是什么?
    Screenshot-2015-02-23-16.27_.27-1024x752_.jpg

    Kitematic 完全自动化了 Docker 安装和设置过程,并提供了一个直观的图形用户接口(GUI)来在 Mac 上运行 Docker。Kitematic 集成了 Docker Machine 来在 Mac 上分发一个虚拟机并安装 Docker 引擎。

    一旦安装成功,Kitematic GUI 便会启动,紧接着你可以立刻运行控制台中的镜像。你仅仅只需要在 Kitematic 搜索框键入镜像名就可以搜索任何在 Docker Hub 上存在的镜像。通过 GUI 你可以非常容易的创建、运行和管理你的容器,不需要使用命令行或者是在 Docker CLI 和 GUI之间来回切换。
    image2015-2-23-18-43-5.jpg

    Kitematic 也让Docker的一些高级特性使用更加方便,比如管理端口和配置 volumes。你可以方便的修改环境变量、查看日志,单机终端就可以进入容器,这些特性GUI都支持。
    ## 未来将会怎样?
    自从测试版发布后,仅短短几个月,Kitematic 就拥有了成千上万的用户,都是积极的反馈并有上千的 GitHub stars。同时,我们相信,一个关于开发者如何与 Docker 交互并运行他们的容器的伟大旅程即将开始。

    你可以通过我们在 GitHub 上的路线图来获取更多信息 ,同时你也可以为你想看到的任何东西提交 pull request。我们会扩大团队处理路线图上的功能,接下来将包含一个新的 Windows 客户端以便更多的开发者能更快速、更容易的在他们的机器上运行 Docker。

    ## 免费尝试下 Kitematic,它是开源的

    当然,Kitematic 将继续保持开源和免费,所有人都可以通过 GitHub获取。团队希望得到你的反馈和支持,好啦,就从 kitematic.com 下载最新版的 Kitematic 开始吧?
    image2015-2-23-16-41-45.png


    ## 学习更多关于 Kitematic 的知识



    原文链接:KITEMATIC A DOCKER GUI JOINS THE DOCKER FAMILY(翻译:叶可强 校对:李颖杰)

    ===========================
    译者介绍
    叶可强,目前在唯品会上海分公司从事应用运维工作。业余时间专注Docker的学习与研究,希望通过DockerOne把最新最优秀的译文贡献给大家,一起促进国内 Docker 的发展。

    Docker Hub的镜像安全吗?会不会有人留个后门啊,如何辨别呢?

    noprom 回复了问题 • 7 人关注 • 4 个回复 • 8697 次浏览 • 2015-11-30 21:11 • 来自相关话题

    Docker Hub的镜像安全吗?会不会有人留个后门啊,如何辨别呢?

    回复

    noprom 回复了问题 • 7 人关注 • 4 个回复 • 8697 次浏览 • 2015-11-30 21:11 • 来自相关话题

    推送镜像到Docker Hub失败

    回复

    最爱xiaoyu77 回复了问题 • 3 人关注 • 2 个回复 • 5168 次浏览 • 2015-03-06 17:57 • 来自相关话题

    运行Docker容器的时候 映射路径遇到用户权限问题

    回复

    大自然保护协会志愿者-王康 回复了问题 • 3 人关注 • 3 个回复 • 9463 次浏览 • 2015-02-28 11:02 • 来自相关话题

    游戏开发  Laradock应用Docker实现开发环境

    mrkelly 发表了文章 • 0 个评论 • 3372 次浏览 • 2017-02-22 10:27 • 来自相关话题

    简单点 最近,跟一个大学金融系的同学交流,发现他对科技发展的动态非常了解,然而对于一些技术关键字的应用并不是很理解。 对于普通不懂技术的小白来说,如果去咨询一些IT行业技术大牛,他们往往会获得一个一脸懵逼的回答。比如说,他 ...查看全部
    简单点
    最近,跟一个大学金融系的同学交流,发现他对科技发展的动态非常了解,然而对于一些技术关键字的应用并不是很理解。

    对于普通不懂技术的小白来说,如果去咨询一些IT行业技术大牛,他们往往会获得一个一脸懵逼的回答。比如说,他问我“云计算”是什么?百度百科:

    云计算[1] (cloud computing)是基于互联网的相关服务的增加、使用和交付模式,通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。



    01.png

    别说一个技术小白了,就算现在我看完这句话,我也是一脸懵逼,难为大家了。站在技术小白的角度,去看看网上的一些“云计算”的解释,你会发现,还是那么的难以理解。

    用产品的口吻来说:用户体验不好。

    我尝试给他作出类比:

    “古时候,人们家里做一口井,水从井里打出来,而现在,我们扭开水龙头,水就来了; 10年前,你要装软件,得跑去电脑城买光碟,而现在,连上网打开应用商店,软件尽在眼前——这就是云计算”。



    当然了,本来“云计算”就是一个很广的问题,这样的解释无非是拿出其中之一的应用场景作类比。但是它能帮助普通人更好的理解。

    我觉得这是一个非常有趣的过程:用跨界思维,用拟物或拟人的方式,去提炼简化一些看起来很复杂、枯燥的技术关键词。


    Docker是什么?

    回归正题,我们讨论Docker。估计喜欢浏览技术新闻资讯站的同学,都会知道Docker——传说中改变世界的东西,它改变了应用的部署运维。那么Docker是什么?来看看百度百科:

    Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。



    当初,看完它的解释后,我的第一反应依旧是懵逼,因为它跟我们脑海中常见的物理机、虚拟机的概念相比,是一种未曾想象过的新事物。

    鉴于所在工作环境周围,还没见过应用Docker在开发环境的同学(希望大牛云集的项目不要鄙视),而我又觉得用通俗化的思路去解释Docker思维是有价值的一件事,这也是本文的成文目的。
    02.png

    这是Docker的官方图标——一只大鲸鱼,上面有各种各样的集装箱;鲸鱼就像一个操作系统,上面装着各种各样的集装箱——软件

    也许你会问,这不跟我们iPhone应用一样吗?手机操作系统(鲸鱼),里面有各种各样的App(集装箱)。

    但是,仔细想想,iPhone上的App,Android上能运行吗?——不行。因为iPhone使用IPA格式的App包装方法,而Android使用APK格式的App包装方法,两者部署上是非常的不一样的。

    能不能在Android上,运行iPhone应用,而又不使用损耗资源的虚拟机技术? 这就是Docker——它应用在PC平台上的,可以让不同的操作系统平台,占用很少的资源,运行同样的软件程序

    03.png



    它就像一个提供开发型软件的应用商店。以往,我们需要安装MySQL数据库,我们首先要想,我的操作系统是Windows?我的CPU是64位? 然后我们找到了MySQL Windows 64位版本进行下载,然后开始安装,安装在C盘?安装完成后,把数据库账号密码设置好?

    而在Docker时代,我们只需要下载MySQL的Docker镜像安装就可以了。

    这个思路推而广之,Android上利用Docker运行iPhone应用什么时候可以做到?这是技术上可行的,但这里不作过多幻想了。

    Docker不是什么新生事物,早在2013年就诞生了,而它的核心技术cgroup早在2006年就写进Linux内核了,直到这2年,才渐渐开始广泛的应用。

    Docker常见的场景,是部署和运维。今天,我们抛开技术细节、理论、运维需求,简单谈谈Docker怎么应用到我们日常游戏开发环境当中,并让团队的工作流程起到什么样的优化。

    快速搭建MySQL+Redis开发环境

    Laradock是一个PHP的Docker开发环境,使用它可以极其方便的快速搭建PHP开发环境。 它不但包含了PHP语言执行环境,还包括了一系列相关工具,其中包括我们非常常用的MySQL、Redis。

    在Laradock的官方文档中,就有这样的一句话:

    Use Docker first and learn about it later.
    > 先使用Docker,然后再学习它。



    是的,先使用它,然后再深入学习Docker的一些很原理,一个自上而下的学习过程,可以让你更加快速的理解和应用Docker。应用Laradock是一个很好的Docker学习起点。

    要使用Laradock,首先你得安装Docker。 一般有可以选择下载Windows版Docker
    下载Mac版Docker,跟着安装步骤安装即可。

    而在国内,访问Docker的镜像仓库非常的慢,因此,需要设置国内的加速镜像仓库。
    04.png

    安装好Docker以后,会有小鲸鱼的图标出现在系统托盘上。右击出现菜单(macOS系统则是左击),并选择“Settings”。
    05.png

    Windows环境时,选中“Docker Daemon”界面,往"registry-mirrors"字段里添加镜像仓库的地址。

    为什么要配置镜像仓库地址?像前面所说的,Docker有点像应用商店——把需要的开发软件,下载并安装。因此镜像仓库()上储存着各种各样的“镜像”,可理解成别人预先制作好的开发软件。包括我们常见的MySQL、CentOS,其官方都会维护一份Docker镜像。

    使用Laradock,你可以使用它在GitHub上托管的源码:
    bash
    git clone https://github.com/laradock/laradock
    cd laradock
    docker-compose up -d nginx mysql redis memcached

    或者,如果连命令都不想输入(或者git都还没安装),下载https://github.com/mr-kelly/laradock/archive/master.zip ,解压后,在安装好Windows环境双击执行start.bat批处理。
    06.png

    这样的一条命令,呼叫Laradock下载、启动了nginx、MySQL、redis、memcached四个主要容器。这几个不同的Docker容器互相组合,并映射端口到本地。比如把localhost:80端口映射到nginx容器的80端口,把localhost:3306端口映射到MySQL容器的3306端口。

    这时候,使用你的MySQL数据库工具(比如Navicat),输入连接地址localhost,账号root,密码root,你就能连上了MySQL容器中的MySQL数据库程序了。


    # 为什么我会使用Laradock?

    在以往,我一般会使用XAMPP来当作我的PHP HTTP开发环境——它内置了Apache、MySQL等开发组件,并且能以“绿色”软件的方式安装运行在我的电脑上。 直到有一次,XAMPP在我的macOS上,出现phpredis扩展无法访问Redis的问题,折腾很久也没找到具体的原因,最终转而使用Docker搭建开发环境。

    在日常的工作中,我们其实经常遇到这种情况:因为一些跟业务工作的一些小问题,比如装系统啊、环境配置的坑啊等等,会耗费我们非常多的精力。

    要真正的应用Docker到您的开发环境,需要根据项目业务、技术选型,来自定义Docker镜像,比如说,一个使用Java+MySQL的项目,除了MySQL镜像外,还需要Java运行时镜像,多个镜像互相组合。

    可能你会疑惑,为什么要弄成多个镜像?使用一个Linux发行版镜像,然后在上面安装好Java、MySQL,再制作一个完整的镜像不就行了吗? 是的,这也是可行的,只是说这样做法,类似于编程开发中的“耦合度高”,就是当这样一个完整的开发环境镜像在某一天需要修改时,比如说其中的MySQL版本更新了,就需要对这个镜像进行重新制作。而拆分成多个镜像互相组合,则只需要使用官方对应版本的新镜像即可。

    怎么使用Docker进行镜像的制作,官方的文档很多,这里就不重复“造轮子”了。Laradock的Github地址https://github.com/laradock/laradock ,上面有其更加详细的使用方法。

    应用Docker开发环境的场景

    # 一个新人入职

    新人工程师走进公司,会有一个熟悉工作环境的过程,其中一个耗时的环节,就是安装开发环境。这是一个非常折腾人的过程,如果你是使用大型IDE的开发者,比如说安装MySQL、SQLServer、Android SDK等大型开发软件,这将是一个耗时的过程——首先你得找到软件包,然后再进入漫长的安装过程。最常见的实践是公司内部共享,把这些常用软件都共享出来,让大家安装。然而大家的习惯不同的,操作系统也不同,过程中依然会遇到种种兼容问题。

    曾经一个做Android开发的朋友,在入职公司的第一周内——花了一周的时间,终于把开发环境搭建完成,让Java工程编译通过。

    # 游戏策划跑单服

    游戏团队开发的过程中,免不了出现非技术人员需要在自己机器上启动游戏服务器进行测试的情况。因此,“搭建开发环境”这个技能,会出现非技术人员身上。跟程序员相比,非技术人员“搭建开发环境”或“配置服务器环境”是相对更加难的事情,他们最需要的是有一种“双击就能运行”的单服运行体验。 有一些非技术人员和程序员之间对话,是我们经常听见的:

    “嗯,这个功能我提交前测试是正常的——你的环境干净吗?需要的数据都干净地重新生成了吗?第三方库的二进制文件更新了吗?你们几个人测试的版本一致吗?要不你 Cleanup / 重启 / 重新保存 / 重新建个账号试试?”



    (引自厚积薄发 | 游戏引擎技术点滴

    然而实际的开发过程中,程序、策划之间是缺乏换位思考的,程序员更喜欢直接在自己的工作上开码,而不是为非自己工作范围内的体验进行优化。因此,“技术流”策划甚是常见,不但了解软连接硬链接的创建删除、还熟悉各种各样的SQL数据库、还会通过Visual Studio编译程序,甚至有很多都能直接编程的。

    # 开发软件

    那么能不能把装好软件的开发机整个做一个Ghost系统镜像?

    这确实是我前两年项目所使用的方法:在一台电脑上,装好所有开发环境软件,然后使用Ghost打包一个系统镜像。想法很美好,但是实际过程却很难执行。一个镜像大小动辄10多GB的占用,克隆慢,恢复镜像也慢;更要命的是,开发环境在研发过程中经常的变化,比方说想把旧有镜像中的MySQL 4升级成MySQL 5,怎么做? 不停的重新构建虚拟机镜像? 太艰难。

    后来我为了达到这样的目的,完整的MySQL执行程序、MongoDB执行程序直接放到SVN上传。从程序员角度来看,这是肮脏的,把一些无关重要的二进制文件进入到了代码库;但是从用户体验的角度来看,这是提高了非技术人员的使用体验。

    类似这个情况如果应用Docker后,我们大可以只需要把MySQL或MongoDB的Dockerfile定义文件上传到SVN,非技术人员在首次启动时就会自动从容器仓库(内网或外网均可)拉取到对应的容器并启动,快速并且规避兼容性问题。

    # 一些Linux-only的程序

    redis对Windows的支持非常有限,skynet游戏框架不支持Windows平台,但是对于使用Windows的人来说,会使用一台虚拟机来进行开发。

    而使用Docker,则可以改善这样的开发环境:部署一个Linux容器,并把本地代码文件映射到容器中,做到使用本地环境编辑代码、使用Docker运行程序;Redis官方提供Docker版本,体积非常小,让Windows下运行不再困难。

    # 导入真实玩家数据

    在项目运营中,出现的一些BUG,我们希望能模拟玩家的数据进行测试,这时候需要把一些玩家的数据导入,进行测试。一般来说,我们需要把数据库的数据导出,然后再在开发环境中导入。

    而如果运营的项目是使用Docker容器进行部署的,那我们只需要把这个容器整个拖回到本地执行,我们就能完整的模拟到真实数据环境了。 同样,应用这样的思路也可以进行数据库的备份。


    # DevOps

    说起Docker,总是免不了DevOps——开发运维一体化。这是一个很大很抽象的思想话题,但我们这里只简单的介绍其中一种应用:开发所使用的Docker容器,直接丢到生产服务器,极简部署

    比方说,我所在项目使用C#进行游戏服务器的开发,在Windows上使用.net Framework跑,实际运维环境则使用Mono。也就是说,实际运维环境中,如果出现了有.net Framework和Mono不同兼容性的BUG,这些BUG对开发人员来说都是前所未见、难以理解的——因为开发环境,跟运营环境,是完全不一样的,这会引领开发人员进入另一场爬坑游戏。

    其他

    # Docker原理
    07.png

    Docker的两大核心基础技术是namespace和cgroup,它们早在2006年的就被写进如Linux内核。

    抽象来说,跟虚拟机不一样的是,虚拟机技术,把CPU、内存等所有硬件用软件化进行虚拟,形成一个虚拟的计算机环境;而Docker,则有点像“CPU中的虚拟CPU”、“内存中的虚拟内存”来对计算机进行资源隔离。
    # Vagrant
    在使用Docker之前,我一直使用Vagrant来进行开发环境快速部署。它们的目的很相像,但是又不是那么一回事。

    Vagrant说白了,就是一个VirtualBox虚拟机的快速管理工具。以往使用虚拟机,我们需要安装VirtualBox,需要下载Linux发行版镜像,需要安装,安装后再安装各种开发软件。

    而使用Vagrant,就像Docker一样,只需要一条命令,就可以完成以上所有的工作了。 只是,说白了,Vagrant就是一个虚拟机管理工具,它就类似于你使用了一个CentOS Docker容器,然后在里面安装好所有的开发软件。


    --------------

    在Web开发领域,看到很多程序员已经应用上Docker用于开发环境了;目前身边的游戏开发中还没看到,也希望Docker慢慢普及开来。

    本文只是非常片面的展现了Docker应用的冰山一角——搭建简单开发环境。谨供你参考。

    Docker生态系统一览

    徐笑笑 发表了文章 • 0 个评论 • 10674 次浏览 • 2016-04-01 16:50 • 来自相关话题

    【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Cen ...查看全部
    【编者的话】本文旨在介绍当前可用的Docker生态系统存在哪些部分,包括:Docker Hub、Docker Engine、Kitematic、Docker Machine、Swarm、Docker Compose、Dokcer Cloud以及Data Center,文章会详细介绍这些工具的功能,以及怎样能够更好地将这些工具结合起来。

    @Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网、华为等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

    在过去的18个月内参加任何技术相关的活动或者阅读任何技术相关的文章时,你可能已经听说过Docker并且对Docker是什么以及它是用来做什么的略有所知。

    简单来说,Docker是建立在过去的一些概念之上,但是对这些概念进行了更好的封装。Docker是一个用来创建“容器”的工具,这些容器仅仅包含你所需要的一个独立的应用或者技术堆栈。与虚拟机不同的是,这些容器共享相同的资源来管理容器与主机之间的相互作用。这一点使得Docker容器快速、轻量、安全并且共享。

    “Docker建立在过去的概念之上但又对这些概念进行了更好的封装。”via @ChrisChinch
    >
    CLICK TO TWEET



    就我个人而言,作为一个技术作家和主持人,我发现Docker对于创建演示文稿是非常宝贵的。我可以组装一堆我需要的组件,运行它们,然后再摧毁我不再需要的包和数据,以保持我的系统干净整洁。

    许多开发人员在开发和测试过程中能够看到一个清晰的Docker用例,但是仍然想要了解Docker在生产中如何最好地工作。一系列第三方工具和服务的出现用来帮助开发人员从开发到生产过程中部署、配置和管理他们的Docker工作流程。

    Docker已经通过一系列收购和产品发布建立了自己的“官方”工具包。众所周知,Orca项目在去年美国的DockerCon大会上公布了,虽然细节有点模糊。在我看来,与其说Orca是一个实际的项目或者产品,还不如说它其实是Docker不断增长的产品组合的巩固策略。

    所以在这篇文章中,我会提出关于当前可用的Docker生态系统有哪些部分,它们如何帮助你,以及怎样更好地组合它们的一个总结。

    “让我们讨论一下Docker生态系统的组成部分以及这些组成部分是如何配合在一起的。”



    CLICK TO TWEET



    #Docker Hub
    任何使用Docker的项目的核心是一个Dockerfile文件。这个文件包含Docker如何创建一个镜像的指示说明。让我们来看一个简单的例子:
    FROM python:2.7
    ADD . /code
    WORKDIR /code
    RUN pip install -r requirements.txt

    在这个例子中,该Dockerfile文件拉取一个特定版本的现有镜像,将当前本地目录复制进容器的文件系统,并设置它为工作目录,然后通过pip命令从一个文本文件下载Python依赖。

    Docker Hub是预先写好的Dockerfile官方资源,提供公共的(免费的)和私人的(付费的)镜像存储库。如果你正在寻找一个Dockerfile来满足你的需求,首先在Docker Hub上搜索,使用项目文档、下载量和镜像等级来帮助指导你的决定。
    1.png

    #Docker Engine
    Docker Engine创建Dockerfile文件并把它们转化为可用的容器。Docker Engine是Docker的核心,如果没有Docker Engine那么什么也运行不了。依据你的操作系统不同有几种下载Docker Engine的方案,你可以在这里发现更多的细节

    依据Docker Hub中的一个镜像开启一个容器,应该首先拉取这个镜像并运行它。继续以Python为例:
    docker pull python
    docker run -it --rm --name script-name -v "$PWD":/usr/src/appname -w /usr/src/appname python:3 python app.py

    这样就会拉取最新的Python镜像然后开启一个容器运行一个Python脚本并且运行完后退出容器。run命令提供了更多的选项设置,你可以在这里阅读完整的指南
    当一个Docker run命令开始变得更为复杂,它可以创建自己的自定义Dockerfile文件或许是一个更好的主意。开启一个基于本地Dockerfile文件的容器,运行以下里面包含文件的目录:
    docker build -t my_image .

    这个命令将会创建一个名为my_image的镜像。运行以下命令开启一个基于这个镜像的容器:
    docker run -name my_image_container -i -t my_image

    这个命令会开启一个基于自定义的my_image镜像的容器,这个容器命名为my_image_container。
    #Kitematic
    对于那些宁愿避免命令行的用户来说,Kitematic是Mac OS X和Windows的一个伟大的GUI。搜索你需要的镜像,创建一个容器,你最好去Kitematic。Kitematic提供了基本的配置选项,但对于更高级的设置,你可能需要进入命令行。
    2.png

    你的容器出现在左手边,在那里它们可以被启动、停止、重启,更有用的是,你可以在那里找到容器日志和直接SSH(exec按键)访问。
    3.png

    #Docker Machine和Swarm
    生产中使用Docker的第一步是了解Machine和Swarm,它们为各种虚拟化和云服务提供商提供了一套简单的工具集用以移动和缩放他们的本地项目。

    “生产中使用Docker的第一步是了解Machine和Swarm。”



    CLICK TO TWEET



    例如,在Azure上创建一个Docker实例:
    docker-machine create -d azure --azure-subscription-id="XXX" --azure-subscription-cert="/mycert.pem" ecodemo

    这个命令使用预装的Docker创建一个Ubuntu 12.04-based虚拟机并命名为ecodemo。每个供应商都需要不同的参数和认证方法,这些默认设置可以被重写。在这个文档中可以阅读到更多的细节。

    当与Swarm结合后,Machine可以创建Docker实例的集群,这个集群被视为一个单一的、大的Docker实例。每一个Swarm集群都需要一个master实例,这个master实例可以用下面的命令来创建:
    docker-machine create
    -d virtualbox
    --swarm
    --swarm-master
    --swarm-discovery token://TOKEN_ID
    swarm-master

    这样就会在VirtualBox中创建一个Docker实例并且设置这个Docker实例为Swarm集群的一个master节点。TOKEN_ID非常重要,因为它可以帮助集群中的所有节点识别彼此。除了手动创建TOKEN_ID标识以外,Swarm也有发现系统来帮助你管理这个过程。

    下面的命令使用相同的TOKEN_ID标识添加Docker实例到Swarm集群:
    docker-machine create
    -d virtualbox
    --swarm
    --swarm-discovery token://TOKEN_ID
    swarm-node-n

    swarm-node-n对于集群中的每一个节点来说都是一个唯一的名字。

    现在,代替从单个虚拟机中开启容器,你可以在集群中开启容器,master节点将会把这个容器分配给最可用的和最有能力的节点。
    #Docker Compose
    Compose使得由多个组件(像容器)组成的应用程序更加简单,你可以开始使用一个命令在一个单一的配置文件中声明所有这些组件。

    下面是一个Compose文件(称为docker-compose.yml)的例子,这个例子创建三个Crate数据库实例和一个Laravel(用一些额外的配置)PHP框架实例。最重要的是,容器与Links配置选项相连。
    crate1:
    image: crate
    ports:
    - "4200:4200"
    - "4300:4300"
    crate2:
    image: crate
    crate3:
    image: crate
    volumes:
    - ./data:/importdata
    laravelcomposer:
    image: dylanlindgren/docker-laravel-composer
    volumes:
    - /laravel-application:/var/www
    command: --working-dir=/var/www install
    links:
    - crate1
    laravelartisan:
    image: dylanlindgren/docker-laravel-artisan
    links:
    - crate1
    volumes_from:
    - laravelcomposer
    working_dir: /var/www
    command: serve --host=0.0.0.0:8080
    ports:
    - "8000:8000"
    - "8080:8080"

    所有这些实例和它们的配置现在可以通过运行以下在同一目录中的docker-compose.yml文件的命令来开始:
    docker-compose up

    4.png

    你可以使用相同的子命令作为Docker的命令来影响所有以docker-compose开始的容器。例如,docker-compose stop命令可以停止以docker-compose开始的容器。
    5.png

    #Docker Cloud
    容器的自动化管理和编排是Docker的主要功能,但却一直由第三方服务来提供,直到去年Docker获得了Tutum(它支撑着Docker云)。虽然没有完整的命令行工具(还没有),Docker云服务允许Docker Compose文件设置应用程序栈,所以它不是来自于生态型的其它部分的一个大的导流。

    “容器的自动化管理是Docker的重要组成,但知道最近一直由第三方来提供。”



    CLICK TO TWEET



    例如:
    crate1:
    image: crate
    ports:
    - "4200:4200"
    - "4300:4300"
    command: crate -Des.network.publish_host=_ethwe:ipv4_
    crate2:
    image: crate
    command: crate -Des.network.publish_host=_ethwe:ipv4_
    crate3:
    image: crate
    command: crate -Des.network.publish_host=_ethwe:ipv4_

    这样就创建了同一个镜像的三个实例,其中一个手动设置主机与Docker之间的端口分配,其他的端口分配是自动的。我将很快重新访问command。

    如果你想在超过一个节点(节点能够运行它可以管理的足够多的容器和一个私有仓库上扩展应用程序,Docker Cloud是有偿服务。这对于实验目的来说足够了。记住,Docker Cloud默认管理托管在第三方托管服务器上的容器,所以你也需要支付费用。使得Docker Cloud代理运行在任何你管理的Linux主机上是可能的,你可以在这里找到操作指南
    6.png

    上面的截图显示了三个使用预先设定的规则运行在跨越两个数字海洋的实例上的Docker容器,这个预先设定的规则是根据你设置的参数来将容器分配给主机。它会自动确保你指定数量的容器始终在运行。

    在之前的Docker Compose例子中,你可能已经注意到_ethwe:ipv4_。这是Docker Cloud的另外一个重要特征。许多分布式应用和服务依赖“服务发现”来找到同一服务的其他实例并进行通信。当在数据中心和物理机器上传播服务时,这往往需要实例的手动说明或者需要另一种方式来找到彼此。

    Docker Cloud包括支持Weave在你的实际网络中创建一个“软”网络;所有的容器和应用都可以发现彼此,无论它们被托管在哪里。在上面的例子中,我们重写了向容器发出的默认命令,以确保它接收它需要使用此功能的信息。
    #Data Center
    到目前为止,本文涉及的大部分工具都是你安装,主机,和支持的工具。对企业用户来说,他们寻找安全性、性能和支持较高的保证,Docker提供了数据中心

    它使用了覆盖这里的许多相同的工具包,但是增加了一个放置你的镜像的私有仓库,一个私有云,高级支持,和供应商可能吸引企业用户的第三方集成。这些包括LDAP and Active Directory用户管理,容器检测,和日志记录。
    #总结
    正如你从我的截图和你的实验中看到的这些工具,它们仍然感觉像是一套有关系但却松散耦合的产品,而不是一个紧密结合的“套件”。Orca项目似乎试图把重点放在建立所有这些项目之间的一致性上,使每一个项目都成为下一个项目的逻辑铺垫,而且所有这些项目都来自于同一个GUI或者CLI。其目的不仅仅是回答“为什么我应该使用Docker?”,而是回答“为什么我不使用Docker呢?”

    “Docker的这些工具仍然感觉像是一组松散耦合的产品,而不是一个紧密结合的套件。”



    CLICK TO TWEET



    原文链接:Understanding the Docker Ecosystem(翻译:徐婷)

    Docker Datacenter(DDC)介绍

    ozbillwang 发表了文章 • 0 个评论 • 3763 次浏览 • 2016-02-28 15:07 • 来自相关话题

    Docker 公司最近推出针对公司内部部署Docker容器的管理平台 Docker Datacenter (DDC)。 我上传几个关键的图表,可以方便的理解这个新产品。 图表一 ...查看全部
    Docker 公司最近推出针对公司内部部署Docker容器的管理平台 Docker Datacenter (DDC)。

    我上传几个关键的图表,可以方便的理解这个新产品。

    图表一
    Screen_Shot_2016-02-27_at_3.14_.26_PM_.png

    DDC 是由DTR(Docker trusted registry)和 UCP(Docker universal Control Plane)这两个产品组成。对应 docker cloud 的产品就是 docker Hub(hub.docker.com)和Tutum by Docker 。 也就是说DDC针对的是企业用户在内部部署,Tutum 针对的是网络用户,在线部署。 市场定位完全不同。

    图表二
    Screen_Shot_2016-02-27_at_11.40_.31_AM_.png

    这个图表说明DDC是如何工作的。 DTR (docker trusted registry)替代了我们常用的镜像注册服务。 增加了安全性。其后的UCP 基本上和tutum类似的功能。主要是针对私有容器的管理。当然安全性也提高很多。

    图表三
    Screen_Shot_2016-02-27_at_4.40_.49_PM_.png

    这个是Docker hub 和 DTR 之间的对比。DTR 增加了ldap 和 active directory 的集成,使得用户管理变得方便。可以添加组织,赋予各组织不同的成员,和权限。 增加了对镜像的安全管理,有个签名的功能。 支持多方的存储方式。 还增加了日志输出功能,软删除镜像以及GC的收集。

    图表四
    Screen_Shot_2016-02-27_at_4.47_.33_PM_.png

    这个是 UCP 和 Tutum 的对比。UCP主要是增加了TLS 和HA (高可用性)的支持,需要Swarm 的支持,可以管理网络和目录卷,也继承了ldap/AD。
    图表五
    Screen_Shot_2016-02-27_at_4.30_.48_PM_.png

    最后这个图表有些牵强。Docker试图通过它告诉大家,他们家是最正统的,支持是最正宗的。但是,大家要记住的是Docker是一家带 .com的公司,也就是说,他不是非盈利组织,所以Docker Hub、Tutum、DTR、UCP 都不开源。DTR 和 UCP 都是需要购买 服务的。 否则只能试用一个月。但是就算购买了他们家的 “business day“ 支持,也只是美国工作时间支持,对中国或者亚洲用户没用。一定要买最高级别的 "business critical “才会有 7 X 24 服务。

    我能介绍的就这些了。 DDC使用下来和Tutum 的感觉稍有不同。DDC 里的 证书,权限的管理也不简单,或者说具有挑战。需要对Docker Compose、Docker Machine、Docker Swarm 全面的理解才能用好这个产品。

    备注:

    Docker UCP 需要 最新的 Docker engine v1.10 版本支持。

    推荐链接:

    UCP产品介绍
    https://www.docker.com/products/docker-universal-control-plane
    https://blog.docker.com/2016/02/docker-datacenter-caas/

    价格
    https://www.docker.com/pricing

    Q:请问DDC需要使用Docker的数据中心,还是可以和企业自己的数据中心整合,做混合云,或私有云?

    A:  DDC里没谈到混合云。Node 管理部分非常的简单,可能以后会增加混合云的支持吧。

    Docker Hub彻底放弃Registry V1,灵雀云镜像市场国内率先支持V2

    灵雀云 发表了文章 • 2 个评论 • 3850 次浏览 • 2015-10-26 16:07 • 来自相关话题

    10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端: 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 i ...查看全部
    10月17日,在给用户的Newsletter中,Docker 正式发表声明表示 Docker Hub 将不再支持版本1.5和更早版本的客户端

    • 截至2015年11月19日,版本 1.5 和更早版本的 Docker 客户端将无法将 image push 到 Docker Hub,仍然能够 pull image;
    • 截至2015年12月7日,版本 1.5 和更早版本的客户端 pull image 也将被禁用,只支持 1.6 或更高版本。


    registry_alauda.jpg


    在这之前,随着 Docker 官方宣布 v1 的 registry 不再进行开发,灵雀云的小伙伴们就积极的投入了 v2 版 registry 工作的对接中,经过几个月的相关开发调试以及小规模的内测后,灵雀云的镜像市场服务已经正式敞开怀抱拥抱 v2 版本的 registry, 来为大家提供更加优质的服务。

    下面我们就来看下,新版本的 registry 会带来哪些体验提升:

    安全

    v1 版的 registry 一直存在着安全漏洞,存在着镜像造假的隐患,由于 v1 无法对镜像的内容和正确性进行校验,从 v1 pull 镜像会有着 pull 到伪造镜像的风险,可以类比一下之前下载到带木马的 Xcode 的事件。v2 版提供了服务器短内容校验的功能,可以杜绝这种客户端伪造镜像的欺骗方法,并且 1.6 之后版本的 docker 也可以利用这种方式在本地进行校验,保证了上传和下载到镜像的一致。这也是 docker 官方主推高版本 docker 以及 v2 registry 的原因。我们也建议大家升级到高版本的 docker 来使用更安全的 v2 服务,不过目前我们可能是国内第一个全面支持 v2 的公有镜像市场 :)
    性能

    新版本的 registry 在性能方面有了大幅提升,并且支持并行 pull,以后再 pull 镜像就是这个样子了,可以感受一下 pull 镜像飞起是一种怎样的体验了。

    1.pic_.jpg


    灵雀云的 CaaS 平台也已经全面对接了 v2 registry,相应服务的性能也会得到提升,可以进一步加速用户持续化集成和部署的速度,我们之后也会持续优化这部分的性能。

    兼容性

    Docker Hub 已经宣布即将停止对 v1 的支持,很快就无法通过 1.6 之前的版本从 Docker Hub 上传下载任何镜像。灵雀云没有那么任性,还会对各个版本的 docker 提供服务支持,并对不同的客户端做了透明的兼容。由于 docker 客户端的限制,只有 1.6 之后的版本可以使用 v2 registry,不过 1.6 版本之前的小伙伴也无需担心,我们在后端服务做了大量的工作,使得同一个 registry 地址兼容两套 registry,并会做两者之间的镜像实时同步,不管你使用哪个版本的 docker 或者升级或者降级版本都可以无感知的使用到对应版本registry,并找到自己对应的镜像。

    相关的技术文章可以点击这里查看。当然我们还是推荐大家升级到更高版本的 docker,这样即能够获得更好的镜像市场使用体验,也可以享用到 docker 新版本的其他特性,何乐而不为呢?

    简讯 | Docker Hub将不再支持1.5和更早版本的客户端

    田浩浩 发表了文章 • 1 个评论 • 3109 次浏览 • 2015-10-19 10:35 • 来自相关话题

    【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。 亲爱的Docke Hub用户: 去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Reg ...查看全部
    【编者的话】Docker Team邮件简讯:Docker Hub将不再支持客户端为`1.5`和更早的版本。

    亲爱的Docke Hub用户:

    去年春天Docker发布了版本 `1.6`的引擎和版本`2`的Registry。引入了具有更快镜像传输的推送/拉取协议、简化了镜像定义并且提高了安全性。Docker社区一直在积极采纳他们,结果显示超过99%Docker Hub的使用是基于这些较新版本的。这样一来,我们准备在Docker Hub上不再支持版本`1.5`和更早版本的客户端。

    * 截止到2015年11月19号,版本`1.5`和更早版本的Docker客户端将无法将镜像推送到Docker Hub。他们仍然能够拉取镜像。当然较新版本的Docker客户端可以完全访问Docker Hub的仓库。
    * 截止到2015年12月7日,版本`1.5`和更早版本的客户端拉取镜像也将被禁用。只支持`1.6`或更高版本。

    处理这种迁移非常简单。您所需要做的是升级你的Docker客户端到`1.6`或更高版本。请务必要升级从你的Docker Hub仓库推送或者拉取镜像的客户端,他们包括那些在开发机器、线上的服务器或者是CI和CD工作流程中的部分的客户端。

    如果您有任何问题,请及时与我们联系。

    诚挚的问候,

    Docker Hub团队

    原文链接:Docker Hub deprecation for clients 1.5 and earlier (翻译:田浩浩

    一周 Docker 镜像精选(第三期)

    tenxcloud 发表了文章 • 0 个评论 • 4369 次浏览 • 2015-10-06 22:38 • 来自相关话题

    本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。 《一周 Docke ...查看全部
    本期精选了GitLab 代码管理系统,KODExplorer 资源管理器,Gitblog Markdown博客系统,ThinkSAAS,NodeBB,HBase,Spark,JIRA 项目与事务跟踪工具等十个镜像。

    《一周 Docker 镜像精选》 是一份专为 Docker 爱好者打造的容器技术周刊。我们会为您精选一周的优秀 Docker 镜像,每周一期,完全免费。也欢迎极客们向我们投稿:service@tenxcloud.com
    # 1.GitLab 代码管理系统

    GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。

    wangh/gitlab
    3期镜像11.png

    # 2.KODExplorer 芒果云 资源管理器

    KodExplorer是一款开源的基于Web的在线文件管理、代码编辑器。它提供了类windows经典用户界面,一整套在线文件管理、文件预览、编辑、上传下载、在线解压缩、音乐播放功能。让你直接在浏览器端实现web开发、源码文件预览、网站部署。同时拥有与本地操作一样方便、快捷、安全的体验。

    chenlilian/kode
    3期镜像2.png

    # 3.Hadoop Database,高可靠、高性能、面向列、可伸缩的分布式存储系统

    HBase – Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

    sdvdxl/hadoop
    3期镜像3.png

    # 4.Web-terminal 基于网页的命令行终端

    Docker Web Terminal 一个基于网页的命令行终端。运行容器 docker run -d -p 5000:5000 name/web-terminal:latest 在浏览器中访问 open http://`boot2docker ip`:5000。

    wangh/web-terminal
    3期镜像4.png

    # 5.用于编排 Spark 集群的简单 Docker 容器

    一个用于编排Spark集群的简单Docker容器 Apache Spark 是一种与 Hadoop 相似的开源集群计算环境,但是两者之间还存在一些不同之处,这些有用的不同之处使 Spark 在某些工作负载方面表现得更加优越,换句话说,Spark 启用了内存分布数据集,除了能够提供交互式查询外,它还可以优化迭代工作负载。

    sczyh30/docker_spark
    3期镜像5.png

    # 6.Gitblog 一个简单,易用,高效的Markdown博客系统

    GitBlog是一个简单易用的Markdown博客系统,它不需要数据库,没有管理后台功能,更新博客只需要添加你写好的Markdown文件即可。它摆脱了在线编辑器排版困难,无法实时预览的缺点,一切都交给Markdown来完成,一篇博客就是一个Markdown文件。同时也支持评论,代码高亮,数学公式,页面PV统计等常用功能。GitBlog提供了不同的主题样式,你可以根据自己的喜好配置,如果你想自己制作博客主题,也是非常容易的。GitBlog还支持整站静态导出,你完全可以导出整站静态网页部署到Github Pages。

    dockerxman/docker-gitblog
    3期镜像6.png

    #7.NodeBB 基于nodejs的响应式论坛

    NodeBB是Design Create Play开发的一款使用Node.js构建的论坛系统,使用redis或mongoDB数据库,采用web socket技术实现。支持响应式布局,兼容IE8,将论坛的体验带向一个新的高度。nodeBB的优点:基于socket.io,界面高度简约,丰富插件和主题提供,提供实时聊天功能,新消息消息声音提醒,可以恢复上次浏览页面的具体位置,丰富的管理模式,中文支持,高度开放控件和页面编辑。

    csuhp007/nodebb
    3期镜像7.png

    # 8.轻量级的开源社区系统 ThinkSAAS

    ThinkSAAS是一个轻量级的开源社区系统,是一个可以用来搭建讨论组,bbs和圈子的社区系统。ThinkSAAS是将sns社会化网络元素,人和圈子(讨论组)结合在一起的新型的社交系统。系统特点:开发简单,php新手也可以开发强大功能;单一入口;扩展强大,支持应用扩展和wordpress式插件扩展 APP可单独配置独立数据库;WEB端和server端API接口统一;多端自适应,集成bootstrap;底层加载速度快,抗压和并发能力强;集成ueditor,内容编辑异常强大;适合个人和团队协作开发;集群、分布式部署、各种缓存、数据库读写分离等各种针对大数据和高并发的策略都在实践中

    jechiy/thinkssas
    3期镜像8.png

    # 9.Discuz! 论坛(BBS)系统 - Docker版

    Discuz! 论坛(BBS),是一个采用 PHP 和 MySQL 等其他多种数据库构建的性能优异、功能全面、安全稳定的社区论坛平台,是全球市场占有率第一的社区论坛(BBS)软件。

    tenxcloud/discuz
    3期镜像9.png

    # 10.JIRA 项目与事务跟踪工具

    JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富,其超过150项特性得到了全球115个国家超过19,000家客户的认可。JIRA推出云服务和下载版,均提供30天的免费试用期。云服务无需安装可直接试用,下载版采用一键式评估安装,在用户自己的服务器上运行。

    wenzizone/jira
    3期镜像10.png

    有人说Docker Hub上三成的镜像包含漏洞?扯吗不是?

    kurtzhong 发表了文章 • 0 个评论 • 5795 次浏览 • 2015-06-04 12:00 • 来自相关话题

    【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用We ...查看全部
    【编者的话】到底Docker Hub上是否三成的镜像存在漏洞?通过漏洞计算发现确实有高比例漏洞,对于管方镜像遵循Docker的安全指南,如若是自创建镜像,可找源仓库或自行处理。但我们发现,这些漏洞中大部分是老镜像。面对漏洞镜像,我们可以采取本地措施,还可用Web安全审查进行检查,如果想让Docker更加安全,建议用dockerbench来评估。文中额外阐述了容器究竟有什么用。

    这个数字太神奇了!并不是因为这个比例过高或者过低,而是因为居然存在这个比例。既然存在(相对容易地)计算出这个比例的可能性,也就意味着存在(相对容易地)改善这个比例的可能性。

    声明:我是Docker官方人员,然而我写这篇文章并未受到公司批准,所以最好带着批判的思维来读本文。

    这个数字来源于BanyanOps的博客

    漏洞的计算
    -----------

    首先,来看看怎么才能计算出原文中的数据。这过程比较简单:

    • 获取Docker注册表的一个列表
    • 下载列表中的镜像
    • 检查镜像中的漏洞
    这步骤看起来似乎太简单,我们稍微深入下细节。# 列举镜像列举官方的镜像是容易的。这些镜像是基于一个叫bashbrew的自动化系统构建而来的,使用的都是公布于众的方法。顺便一提,这意味着如果你想重建官方的镜像,做起来也会很容易。(记住那些方法中涉及一些blobs或者tar包,是在启动的时候用到的;因而有时你要多费一点力,重建这些blobs或者tarbal)。构建官方镜像的方法在Github上的docker-library仓库可以找到。要列出其他的镜像(即属非官方的用户和机构所有的镜像)要困难点。Docker Hub目前没有提供什么方法来列举他们,所以一个暂时可行的方法是搜索一个十分宽泛的关键字,然后对其结果进行提取。当然,这需要一些抓取的工作;抓取到的结果可能会漏掉一些用户的数据,但是你拿到的结果已经会十分接近了。(虽然这么做肯定可行, 我也听说新的注册表接口有一些十分好的特性,可以让这一步完成起来容易点)。# 下载镜像下载镜像是一个繁琐的任务。如果你想安安静静的做这件事情,运行一个docker的守护者进程,然后执行`docker pull username/imagename:tag`即可。如果你想拿到容器的文件系统的一个tar包,也很容易:只需要运行`docker export username/imagename:tag`就行。(记得把标准输出重定向到其他地方,否则你的终端会抓狂的)如果你不十分相信Docker的守护者进程,你可以检查registry的接口(v1v2)并且通过接口来下载层,然后把层文件重组成镜像文件。一些细节我想留给你自己去做,但是层文件只是普通的tar包,你只需要在彼此之上解包(需要保持正确的顺序)就可以重组成镜像文件。没有什么特别难的步骤;唯一需要留心的地方就是“留白”(whiteout)。“留白”是特殊的标记文件,用来表明“此处曾经有文件存在于此,但目前没有了”。换句话说,如果一个层包含文件`/etc/foo.conf`,但是之上的层把其删除了,上一层就会包含一个`/etc/.wh.foo.conf`文件,并且`foo.conf`不会出现在容器里面。这个文件相当于被留白文件加上了蒙板。我后来发现,了不起的Tianon已经为此写好了一个脚本,如果感兴趣你可以去看看。# 检查镜像在这个阶段你有几件事情需要做。细节繁琐,本文无法全部叙述;但是在一个全面的安全检查中,下面这些步骤你可能需要做:
    • 运行`yum-security`或者类似的命令,保证在此刻没有安全更新;
    • 或者更好的做法是:列举出所有安装的包及其版本,然后检查软件包在该版本是否包含漏洞;
    • 计算系统中的每一个文件的hash值,然后去跟已知的有漏洞的文件的hash集合去做比较;
    • 执行自动化工具(如`chkrootkit`)寻找可疑的文件;
    • 运行一定数量的专门为某些漏洞而打造的漏洞测试。这些测试的目标是尝试利用某些漏洞,然后告诉你,“你的系统有漏洞,因为我已经设法利用了这个漏洞”或者“我无法利用这个漏洞,所以你的系统很可能没有此漏洞”。
    事情到了容器的环境中变得很有趣,因为用Docker来自动化这些步骤容易且便捷。例如,你可以将你的漏洞分析工具包放在`/tmp/toolkit`中,然后对于每一个镜像`$I`,执行`docker run -v /tmp/toolkit:/toolkit $I /toolkit/runall.sh`。(注意:这里假设你的工具包是静态链接并且/或者是自包含的,如不依赖你容器镜像中的任何地方,因为这又可能让你的工具包收到蒙骗。我这里主要想说的是,如果你想用一系列的测试来检查你的容器镜像,你可以用容器让这个步骤变得很简单,并且整个过程会更加的快速,因为对于每一个测试你不需要单独做一个检查的机器的拷贝)提升指标----------那么在我们运行完这些测试,然后发现出奇高比例的镜像包含有漏洞的包。我们怎么来改善这个指标呢?对于官方的镜像,最容易的方法是遵循Docker的安全指南。以后随着官方镜像数的增长,Docker也会改善这个机制,达到自动提示官方镜像的上游安全列表的效果。对于非官方的镜像,你可以检查镜像中的`Author`字段:
    $ docker inspect --format '{{.Author}}' bin/ngrepJerome Petazzoni 
    如果该镜像是自动构建出来的,你可以找到其来源的仓库,并且直接联系他们。如果你直接受到了漏洞的影响,想事情进展的更加快速,你可以自己重建镜像,并且/或者研究怎么才能修复这个漏洞,然后提交一个包含相应修复的PR。这里的意图不是把安全的责任推卸到镜像的使用者身上,而是让有意愿和有能力修复这些漏洞的人能对Docker镜像的安全做贡献。在将来,这些步骤会完善,并且流式化。会有自动化的过程构建出来减少需要联系相关机构的烦琐,然后尽量降低发布包含漏洞补丁版本的时间。# 但是30%还是太高了,对不对?30%的“有漏洞的镜像”可能听起来非常多。我第一次听到也是这么想。但是如果你细看,你会发现其中一大部分的镜像是老的镜像,它们是__故意不被更新__的。什么?__故意不被更新__?是的,并且对此有一些好的解释。第一个是(其中的一部分)照顾其他的媒介。有的发行版想`XYZ`想在CD/DVD,网络安装,VM镜像,和容器都保持一致。第二个原因是(这也解释了第一个原因)可重复的构建。设想你有一个服务器跑着12.04,但是你用一个新的Ubuntu 12.04的版本(更别提14.04)却重现不出来。在更加深入的研究后发现,这个问题只存在于那些在某特定时间安装的机器,其版本是12.04.02。如果一个容器镜像有12.04.02的版本,你可以重现出这个bug;否则,你得从其他地方得到这个特定版本。这就是为什么Docker Hub有很多老的镜像,它们保持着发行时的状态 - 同时包含当时发行时的安全问题。尽管这么说,我们已经放置了安全警示说“历史的镜像 - 保持远离”,所以我们比较希望这些镜像在计算出这些安全的指标的时候不应该被包含进去。让我们希望下次有人在计算安全指标的时候他们能意识到这一点。在本地采取措施 ---------------我们可能跑着有漏洞的镜像!求救!怎么办,怎么办?事情没有其看起来那么糟。当你(或者其他人)做完对于这些镜像(官方的,公开的,私有的)的审查,结果是一个镜像的列表(以一个唯一的hash串),并且包含“PASS”或者“FAIL”的状态。(对于“FAIL”的镜像,你可能想知道一些其为何不通过的细节,如:“好像有ShellShock/CVE-2014-7187和其他漏洞”或者“包含软件包OpenSSL 1.0.1c / CVE-2014-0160”。)# Web规模的安全审查你可以拿着这个列表,然后与你本地的镜像做比较。这里就是事情变得有趣的地方。根据本地镜像和这个列表做一个简单而廉价的匹配结果,你就马上能知道你是否运行着有漏洞的镜像。这可以很容易的扩展到成千上百万的主机。这也意味着事情可以很好的解耦:你的安全审查员不需要访问你的生产环境(甚至不需要访问你的开发环境中的系统)。他们甚至不需要要知道你运行着什么镜像:他们只需大面积的对镜像做分析,然后得出结果给你。你甚至可以从几个安全公司那里拿到结果然后比较他们的结果。# 我的镜像在创建后修改过怎么办?对于新手,你不应该这么做。如果你像更新容器中的某些东西,你应该创建一个新的镜像然后运行该新的镜像。好吧,但是我已经这么做了该怎么办?那真是什么都说不准,但是至少我们能知道你这么做了。安全审查的一部分,你可以在运行的容器上运行docker diff来知道是否他们被修改了。(通常docker diff是没有结果的。注意你已经用shell启动了一个容器,或者在容器内执行过docker exec,你可能会看到少许的更改。但是生产环境的容器不应该出现任何的更改结果。)专业的Tip:你甚至可以防止更改,通过在容器中使用`--read-only`的标记来达到这一点。这会让容器的文件系统只读,保证`docker diff`的结果为空。如果你想用一条命令来检查所有的容器,可以执行:
    docker ps -q | xargs -I {} dockr diff {}
    (感谢@diogomonica提供命令!)# 我已经构建了自定义的容器怎么办如果你构建了自己的容器,我建议你把他们上传到一个仓库里面。如果这是一个公共的,我们就会到最初讨论的情形。如果这是一个私有的,让我们看下一个部分!私有的镜像和注册表该怎么办?----------------------如果你上传的是私有的镜像怎么办?如果你上传的地方是一个本地的注册表,或者Docker Hub的企业版怎么办?事情显然变得更加复杂了。你可能会看见有人告诉你“设想ABC有CVE-XYZ的漏洞”如果他们从来没有看到过镜像ABC。这里是一些可能会发生的事情:
    • 安全提供商可以提供镜像的扫描器,你可以用在自己的镜像上;
    • 安全提供商可以更进一步,将其集成到Docker的注册表中。这可以通过分配读权限(访问Docker Hub上的私有镜像)或者部署前置(on-prem)的安全扫描器(对于Docker Hub企业版的情形)来实现。在两个情形中,都能达到一旦镜像上传就会被自动扫描的效果,并且立即报告任何可能包含的漏洞。
    结论---有两点我想强调,因为我相信这能在安全领域产生好的结果。[list=1]
  • 得出数字是好的。一旦我们得到了量化的数据,我们可以提升他们。Docker对于安全问题十分延严肃,你可以很肯定我们会和社区及镜像的维护者一期来改善这些量化数据。
  • [list=1]
  • 有类似这样的围绕着Docker和Docker Hub的生态环境和社区,让他们成为一个树立标准的地方。正如Soloman在一些keynote里面指出的,Docker里面最重要的一点不是技术,而是让人在某事上达成一致。
  • 后一点意味着Docker现在有足够的批评群体来校正横向的工具(包括安全审查)来让这个生态环境受益。其结果会是更加完善的安全机制,让每一个人受益。# Docker注重安全如果有Docker公司不在乎安全的印象,那真相离你就太远了。正如上面指出的,我们有一个负责的披露安全的政策,并且我们总是很快的解决我们意识到的问题。没有哪个软件是没有bug的。Docker也是由人类编写出来的,即时他们有些人十分的了优秀,但是还是会犯错。重要的是我们对待安全报告的严肃态度如何,我们解决这些问题的速度如何;我想我们在这些方面都一直做的很好。如果你想让你的Docker的环境更加安全,我推荐你看下dockerbench。我参与了其编写,该软件包含了一个自动化的评估工具可以用来评估Docker的主机,使用的是CIS Docker 1.6 Benchmark。它会检查很多事情(如是否SELinux和AppArmor是启用了的)然后生成一个报告。这是Docker会推出或者参与的一大批软件的第一批,目的是让你可以在没有Docker容器安全方面的Ph.d的证书的情形下,或者在没有聘请一个Taylor Swift的情形下,安全地运行Docker。并且,我们鼓励公开的讨论,安全的担忧也不例外。Docker Library的仓库里面有一个十分有趣的有关于这个话题的讨论# 额外的提示有人问我阐释下容器究竟为什么有用,如果我们不反复的检查我们运行的所有的东西的来源。这里是一些例子:
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如著名的`curl ... | sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(比如一个商用软件的`install.sh`),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个npm,pip,gem等等的包,但是我们不清楚其来源),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个deb,rpm或者其他的发行版的包),并且可以查看到底能产生结果,这得益与`docker diff`。
    • 容器让我们可以在沙箱环境下测试一些危险的操作(如安装一个危险的squid包),并且可以查看到底能产生结果,这得益与`docker diff`。

    我猜想你能看出这个模式。仅仅因为事情以一种熟悉的形式呈现给你并不代表它们是安全的。但是我们可以使用Docker来提升安全性。


    原文链接:Someone said that 30% of the images on the Docker Registry contain vulnerabilities(翻译:钟最龙)

    Docker Hub中超过30%的官方镜像包含高危漏洞

    kurtzhong 发表了文章 • 1 个评论 • 7380 次浏览 • 2015-05-28 15:40 • 来自相关话题

    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。 Dock ...查看全部
    【编者的话】Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险。

    Docker Hub是一个供Docker开发者用来上传/下载容器镜像的地方。为了认识其应对安全风险的能力如何,我们对其中的镜像进行了一次细致的研究。结果我们惊奇的发现,超过三成的官方仓库包含的镜像疑有高安全风险(如:Shellshock、Heartbleed、Poodle等)。对于普通的镜像,即那些被Docker用户上传的,没有经过任何权威机构验证过的镜像,这个比例高达40%(样本的错误大约在3%)。
    1.jpg

    [图:多姿多彩的容器,图片来源自VSMagazine]

    为了开展这次研究,我们下载了Docker Hub中的的镜像,然后分析其中的软件包和版本。然后我们使用来自Mitre、NVD(美国国家漏洞数据库)和Linux发行版自己的数据库来分析哪些镜像易于受到攻击。我们开发一个开源的工具 Banyan Collector,并且使用一个叫做Banyan Insights的服务来生成这个研究中的数据。

    尽管我们的分析是基于公共的Docker Hub进行的,我们预估这结果与那些使用私有容器注册中心的企业会类似。企业通常会不断基于那些口碑较好镜像来部署容器,依赖这些镜像的周期更新来获取最新的软件包。尽管有这些措施,企业仍然有漏洞的威胁;更加严格的运维管理加上实时的监控对于保证安全必不可少。

    在本文的剩余部分,我们简单的从高层次介绍下安全漏洞是如何分类,描述基于分析Docker Hub上官方和普通镜像中漏洞得到的结果,然后讨论下这份研究对于运维管理的意义。


    安全漏洞的指定和分类
    -----------------------

    Mitre作为一个不以盈利为目的机构,指定并维护一份CVE(常见安全漏洞和威胁)的列表,每一个CVE描述了在广泛发布的软件中的漏洞。由美国政府维护的NVD数据库列出了每一个CVE的影响,包含其波及的软件和相应的修复措施(或者尚未采取修复措施的)。每一个Linux发行版也都维护了一个发行版特定的影响和提供修复该漏洞的软件包版本。

    每一个漏洞都会被NVD和Linux的发行版指定一个分值。分值的范围从0到10,7.0到10.0属于高危漏洞,4.0-6.9之间的属于中危漏洞,0-3.9的属于低危漏洞。这个分类考虑了一系列因素,包括利用该漏洞攻破系统所需要的复杂度(复杂度越低,分数越高)和该漏洞可能会造成的影响(影响越大,分值越高)。下面是一些例子:

    1. 高危漏洞:如:ShellShock(bash)、Heartbleed(OpenSSL)
    2. 中危漏洞:如:Poodle(OpenSSL)
    3. 低危漏洞:如内存中数组的内存的分配可能会导致整形溢出

    把漏洞划分为高中低漏洞的做法带有主观性,一些公司也可能会根据自己的情况来重新分类。而且,NVD指定的分值可能跟Linux发行版中的分值不一致,并且可能会随着时间推移而更改。我们的研究中使用的漏洞的分值来源于Ubuntu和CentOS发行版指定的分值,对于Debian我们直接使用了NVD数据库中分值,因为我们找不到任何关于Debian发行版对漏洞分类比较好的数据源。我们对Docker Hub在2015的5月20日的镜像做了一个快照,然后进行分析。我们也试了一下其他日期,得出的结论十分相近。

    对于Docker Hub中官方仓库的评估
    ------------------------------------

    Docker维护着一个官方的仓库的列表,为软件厂商和机构(如Canonical、Debian、Redhat等)提供了一个即时更新它们最新容器镜像的渠道。官方仓库可以从他们的路径体现出来,他们的路径在`library`的命名空间下。举几个例子:`library/ubuntu`,`library/redis`等。Docker Hub包含大约75个官方的仓库(在我们写这篇文章的时候),大概包含约1600的不同的标签,指向约960个不同的镜像。
    2.png

    [图一:官方有漏洞的镜像]

    图一展示了根据分析Docker Hub上所有官方的镜像的得出的主要结果。超过1/3的镜像有高危漏洞,接近2/3的有高或中级危漏洞。这些统计数据让人无法平静,因为这些镜像中一些也是下载量最多的镜像(一些有几十万的下载量)。

    如果我们只看今年创建的镜像,有高危漏洞的镜像的比例仍然超过1/3,但是含有高和中级危漏洞的镜像接近了75%。换句话说,今年创建的镜像,每四个中就有三个存在较容易被利用的漏洞,并且潜在影响非常大。

    如果我们将范围缩小到哪些标注了`lastest`(最新)的镜像,这比例分别下降到了23%和47%,这比例显然还是很高。这更小的数据说明,Docker的用户和维护者们,倾向于将镜像保持到最新,但是老一些的镜像却被忽略;创建容器数量之大和速度之快,让老的镜像在更新的时候被忽略。

    为了理解这些漏洞,特别是排名靠前的,我们做了一个详细的影响Docker Hub的镜像漏洞的分析:
    3.png

    [图二: Docker Hub官方镜像中有高危漏洞的镜像]

    图二展示了该分析的主要结果,并且表一列举了跟这些软件包相关的主要的CVE。最近发布的存在于mercuarial的漏洞在很多镜像中都有(大约20%)。著名的OpenSSL漏洞如Heartbleed和Poodle,在近10%的官方镜像中存在。一些镜像还包含bash的ShellShock(如Centos5.11镜像中)漏洞,这个漏洞在7个月前就被发布了。即便一些机构不使用这些包,但是如果不手动将这些包从容器中移除掉也会成为恶意攻击的羔羊。
    4.png

    对于Docker Hub中普通仓库的评估
    --------------------------

    除了一些官方的仓库,Docker Hub包含了一大部普通仓库(在写本文的时候大约有95000个),并且有数十万不一样的镜像。我们实验中随机选择了1700个镜像,然后对他们的内容的内容进行分析(误差约百分之三)。
    5.png

    [图三:有漏洞的普通镜像]

    图三显示了在分析了普通镜像后得到的主要结果。大体上,漏洞的出现概率比官方镜像的相比大很多。这个结果合乎预期,因为目前尚没有措施可以在将镜像上传到Docker Hub前可以过滤并检查这些普通的镜像。

    大约40%的普通镜像有高危的漏洞。即便我们只是看今年创建的镜像,并且只看那些有`latest`标签的,包含漏洞威胁的镜像的比例仍然在30-40%之前徘徊。如果我们包含那些含有中危漏洞的镜像,比例会迅速升到70%以上,不管哪个时间段都是如此。尽管你可能会说,这些镜像比起官方镜像下载次数太少了,但是考虑到它们庞大的数量(几十万的规模)可以预想它们跟官方镜像一样使用甚广。

    我们又分析了影响普通镜像中的高危漏洞,图4展示了主要的结果:
    6.png

    [图四:普通镜像中含有高危漏洞的软件包]


    有趣的是,不同于官方镜像中首要祸源在于mercurial,在这些普通的镜像中,openSSL、bash、和apt成了祸源的榜首。我们怀疑官方的和普通这种数字上的差异来源于发行版的差异,他们占据了这些镜像的大部分。官方镜像通常基于Debian,并且其中一一大部分包含mercurial包。而普通的镜像,却通常基于Ubuntu因而有bash、apt和/或openssl相关的漏洞。


    延伸
    ---

    容器技术带来软件开发中的变革,它提供了一个十分高效的方法,可以将开发者开发的软件在数分钟或者几小时内搬上生产环境运行,而传统的方式可能需要几天甚至数月。但是我们的数据显示这种优势有其弊端,没有谨慎的运维和安全管理的措施,我们冒着让我们的软件生态环境更容易被攻击的危险。

    容器为运行于不同容器之间的运行程序提供了一层安全隔离,因而提高了安全性。然而容器还是需要和其他的容器和系统进行通讯,因此,由于镜像中存在的安全漏洞,它们还是很容易被远程攻击,包含那些我们没有分析到的漏洞。再者,在多种多样的环境中启动大量的容器的轻便与快捷,如在你的共有云上,私有云上,笔记本上,都让追踪和防护有安全漏洞的容器变得更加困难。部署容器的高效性,大大的加速了部署软件的多样性,结果让环境中的新的漏洞越来越多。

    使用容器的另外一个根本点在于,包管理已经被转移到了容器的内部,而传统的方式是仅仅是基于安装在虚拟或者实体机的操作系统层面上。这种改变主要根源于虚拟机和容器提供的抽象处于不同的层面。虚拟机提供的是以主机为中心的抽象,其特点是长期不停机一直运行,包含的软件包供不同应用所需。与之相对的,容器提供的是一个更加以进程为主的抽象,其特点是短暂性,可以到处运行,构建后不会改变,仅仅包含运行一个应用所必须的软件包。任何更新都需要重新构建容器,从而保持容器的不可修改性,这让任何的漏洞同时被复制。

    另外,向DevOps模式的转变,开发者开始为他们开发的应用的软件包负责,这意味着现在开发者开始负起了维护软件包的责任。除了操作系统的软件包,开发者在容器中可以包含应用层面中的模块,如pip(Python)、npm(Node.JS)和maven(Java)等,而这些都在我们的研究之外,然而它们也可能带来新的安全问题。因为开发者更加关注快速的开发出新的功,这让保持老的镜像更新变得更加困难,正如我们的研究呈现的一样(如官方的与201年4月发布的CentOS 5.11镜像仍然包含Shellshock漏洞,该漏洞是八个月前,2014年9月被爆出的)。

    一个很好的避免这些问题的方式是经常用最新的更新重新构建镜像。重新构建的过程必须使用发布商发布的最新的基础镜像,并且不能使用任何缓存的镜像层(如:使用在apt-get upgrade的时候加上`-no-cahce`)。但是在一旦发现漏洞从头重新构建,并且重新部署所有的容器的开销太大,十分不切实际了—— 漏洞出的频率太高,每天都会爆出好几次,并且很难评估每一个安全漏洞的的影响范围。加之,更新容器的软件包很可能给容器中的应用带来负面影响和不稳定性,而这即使用复杂的测试也未必能捕捉到,这让人更加不情愿经常更新。


    结论
    ---

    我们的研究结果鼓励使用严格的运维管理流程,实时的分析镜像中的内容,清楚其中的内容和包含的漏洞。镜像应该经过安全漏洞的扫描,并且根据漏洞的严重程度来标记是否需要更新。任何重大的漏洞都应该被及时的发现,并且应该可以触发对这些有隐患的镜像进行隔离机制。镜像不仅仅应只从操作系统层面进行扫描,也应从应用的层面的安全漏洞进行扫描。这些流程应该被集成到持续构建的框架中,这样在享受容器带来的全面福利的同时,仍然保持着好的安全实践。

    原文链接:Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities(翻译:钟最龙 审校:魏小红)

    Docker收购Kitematic:一个非常棒的GUI工具

    叶可强 发表了文章 • 3 个评论 • 36407 次浏览 • 2015-03-12 23:32 • 来自相关话题

    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持 ...查看全部
    【编者的话】Docker宣布收购Kitematic,Kitematic是一个 Docker GUI 工具,它可以在 Mac 上更快速、更简单的运行Docker。Docker官方表示,Kitematic是其生态系统中成长起来的一个非常棒的项目,接下来官方也将支持Windows。本文翻译自Docker官方博客。

    image2015-2-23-16-36-9-300x78.png

    我们非常高兴地宣布我们收购了Kitematic,它是Mac上最快、最易使用的Docker工具。Docker 是一款面向开发者的工具,我们也发现生态系统中的开发者为 Docker 构建了最酷的工具。Orchard 的 Fig(现在是 Compose)以及 SocketPlane 都是产生于生态圈中的最佳案例,它们提升了开发者体验并为分布式应用提供了灵活性操作。

    今天,Kitematic在简化开发者体验这一步上更上一层楼。它可以让Docker更易使用:Kitematic进一步增长和丰富了社区和生态系统。
    ## Kitematic 是什么?
    Screenshot-2015-02-23-16.27_.27-1024x752_.jpg

    Kitematic 完全自动化了 Docker 安装和设置过程,并提供了一个直观的图形用户接口(GUI)来在 Mac 上运行 Docker。Kitematic 集成了 Docker Machine 来在 Mac 上分发一个虚拟机并安装 Docker 引擎。

    一旦安装成功,Kitematic GUI 便会启动,紧接着你可以立刻运行控制台中的镜像。你仅仅只需要在 Kitematic 搜索框键入镜像名就可以搜索任何在 Docker Hub 上存在的镜像。通过 GUI 你可以非常容易的创建、运行和管理你的容器,不需要使用命令行或者是在 Docker CLI 和 GUI之间来回切换。
    image2015-2-23-18-43-5.jpg

    Kitematic 也让Docker的一些高级特性使用更加方便,比如管理端口和配置 volumes。你可以方便的修改环境变量、查看日志,单机终端就可以进入容器,这些特性GUI都支持。
    ## 未来将会怎样?
    自从测试版发布后,仅短短几个月,Kitematic 就拥有了成千上万的用户,都是积极的反馈并有上千的 GitHub stars。同时,我们相信,一个关于开发者如何与 Docker 交互并运行他们的容器的伟大旅程即将开始。

    你可以通过我们在 GitHub 上的路线图来获取更多信息 ,同时你也可以为你想看到的任何东西提交 pull request。我们会扩大团队处理路线图上的功能,接下来将包含一个新的 Windows 客户端以便更多的开发者能更快速、更容易的在他们的机器上运行 Docker。

    ## 免费尝试下 Kitematic,它是开源的

    当然,Kitematic 将继续保持开源和免费,所有人都可以通过 GitHub获取。团队希望得到你的反馈和支持,好啦,就从 kitematic.com 下载最新版的 Kitematic 开始吧?
    image2015-2-23-16-41-45.png


    ## 学习更多关于 Kitematic 的知识



    原文链接:KITEMATIC A DOCKER GUI JOINS THE DOCKER FAMILY(翻译:叶可强 校对:李颖杰)

    ===========================
    译者介绍
    叶可强,目前在唯品会上海分公司从事应用运维工作。业余时间专注Docker的学习与研究,希望通过DockerOne把最新最优秀的译文贡献给大家,一起促进国内 Docker 的发展。

    深入浅出Docker

    崔婧雯 发表了文章 • 3 个评论 • 19267 次浏览 • 2015-02-07 13:57 • 来自相关话题

    【编者的话】本文是一篇Docker入门文章,作者介绍了Docker相关的基础知识,包括Docker镜像、Dockerfile、Docker容器、Docker Hub。然后作者使用Docker搭建了一个WordPress应用,基础架构包含一个Nginx服务器来路 ...查看全部
    【编者的话】本文是一篇Docker入门文章,作者介绍了Docker相关的基础知识,包括Docker镜像、Dockerfile、Docker容器、Docker Hub。然后作者使用Docker搭建了一个WordPress应用,基础架构包含一个Nginx服务器来路由/代理请求、WordPress应用服务器来部署应用以及MySQL数据库来提供存储。初学Docker的同学可以看看。

    在持续集成这样新的开发方法论流行的今天,软件工程师只是将代码推送出去并且祈祷代码能在另外的环境里成功运行的日子已经一去不复返了。开发、测试和运维之间的传统高墙正在逐渐瓦解,并且这些职责会互相渗透,从而造就了新型工程师。DevOps在业界流行,项目开发团队越来越敏捷高效,并且能够迅速响应变化。这样的转变使得新工具和框架随之兴起,帮助我们自动化地部署、测试和标准化基础架构。

    转型浪潮的前端工具之一就是Docker,Docker是一个开放的平台,帮助开发人员和系统管理员构建、发布并运行分布式应用。在进一步深入探讨实际经验之前,推荐大家阅读这篇文章:《什么是Docker》

    在开始操作之前,你需要先安装Docker,我在Mac上用Boot2Docker来安装,更为详细的适合你的平台的安装指南请参考Docker安装介绍。另外,可以使用云服务商来运行Docker主机,Digital Ocean提供运行在云端,并且可以使用Docker的服务器,只需要花费每小时0.007美元,要是你受限于带宽或资源的话,这是个很好的解决方法。

    # 基础知识
    ##Docker镜像
    Docker镜像是一个只读容器,例如Ubuntu操作系统或者CentOS操作系统镜像。在Docker里运行的每个容器都需要基于某个Docker镜像。
    ##Dockerfile
    Dockerfile其实就是一些代码指令,它告诉Docker应该如何构建Docker镜像。Docker镜像是分层的,易于扩展,支持在已有的基础镜像上增加额外的功能。常用的基础镜像是ubuntu:latest,这是Ubuntu版本的基础镜像。
    ##Docker容器
    Docker容器可以看成是运行着Linux系统(通常精简过的Linux系统)的虚拟机的轻量级自包含实例,可以迅速启动和停止。Docker容器可以通过Docker镜像无限复制,它们是无状态/短暂的资源。
    ##Docker Hub
    Docker Hub给系统基础框架引入了软件工程DRY的原则,它是存储Dockerfile和镜像的全局仓库。目前Docker Hub已经有很多的可用镜像,比如Ubuntu、RedHat、RabbitMQ、MongoDB、Nginx。
    #深入Docker
    让我们直接深入Docker,我们要构建一个简单的基础框架,其上运行一个WordPress的自包含实例,WordPress是被全世界很多公司和作家使用的流行博客工具。这个基础架构包含一个Nginx服务器来路由/代理请求,WordPress应用服务器来部署应用以及MySQL数据库来提供存储。最终的架构类似于:
    dockercrashcourse.png

    ##数据库容器
    现在开始创建MySQL数据库容器,很幸运的是MySQL已经被Docker化了,我们可以从Docker Hub上直接下载,默认配置就很好,因此不需要写自己的Dockerfile或者构建新的镜像。可以使用`docker run`命令行来启动新容器。

    第一次运行需要一些时间,因为需要下载镜像,下载一次之后就会缓存,后续的构建可以直接使用缓存。

    docker run --name wordpress-db -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql

    上面的命令是让Docker使用MySQL基础镜像运行一个新容器,各个参数意义如下:

    * `-name`表示分配给新容器的名字(或者标签)
    * `-e`设置容器的环境变量,指定MySQL实例的密码,已有配置文档可以在MySQL Docker Hub中找到。
    * `-d`指定Docker在后台运行容器。
    * `mysql`指定要使用的Docker镜像的名字,这是从Docker Hub下载下来的。

    注意:为了维护跨容器的数据,必须配置一个VOLUME来确保数据一致性。为了简单起见我们忽略了这个标志,但是要记住涉及状态的部署必须考虑到数据跨容器生命周期的持续性。
    #应用容器
    下面我们需要运行WordPress应用容器,这个也已经被Docker化并放在Docker Hub上了:WordPress仓库

    docker run --name wordpress-app --link wordpress-db:mysql -d wordpress

    `-link wordpress-db:mysql`这个参数告诉Docker创建网络连接到wordpress-db容器(之前创建出来的),使得两个容器间能够网络通信。这个值分为两部分,左边部分指定想要连接的容器(wordpress-db),右边部分指定这个容器的主机别名(mysql)。

    用`docker ps`查看一下正在运行的容器:

    docker ps

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    c39600354fcb wordpress:latest "/entrypoint.sh apac About a minute ago Up About a minute 80/tcp wordpress-app
    20e66802e914 mysql:latest "/entrypoint.sh mysq About a minute ago Up About a minute 3306/tcp wordpress-db

    可以看到有两个容器正在运行,一个在80端口,一个在3306端口。可以ssh进wordpress-app容器,验证可以连接到wordpress-db:

    docker exec -i -t wordpress-app bash
    ping mysql
    64 bytes from 172.17.0.2: icmp_seq=0 ttl=64 time=0.085 ms
    64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.127 ms
    64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.108 ms

    非常好,wordpress-app容器可以连接到wordpress-db容器。退出bash会话,如果需要也可以查看运行着的容器的日志。

    docker logs wordpress-app

    很好,一切看起来都不错。
    #Nginx容器
    Web应用之前通常有HTTP Web代理。这样做有很多好处,比如控制请求路由、审查、安全、日志、缓存、负载均衡、存放静态内容等。Nginx是常用的HTTP Web代理服务器。因为需要创建自定义的Nginx,所以需要一个新Dockerfile来定义包含自定义Nginx配置的新镜像:

    mkdir wordpress-nginx
    cd wordpress-nginx
    vi default.conf

    server {
    listen 80;
    server_name localhost;

    error_log /var/log/nginx/error.log warn;

    location / {
    proxy_pass http://wordpress-app:80/;
    proxy_redirect http://server_name http://wordpress-app:80/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto http;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    root /usr/share/nginx/html;
    }
    }

    注意我们将到达的请求路由到80端口的wordpress-app容器。接下来创建Dockerfile,定义如何构建Nginx容器镜像:

    vi Dockerfile

    FROM nginx
    COPY default.conf /etc/nginx/conf.d/default.conf

    `FROM nginx`命令中的FROM指令告诉Docker从DockerHub上下载Nginx基础镜像
    `COPY default.conf /etc/nginx/conf.d/default.conf`这个命令从当前目录得到default.conf,并拷贝到/etc/nginx/conf.d/下的容器镜像。

    剩下的事情是构建新的Docker镜像并运行容器:

    docker build -t wordpress-nginx .
    docker run -d --name=wordpress-nginx --link=wordpress-app:wordpress-app -p 80:80 wordpress-nginx
    docker ps

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    2b9f99664249 wordpress-nginx:latest "nginx -g 'daemon of 3 seconds ago Up 2 seconds 443/tcp, 0.0.0.0:80->80/tcp wordpress-nginx
    c39600354fcb wordpress:latest "/entrypoint.sh apac 9 minutes ago Up 3 minutes 80/tcp wordpress-app
    20e66802e914 mysql:latest "/entrypoint.sh mysq 9 minutes ago Up 4 minutes 3306/tcp wordpress-db

    可能你会注意到我们指定了参数`-p 80:80`,这是告诉Docker暴露容器的80端口,这样可以从Docker的宿主机器外部访问该容器。
    #Hey Presto
    在浏览器浏览http://DOCKER_HOST_IP/,看,WordPress已经可以用了,按照WordPress安装提示配置实例,很快就可以看到如下页面:
    screen-shot-2015-01-31-at-23-02-51.png

    总的来说,我们通过实际使用Docker Hub上的一些已有资源,学习到了一些Docker的基本概念,构建了WordPress的自包含可运行实例。一切只需要运行几个Docker命令。希望这篇文章能够帮助你开始Docker化你的应用基础架构,享受到Docker带来的巨大好处。

    如果喜欢这篇文章,请帮忙转发给你的朋友,或者在Twitter,LinkedIn上共享。多谢阅读!

    原文链接:A Dive into Docker(翻译:崔婧雯 校对:李颖杰)

    ===========================
    译者介绍
    崔婧雯,现就职于VMware,高级软件工程师,负责桌面虚拟化产品的质量保证工作。曾在IBM WebSphere业务流程管理软件担任多年系统测试工作。对虚拟化,中间件技术有浓厚的兴趣。