Docker容器与容器云彩色第二版PDF电子书下载|百度网盘下载

编辑评论：

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

简介

本书是第一版基于Docker 1.10版和Kubernetes 1.2版的全面更新。站在从业者的角度，重点关注 Docker 和 Kubernetes，从《基本用法介绍》到《核心原理解读》再到《高级实用技能》的思路，一本书讲解了当前主流的容器和容器云技术，帮助读者在实际场景中使用Docker容器和容器云解决问题，启发新思维。本书分为两部分，第一部分是对Docker容器技术的深入解读，包括Docker架构与设计、核心源码解读和高级实战技巧；第二部分总结对比了三类基于Docker的主流容器云项目，包括专注于Docker容器编排和部署的容器云，专注于应用支持的容器云，以及万物皆容器的Kubernetes，然后讲解了设计详细介绍了Kubernetes核心源码的实现，并介绍了Kubernetes在几个典型场景下的实践。

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

关于作者

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

书籍结构

本书分为两部分，沿着从容器到容器云的开发路线，从“概念使用分析”到“核心原理分析”，再到“进阶实践技能”，层层递进，全面Docker介绍以及围绕Docker构建的各种容器云平台技术，深入剖析Kubernetes背后的技术原理和设计思路。

第一部分讲解Docker容器的核心原理和实战技巧。第1章和第2章让读者在短时间内体验IT界的风暴，对Docker的使用有一个初步的了解，为后续源码分析做铺垫。第三章是本书第一部分的核心。本章以Docker 1.10源码为基础，深入剖析容器的命名空间和cgroups原理。然后我们以 docker run 命令为线索，运行 Docker 的容器创建和镜像。组织、联合文件系统和容器网络初始化的源码，彻底透彻地向读者展示了Docker源码从一条指令到最终Linux容器生成的全过程的设计原理和执行路线。第4章介绍了当下“容器化思维”的趋势以及Docker相关的几类实用技能，包括网络、监控、服务发现等。值得一提的是，在阅读上述代码的过程中，本书几乎没有贴出任何内容Docker 源代码或功能的一部分，但尽量用通俗易懂的语言和生动的插图来展示代码背后的执行逻辑和设计思想。 Docker 的源代码字面意思是字面意思，我们希望通过这种解读，让读者真正了解 Docker 和容器背后的设计方法和技术精髓，而不是把它变成一本简单的技术手册。

第二部分深入分析了各种基于Docker的“容器云”平台背后的架构细节和设计理念。虽然这些容器云在底层技术上都是基于Docker等容器技术，但它们背后的设计思路却有着很大的不同。我们将看到一个颠覆原有las和Paas云计算生硬分类的辉煌容器云世界。第 5 章介绍了一种最简单的容器云解决方案作为介绍；第6章和第7章分析比较了几类典型的容器云开源项目，包括Docker官方的“三剑客”项目，Fleet and More类似于经典Paas的Flynn和Deis；第八章是本书第二部分的重点。基于Kubernetes 1.2版本的源码，我们从核心概念到架构分析，再深入到Kubernetes源码的组件级分析。这是国内第一次在这个维度详细讲解Kubernetes容器云平台的各种技术细节。我们希望通过容器云平台的源码解读，带领读者从纷繁复杂的容器云项目中梳理出一个详细的脉络，让读者在选型和二次开发过程中减少困惑和试错成本发展。作为 Kubernetes 项目的贡献者和特性维护者，我们希望更多的技术人员能够从源代码层面对 Kubernetes 有更深入的了解和了解，与我们一起推动这个优秀的开源项目在中国的进步和发展.降落。在第二部分的最后，我们尝试回答之前关于容器云应该采取什么样的形态才能更好地支持当前时代的问题。

信号和初始化过程

内核还授予 PID 命名空间中的 init 进程其他权限 - 信号屏蔽。如果在 init 中没有处理信号的代码逻辑，那么与 init 相同 PID 命名空间下的进程发送给它的信号（即使它具有超级权限）将被阻塞。该函数的主要作用是防止init进程被误杀。

那么，父节点的PID命名空间中的进程向子节点中的init进程发送相同的信号，这个会被忽略吗？父节点中的进程发送的信号，如果不是 SICKILL（销毁进程）或 SICSTOP（挂起进程）也将被忽略。但是如果发送了SIGKILL或SIGSTOP，则会强制执行子节点的init（不能通过代码抓包进行特殊处理），这意味着父节点中的进程有权终止子节点中的进程。一旦init进程被销毁，相同PID命名空间中的其他进程在收到SIGKILL信号后也被销毁。理论上，PID 命名空间不再存在。但是如果 /proc/[pid]/ns/pid 被挂载或打开，命名空间将被保留。但是，保留的命名空间不能用于通过 setns() 或 fork() 创建进程，因此它实际上并没有做任何事情。

当容器中有多个进程时，容器中的init进程可以捕获信号，当SIGTERM或SIGINT等信号到达时，会为其子进程保存信息并回收资源。在Docker daemon的源码中也可以看到类似的处理方式。当结束信号到来时，容器进程被终止，相应的资源被回收。