6大分类，17大有用的docker工具，你知道几个？

1，编排和调度程序

2，持续集成/持续部署（CI/CD）

Travis CI是一个免费的开源CI项目，通过自动构建和测试代码更改来提高开发的效率。软件即服务（Saas）平台随即能够对代码更改的成功与否提供即时反馈。Travis CI还能够通过管理部署和通知来自动化项目开发的其他部分。

工具链接：>Linux系统技术交流QQ群（1670392）验证问题答案：刘遄

Linux Kernel 的稳定分支维护者 Greg Kroah-Hartman 近日在其 个人博客 上谈及了关于稳定内核版本的选择。Kroah-Hartman 表示经常会有人咨询他们的产品/设备/笔记本电脑/服务器等应该使用哪个版本的稳定内核，但考虑到每个人的需求不同，各个版本的支持时间也有差异，所以答案并非固定。他试图用这篇文章来写下对此事的看法，以表达自己的观点。

Kroah-Hartman 列出了推荐使用的内核版本列表，从优至劣排序如下：

1选择使用自己喜欢的发行版所支持的内核

2最新的稳定版本

3最新的 LTS 版本

4还在维护的老 LTS 版本

Kroah-Hartman 解释称，对所有 Linux 用户来说，最明智的选择是使用自己喜欢的发行版中的内核。就个人而言，他更喜欢基于社区的 Linux 发行版，它们会不断推出最新的内核，并且会得到了社区的支持，不断打上补丁。这些发行版包括像是 Fedora、openSUSE、Arch、Gentoo、CoreOS 等。

最新的稳定版本则不用多说，大约每三个月，Linux 社区会发布一个新的稳定内核，其中包含所有最新的硬件支持，最新的性能改进，以及针对内核的最新 Bug 修正。

最新的 LTS 版本则相较更适合于一些嵌入式设备，无需担心每三个月发生一次“重大”升级。缺点是无法及时获得新内核中出现的性能改进，除非更新到下一个 LTS 版本。

一些更老的 LTS 版本则已经过社区考验，由于 Google、Linaro、kernelciorg 和其他公司的测试和基础设施的大量支持和投资，这些内核得到了更长时间的支持。使用这种内核实际上就代表你是独立的，最好是能够自己为内核提供支持。

也就是说，在适用性上，Kroah-Hartman 推荐：

笔记本电脑/台式机：最新的稳定版本

服务器：最新的稳定版本或最新的 LTS 版本

嵌入式设备：最新的 LTS 版本或更还在维护的老 LTS 版本

对于 Linux Kernel 的版本，你是怎么选的？欢迎评论。

原文来自： >首先我们的问题是：产品包含了大量的服务，并且服务之间存在复杂的依赖关系，以拓扑的形式运行并相互协作，部署的时候需要手动解决整体的依赖，配制通信的协议和地址，重新部署新环境复杂度非常高。因此，我们希望有一种容器技术可以让我们构建产品所需要的所有的服务能够迅速快捷的重新部署，并且可以根据需求横向的扩展，且保证高可用性，在出现问题的时候可以自动重启或者启动备份服务。

目前有多种解决方案，考虑我们有私有云，亚马逊云以及物理机的几种部署方式，所以Docker作为解决方案的基础，在其之上选择合适的容器拓扑管理工具就成了主要任务，常见的解决方案有：

多种解决方案中我们优先选择官方提供的工具，一般来说官方提供的工具跟自己的原生服务结合的更好，也具有更长远的规划，在官方工具确实不足的情况下辅助以第三方的工具，因此初步我们决定采用Docker原生的工具Machine+Swarm+Compose辅助以Mesos来实现整个工程的部署，其中Swarm负责某一功能模块小规模的容器分配调度，Mesos负责整个集群最外层大规模容器资源调度，可以说以Mesos为主，Swarm为辅助，因为Mesos是比较成熟的资源管理框架，也有非常适合的调度引擎，Swarm还相对初步随着时间演进，也许会接管更多的调度。

简单介绍下Docker官方原生的工具：

关于Docker网络解决方案的争论比较多了，CoreOS和Kubernetes都有自己的解决方案，前两者都是比较通用的PAAS工具，作为通用性的服务编排工具容器的具体实现可以是多种，Docker只是其中之一，而Docker libnetwork的解决方案过于底层，不适合作为通用的插件集成到Kubernetes或者CoreOS中，因此这两家都有自己CNI类型的解决方案，对于使用者来说我们不那么关心到底这个工具支持多少种容器，只需要知道Docker这种容器能够满足当前产品部署的需求就好，因此我们仍然以Docker的工具为主，尽管不那么通用，但是能够解决我们目前服务编排的问题。

官方的工具看起来很美好，解决方案也足够优雅和简洁，问题就是成熟程度，compose和swarm的结合仍然是在试验阶段，对于处于不同host的container，进行link仍然需要手动对整个Swarm集群设置网络，对于大规模或者复杂拓扑的部署工作量不小，因此我们借助于Mesos来做第一级的资源或者容器管理，其中第二级或者说小规模容器部署是可以在swarm中实现。

