【Deis文档】管理Deis之操作型任务

DockOne 发表了文章 • 0 个评论 • 2293 次浏览 • 2014-12-07 21:43 • 来自相关话题

注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。 下面是一些常见的管理Deis平台的操作。 # 管理用户 Deis用户分两类:普通用户和管理员。 []普通用户可以使用Deis的绝大部分功能 - 创 ...查看全部
注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。
下面是一些常见的管理Deis平台的操作。
# 管理用户
Deis用户分两类:普通用户和管理员。
    []普通用户可以使用Deis的绝大部分功能 - 创建,部署应用,添加删除域名等等[/][]管理员可以执行所有普通用户的操作,但他们也拥有所有应用所有者的访问权[/]
第一个在Deis上创建的用户自动成为管理员。
## 将用户提升为管理员
你可以使用deis perms命令来提升一个普通用户的角色到管理员。
```
$ deis perms:create john --admin
```
## 重新发布普通用户的认证令牌
控制器组件API使用了一个很普通的基于令牌的HTTP认证方式。令牌式的认证对于客户端-服务端的格局,如原生的桌面和手机客户端是比较适用的。每一个平台的用户都会在第一次注册平台的时候由平台颁发一个令牌。如果令牌被泄露,你需要手动的介入来重新为该用户颁发一个认证令牌。这一步骤可以通过SSH进入运行有控制器组件的节点然后打开一个Django的命令行:
```
$ fleetctl ssh deis-controller
$ docker exec -it deis-controller python manage.py shell
```
至此,让我们为此用户重新颁发一个认证的令牌。我们假定这个倒霉的用户名字叫Bob:

>>> from django.contrib.auth.models import User
>>> from rest_framework.authtoken.models import Token
>>> bob = User.objects.get(username='bob')
>>> token = Token.objects.get(user=bob)
>>> token.delete()
>>> exit()

这时,Bob再也无法通过使用他之前的认证令牌来通过控制器的认证:
```
$ deis apps
401 UNAUTHORIZED
Detail:
Invalid token
```
Bob要想重新能够使用API,他必须登录进控制器然后重新领取一个新的令牌:
```
$ deis login http://deis.example.com
username: bob
password:
Logged in as bob
$ deis apps
=== Apps
```

【Deis文档】管理Deis之配置负载均衡

DockOne 发表了文章 • 0 个评论 • 2491 次浏览 • 2014-12-07 21:38 • 来自相关话题

注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。 Deis包含多个路由组件作为路由网格的一部分。在一个主机失效的情况下,这些路由组件可以移动主机。因此,建议你配置一个复 ...查看全部
注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。
DeisLoadBalancerDiagram.png

Deis包含多个路由组件作为路由网格的一部分。在一个主机失效的情况下,这些路由组件可以移动主机。因此,建议你配置一个复杂均衡器,在Deis集群的前端来接受应用的外部访问请求。
下边的端口需要在负载均衡组件上打开:
    []80:用来服务应用的访问,和向控制器组件的API调用[/][]2222: 用来访问Builder组件[/]
如果你想在你的负载均衡器上配置SSL,参见SSL/TLS端点。
在负载均衡器上,应该配置好健康检查,向Deis集群中的所有节点的80端口上/health-check发送HTTP请求。健康检查的端点会返回200的状态码。这样可以让负载均衡器将流量发送到某时某刻恰好正在运行deis-router组件的主机上。
# EC2
Deis的EC2操作脚本会自动为你的Deis集群创建一个Elastic的负载均衡器。然而,EC2上的ELB会60s超时,这会在使用Deis的时候打断git push。你应该手动的提高此超时值到1200秒,以符合路由器上和应用单元文件(application unit files)的超时时间。
# Rackspace
你需要创建两个复杂均衡器,像下面这样:
```
Load Balancer 1
Port 80
Protocol HTTP
Health Monitoring -
Monitor Type HTTP
HTTP Path /health-check
Load Balancer 2
Virtual IP Shared VIP on Another Load Balancer (select Load Balancer 1)
Port 2222
Protocol TCP
```
# Google Compute Engine
对于Google Compute Engine的操作指示包含了创建一个负载均衡器的步骤。现在还不可能修改 Google Compute Engine 中的负载均衡器的超时时间。

【Deis文档】管理Deis之配置DNS

DockOne 发表了文章 • 0 个评论 • 3062 次浏览 • 2014-12-07 21:36 • 来自相关话题

