Subscribe最新博客 (更多)

14 Sep 2015

Docker挺适合用于软件开发环境

介绍

前几天在微信中看到一篇翻译的文章Docker根本不适合用于本地开发环境,翻译得很流畅,一下子看懂了,但对于原作者的观点实在不敢苟同。我有点不敢确认是否作者真心研究过docker对于软件开发环境带来的好处。因为我从去年年初开始用docker以后的感触是:部署docker行不行还有待商榷,但是用在开发中是足够了、可以极力推广的。

这篇博客用我实际工作中的一个例子让大家跟着我一起体会一下,我是如何用docker来作为开发环境的,并给出我使用的一些小技巧,最后也对原文中提到的几个问题一一进行探讨。

真实案例

最近我一直在和JenkinsDashing打交道,前几周,有人提需求要把Jenkins中在等待构建队列(Queue)中超过一定时间的Job显示在Dashing的Widget中,以便于他们及时发现解决。

Jenkins是Java写的,Dashing是Ruby的,为了完成这个任务,我决定使用Groovy来写个Jenkins的Job定期检测并发到dashing上。

Docker开始派上大用场了。如果要在Windows上把这些一一搭建还是蛮费周折的,如果用虚拟机的话,重用性和灵活性会打个折扣。

开发环境

我上班使用的是Windows 7,所以就以Windows环境为例子,Mac类似,Linux更方便点。为了在Windowns上使用Docker,它和MacOS一样需要安装Docker Toolbox(原来叫Boot2docker), MobaXterm是一个终端软件比PuTTY好用(季浩小盆友推荐的),我用它来处理Docker环境,而不是Windows下的Git Bash终端。

源代码

代码当然是用Git来处理,我习惯在Windows上运行Git,如果你习惯,也可以用在docker中。

技巧一:把代码克隆到用户目录下,这样就可以映射到docker主机中被访问,对应的目录是/c/User/<id>

在Windows的Git Bash中克隆下代码。

cd ~/git/docker
git clone https://github.com/larrycai/docker-dev-demo.git

里面两个目录dashingjenkins代表了我要编程的工作目录,第一版工作的代码已经在里面了。

启动Docker Toolbox,然后使用MobaXterm一键登陆到docker主机上(提前存好了配置)。进去以后,你可以发现在docker主机中能看到克隆下来的文件了。

docker@default:~$ ls /c/Users/larrycai/git/docker/docker-dev-demo/
README.md   dashing/    dashing.sh  jenkins/    jenkins.sh  start.sh    stop.sh

它说明了Windows目录下的文件能够共享到docker主机中。这个不是docker做的,它只是集成进了Virtualbox的共享文件夹功能。

技巧二:建立一些软链接到缺省的docker用户下,不然这个目录下的文件重启就重置了。

为了方便访问,我一般做个软链接(soft link)如git放在docker用户下,这样方便使用 (~/git)。 具体方法见stackoverflow

docker@default:~$ ls -al
..
lrwxrwxrwx    1 root     staff           20 Sep 11 09:19 git -> /c/Users/larrycai/git/
lrwxrwxrwx    1 root     staff           21 Sep 11 09:19 m2 -> /c/Users/larrycai/.m2/

Docker镜像

Jenkins和Dashing我都做了相应的Docker镜像,可以提前下载。

docker pull larrycai/jenkins
docker pull larrycai/dashing

启动docker应用容器