Mesos作为资深的资源管理平台，在Docker出现之前就已经被广泛利用了，基本上所有的主从类型的分布式计算框架都支持使用Mesos来做基本的资源分配调度，比如hadoop, storm，spark等等，同时Mesos的设计也可允许长时间运行的application， 不管是batch job, stream job还是普通的应用服务都可以接入Mesos来申请资源启动自身的容器。早期Mesos只支持LXC形式的资源限制，在Docker崛起之后Mesos也开始支持直接使用Docker容器来运行具体的计算框架，可以说二者既有竞争又相辅相成。说竞争是因为目前Docker自己的工具已经慢慢的可以替代一部分Mesos的应用场景了，只要机器上安装了Docker engine就可以无差别的管理所有主机，比如Swarm就可以组建简单的服务集群，管理容器在集群中的运行，同时也能够利用Machine来进行远程管理，说相辅是因为Swarm的设计是可以替换具体的调度后端的，默认情况使用自己的调度器在服务发现的基础上选择一个host来启动容器，通过配置可以选择Mesos作为其调度后端，将Swarm 作为跟Spark同等的Compute Framework来运行，这样Swarm就能够使用Mesos更加成熟和灵活的调度机制来管理容器，在此之上Compose就可以把编排好的服务运行在Mesos集群，可见Mesos和Docker结合的生态系统在当前阶段是比较和谐的。

这样，最终我们的解决方案就基本确定了，Mesos作为最基础的集群资源管理或者调度工具运行在所有的服务器上，Spark等计算框架不再独立部署，而是使用Mesos最初的LXC容器来运行，Swarm使用Docker容器通过Mesos来调度，Compose文件用来启动结合比较紧密服务堆栈，比如Tachyon集群，我们自己所开发的应用服务以及ACO集群也作为一个Docker服务堆栈在Swarm上运行。所以我们的Mesos集群上目前运行两种计算框架，Spark和Swarm，负责我们的应用和分布式计算的部署，具体的应用和服务编排都是在Compose中完成，个别复杂的应用需要手动去处理关联关系，依然是以Docker的形式运行在Mesos中。

Mesos可以把我们的机器聚合在一起作为一个机器来使用，不管是我们的应用还是分布式计算的任务，都直接提交给Mesos来进行调度，减少了对服务器的垂直划分，不存在Spark的集群， Hadoop的集群等概念，Spark或者Hadoop的job直接在Mesos的slave中分配资源并运行各自job相关的Executor, 运行结束后释放资源，就像Spark没有存在过一样， 因此从更高的角度看Mesos的Framework其实就是一个调度器加一个运行时的处理流程，不用再需要Spark或者Storm等框架的Standalone 模式自己来处理调度，只需要使用Mesos的API，实现自己的scheduler和具体启动停止运行过程的Executor就好， 而对于我们自己的应用如果要作为Framework存在也需要实现对应的Scheduler和Executor， 不过可以利用现成的比较好的调度器比如Marathon来托管我们的应用，减少开发Framework的工作量。使用Mesos这样的好处是资源的利用率更高， 因此我们在也不需要除了Mesos之外的long running 集群， 即使有Long running的服务，也是在Mesos分配好的容器内运行。
Framework = Scheduler + Executor
Mesos的安装过程稍微有点服务，虽然Docker镜像可以减少Mesos的部署复杂度，但是这样就存在了两层容器， Mesos在Docker 容器中运行，而Mesos里边的任务也是在自己的Docker容器里运行，如果有些长时间运行的任务需要暴露出端口跟外界交互，就需要先Expose port到Mesos slave级别的容器， 然后再Expose到最外层的物理机，复杂度增加且对性能有损耗，因此我们最终还是倾向于在物理机上部署Mesos， 只保留一层Docker容器不推荐嵌套，而且有了Mesosphere的DCOS系统，在AWS上部署Mesos就比较简单了。

Mesos看起来很完美，那我们为什么还需要Docker容器呢， 直接使用LXC标准Linux kernel支持的容器不就可以了，在这个解决方案中我们期望所有运行的应用或者分布式计算框架的任务的Executor都是在Docker容器中运行，也是因为Docker杀手级的功能，一个Docker容器就像一个集装箱，里边包含了需要运行一个服务或者任务的所有的依赖条件或者配置，都可以根据需求自身灵活的修改，并且一次装箱随处运行，不用关心外在环境，举个例子假如直接使用LXC来运行Spark的某个任务的Executor，需要提供Spark jar包的地址，相关的配置集成到ExecutorInfo中才能运行，而如果使用Docker container就简单很多，Spark executor运行需要的信息都在某个Docker image中，Mesos slave只要调用Docker client启动某个镜像就足以运行一个Framework的某个任务，任务的执行在Docker 容器中。对于我们自己开发的各种服务同理也是组织成镜像最终在Docker容器中运行， Scheduler依赖Marathon就可以。

1 云计算经历了这样一个过程