注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。 对于使用Vagrant的用户,我们添加了DNS的记录local.deisapp.com可以解析到第一个虚拟机,172.17.8.100。你可以使用local.deisapp.com ...查看全部
注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。
对于使用Vagrant的用户,我们添加了DNS的记录local.deisapp.com可以解析到第一个虚拟机,172.17.8.100。你可以使用local.deisapp.com 来登录进控制器组件和访问你已经部署的应用(他们会是local.deisapp.com的子域名,如happy-unicorn.local.deisapp.com)。类似的,你可以使用local3.deisapp.com或者local5.deisapp.com来分别命名三个或者五个节点的集群。
对于在其他地方放置的Deis集群(EC2、Rackspace、DigitalOcean,、Google Compute Engine、裸机等)。DNS记录应该添加来指向集群。对于一个单节点的集群,我们计划放置然后启动一个路由组件,然后deis的路由和deis-controller将会在相同的主机上。因此,下面指定的DNS的记录可以配置成指向此单一机器上。
然而,在一个多节点的集群上,可能有多个路由组件,并且控制器组件很可能会被计划放置到一个单独的机器上。根据“配置负载均衡”,在这种情形下推荐使用一个负载均衡器。
注意控制器组件可能会最终放置到路由器组件之后,这样所有的外部访问都会通过负载均衡器 - 配置一个DNS记录指向一个IP地址会变化的的服务显然不是很理想的。
# 必要的DNS记录
Deis需要一个通配符型的DNS记录。假设myapps.com是顶级的域名,所有的应用都放置其下:
    [].myapps.com应该针对么一个负载均衡器的IP地址有A记录的条目
之后,应用就可以通过浏览器以appname.myapps.com访问,并且控制器组件可以在Deis的客户端通过deis.myapps.com访问。
E2建议不创建A记录;相反,应该为负载均衡器的DNS名字创建一个通配符型的“CNAME”记录,或者使用Amazon的Route 53。
这些记录对于所有Deis的部署都是必要的(EC2、Rackspace,、DigitalOcean、Google Compute Engine、裸机等)。Vagrant的集群可以使用域名:local.deisapp.com、local3.deisapp.com或者local5.deiaspp.com。
# 使用xip.io
不手动配置你自己的DNS记录的另外一种选择是使用xip来指代你的负载均衡器的IP。比如:
```
$ deis register http://deis.10.21.12.2.xip.io
```
你然后需要用10.21.12.2.xip.io作为集群的域名来创建集群。
注意xip对于EC2 ELB似乎没效果 - 你需要使用实际的DNS记录。

【Deis文档】管理Deis之备份和还原数据

DockOne 发表了文章 • 0 个评论 • 2956 次浏览 • 2014-12-07 21:33 • 来自相关话题

