基于Docker的DevOps实战培训
图片来自徐老师的PPT，为了记笔记方便，截下来了。
中国最大的DevOps社区平台：http://devopshub.cn
容器技术介绍
Overview
Docker的出现使得在一个企业中使用多种技术栈成为可能。运输系统就是围绕集装箱去构建的。
Docker工具就是码头工人，做了就是装卸集装箱的工作。
DockerHub是制做集装箱的工具。
把应用本身和运行环境整体打包，除了操作系统。可以描述内存、CPU用量、网络类型等等。
搬运也很简单。
Docker并不是容器技术，只是打包、运输等等的工具。
运行环境只是有developer最清楚，在Devops出现 前我们希望Ops的人能懂点开发，但是DevOps出现之后，Ops其实是对Dev的人发布了一个构建接口。即，为不同职能、技能的人各司其职提供了条件。
京东的案例，周二和周四上一些版本，上的东西不一样，周二会上一些大的东西，周四上一些促销。上线的时候需要一个资深的开发人员和运维人员一起上，没办法，有时候出现 问题的时候还是需要开发人员调代码。
可以把容器和虚拟机比较，但是不能把Docker和虚拟机比较。
只包含应用和应用的配置本身。
容器本身基于分层技术，对窗口镜像的存储做分层处理。之前 看过的UFS，联合文件系统。也就是说底层容器镜像可以只有一个。
Windows的基础镜像目前有个问题就是太大。
基于Docker的发布系统
代码库里存在应用的代码和依赖环境的配置。
最重要的三个组件：
- 代码库
- 容器镜像库
- Docker的运行主机（Deamon）
基础镜像（比如一些底层库，.netFX,C++runtime..）-》与应用打包
第一次push的时候可能需要传输基础镜像，再次push的时候就不需要了。
容器编排平台(微服务调度平台)
真正的云，是我有一万台服务器当牛在养，我不会给每头牛取个名字，它病了就杀了吃肉（回收资源）。不像养宠物（同单体应用架构）
微服务的出现并不是技术原因的推动，而是业务的原因逼迫系统变成这样。所以任何一个系统架构与业务的匹配性体现成熟度。让IT的系统和业务形成1对1的关系。这个也确实违反了传统软件设计的原则。有非常大的冗余。
第一级耦合，代码引用。用源码管理工作解决
第二级耦合，编译时包的引用。版本依赖
第三级别耦合：在生产环境耦合。各种接口版本都可以用。升级也不影响。IT系统的松耦合也代表所有业务系统的松耦合。这才是微服务出现的原因。
思考：我们是不是需要微服务架构？
解决了被不同平台，不同公有云厂商技术绑架的问题。
OS可以是Windows和Linux同时存在，比如各5台。
有了容器技术，虽然Dev的技术栈不会被绑架了，但是编排平台的技术还是会被绑架。
所以这四家竞争很激烈。
Windows容器技术
基于Docker的持续交付
向DevOps转型过程中，测试模型是最难转变的。
大大节省测试人员的时间。
适合大型企业的DevOps团队模型
横向三条线，
纵向分业务，按项目，针对业务部门有唯一的接口人。
技术栈：全局观，前瞻性。
项目线和技术栈是网状关系，没有固定的从属关系。
SM更多的是People manager，和自己的团队是1对1的。
上百人以上的组织 需要有工艺改进团队，对工艺改进的支撑，比如CI，Devops技术的引入，即研究院，研究组。
3种Coding Flow
Point3 ：受到代码门禁的控制。
在逻辑关系上，特性分支是主杆的分支，不可能成为主干，但fork有可能成为主干，同主干是对等的。
在超大型团队可能使用。
测试模型
上面的组织架构中没有测试团队，也就是专门的测试团队会消失，一个快速交付的团队要具备全部的能力，测试团队被放到业务开发团队中。
单元测试：程序开发人员执行
功能测试：测试人员执行
UAT测试：业务人员执行
强调单元测试
测试越接近用户层，可维护性越差。但是写单元测试有它的难度。
发布模型
基于Docker的DevOps工具链