v10 --- 以计算为核心，kvm，hyper-v，xen， vmware exi，提高资源利用率

v20 --- 以资源为核心，openstack，vmware， aws，基础设施云化，资源服务标准化、自动化

v30 --- 以应用为核心，Docker，CoreOS，Cloud Foundry，应用云化，敏捷应用开发与生命周期管理

2 云计算类型：

---IaaS - 基础设施

---PaaS - 平台

---SaaS - 软件
3云计算关键技术：

---虚拟化

---分布式存储

---数据中心联网

---体系结构：用户界面，服务目录，管理系统，部署工具，监控，服务器集群

4云计算部署：

---存储云

---医疗云

---教育云

---交流云

---金融云

5虚拟化

云计算：一种服务

虚拟化：一种计算机资源管理技术，将各种IT实体资源抽象、转换成另一种形式的技术都是虚拟化

1）虚拟化类型

---寄居虚拟化， virtualbox， vmvare workstation

---裸金属虚拟化， VMware ESX， Xen， FusionSphere，虚拟化层内核需要开发

---混合虚拟化， KVM

2）虚拟化层架构：

---全虚拟化， kvm

---半虚拟化，Xen

---硬件辅助虚拟化

容器：实现APP与 *** 作系统的解耦

6计算虚拟化

---CPU虚拟化

------cpu QoS：份额、预留、限额

------NUMA

---内存虚拟化

------全虚拟化，影子页表技术：每个VM维护一个页表，记录虚拟内存到物理内存的映射，由VMM提交给MMU进行转换，VM不需要改变。但是这种方式是固定好的区域分配给虚拟机的

-------半虚拟化，页表写入法：每个VM创建一个页表并向虚拟化层注册，VM运行过程中不断管理、维护该页表

-------硬件辅助虚拟化， Intel的EPT, AMD的NPT

-------内存复用：内存气泡、内存共享、内存交换

---IO虚拟化

------全虚拟化，性能不高

------由Hypervisor提供接口，需要修改内核

------硬件辅助虚拟化，IO直通技术，SR-IOV 单根IO虚拟化

------IO环，用来提升大块多队列类型的IO密集型业务的IO性能

---策略

------虚拟机HA

------DRS，动态资源调度

------DPM，分布式电源管理，低负载是迁移到一个主机，节能

------IMC，集成存储控制器，在不同类型CPU类型主机之间切换

7存储虚拟化

把多个存储介质通过一定技术将它们集中起来，组成一个存储池，并进行统一管理。这种将多种、多个存储设备统一管理起来，为用户提供大容量、高数据传输性能的存储系统，称为虚拟存储。

作用：

-----提高硬件资源使用效率，异构的管理

-----简化系统管理

-----增强云存储平台的可靠性
存储资源：

---DAS

---NAS

---SAN

存储设备：

---本地磁盘

---LUN

---Storage存储池

---NAS共享目录

数据存储

---表示虚拟化平台中科管理的存储逻辑单元，承载虚拟机业务，创建磁盘

存储模式：

---非虚拟化存储

---虚拟化存储

---裸设备映射

虚拟化实现方法：

---基于主机的存储虚拟化，单主机访问多存储， das, san

---基于存储设备的虚拟化，多主机访问同一磁盘阵列, SAN

---基于网络的存储虚拟化，多对多，异构整合

存储虚拟化功能：

---精简磁盘和空间回收

---快照

------ROW写时重定向，原磁盘+差分卷共同挂载，读时读原元磁盘，写时写差分卷（个人觉得这里有问题）

------COW写时拷贝，写时写元磁盘（元磁盘已经更新过了），读时同时同时读原磁盘和差分卷

------WA随机写

------快照链

------链接克隆

虚拟机磁盘文件迁移

8 网络虚拟化

目的：

---节省物理主机的网卡资源，并且可以提供应用的虚拟网络所需要的L2-L7层网络服务

---网络虚拟化软件提供逻辑上的交换机和路由器（L2-L3），逻辑负载均衡器，逻辑防火墙（L4-L7）等，且可以以任何形式进行组装，为虚拟机提供一个完整的L2-L7层的虚拟网络拓扑。

特点：

---与物理层解耦合

---网络服务抽象化

---网络按需自动化

---多租户网络安全隔离

网卡虚拟化 ：

---软件网卡虚拟化

---硬件网卡虚拟化，SR-IOV

虚拟化化软件交换机

---OVS，Open vSwitch

---虚拟机之间的通信

---虚拟机和外界网络的通信

网络虚拟化 ：

---链路虚拟化：虚链路聚合，二层虚拟化

-------VPC，Virtual Port Channel，虚链路聚合

-------隧道协议， GRE，通用路由封装；IPsec，internet协议安全

---虚拟网络，由虚拟链路组成的网络

------层叠网络（虚拟二层延伸网络）

-----------Overlay Network, 在现有网络基础上搭建另外一种网络

-----------允许对没有IP地址标识的目的主机路由信息虚拟扩展局域网，大二层的虚拟网络技术

-----------vxlan，

------***

---