注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。 尽管部署在Deis上的应用因遵循12因子的方法学而无状态,Deis却需要在存储(Store)部件维护着平台的状态。 存储部件运行着Ceph、数据库组件(Database) ...查看全部
注:本文翻译自Deis官方文档,无任何商业目的,转载请注明出处。
尽管部署在Deis上的应用因遵循12因子的方法学而无状态,Deis却需要在存储(Store)部件维护着平台的状态。
存储部件运行着Ceph、数据库组件(Database)、注册表组件(Registry)、控制器组件(Controller)和日志组件(Logger)都需要把存储组件(Store)当做一个数据存储来使用。数据库组件和注册表组件使用存储网关(store-gateway),控制器和日志组件使用存储卷(store-volume)。这些组件有了存储组件作为后备,可以自由的在集群上移动,因为他们的状态有存储组件做后备。
假如一个主机失效然后重新加入集群,根据配置存储组件仍然会以降级的状态运作,并且会自动的恢复。Ceph的数据完全丢失只可能发生在所有的存储容器被移除的情形下。然而,备份Ceph相当直接简单,我们建议在升级Deis之前进行备份。
存放在Ceph中的数据可以通过两个地方访问到:在CoreOS文件系统的/var/lib/deis/store下,和存储网关组件(store-gateway)。备份此份数据也比较简单,我们可以把该文件系统的数据做一个tar包,然后使用任何S3兼容的blob存储工具将存储网关所有的文件下载下来。
# 设置
Deis的存储网关组件对外暴露了一个S3兼容的API,因而我们可以使用如s3cmd来操作存储(object store)服务。首先请安装我们的fork的s3cmd,里面包含了支持ceph的补丁。
```
$ pip install git+https://github.com/deis/s3cmd
```
我们需要生成了的访问key(access key)和秘钥key(secret kejy)来使用存储网关。我们可以通过在集群上的任意一台主机,或者通过在设置了DEISCTL_TUNNEL的远程主机上使用deisctl来获取访问key和秘钥key。
```
$ deisctl config store get gateway/accessKey
$ deisctl config store get gateway/secretKey
```
回到本地主机,运行s3cmd --configure并且输入你的访问key和秘钥key。其他设置都可以不修改使用默认值。如果配置脚本提示你测试下身份验证,略过此步骤 - 它会去Amazon S3做验证然后肯定会返回失败。
你需要更改一些其他的设置。首先,编辑`~/.s3cfg`文件然后修改`host_base`和`host_bucket`的值,使它们与deis-store.一致。比如,在我本地的Vagrant主机上,我做了如下修改:
```
host_base = deis-store.local3.deisapp.com
host_bucket = deis-store.local3.deisapp.com/%(bucket)
```
你还需要开启`use_path_mode`模式:
```
use_path_mode = True
```
现在我们可以使用s3cmd命令通过存储网关做备份和还原的操作了。
# 备份
## 数据库组件和注册表数据的备份
存储网关组件存储数据库的备份,并且会被用来存储注册表的数据。在我们本地的机器上,我们可以使用s3cmd sync来把数据对象拷贝到本地:
```
$ s3cmd sync s3://db_wal .
$ s3cmd sync s3://registry .
```
## 日志数据
存储卷(store-volumn)服务挂载了一个文件系统,控制器组件和日志组件用它来存储和获取应用和组件的日志。
由于这只是一个POSIX的文件系统,你可以方便的将此目录打包然后rsync到本地主机上:
```
$ ssh core@ 'cd /var/lib/deis/store && sudo tar cpzf ~/store_file_backup.tar.gz .'
tar: /var/lib/deis/store/logs/deis-registry.log: file changed as we read it
$ rsync -avhe ssh core@:~/store_file_backup.tar.gz .
```
注意如果你使用的是Vagrant,你需要指定SSH的端口:
```
$ rsync -avhe 'ssh -p 2222' core@127.0.0.1:~/store_file_backup.tar.gz .
```
留意此警告 - 在一个运行中的集群上,日志文件被不断地改写,因而我们仅仅是备份着一段时间的数据。
## 数据库数据
尽管备份Ceph的数据已经足够(因为数据库组件将备份和WAL日志放入存储组件中),我们可以使用pg_dumpall来备份PostgreSQL数据的数据,这样我们就得到了数据库的一个文本dump。
我们可以通过deisctl list找到该主机然后在该主机上:
```
core@deis-1 ~ $ docker exec deis-database sudo -u postgres pg_dumpall > dump_all.sql
core@deis-1 ~ $ docker cp deis-database:/app/dump_all.sql .
```
还原
注意:
还原仅仅在部署一个新的集群的时候才必要。大多数的用户只需要使用平常的即时升级(in-place upgrade)的工作流即可,不需要进行还原操作。
我们需要在Deis其余的组件启动和初始化之前进行数据的还原。因此,我们需要安装整个平台,但是仅仅启动存储组件:
```
$ deisctl install platform
$ deisctl start store-monitor
$ deisctl start store-daemon
$ deisctl start store-metadata
$ deisctl start store-gateway
$ deisctl start store-volume
```
我们也需要启动路由组件这样我们才能访问到存储网关:
```
$ deisctl start router@1
```
路由组件上默认最大的消息体的大小对于支持数据较大的像存储网关的上传还是太小,因而我们需要增大此值:
```
$ deisctl config router set bodySize=100m
```
新的集群应该已经生成了新的访问key和秘钥key,因此我们需要再次获取:
```
$ deisctl config store get gateway/accessKey
$ deisctl config store get gateway/secretKey
```
编辑`~/.s3cfg`然后更新key。
现在我们可以还原数据了!
## 数据库还原和注册表数据
因为数据库和注册表组件都还没有启动,我们要还原的目标bucket还不存在。因此我们需要手动创建这些bucket:
```
$ s3cmd mb s3://db_wal
$ s3cmd mb s3://registry
```
现在我们可以开始还原数据了:
```
$ s3cmd sync basebackups_005 s3://db_wal
$ s3cmd sync wal_005 s3://db_wal
$ s3cmd sync registry s3://registry
```
## 日志数据
一旦我们将tarball拷贝回一个CoreOS的主机上,我们可以解包:
```
$ rsync -avhe ssh store_file_backup.tar.gz core@:~/store_file_backup.tar.gz
$ ssh core@ 'cd /var/lib/deis/store && sudo tar -xzpf ~/store_file_backup.tar.gz --same-owner'
```
注意如果你使用的Vagrant你需要指定SSH的端口:
```
$ rsync -avhe 'ssh -p 2222' store_file_backup.tar.gz core@127.0.0.1:~/store_file_backup.tar.gz
```
## 收尾
现在数据已经还原好了,集群剩下的组件在执行`deisctl start platform`后应该能正常的启动。
最后的任务就是告诉控制器组件重写用户的Key,应用的数据,和domains域到etcd。登陆进入运行着deis控制器组件的主机然后运行如下命令。注意在export命令上使用的IP地址应该符合运行此容器的宿主主机的IP。
```
$ nse deis-controller
$ cd /app
$ export ETCD=172.17.8.100:4001
./manage.py shell < from api.models import *
[k.save() for k in Key.objects.all()]
[a.save() for a in App.objects.all()]
[d.save() for d in Domain.objects.all()]
EOF
$ exit
```
注意:
数据库组件会监控运行应用容器。由于这是一个全新的集群,我们建议用deis scale =0然后deis scale回到你想要一个应用的容器的数量。这可以保证数据库组件对集群有一个确切的了解。

