-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathpres
153 lines (130 loc) · 7.38 KB
/
pres
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
P1. 提纲
1. OCI来历
2. 什么是容器标准
3. OCT项目介绍
4. OCT未来计划
P2. OCI来历 - 过渡页
P3. 容器技术产业链
OS层 -- Container层 -- Orchestar stack -- 服务支持 -- 用户体验
（这里是未来说清楚后面的CoreOS - Docker之争）
前三层是产品，后两层是服务，一个是主要面向生产者的企业服务，一个是面向终端个人、企业用户的互联网服务。
这个是涉及到开源相关的商业模式了：产品卖不卖钱？ －－ 卖，但比较难。以ＳＵＳＥ和Redhat为例，虽然目前主要的
还是产品许可，但是开源本身决定了服务是关键。
目前将自己产品开源的创业公司都是在以产品抢用户，赢取为来的服务收入。
P4. 原先 CoreOS的势力范围、Docker的势力范围
这里面CoreOS的优势比较薄弱，依托于Docker获取了很多关注度。（在SUSE的时候讨论过CoreOS的特点）
如果CoreOS定位在OS层，那么赚不到钱。
所以CoreOS的优势在于Orchestar这层。
P5. 之后Docker的势力范围 ---》 进军Orchestar
成了导火索
P6. CoreOS不干了
Unix哲学， Docker定位懂不懂： docker是个产品啊，社区的朋友们，通吃之后很危险的你们知道吗。
1. APPC
2. rocket
P7. OCP --> OCI成立
APPC + Docker libcontainer-runc
P8. OCI介绍
愿景
制定标准
给出一个符合标准的实现
P9. 标准是什么 - 过渡页
P10. 标准是
基本要求： 满足基本的功能 - 准入门槛 （不是每一个牛奶都是特仑苏）
共同要求： 兼容性 - 限制勾心斗角
--- 争夺标准： 对水平不行的，搭上末班车；对垄断优势的，给后来者公平环境
--- 标准的好处：公平、良性竞争，最后拼硬实力。
所以，OCI里面也说了，标准对谁好，对有实力的人好。比如微软，WPS。
P11. 开源界标准举例
freedesktop
LSB
P12. 容器的标准
基本功能： APPC的四个标准。
兼容性： 这个要重点说说
P13. 不是什么
铁轨而不是火车
限制在容器这层，存储调度不管（是不是OCI宪法，会不会变）
P14. 争议话题
runc, 发展进度等等
P15. 标准的验证
给个猪肉合格的标记图片
---- 标准测试的项目
P16. OCT项目
P17. OCT定位
SPEC开始
能不能步子迈大一点
P18. 框架介绍
图
p19. TC server
P20. schedular
P21. test server
P22. hostOS上的测试客户端
p23. container pool ?
p24. 目前进展
运行良好，spec测试顺利，得到了OCI的鼓励和认可
P25. 过渡页 - 未来计划
P26. web化
build server图
方便很好的使用和推动OCI
P27. 项目社区化
github介绍
1.背景介绍
1.1 矛盾
关键事件 docker
UNIX哲学：把每件事做好
docker好 -- 技术层面
上层的生态环境 -- 商业层面了
社区VS公司
1.2 APPC标准成立
1.3 OCI成立
基金会 一页 现状： APPC标准+docker(runc)实现
OCI: 愿景
一步一步来
OCI：使命： SPEC标准
2. OCI在定义什么标准
2.1 标准是什么
配图， 插座 对用户：通用性，对企业：防止人为设置障碍
两个标准 http://blog.csdn.net/liuyifeng_510/article/details/6661563
目 前 Linux 的发行版非常繁多，为了促进 Linux 不同发行版间的兼容性，LSB（Linux Standards Base）开发了一系列标准，使各种软件可以很好地在兼容 LSB 标准的系统上运行，从而可以帮助软件供应商更好地在 Linux 系统上开发产品，或将已有的产品移植到 Linux 系统上。
两个 free standard
2.2 容器的标准是什么
为了促进不同容器产品的兼容，使得基于容器技术的应用可以很好的在符合OCI标准的容器产品里运行，从而可以帮助各个应用供应商更好地在容器上开发、部署产品，或将已有的应用移植到容器上。
什么是不同容器产品的兼容性？
由于目前市面上Docker一家独大，CoreOS家的rkt也是个半成品，所以这几乎是一个理论上的话题，实际的作用不明显。但未来如果有众多容器产品产生，或者是基于Docker, rkt的衍生产品产生（就会Linux发行版一样），容器兼容性的意义就很重要了。
先拿20多年的Linux操作系统举例子，很多软件产品供应商、运维商最头痛的地方是同样的配置在不同操作系统里面有不一样的表现。这种不一样的表现可能是不同系统的软件安装路径不一样，
可能是默认的配置不一样，或者是目录格式不一样。但这个问题不是单个操作系统发行商的问题，如果所有软件都部署在同一个发行版，那么这些系统兼容性导致的问题就不存在了。
DevOPS时代很多人偏好容器，认为容器可以屏蔽这些系统问题。但这个偏好有个前提：都采用Docker。如果未来有多种容器产品出现，或者基于Docker产品的不同衍生版出现，那么由于容器兼容性所带来的麻烦还是会存在。
因此OCI就是把这些扼杀在摇篮里面。所以，从开发者、用户角度来看，OCI还是功在当代利在千秋的。
2.3 标准举例
2.3.1 bundle
OCI定义了一个bundle
2.3.2 config
config里面描述了一个容器里面的关键配置和运行期参数。比如mount，比如process的环境变量等。
描述了容器运行前后的命令 ： 非常像 rpm打包。
2.4 标准不是什么
2.4.1 不限制实现
铁路而不是火车， 可以是高铁、可以使临客，这个拼各家的开发硬实力。
2.4.2 不限制容器的周边 ： 存储、发现、调度
—— 所以这里面给外圈的商业公司提供的差异化、进而带来额外收益的地方， 这个拼各家的市场、战略能力。
3. OCT - 标准实现的检查
3.1 诞生
OCI对标准的要求是这样的：实现在标准之前。这个有点夸张，但意思很简单：拒绝空中楼阁的的定义和纸上谈兵的讨论。
所以RunC的发展一直是和SPEC同步进行。那么同时，如何判断RunC或者以后声称如何OCI的容器是否符合标准呢。
这个就是OCT的来历： 需要一套基于容器、检查容器是否符合SPEC标准的测试框架。
openstack 标准
但是且慢，我们能不能步子迈的稍微大点，比如测试不同操作系统作为host、不同容器产品作为runtime是否满足基本的功能要求？
或者测试不同操作系统作为host、不同容器产品作为runtime是否有着比较好的性能。
所以最后我们的OCT的名字 open container testing
3.2 设计
3.2.1 框架
3.2.2 模块介绍
3.3 和OCI的交流
4. 未来计划
4.1 架构
web化
4.2 社区
更多开发者： OCT定位是一个开放的项目，尤其是在被OCI认可后， 目前的是一个原型，还需要不断壮大。
huawei-openlab属于一个huawei员工发起的社区组织， 类似于 openSUSE和SUSE的关系。
基于容器的测试框架算是比较新的概念，大家可以一起来开发和贡献。
更多使用者：
使用这个框架，部署于不同网络环境、不同云环境，双赢：利用框架可以适应各种复杂环境，也可以和运营团队一起来提高容器的部署能力和性能表现。
更多的批评者