Docker容器与容器云第2版豆瓣在线阅读-Docker容器与容器云彩色第二版PDF电子书下载

编辑点评：

Docker容器与容器云（第2版）以源码解读为基础，以构建Docker云平台为目标，通过回答实际项目中的问题为线索，全面解析Docker原理。这是国内首部在解读Docker原理的同时深入实践Docker三件套和云平台的图书，也是国内首部深入解读Kubernetes的图书。

内容简介

本书根据Docker 1.10版和Kubernetes 1.2版对第1版进行了全面更新，从实践者的角度出发，以Docker和Kubernetes为重点，沿着“基本用法介绍”到“核心原理解读”到“高级实践技巧”的思路，一本书讲透当前主流的容器和容器云技术，有助于读者在实际场景中利用Docker容器和容器云解决问题并启发新的思考。全书包括两部分，首部分深入解读Docker容器技术，包括Docker架构与设计、核心源码解读和高级实践技巧；第二部分归纳和比较了三类基于Docker的主流容器云项目，包括专注Docker容器编排与部署的容器云、专注应用支撑的容器云以及一切皆容器的Kubernetes，进而详细解读了Kubernetes核心源码的设计与实现，介绍了几种典型场景下的Kubernetes实践。 

本书适用于有一定Docker基础的开发者、架构师、IT专业学生以及探索基于Docker构建云计算平台的技术人员，也非常适合作为高校教材或培训资料。

作者简介

浙江大学软件工程实验室（Software Engineering Lab，SEL）云计算团队组建于2011年，组织博士和硕士研究生搭建、分析和钻研开源的云计算技术，包括Docker、Kubernetes、Cloud Foundry、OpenStack、CloudStack、Eucalyptus、Convirt、OpenShift等，积极为开源社区贡献代码，管理和参与线上线下讨论社区，参加国内外云计算技术峰会并发言。以开源社区为技术交流研发平台，浙江大学SEL实验室在4年多的时间里成长为一个充满热情、富有能力的云计算研发团队，也在国内外开源云计算社区，尤其是在Docker、Kubernetes和Cloud Foundry社区得到了广泛认可。

本书结构

本书共分两部分，沿着从容器到容器云的发展脉络，从“概念用法解析”到“核心原理分析”，然后到“高级实践技巧”，层层推进，全面介绍了Docker以及围绕Docker构建的各类容器云平台技术，深入分析了Kubernetes背后的技术原理和设计思想。

第一部分讲解了Docker容器的核心原理和实践技巧。其中第1章和第2章能够让读者在短时间内体验这场IT界的风暴，并且初步了解Docker的使用方法，为后续的源码解析做铺垫。第3章是本书第一部分的核心，这一章以Docker 1.10版本源码为基础，深入分析了容器的namespace和cgroups原理，紧接着我们以docker run命令为线索，一路贯穿Docker的容器创建、镜像组织、联合文件系统以及容器网络初始化的源码，深入透彻地向读者展示了从一条指令到最终Linux容器生成的整个过程中，Docker源码的设计原理和执行路线。第4章则介绍了当前时髦的“容器化思维”以及Docker相关的几类实践技巧，包括网络、监控、服务发现等。值得一提的是，在上述代码走读的过程中，本书几乎没有贴出任何一部分Docker源码或者函数，而是力图使用平实的语言和生动的图示来展示代码背后的执行逻辑和设计思想。Docker的源码字字珠玑，我们希望能够使用这样的解读方式使读者真正理解Docker和容器背后的设计方法和技术本质，而不是变成一本单纯的技术手册。

第二部分深入分析基于Docker的各类“容器云”平台的架构细节和背后的设计理念，这些容器云虽然在底层技术上都基于Docker这样的容器技术，但在背后的设计思想上却存在很大的差异。我们将看到一个因颠覆了原有las、Paas云计算生硬的分类方式而精彩纷呈的容器云世界。其中第5章介绍了一个最简单的容器云解决方案作为引子；第6章和第7章分析和比较了几类典型的容器云开源项目，包括了Docker官方的“三剑客”项目、Fleet以及更类似经典Paas的Flynn和Deis；第8章是本书第二部分的重点，我们以Kubernetes 1.2版本源码为基础，从核心概念到架构梳理，再到深入到组件级别的Kubernetes源码解析，从多个维度详细讲解了Kubernetes容器云平台的各种技术细节，这在国内尚属首次。我们希望通过容器云平台的源码解读，能够带领读者从纷繁复杂的容器云项目中梳理出一个细致的脉络，让读者在选型和二次开发的过程中减少迷茫和试错成本。而作为Kubernetes项目的贡献者和特性维护者，我们希望有更多的技术人员能够从源码层面对Kubernetes有更深刻的理解和认识，并且同我们一起来推动这个优秀的开源项目在国内的进步和落地。在第二部分的结尾，我们试图回答之前的提问，即容器云应该以何种形态来更好地支撑当今时代。

信号与init进程

内核还为PID namespace中的init进程赋予了其他特权-信号屏蔽。如果init中没有编写处理某个信号的代码逻辑，那么与init在同一个PID namespace下的进程（即使有超级权限）发送给它的该信号都会被屏蔽。这个功能的主要作用是防止init进程被误杀。

那么，父节点PID namespace中的进程发送同样的信号给子节点中的init进程，这会被忽略吗？父节点中的进程发送的信号，如果不是SICKILL（销毁进程）或SICSTOP（暂停进程）也会被忽略。但如果发送SIGKILL或SIGSTOP，子节点的init会强制执行（无法通过代码捕捉进行特殊处理），也即是说父节点中的进程有权终止子节点中的进程，一旦init进程被销毁，同一PID namespace中的其他进程也随之接收到SIGKILL信号而被销毁理论上，该PID namespace也不复存在了。但是如果/proc/[pid]/ns/pid处于被挂载或者打开状态，namespace就会被保留下来。然而，保留下来的namespace无法通过setns（）或者fork（）创建进程，所以实际上并没有什么作用。

当一个容器内存在多个进程时，容器内的init进程可以对信号进行捕获，当SIGTERM或SIGINT等信号到来时，对其子进程做信息保存、资源回收等处理工作。在Docker daemon的源码中也可以看到类似的处理方式，当结束信号来临时，结束容器进程并回收相应资源。

Docker容器与容器云彩色第二版PDF电子书下载截图