Docker Swarm介绍

DockOne 发表了文章 • 0 个评论 • 10837 次浏览 • 2014-12-07 20:47 • 来自相关话题

Docker Swarm是一个Dockerized化的分布式应用程序的本地集群,它是在Machine所提供的功能的基础上优化主机资源的利用率和容错服务。具体来说,Docker Swarm支持用户创建可运行Docker Daemon的主机资源池,然后在资源池中运 ...查看全部
Docker Swarm是一个Dockerized化的分布式应用程序的本地集群,它是在Machine所提供的功能的基础上优化主机资源的利用率和容错服务。具体来说,Docker Swarm支持用户创建可运行Docker Daemon的主机资源池,然后在资源池中运行Docker容器。Docker Swarm可以管理工作负载并维护集群状态。
logo.png

Docker默认调度器会根据Docker容器的工作负载以及集群中主机的可用资源,使用bin pack自动优化工作负载。 例如,调度一个需要1G内存的Redis容器:

% docker run -d -P -m 1g redis

为了支持特定的需求和基于策略的调度,Docker Swarm还提供了标准和自定义约束。比如为了保证好的IO性能,用户可能想在SSD上运行MySQL容器,这个时候可以定义如下约束:

% docker run -d -P -e constraint:storage=ssd mysql

docker-swarm_w_450.png

除了资源优化,Docker Swarm可以保证应用的高可用性和容错性。Docker Swarm会不断的检查Docker Daemon所在主机的健康状态。当某个主机不可用时,Swarm就会将容器迁移到新的主机上。
Docker Swarm的亮点之一是它可以在应用的生命周期内扩展,也就是说当应用从一个主机扩展到2个、20个或者200个的时候,用户可以保证接口的一致性。
同样,和Machine一样,Swarm的架构是可插拔的,系统已经包含一个默认的调度器。其它的厂商可以实现自己的调度器。
可能上面的解释不太好理解,读者可以看完例子后再回来看上面那段话。或者可以看看作者(Andrea Luzzardi)在DockerCon上的演讲稿

CoreOS的集群中的Discovery服务器搭建,有朋友在这方面有所研究不?

回复

jamlee 回复了问题 • 2 人关注 • 1 个回复 • 4537 次浏览 • 2014-12-07 20:40 • 来自相关话题

Docker Machine介绍

DockOne 发表了文章 • 0 个评论 • 24158 次浏览 • 2014-12-06 21:24 • 来自相关话题

Docker Machine是一个简化Docker安装的命令行工具,通过一个简单的命令行即可在相应的平台上安装Docker,比如VirtualBox、 Digital Ocean、Microsoft Azure。Docker官方是这样介绍Machine的初衷的 ...查看全部
Docker Machine是一个简化Docker安装的命令行工具,通过一个简单的命令行即可在相应的平台上安装Docker,比如VirtualBox、 Digital Ocean、Microsoft Azure。Docker官方是这样介绍Machine的初衷的:

