b*******s
发帖数: 5216 | 1 对推动linux占据更大服务器市场份额绝对是大大有利
非常聪明的设计，不是简单堆资源 |
l*********s
发帖数: 5409 | |
i**i
发帖数: 1500 | 3 a jar of classes,
a docker of jars,
a ??? of dockers. （时间是把杀猪刀．当docker上面蒙上一层灰的时候，麻烦会有的
．）
【在 b*******s 的大作中提到】
: 对推动linux占据更大服务器市场份额绝对是大大有利
: 非常聪明的设计，不是简单堆资源
|
P****i
发帖数: 12972 | 4 a VM of dockers
【在 i**i 的大作中提到】
: a jar of classes,
: a docker of jars,
: a ??? of dockers. （时间是把杀猪刀．当docker上面蒙上一层灰的时候，麻烦会有的
: ．）
|
d****i
发帖数: 4809 | 5 没那么夸张吧，Linux下和其他OS都早就有类似的container的实现了，docker只不过是
一个狗狗用Go来实现的例子而已：
http://en.wikipedia.org/wiki/Operating_system%E2%80%93level_vir
【在 b*******s 的大作中提到】
: 对推动linux占据更大服务器市场份额绝对是大大有利
: 非常聪明的设计，不是简单堆资源
|
c*****e
发帖数: 3226 | 6 跟狗狗有个毛关系。完全是外面开源的。
【在 d****i 的大作中提到】
: 没那么夸张吧，Linux下和其他OS都早就有类似的container的实现了，docker只不过是
: 一个狗狗用Go来实现的例子而已：
: http://en.wikipedia.org/wiki/Operating_system%E2%80%93level_vir
|
d****i
发帖数: 4809 | 7 开源不开源无所谓，反正狗狗要支持一下Go的作品吧，要是连狗狗自己都不支持，还能
指望别人支持？
【在 c*****e 的大作中提到】
: 跟狗狗有个毛关系。完全是外面开源的。
|
M****z
发帖数: 1058 | |
c*******0
发帖数: 5247 | 9
Docker的火和Google支持一点关系都没有，Google官方的支持也就是几个星期前而已。
如果你不理解为什么Docker火是因为你不了解Docker，那建议还是先去看看，试用一下
为好，不要什么事情都是阴谋论。
【在 d****i 的大作中提到】
: 开源不开源无所谓，反正狗狗要支持一下Go的作品吧，要是连狗狗自己都不支持，还能
: 指望别人支持？
|
c******o
发帖数: 1277 | 10 docker很好，但是里game changer 还差得远。 很多东西还是要old chef/puppet/salt
/ansible, docker 只是一种light image 而已。 |
|
|
P****i
发帖数: 12972 | 11 同意
salt
【在 c******o 的大作中提到】
: docker很好，但是里game changer 还差得远。 很多东西还是要old chef/puppet/salt
: /ansible, docker 只是一种light image 而已。
|
c*****e
发帖数: 3226 | 12 任何技术的进化都不可能源于真空。
salt
【在 c******o 的大作中提到】
: docker很好，但是里game changer 还差得远。 很多东西还是要old chef/puppet/salt
: /ansible, docker 只是一种light image 而已。
|
c******o
发帖数: 1277 | 13 不是 “源于真空” 的问题，这两类技术根本就不是寻求解决同一类问题。 |
b*******s
发帖数: 5216 | 14 主要影响不仅仅是admin工具
Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，接
近原生的性能，还一下子把大量现有资源都跨distro利用起来了
另外是效率，原先跑几个vm的资源现在看上去能跑高一两个数量级的有用的东西，硬件
虽然便宜得很了，但是能再省个七成八成还是很可观的一笔钱
最近在做的一个东西看上去用这个很合适
对于开发方法影响也很大，有时就是好用那么一点，区别就会很大
salt
【在 c******o 的大作中提到】
: docker很好，但是里game changer 还差得远。 很多东西还是要old chef/puppet/salt
: /ansible, docker 只是一种light image 而已。
|
N******K
发帖数: 10202 | 15 jvm要进垃圾箱了？
【在 b*******s 的大作中提到】
: 主要影响不仅仅是admin工具
: Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，接
: 近原生的性能，还一下子把大量现有资源都跨distro利用起来了
: 另外是效率，原先跑几个vm的资源现在看上去能跑高一两个数量级的有用的东西，硬件
: 虽然便宜得很了，但是能再省个七成八成还是很可观的一笔钱
: 最近在做的一个东西看上去用这个很合适
: 对于开发方法影响也很大，有时就是好用那么一点，区别就会很大
:
: salt
|
b*******s
发帖数: 5216 | 16 不会，只是多一种选择了，而且是大家都喜欢的轻量级方案，估计用户会有爆发式增长
【在 N******K 的大作中提到】
: jvm要进垃圾箱了？
|
b*******s
发帖数: 5216 | 17 我的感觉是，一下子挖出了现有Linux生态的很多潜力，以后包管理等方式可能都要变
化了 |
b*******s
发帖数: 5216 | 18 还有就是paas,docker是从单机到平台的全面的轻量级解决 |
c*****e
发帖数: 3226 | 19 但是是相互辅助的
【在 c******o 的大作中提到】
: 不是 “源于真空” 的问题，这两类技术根本就不是寻求解决同一类问题。
|
d*******r
发帖数: 3299 | 20 "主要影响不仅仅是admin工具
Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，
接近原生的性能，还一下子把大量现有资源都跨 distro 利用起来了"
这个能做到很牛了吧，Linux 跨 distribution 配置 app 那些碎片化问题，不要太烦，
这个真能做到的话，就是针对每一个 app，docker 都有一套自己的跨 distribution
的配置？
docker community 维护这些 app cfg 工作量不小吧，靠谱吗？
我知道 chef / ansible 啥的，也有自己的一堆 cookbook / playbook 啥的，但是感
觉，针对大多数 app, 都有一套可靠的，跨 Linux distribution 的 cookbook /
playbook, 是不可能的。
【在 b*******s 的大作中提到】
: 主要影响不仅仅是admin工具
: Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，接
: 近原生的性能，还一下子把大量现有资源都跨distro利用起来了
: 另外是效率，原先跑几个vm的资源现在看上去能跑高一两个数量级的有用的东西，硬件
: 虽然便宜得很了，但是能再省个七成八成还是很可观的一笔钱
: 最近在做的一个东西看上去用这个很合适
: 对于开发方法影响也很大，有时就是好用那么一点，区别就会很大
:
: salt
|
|
|
b*******s
发帖数: 5216 | 21 我实验了几个repo，很齐全，不是docker维护的，是各个distro自己维护的
烦，
【在 d*******r 的大作中提到】
: "主要影响不仅仅是admin工具
: Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，
: 接近原生的性能，还一下子把大量现有资源都跨 distro 利用起来了"
: 这个能做到很牛了吧，Linux 跨 distribution 配置 app 那些碎片化问题，不要太烦，
: 这个真能做到的话，就是针对每一个 app，docker 都有一套自己的跨 distribution
: 的配置？
: docker community 维护这些 app cfg 工作量不小吧，靠谱吗？
: 我知道 chef / ansible 啥的，也有自己的一堆 cookbook / playbook 啥的，但是感
: 觉，针对大多数 app, 都有一套可靠的，跨 Linux distribution 的 cookbook /
: playbook, 是不可能的。
|
b*******s
发帖数: 5216 | 22 docker的工作模式简单说一下
先有各个distro提供的image，大概一两百兆大小的样子，比如ubuntu 14.04的image
你需要那个就pull哪个，不用不付出代价
然后你把你的程序以及依赖添加到image里面，可以存成你自己的image
但实际上存的只是你新增的部分，在image里面各种包管理器照样用，和你用linux没区别
如果你在开发阶段能保证你加入的部分能在先导的某个image上工作
那每次你加的都只是一个增量，不存在你说的为每个程序维护基础设施的问题
只要你的开发系统能跑的程序，就能放到你的host上跑，所谓代价不过是/etc下一个文
件而已
和普通linux程序的一样简单
也就是说，比如netstat可以在ubuntu上跑，那distro会负责能在原始image上跑
也就肯定能在你的host上跑，多简单！
而你可以基于一个image做几百上千个不同的images，如果说原始大小的可能200兆
做上千个搞不好也总共就300兆的样子
他们可以都只有很小的尺寸，而依赖关系你可以自己定义，比如程序a,b都依赖c
你可以先做c，然后在此之上做a和b
都是docker的文件系统把各个layer最终合成一个完整的大的运行很多东西的系统
因为container运行时是一个process加了个壳，所以overhead不大
烦，
【在 d*******r 的大作中提到】
: "主要影响不仅仅是admin工具
: Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，
: 接近原生的性能，还一下子把大量现有资源都跨 distro 利用起来了"
: 这个能做到很牛了吧，Linux 跨 distribution 配置 app 那些碎片化问题，不要太烦，
: 这个真能做到的话，就是针对每一个 app，docker 都有一套自己的跨 distribution
: 的配置？
: docker community 维护这些 app cfg 工作量不小吧，靠谱吗？
: 我知道 chef / ansible 啥的，也有自己的一堆 cookbook / playbook 啥的，但是感
: 觉，针对大多数 app, 都有一套可靠的，跨 Linux distribution 的 cookbook /
: playbook, 是不可能的。
|
d*******r
发帖数: 3299 | 23 赞经验分享！
另外，你说的 “我实验了几个repo，很齐全，不是docker维护的，是各个distro自己
维护的”
看起来 make sense, 那就是说这些 Linux distro maintainer 跟 docker 合作很好了？
为啥 chef/ansible 没这待遇呢？或者说，因为 chef/ansible 更偏向 system states
的改变，docker 更偏向于更简单的抽象: system images, 所以 distro maintainer
和 docker 更容易合作?
我看着，觉得直接用 docker without chef/ansible, 貌似更简单可靠一些。
区别
【在 b*******s 的大作中提到】
: docker的工作模式简单说一下
: 先有各个distro提供的image，大概一两百兆大小的样子，比如ubuntu 14.04的image
: 你需要那个就pull哪个，不用不付出代价
: 然后你把你的程序以及依赖添加到image里面，可以存成你自己的image
: 但实际上存的只是你新增的部分，在image里面各种包管理器照样用，和你用linux没区别
: 如果你在开发阶段能保证你加入的部分能在先导的某个image上工作
: 那每次你加的都只是一个增量，不存在你说的为每个程序维护基础设施的问题
: 只要你的开发系统能跑的程序，就能放到你的host上跑，所谓代价不过是/etc下一个文
: 件而已
: 和普通linux程序的一样简单
|
b*******s
发帖数: 5216 | 24 是啊，让人舒服自己舒服嘛
直接用docker就够好了，管理界面也超简单，感觉就跟用git似的
了？
states
maintainer
【在 d*******r 的大作中提到】
: 赞经验分享！
: 另外，你说的 “我实验了几个repo，很齐全，不是docker维护的，是各个distro自己
: 维护的”
: 看起来 make sense, 那就是说这些 Linux distro maintainer 跟 docker 合作很好了？
: 为啥 chef/ansible 没这待遇呢？或者说，因为 chef/ansible 更偏向 system states
: 的改变，docker 更偏向于更简单的抽象: system images, 所以 distro maintainer
: 和 docker 更容易合作?
: 我看着，觉得直接用 docker without chef/ansible, 貌似更简单可靠一些。
:
: 区别
|
N******K
发帖数: 10202 | 25 增量式添加 会不越加垃圾越多？
区别
【在 b*******s 的大作中提到】
: docker的工作模式简单说一下
: 先有各个distro提供的image，大概一两百兆大小的样子，比如ubuntu 14.04的image
: 你需要那个就pull哪个，不用不付出代价
: 然后你把你的程序以及依赖添加到image里面，可以存成你自己的image
: 但实际上存的只是你新增的部分，在image里面各种包管理器照样用，和你用linux没区别
: 如果你在开发阶段能保证你加入的部分能在先导的某个image上工作
: 那每次你加的都只是一个增量，不存在你说的为每个程序维护基础设施的问题
: 只要你的开发系统能跑的程序，就能放到你的host上跑，所谓代价不过是/etc下一个文
: 件而已
: 和普通linux程序的一样简单
|
c******o
发帖数: 1277 | 26 所以没法是game changer, 我在好多dev ops地方还是只能用chef
【在 c*****e 的大作中提到】
: 但是是相互辅助的
|
m********5
发帖数: 17667 | 27 可惜啊，我们IT啃次啃次换XFS
一天到晚骂docker, LoL
区别
【在 b*******s 的大作中提到】
: docker的工作模式简单说一下
: 先有各个distro提供的image，大概一两百兆大小的样子，比如ubuntu 14.04的image
: 你需要那个就pull哪个，不用不付出代价
: 然后你把你的程序以及依赖添加到image里面，可以存成你自己的image
: 但实际上存的只是你新增的部分，在image里面各种包管理器照样用，和你用linux没区别
: 如果你在开发阶段能保证你加入的部分能在先导的某个image上工作
: 那每次你加的都只是一个增量，不存在你说的为每个程序维护基础设施的问题
: 只要你的开发系统能跑的程序，就能放到你的host上跑，所谓代价不过是/etc下一个文
: 件而已
: 和普通linux程序的一样简单
|
n****1
发帖数: 1136 | 28 Chef: mutating image files in a more structured and manageable way
Docker: image are just immutable, just creat a new copy.
To me, these two have fundamentally different mentality, kinda of similar to
the disagreement over mutability of variables between OOP and FP.
I'm can not say docker's way is strictly superior than the other, because
Chef is apparently much more mature, and is available on Mac OS/Win. The
bottom line is that they are mutually incompatible: if docker images are
immutable, what is the point to mutating them using Chef?
Below is an interesting blog on docker&chef, a lot of comments are also
interesting, both for and againt Chef:
http://blog.relateiq.com/why-docker-why-not-chef/
Edit: You can still use Chef to provision bare metal O/S and ship
applications with docker (and there’s cookbooks, e.g.: https://github.com/
bflad/chef-docker).
【在 c******o 的大作中提到】
: 所以没法是game changer, 我在好多dev ops地方还是只能用chef
|
h**********0
发帖数: 88 | 29
lmctfy应该就是google自己的"docker"
http://en.wikipedia.org/wiki/Lmctfy
没明白docker跟纯lxc然后自己加自己想要的有什么区别。。。
【在 d****i 的大作中提到】
: 开源不开源无所谓，反正狗狗要支持一下Go的作品吧，要是连狗狗自己都不支持，还能
: 指望别人支持？
|
c******o
发帖数: 1277 | 30 So I have a mongodb server cluster, now I want to upgrade newrelic agent on
them.
Use docker, I have to redeploy, restart, and need maintenance time.
With chef/puppet, I just push the change and it will be done in next chef
run. no down time for production.
Right, "The bottom line is that they are mutually incompatible". So in dev
ops area, docker is not game changer, as it only cover part of the things we
want to do, it does not change the game..
In fact use docker with Chef is great in the same sense as use AMI with Chef.
to
【在 n****1 的大作中提到】
: Chef: mutating image files in a more structured and manageable way
: Docker: image are just immutable, just creat a new copy.
: To me, these two have fundamentally different mentality, kinda of similar to
: the disagreement over mutability of variables between OOP and FP.
: I'm can not say docker's way is strictly superior than the other, because
: Chef is apparently much more mature, and is available on Mac OS/Win. The
: bottom line is that they are mutually incompatible: if docker images are
: immutable, what is the point to mutating them using Chef?
: Below is an interesting blog on docker&chef, a lot of comments are also
: interesting, both for and againt Chef:
|
|
|
c*****e
发帖数: 3226 | 31 还纠结啊， 举个例子， 如果 你的 mongo use library xyz version 1.0, 你的
application service uses libxyz version 2.0 你怎么办？
in docker, you release app+ app running environment.
with docker, you 也可以在 docker 内部自己程序更新， 也可以更新整个 docker
image. 完全取决于你。
on
we
Chef.
【在 c******o 的大作中提到】
: So I have a mongodb server cluster, now I want to upgrade newrelic agent on
: them.
: Use docker, I have to redeploy, restart, and need maintenance time.
: With chef/puppet, I just push the change and it will be done in next chef
: run. no down time for production.
: Right, "The bottom line is that they are mutually incompatible". So in dev
: ops area, docker is not game changer, as it only cover part of the things we
: want to do, it does not change the game..
: In fact use docker with Chef is great in the same sense as use AMI with Chef.
:
|
c*******0
发帖数: 5247 | 32
烦，
哥们，你问docker的问题也不少了，花的时间自己玩一下Docker都玩熟了。
去http://blog.docker.com/看看吧。我不是发过Docker上手教程么。我保证一天就入门。
上次你一直问的log的问题不想回答就是因为想让你上手看看，你用一下很多问题就没
了。Docker的log是可重定向到host上的log系统的。
【在 d*******r 的大作中提到】
: "主要影响不仅仅是admin工具
: Linux的碎片化解决得不错，不需要jvm那个笨拙的东西来实现一次编译到处运行了，
: 接近原生的性能，还一下子把大量现有资源都跨 distro 利用起来了"
: 这个能做到很牛了吧，Linux 跨 distribution 配置 app 那些碎片化问题，不要太烦，
: 这个真能做到的话，就是针对每一个 app，docker 都有一套自己的跨 distribution
: 的配置？
: docker community 维护这些 app cfg 工作量不小吧，靠谱吗？
: 我知道 chef / ansible 啥的，也有自己的一堆 cookbook / playbook 啥的，但是感
: 觉，针对大多数 app, 都有一套可靠的，跨 Linux distribution 的 cookbook /
: playbook, 是不可能的。
|
c*******0
发帖数: 5247 | 33
on
we
Chef.
Docker在某些case下可以脱离任何现有部署工具，在某些case下和Chef/puppet这些工
具配合非常好，这完全就是othorgonal的，真不知道你在argue什么。
看你的描述，你根本就没明白Docker解决的是什么问题。说Docker game changer，不
是说Docker解决了所有devops的问题。是他解决了某个非常大的devops的问题，然后基
于此衍生出了一整个生态系统。
过几天等dockercon的视频发出之后，你可以去看看，到底别人是怎么用docker的。
【在 c******o 的大作中提到】
: So I have a mongodb server cluster, now I want to upgrade newrelic agent on
: them.
: Use docker, I have to redeploy, restart, and need maintenance time.
: With chef/puppet, I just push the change and it will be done in next chef
: run. no down time for production.
: Right, "The bottom line is that they are mutually incompatible". So in dev
: ops area, docker is not game changer, as it only cover part of the things we
: want to do, it does not change the game..
: In fact use docker with Chef is great in the same sense as use AMI with Chef.
:
|
d*******r
发帖数: 3299 | 34 这不想先多知道点，省点劲吗，加班回来就花几分钟灌个水，
要自己搞的话，得周末划出整块时间来搞吧，我干事情还是挺认真的，就是先看看跳这
个坑不.
【在 c*******0 的大作中提到】
:
: on
: we
: Chef.
: Docker在某些case下可以脱离任何现有部署工具，在某些case下和Chef/puppet这些工
: 具配合非常好，这完全就是othorgonal的，真不知道你在argue什么。
: 看你的描述，你根本就没明白Docker解决的是什么问题。说Docker game changer，不
: 是说Docker解决了所有devops的问题。是他解决了某个非常大的devops的问题，然后基
: 于此衍生出了一整个生态系统。
: 过几天等dockercon的视频发出之后，你可以去看看，到底别人是怎么用docker的。
|
c*****e
发帖数: 3226 | 35 for docker, 推荐的方式是把数据放在 mounted directory 上， 这样换 image 不影
响数据。
【在 c*******0 的大作中提到】
:
: on
: we
: Chef.
: Docker在某些case下可以脱离任何现有部署工具，在某些case下和Chef/puppet这些工
: 具配合非常好，这完全就是othorgonal的，真不知道你在argue什么。
: 看你的描述，你根本就没明白Docker解决的是什么问题。说Docker game changer，不
: 是说Docker解决了所有devops的问题。是他解决了某个非常大的devops的问题，然后基
: 于此衍生出了一整个生态系统。
: 过几天等dockercon的视频发出之后，你可以去看看，到底别人是怎么用docker的。
|
c*******0
发帖数: 5247 | 36
我记得他的问题是想把不同container的log放在一起统一管理，这个和数据没关系
【在 c*****e 的大作中提到】
: for docker, 推荐的方式是把数据放在 mounted directory 上， 这样换 image 不影
: 响数据。
|
c*****e
发帖数: 3226 | 37 每个 container 在 mounted directory 下建一个子目录不就可以么？
【在 c*******0 的大作中提到】
:
: 我记得他的问题是想把不同container的log放在一起统一管理，这个和数据没关系
|
c*******0
发帖数: 5247 | 38
你是说mount一个volume是吧？那就是和我说的一样。
我意思就是他很多问题其实玩半天就明白了，在论坛上问几天也不见得有人回答。
【在 c*****e 的大作中提到】
: 每个 container 在 mounted directory 下建一个子目录不就可以么？
|
f*****e
发帖数: 57 | 39 Even I am a believer in docker, I am with you on this one. We are back to
FP vs. OOP, on the topic whether immutability is good for everything.
We have this issue even before docker. My first approach is to bake
everything into a mongodb AMI(just like a docker container, but heavyweight)
, and put this AMI to an autoscaling group. Great idea: now my mongodb
cluster can autoscaling according to the load. Then I met the same problem
old cluster and create a new one. Unnecessary downtime, so this approach
is shot down.
Our current approach is using the basic AMI for asg, then provision the
instance as they are launched by asg. But this approach is not suitable for
docker, as it promote immutability. After you launch a container, you
shouldn't change the state of it, just like FP.
Back to your case. With docker, a new relic agent update would be like a
mongodb version update in a non-docker environment, you need to update the
slaves first, turn off master, wait for the newly elected master, then
update the old master to be a slave.
It's inconvenient, and harder than just updating the instances. But I think
it is just like the price you need to pay for immutability in FP.
on
we
Chef. |
c******o
发帖数: 1277 | 40 你还没搞懂，docker对这个无能为力。
因为我要no downtime.
【在 c*****e 的大作中提到】
: 还纠结啊， 举个例子， 如果 你的 mongo use library xyz version 1.0, 你的
: application service uses libxyz version 2.0 你怎么办？
: in docker, you release app+ app running environment.
: with docker, you 也可以在 docker 内部自己程序更新， 也可以更新整个 docker
: image. 完全取决于你。
:
: on
: we
: Chef.
|
|
|
N*****m
发帖数: 42603 | 41 是的
真正的solution是在docker装chef/puppet client，每个app一个isolated docker ima
ge。
【在 c******o 的大作中提到】
: 你还没搞懂，docker对这个无能为力。
: 因为我要no downtime.
|
c******o
发帖数: 1277 | 42 我就是说这个不是game changer. 我当然在某些方面打算用docker，像app server的
deployment.
但是我最头疼的东西上（db/resource maintenance/resource monitoring)，docker一
点用没有。
【在 c*******0 的大作中提到】
:
: 你是说mount一个volume是吧？那就是和我说的一样。
: 我意思就是他很多问题其实玩半天就明白了，在论坛上问几天也不见得有人回答。
|
c*****e
发帖数: 3226 | 43 你自己去看 coreos 怎么做的， 用的是 etcd, 别自己关门造轮子了。
【在 c******o 的大作中提到】
: 你还没搞懂，docker对这个无能为力。
: 因为我要no downtime.
|
N*****m
发帖数: 42603 | 44 etcd跟puppet/chef是一回事
【在 c*****e 的大作中提到】
: 你自己去看 coreos 怎么做的， 用的是 etcd, 别自己关门造轮子了。
|
c*******0
发帖数: 5247 | 45
我终于明白了，你的意思是Docker “对你的需求来说” 不是game changer。说清楚也
就没有什么争论了。
不过你的需求除了没有downtime外还有什么特殊的地方么？如果只是要没有downtime，
这个基于Docker的解决方案太多了。
【在 c******o 的大作中提到】
: 我就是说这个不是game changer. 我当然在某些方面打算用docker，像app server的
: deployment.
: 但是我最头疼的东西上（db/resource maintenance/resource monitoring)，docker一
: 点用没有。
|
d********u
发帖数: 5383 | 46 这种话我15年就在听了。
现在还是那个JB怂样。
【在 b*******s 的大作中提到】
: 我的感觉是，一下子挖出了现有Linux生态的很多潜力，以后包管理等方式可能都要变
: 化了
|
c******o
发帖数: 1277 | 47 我的需求有 app package/deployment, 这个现在是AMI, 可以用 docker
还有的事configuration/setup 的 continues maintenance/updating, 这个不是
docker 所擅长的，但是是 devops里很重要的一环 （绝对50% 以上）。我现在用chef,
可见未来也还是一样。。。
别的不说，设立一个mongodb的 sharded instance (13不同的 instance), 要在不同的
instance来回5+ 来回
，sync, wait, link, verify etc.
这些我们现在都是cloudformation/chef自动化，one click, all setup (包括各种周
边的monitoring/backup/restore/failover)
【在 c*******0 的大作中提到】
:
: 我终于明白了，你的意思是Docker “对你的需求来说” 不是game changer。说清楚也
: 就没有什么争论了。
: 不过你的需求除了没有downtime外还有什么特殊的地方么？如果只是要没有downtime，
: 这个基于Docker的解决方案太多了。
|
j********x
发帖数: 2330 | 48 G用linux container估计至少是5年前的事情了。。。
【在 d****i 的大作中提到】
: 开源不开源无所谓，反正狗狗要支持一下Go的作品吧，要是连狗狗自己都不支持，还能
: 指望别人支持？
|
c*****e
发帖数: 3226 | 49 g 家现在正热火朝天的上 docker
【在 j********x 的大作中提到】
: G用linux container估计至少是5年前的事情了。。。
|
M**A
发帖数: 78 | 50 今年7月的文章
Why Docker is Not Yet Succeeding Widely in Production
http://sirupsen.com/production-docker/ |
|
|
d*******r
发帖数: 3299 | 51 太啰嗦，谁给个 summary ?
【在 M**A 的大作中提到】
: 今年7月的文章
: Why Docker is Not Yet Succeeding Widely in Production
: http://sirupsen.com/production-docker/
|