先来把工作的容器启动起来,我的代码也会共享进去。看不懂没关系,大概知道一下就可以了。稍后买本书(推荐第一本Docker书温习一下。

$ cd ~/git/docker/docker-dev-demo
$ docker run --rm --name dashing -it -p 3030:3030 \
    -v $PWD/dashboards:/dashing/dashboards \
    -v $PWD/widgets:/dashing/widgets \
    larrycai/dashing dashing start
Thin web server (v1.6.3 codename Protein Powder)
Maximum connections set to 1024
Listening on 0.0.0.0:3030, CTRL+C to stop

这样就启动了Dashing容器,接着再在MobaXTerm开启另一个Shell来启动Jenkins环境

$ docker run --rm -it --name jenkins -p 8080:8080 \
    --link dashing:dashing \
    -v $PWD/jenkins:/opt/jenkins/data/jobs/longjobs/workspace \
    larrycai/jenkins
Running from: /opt/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
...
INFO: Jenkins is fully up and running

再开启一个Shell窗口,打个docker exec命令进入容器看看,bingo,你可以看到Windows上的代码在容器中也已经妥妥的了。

$ docker exec -it jenkins bash
root@3e026f490f2a:/# ls $JENKINS_HOME/jobs/longjobs/workspace
docker.sh  longjobs_to_dashing.groovy

技巧三:要熟练掌握--volume命令参数和docker exec命令来理解你的代码能够共享到哪里了

实际上一般我都在目录下放个README.mddocker.sh,方便copy/paste和直接启动容器(关键我打字太慢),这儿实际上我写了两个脚本jenkins.shdashing.sh

技巧四:多写些脚本替代冗长的docker命令,容器依赖多的话,可以考虑docker-compose

配置运行

现在可以在Windows浏览器中配置一下,看效果了。常用的端口我已经在Virtualbox中映射好了,一般我用localhost访问

http://localhost:3030/sample (用chrome/firefox打开,不支持早期IE版本)是dashing的,可以看到监控等待队列的Widget已经在那儿了

http://localhost:8080 是jenkins的,创建一个新Job叫longjobs,然后配好系统的Groovy脚本。这个longjobs_to_dashing.groovy就是在git repo中的,现在已经可以在jenkins容器中被访问到了。

保存运行,看看输出的console log,应该dashing widget没有大的变化,只有标题变成了Waited in queue (demo),这就是传上去的。

你也可以创建一个包含sleep 1000的脚本来模拟长运行的job,使得后续构建等在队列中。感兴趣的可以单独联系。

调试代码

到现在为止,还没有改一行代码。不过实际上你就像是和我奋斗在一个团队,现在在代码审阅前,用docker环境方便地验证我写的新功能!!

来点变化吧,简单的代码编辑器我就用Notepad++, sublime太贵,一直没舍得买 ;-)。

假设对那个标题不满意,那就在Windows上打开文件longjobs_to_dashing.groovy,把大概59行改成你喜欢的标题吧。

  title: "Waited in queue (demo)",

再把那个job运行一下,一下子就搞定了吧。

如果有想玩dashing,没问题,很简单,可以试试修改dashing/dashboards/sample.erb,这一步,你自己琢磨吧。

再来看docker镜像

为啥不用标准镜像的呢?一般来说为了自己的开发方便,我们要不断打磨需要的docker镜像,标准镜像一般满足不了需求。我们要把常见的依赖都提前包含在里面,繁杂配置都一次设好。

方便分享的,放在github上,自动生成docker image在docker hub上,否则就放在自己内部的docker私有镜像服务器中。

技巧五:要不断打磨需要的docker镜像,使得使用最方便。

总结

上面的工作方式也是我常用的,里面的技巧还需要你自己体会。