之前,Docker的安装流程非常复杂,用户需要登录到相应的主机上,根据官方的安装和配置指南来安装Docker,并且不同的操作系统的安装步骤也是不一样的。而有了Machine后,不管是在笔记本、虚拟机还是公有云实例上,用户仅仅需要一个命令....当然那你需要先安装Machine。

docker-whales-transparent_meitu_1.jpg

Machine的命令也非常简单:

% machine create -d [infrastructure provider] [provider options] [machine name]

看着有点懵,infrastructure provider是啥?machine name是啥?我使劲想了半天也没想到好的中文翻译,但是你看例子就明白它们的意思了。

$ machine create -d virtualbox dev
[info] Downloading boot2docker...
[info] Creating SSH key...
[info] Creating VirtualBox VM...
[info] Starting VirtualBox VM...
[info] Waiting for VM to start...
[info] "dev" has been created and is now the active host. Docker commands will now run against that host.
$ machine ls
NAME ACTIVE DRIVER STATE URL
dev * virtualbox Running tcp://192.168.99.100:2375
$ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
$ docker run busybox echo hello world
Unable to find image 'busybox' locally
Pulling repository busybox
e72ac664f4f0: Download complete
511136ea3c5a: Download complete
df7546f9f060: Download complete
e433a6c5b276: Download complete
hello world
$ machine create -d digitalocean --digitalocean-access-token=... staging
[info] Creating SSH key...
[info] Creating Digital Ocean droplet...
[info] Waiting for SSH...
[info] "staging" has been created and is now the active host. Docker commands will now run against that host.
$ machine ls
NAME ACTIVE DRIVER STATE URL
dev virtualbox Running tcp://192.168.99.108:2376
staging * digitalocean Running tcp://104.236.37.134:2376

Machine做事也很聪明,很符合Docker公司的做事风格,他们号称自己架构很好,方便第三方集成。所以Machine现在只支持有限的几个平台(VirtualBox、 Digital Ocean、Microsoft Azure),其它平台的兼容留给那些爱Docker的第三方厂商以及开发者去做吧。所以接下来一定会有很多的厂商跟进,比如国内阿里云之类的,他们根据官方的接口开发个Driver即可加入Machine的能力。
需要注意的是Machine是完全独立于Docker项目的,目前的主要维护者是也是一位叫Ben的人,当然还是使用Go语言。



感谢郭蕾的投稿。

Docker发布新的跨容器的分布式应用编排服务

DockOne 发表了文章 • 0 个评论 • 6195 次浏览 • 2014-12-05 23:30 • 来自相关话题

12月4日,Docker宣布发布跨容器的分布式应用编排服务,编排服务可以帮助开发者和运维人员创建并管理新一代的可移植的分布式应用程序,新一代的分布式应用程序是由独立且互通的Docker容器快速组合而成,他们有动态的生命周期,并且可以在任何地方以可扩展的方式运行 ...查看全部
12月4日,Docker宣布发布跨容器的分布式应用编排服务,编排服务可以帮助开发者和运维人员创建并管理新一代的可移植的分布式应用程序,新一代的分布式应用程序是由独立且互通的Docker容器快速组合而成,他们有动态的生命周期,并且可以在任何地方以可扩展的方式运行,不管是在开发者的笔记本上,还是在云端。

“一开始用户在几台主机上运行少量的Docker容器,但是现在他们已经在集群和不同的基础设施中运行了大量的Docker容器,我们需要满足用户的需求,这非常重要”。Docker的创始人兼CTO Solomon Hykes说道。“编排服务开放了原生的接口,可以保证应用的可移植性,并通过一个通用的UI整合了生态圈中的18000个工具和60000个容器化的应用。”

Docker编排服务可以在正在召开的DockerCon欧洲大会上看到,它已经得到了很多合作伙伴的支持,包括Cisco、Digital Ocean、HP、IBM、Mesosphere、Microsoft和VMware。

Docker平台加强了跨容器的分布式应用能力

Docker编排功能在开放平台的基础上构建,开放平台能够创建企业级标准的Docker容器:将分散的应用服务打包到可交互、可迭代、可随处运行的容器中。Docker编排服务可以满足企业从整体式的应用转移到容器化的分布式应用的需求,因为编排这些分布式应用需要多个容器、多个主机以及可以在这些设施中运行的工具和通用UI。

编排服务为应用的开发和运维提供了一种新的方式

Docker的编排功能由3个新的平台服务组成,它们覆盖了分布式应用的所有动态生命周期,当新的代码或者新的容器化服务改变时,应用可以在几分钟内部署到生产环境,而不是像之前一样需要几个月。Docker的编排服务是目前市场上功能最全面的服务,它们独特的模块化结构决定了其可以被不同的人员使用,包括开发者、运维人员以及其它合作伙伴。比如它其中就有一项服务可以帮助开发人员方便地创建分布式的应用程序栈,而另外一个服务可以重点处理集群以及运维团队的问题。
这三个新的编排服务分别是:

Docker Machine:这项服务进一步扩展了分布式应用的可移植能力,它为用户提供了灵活的功能,用户可以在任何主机上运行Docker容器,不管是笔记本、数据中心VM还是云端。这大幅度减少了开发者在手动设置、自定义脚本的时间,可以加快迭代和研发周期。

Docker Swarm:Docker Swarm是一个支持Docker容器(由Docker Machine提供)的原生的集群服务,它在分布式的应用运行的主机提供了一个资源池。相比于手动管理资源的低效率以及易出错的问题,Docker Swarm可以自动平衡容器工作负载和分配资源,它更加高效。在行业中,Docker Swarm是独一无二的,它是专门为从开发到运维的一个持续的生命周期而设计的。开发者可以在生产环境的几台机器上测试集群服务,同时运维团队可以使用相同的工具在不同的架构中的上百台主机上扩展相同的应用程序。

Docker Swarm API支持插件化的集群实现,以便客户选择其它的高可扩展的解决方案,比如Mesosphere需要管理上千个节点的容器。

Docker Compose:这项服务为开发者提供了应用组合的能力,这些应用基于独立于任何底层基础设施的分散的、可交互的Docker容器之上构建,以便于分布式的应用栈可以随时随地部署并迁移。Docker Compose通过一个简单的YAML配置文件来定义分布式的应用程序栈以及依赖,这样一个复杂的过程通过几次键盘输入就可以完成。这个强大的功能也就意味着一个新的集群应用可以在几分钟之内构建完成,而这在之前是不可思议的。

本文翻译自Docker官方博客

CoreOS称Docker有根本性缺陷,推出自己的容器引擎Rocket

田浩浩 回复了问题 • 4 人关注 • 1 个回复 • 5141 次浏览 • 2014-12-05 09:27 • 来自相关话题

为什么CoreOS和Docker的分手是命中注定的

DockOne 发表了文章 • 0 个评论 • 5523 次浏览 • 2014-12-04 20:15 • 来自相关话题

本文翻译自Why Docker and CoreOS’ split was predictable,原文作者Daniel Compton。中文翻译来自七牛云存储&version=11020012&pass_ticket=lkf9QVxqd5MMciJiV7BN ...查看全部
本文翻译自Why Docker and CoreOS’ split was predictable,原文作者Daniel Compton。中文翻译来自七牛云存储&version=11020012&pass_ticket=lkf9QVxqd5MMciJiV7BNzF4GrbLNzvUjAxWzbjNzLd3M7SeuiWN4bxF2GDa%2B8lre),DockerOne基于七牛云的翻译进行了整理。

韦恩·格雷茨基曾说过:“我总是溜向冰球将达到的点,而不是追逐它曾在的地方。

关于Docker是否应该扩大产品的边界以扩张CoreOS的集群管理范围的争论由来已久,这也直接导致了CoreOS开发了自己的容器Rocket来与Docker争雄。这种现象可以被Clayton Christensen教授的 Law of Conservation of Modularity 一书中的观点合理地解释:

0.jpeg

“根据我们的研究,存在这样一种现象,当价值链上的一种产品在商品化的同时,与此同时在价值链上肯定会有一种当前产品非商品化的趋势,这种相互作用的进程就意味着,当新的破坏性浪潮冲刷一个行业时,差异化能力仍然在价值链上不断的转移着。当发生这种情况时,那些将自身定位再不够完善的价值链区间的企业就能够盈利”



-Clayton Christensen, 第六章:创新者的方法。