再来看看原来的文章,我认为原来的文章中主要有三个方面没解决好,结果导致了错误的结论。

  1. 文件的共享问题, 也就是如何在Windows/Mac和docker主机、docker主机和docker容器共享文件,这个分别实际有Docker Toolbox(使用Virtualbox的共享文件夹技术和docker run --volume很好的解决了。
  2. 太拘泥于在容器中运行了:基于上面的文件共享技术,完全可以继续使用原来Windows的IDE(如Sublime)和Git,搭配好MobaXterm来处理docker环境和容器内相关命令的执行。
  3. 把简单问题复杂化了:一般Shell脚本就可以解决了,不熟练的话,刚开始还是少用docker-compose

上面用到的是脚本,实际上对编译型的开发环境也一样。有一阵子在学习陈迪豪的Seagull海鸥项目,程序是用golang写的,我也是完完全全用docker环境来开发的,很顺畅。有问题时,因为环境一样,重现也很方便。

docker用来支撑你的开发环境真的很棒,今天只是分享了其中的一种用法,我们还用在了很多其他地方,有机会再分享。

虽然我不能打包票你的开发环境也一定很适合用Docker,但是如果你碰到了问题,我很希望一起见面聊聊,看看怎么来解决。

感谢

李乾坤也给我提供了很好的建议

View Comments
14 Jul 2015

在Ustack公有云上体验LXD:一个基于Linux容器上的Hypervisor

介绍

粗略看了Hyper以后,我想换个方向,看看Ubuntu的LXD。它不同于Docker/CoreOS container技术。

国内介绍LXD的文章很少,国外也不多(看参考链接)。虽说存在挺长时间了,但只是在今年五月渥太华的Openstack Summit上Ubuntu讲了LXD vs KVM,才引起了更多注意。

这篇博客就是介绍如何在UnitedStack公有云上体验一下LXD的效果来加深理解,相信你自己用物理机或虚机也是一样的(用公有云省去安装和proxy的问题)。

安装 & 运行

安装

在ustack上选择Ubuntu 15.04,最小配置,连上公网IP,ssh登陆,一气呵成。

现在就可以安装了,LXD 0.7也已经在Ubuntu 15.04中了,安装比较方便,看官方文档

我再借鉴了github上的LXD项目,用PPA更新到最新版本。 别忘了更新lxd-client,它包含了使用到的lxc命令。 否则会出现不一致的问题:websocket: bad handshake,参见#832

add-apt-repository ppa:ubuntu-lxc/lxd-git-master 
apt-get update
apt-get install lxd
apt-get install lxd-client

运行

缺省服务没起来

service lxd start

LXC的系统源都在https://images.linuxcontainers.org,加上LXC的源,方便访问。lxc-org只是个别名。

lxc remote add lxc-org images.linuxcontainers.org

查看服务器上的列表。

root@lxd:~# lxc image list lxc-org:
+--------------------------------+--------------+--------+-------------------------+---------+-------------------------------+
|             ALIAS              | FINGERPRINT  | PUBLIC |       DESCRIPTION       |  ARCH   |          UPLOAD DATE          |
+--------------------------------+--------------+--------+-------------------------+---------+-------------------------------+
|                                | 8d552ca0de3c | yes    | Centos 6 (amd64)        | x86_64  | Jun 17, 2015 at 11:17am (CST) |
|                                | f7d9e7940fbb | yes    | Centos 6 (amd64)        | x86_64  | Jun 18, 2015 at 11:17am (CST) |
| centos/6/amd64 (1 more)        | afae698680fc | yes    | Centos 6 (amd64)        | x86_64  | Jun 19, 2015 at 11:17am (CST) |
|                                | 59a75a69c16e | yes    | Centos 6 (i386)         | i686    | Jun 17, 2015 at 11:19am (CST) |
|                                | 824c9996bb00 | yes    | Centos 6 (i386)         | i686    | Jun 18, 2015 at 11:20am (CST) |
| centos/6/i386 (1 more)         | 3266fd8b7b6e | yes    | Centos 6 (i386)         | i686    | Jun 19, 2015 at 11:20am (CST) |

把实验用的ubuntu:trusty版本import到本地。这个国内访问速度极慢,我弄了一个周末才成功,而且没有提示,参见#833。看上去他们会很快解决。(小技巧:有问题,要提交issue,这才是开源的力量)

root@lxd:~# lxd-images import lxc ubuntu trusty amd64 --alias ubuntu
Downloading the GPG key for https://images.linuxcontainers.org
Downloading the image list for https://images.linuxcontainers.org
Validating the GPG signature of /tmp/tmp7cwp4e4u/index.json.asc
Downloading the image: https://images.linuxcontainers.org/images/ubuntu/trusty/amd64/default/20150619_19:15/lxd.tar.xz
Validating the GPG signature of /tmp/tmp7cwp4e4u/ubuntu-trusty-amd64-default-20150619_19:15.tar.xz.asc
Image imported as: 04aac4257341478b49c25d22cea8a6ce0489dc6c42d835367945e7596368a37f
Setup alias: ubuntu

你也可以多下载几个,然后看看结果。

root@lxd:~# lxc image list
+--------------+--------------+--------+-----------------------+--------+------------------------------+
|    ALIAS     | FINGERPRINT  | PUBLIC |      DESCRIPTION      |  ARCH  |         UPLOAD DATE          |
+--------------+--------------+--------+-----------------------+--------+------------------------------+
| ubuntu       | 04aac4257341 | no     |                       | x86_64 | Jul 11, 2015 at 4:31pm (CST) |
| ubuntu-32    | 230c0c42fa5a | no     | Ubuntu trusty (i386)  | i686   | Jul 10, 2015 at 9:44am (CST) |
| jessie-amd64 | f86a94578985 | no     | Debian jessie (amd64) | x86_64 | Jul 10, 2015 at 9:45am (CST) |
+--------------+--------------+--------+-----------------------+--------+------------------------------+

然后是启动lxc launch,取别名ub

root@lxd:~# lxc launch ubuntu ub
Creating container...done
Starting container...done
root@lxd:~# lxc list
+---------------+---------+------------+------+-----------+
|     NAME      |  STATE  |    IPV4    | IPV6 | EPHEMERAL |
+---------------+---------+------------+------+-----------+
| ub            | RUNNING | 10.0.3.221 |      | NO        |
+---------------+---------+------------+------+-----------+

运行lxc exec

root@lxd:~# lxc exec ub /bin/bash
root@ub:~# uname -a
Linux ub 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux   

简单分析

现在我们简单分析一下lxd和docker的相同点和区别。这只是初步的,关于更深层次的分析,可以查其他的资料。

都是linux容器

首先他们都是基于linux容器的技术,所以在容器中看到的内核都是服务器的3.19.0-15-generic #15-Ubuntu SMP

root@lxd:~# uname -a
Linux lxd 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@lxd:~# lxc exec ub /bin/bash
root@ub:~# uname -a
Linux ub 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux   

启动模式

启动模式,这是最大区别,docker启动后,里面看到就是一个process

docker@boot2docker:~$ docker run -it ubuntu bash
root@4a08576d739b:/# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:24 ?        00:00:00 bash
root        15     1  0 09:25 ?        00:00:00 ps -ef

而在lxd中,他是一个比较完整的系统,这是他叫基于Linux容器的Hypervisor的原因。LXD是想和KVM PK的。

root@ub:~# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 01:45 ?        00:00:14 /sbin/init
root       539     1  0 01:46 ?        00:00:01 upstart-udev-bridge --daemon
root       615     1  0 01:46 ?        00:00:00 /lib/systemd/systemd-udevd --daemon
root       796     1  0 01:46 ?        00:00:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
syslog     866     1  0 01:46 ?        00:00:00 rsyslogd
root      1046     1  0 01:46 ?        00:00:00 cron
root      1110     1  0 01:46 console  00:00:00 /sbin/getty -8 38400 console
root      1209     1  0 01:46 ?        00:00:01 upstart-socket-bridge --daemon
root      1210     1  0 01:46 ?        00:00:01 upstart-file-bridge --daemon
root      2397     0  0 01:57 ?        00:00:00 /bin/bash
root      7210     0  0 02:17 ?        00:00:00 /bin/bash
root      9515     1  0 02:50 ?        00:00:00 /sbin/getty -8 38400 tty4
root      9517     1  0 02:50 ?        00:00:00 /sbin/getty -8 38400 tty2
root      9518     1  0 02:50 ?        00:00:00 /sbin/getty -8 38400 tty3
root      9519     1  0 02:50 ?        00:00:00 /sbin/getty -8 38400 tty1
root      9527  7210  0 02:50 ?        00:00:00 ps -ef

程序运行

那如果在容器里运行程序会怎么样呢。

lxd中:

root@lxd:~# lxc exec ub bash
root@ub:~# sleep 100
root@lxd:~# ps -ef | grep sleep
100000    3580  3544  0 12:27 pts/12   00:00:00 sleep 100

docker中:

docker@boot2docker:~$ docker run -it ubuntu bash
root@2fbd16a0b1ad:/# sleep 100
docker@boot2docker:~$ ps -ef | grep sleep
root     25621 25603  0 11:06 pts/5    00:00:00 sleep 100

在容器外面服务器上,都能看到这个运行的进程。

总结

通过几个简单的实验,可以看出LXD是在一个基于container的Linux容器虚拟机,结合了linux容器和虚拟机的优点,目标是云里替换KVM虚拟机。因此他还有一个openstack的组件nova-compute-lxd

我对底层技术不在行,这里只是搭了个环境,理解一下他的简单区别。希望有高手有进一步分析。

LXD一再强调他自己是系统级的container,docker/CoreOS是业务层的App container,两者互补,并不冲突。不过docker和CoreOS像是并不买它的账,毕竟没有这一层,容器也可以运行的很好。

技术就是这样,不是你说好就是好。

碰到的问题

中间还碰到了各种问题

root@lxd:~# lxc launch lxc-org:/ubuntu/trusty/i386 ubuntu-32
Creating container...

这个就一直停在这儿,估计就是网速慢的原因,后来我用lxd-images import命令,问题看得清楚一些。

root@lxd:~# lxc image copy lxc-org:/ubuntu/trusty/amd64 local: --alias=ubuntu-64

这儿网速慢时,会返回下面各种不同的错,反正我也用lxd-images import命令替换,功能都一样。

error: UNIQUE constraint failed: images.fingerprint
error: Post http://unix.socket/1.0/images: unexpected EOF
Temporary failure in name resolution
error: Get https://images.linuxcontainers.org:8443/1.0: read tcp 192.99.34.219:8443: connection reset by peer

参考

下面是我做实验时用到的一下资料。

  • https://github.com/lxc/lxd
  • http://www.ubuntu.com/cloud/tools/lxd
  • https://insights.ubuntu.com/2015/04/28/getting-started-with-lxd-the-container-lightervisor/
  • https://insights.ubuntu.com/2015/06/30/publishing-lxd-images/
  • http://blog.scottlowe.org/2015/05/06/quick-intro-lxd/
  • https://github.com/lxc/lxd/issues/756
  • https://images.linuxcontainers.org/images
  • https://github.com/lxc/lxd/issues/833
  • https://github.com/lxc/lxd/issues/832
  • https://github.com/lxc/lxd/blob/master/scripts/lxd-images
View Comments
09 Jul 2015

在Ustack公有云上体验Hyper-一个基于Hypervisor的容器化解决方案

介绍

现在Docker和容器如日中天,大家都在谈论,这些都是基于LXC的。前一阵子在微博上,马全一讲国内容器相关的的技术流创业项目时,提到了Hyper,兴趣大增。

先阅读了InfoQ的文章Hyper是一个基于Hypervisor的容器化解决方案,还有官方网站http://hyper.sh,都不是特别理解如何在虚拟机上启动docker(是不是笨了好多)和它的效果。

趁上次UnitedStack公有云上给的学习券(coupon)还没用光,决定在公有云上试一试。 (是不是这篇博客又可以给我的coupon呢,哈哈)

这篇博客就是介绍如何在ustack上体验一下Hyper的效果来加深理解,相信你自己用物理机或虚机也是一样的(用公有云省去安装和proxy的问题)。

安装

实际上Hyper的安装,官方文档写得挺详细了,只是他是英文,也没针对哪个版本,这里就更详细些。

在ustack上选择Ubuntu 15.04,最小配置,连上公网IP,ssh登陆,一气呵成。

现在就可以安装了,需要docker,qemu-KVM包。 Ubuntu15.04中可以装docker1.5版本,如果需要最新的加个PPA源。

apt-get update                             # 缺省是国外apt源,有点慢
apt-get install docker.io                  # docker包是docker.io
service docker start                       # hyper安装需要docker服务
apt-get install qemu-kvm
curl -sSL https://hyper.sh/install | bash  # 见文档,这是直接装hyper二进制包

运行

看上去好了,试试吧。国外的网站,下docker镜像(image)比较慢,幸好不到,有空可以把他转到国内的docker镜像源(registry mirror)。

root@hyper1:~# docker pull ubuntu:latest  # 加latest,否则下一坨,
root@hyper1:~# hyper run ubuntu
POD id is pod-EljQlbnRAP
root@ubuntu-5747385737:/# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty

hyper启动Ubuntu容器(hyper run ubuntu)的速度比docker稍微有点慢,但是还是飞快,感觉也是一个完整的Ubuntu环境。

退出后,试一下hyper list命令

root@hyper1:~# hyper list
         POD ID                      POD Name             VM name    Status
 pod-EljQlbnRAP             ubuntu-5747385737                     succeeded

Bingo,就这么简单。和网站上的效果一样,但是为啥是虚拟机上的容器呢?

再看看

既然是虚机上的容器,那么底下的linux kernel应该不同。

root@hyper1:~# uname -a
Linux hyper1 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
root@hyper1:~# docker run ubuntu uname -a
Linux b1f5523cb694 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

docker运行的容器和主机的linux kernel是一样的3.19.0-15-generic #15-Ubuntu SMP,再来看看hyper:

root@hyper1:~# hyper run ubuntu uname -a
POD id is pod-ErbgsvxAjz
Linux ubuntu-8938030742 4.0.4-hyper #16 SMP Fri Jun 19 10:02:22 CST 2015 x86_64 x86_64 x86_64 GNU/Linux

hyper的kernel是4.0.4-hyper #16 SMP,是在自己的虚拟核上。

再来看看qemu吧,启动ubuntu容器hyper run ubuntu,然后在另一个shell中查看qemu,果然多了一个qemu虚拟机的进程。

root@hyper1:~# ps -ef | grep qemu
root       526     1  0 09:05 ?        00:00:00 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0
root     13642     1 14 09:52 ?        00:00:04 qemu-system-x86_64 -machine pc-i440fx-2.0,usb=off -cpu core2duo -drive if=pflash,file=/var/lib/hyper/bios-qboot.bin,readonly=on -dri
ve if=pflash,file=/var/lib/hyper/cbfs-qboot.rom,readonly=on -realtime mlock=off -no-user-config -nodefaults -no-hpet -rtc base=utc,driftfix=slew -no-reboot -display none -boot stri
ct=on -m 128 -smp 1 -qmp unix:/var/run/hyper/vm-pfbFabRstw/qmp.sock,server,nowait -serial unix:/var/run/hyper/vm-pfbFabRstw/console.sock,server,nowait -device virtio-serial-pci,id=
virtio-serial0,bus=pci.0,addr=0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 -chardev socket,id=charch0,path=/var/run/hyper/vm-pfbFabRstw/hyper.sock,server,nowait -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charch0,id=channel0,name=sh.hyper.channel.0 -chardev socket,id=charch1,path=/var/run/hyper/vm-pfbFabRstw/tty.sock,server,nowait -de
vice virtserialport,bus=virtio-serial0.0,nr=2,chardev=charch1,id=channel1,name=sh.hyper.channel.1 -fsdev local,id=virtio9p,path=/var/run/hyper/vm-pfbFabRstw/share_dir,security_mode
l=none -device virtio-9p-pci,fsdev=virtio9p,mount_tag=share_dir

里面具体的你可以自己研究研究吧。

总结

实验做完后,和作者王旭 @gnawux在微博上又聊了几句,再回去看看infoq的那篇文章就明白多了(当然还是皮毛)。

Hyper是一个基于Hypervisor的容器化解决方案,非常有新意,VMWare也跟着推出了相类似的Bonneville项目,这块可能会有很到的市场。特别是大部分用户已经有了成熟的虚拟化基础架构,他们可能更倾向于这种基于虚拟机的方案。

容器技术还需不断磨合,Hyper现在也还只是0.2.1版本 (2015-07-06),假以时日,或许他能成为容器中的一颗明珠。

来吧,加入Hyper的社区,一起来点好点子吧。

参考

  • http://www.infoq.com/cn/news/2015/06/Hyper-Hypervisor-Docker
  • http://hyper.sh
View Comments

联系方式

其他博客