关于Docker和CoreOS之间的这点事在科技界并不新鲜,在计算机产业发展的初期就曾经发生过。当差异化能力在价值链上不断的转移时,力图拥有这种能力的人之间就会产生各种对抗。就像在冰球比赛中一样,总有人滑向价值将要产生的地方。

历史不会重演,但总是惊人的相似。起初,大型机的发展总是差强人意,所以被整体设计、制造和出售是一个大的趋势。IBM在这一整合的历史趋势中获得了大部分利润,由于它的供给能够填补当时这种趋势中的不足。几年后,小型机和大型机已经发展得足够完善了。这时候利润从组装整个机器的整合资源者(如IBM和康柏)转移到各个部件的生产商了:操作系统(微软),处理器(Intel),存储器和驱动器。现在又到了整合资源的商家通过填补整合资源的空白来获取利润的时代了。

在台式机的领域里,处理器和操作系统一开始不那么令人满意,因此价值转移至此并不断被持续改善。但存储器和驱动器就不那么幸运。当他们发展得足够好并且能够进行模块化操作的时候,利润早已经被生产DRAM的厂家瓜分大半。

在云服务领域,截至2013年云服务商提供的虚拟机服务已经足够完善而且成功商品化。发展得并不尽如人的方面是应用的重构、部署和多服务器的管理。这时涌现了一大批工具如puppet、chef 和ansible,但是所有工具的表现不分伯仲。直到王者Docker在Github上的出现才打破了现有的格局。

从模块化和整合化的方面来说,我们可以认为Docker被设计的初衷是在独立封装和在任何平台都可以同步运行。Docker将操作系统、虚拟机、物理机和基于上面的操作整合起来进行商品化。同时提供了一系列的API,使得其他人能够基于这些API进行操作。Docker不能商品化的部分是数据中心,我们稍后会解释为什么特别强调这一点。

从一个开发者的角度,把应用封装在Docker的意义在于你可以你整个云服务作为一个模块进行操作,这其中的模块只是一个可以被替代的商品。Docker的伟大之处在于你可以任意地把你的应用进行迁移而无需做出其他改动。这对于谷歌这样的云服务的提供者可不是一个好消息,因为用户的迁移成本变得非常低。这时代,价值就从提供虚拟环境VM的云服务商流向Docker。

Docker对于开发者的意义在于,封装应用只需要Docker就够了。可以预见的是将会很快出现一大批公司提供基于Docker的无差异的整合服务。最著名的无疑是CoreOS。CoreOS提供了分离式的Linux版本服务和基于容器Docker的集群服务。CoreOS剥离了虚拟机和容器Docker,并以单一集群和商品化的数据中心进行代替。价值再次进行转移,从Docker转向整合Docker之后提供的服务。无论他们承认与否,CoreOS与其友商都是其他云服务商的潜在威胁:他们要将云服务及其建立在之上的整合平台进行商品化

感受到这样的威胁,如果采取调整自己的服务以适应Docker的发展这样的策略对于谷歌这样的云服务提供商来说并不奇怪。他们的服务可以基于自己的硬件平台并将Docker整合在自己的服务里进行管理,这可以使价值重新分布。但令人大跌眼镜的是,谷歌又推出了自己的容器集群管理工具 Kubernetes,直到现在我还是不能理解。

那最后留给Docker的是什么呢?从一开始它提供了一个模块化的组件供其它应用使用。这对于其他组件是有很大价值的,但对Docker却没有什么价值,因为这个过程并不能获得极大的利润。完全商品化并不是一条好的出路,对于Docker的投资人来说肯定也不会带来极高的回报率。

所以CoreOS肯定会把Docker当作一个商品的构成要素,当Docker意识到自己的价值不过是被像CoreOS这样的企业作为一个工具来创造价值的时候,Docker肯定不能只是继续停留在OS层面提供价值。对于Docker来说,惟一的出路是向上一层发展。基于Docker进行构建和运行并且进行管理的整合式集群服务对Docker来说才有意义。

CoreOS对这种变化是非常在意的,因为Docker对于他们来说 ,在开发者中间,是一个极大的潜在竞争者。最自然的反应就是构建一个新的容器作为和Docker进行博弈的工具从而支持他们本来自己的服务。Rocket从出生开始相对于Docker就有技术方面的优势,这是因为它本身就是CoreOS制造用来抵挡来自Docker的威胁。

在不久的将来,集群管理也将会被完全商品化,价值将会流到别的地方,这种循环又会重新上演。这种把戏,跟打冰球没什么两样。