《Docker——容器与容器云（第2版）》是一本由浙江大学SEL实验室著作，人民邮电出版社出版的平装图书，本书定价：89.00元，页数：472，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《Docker——容器与容器云（第2版）》精选点评：

　　●不适合入门，太细节、博文风。

　　●docker部分讲的还是很精彩和详细的。适合仔细研究。k8s的部分还没细看，个人觉得是总结较多。建议先玩熟了再看k8s的部分作为总结

　　●更侧重于docker和k8s的实现原理，更像是一本供查询的工具书，不是那种实战书。

　　●专业，严谨

　　●通过docker底层原理、运行到投产，容器化，云，SaaS，多租户实现，了解了计算机服务端底层和网络通信的一些基础理论，有帮助。

　　●挺不错的，毕竟是市面上少有的kube书了

　　●看了第一部分，还是不错的

　　●一直没买书 等读到的电子版的时候 2019年了 1.11 好多内容 都过时了

　　●介绍了docker 和常见docker 编排系统。对k8s 的相关原理也做了介绍。很翔实。此书最好在了解k8s 基本使用后在阅读，否则容易出现『只见树木不见森林』

　　●还可以吧

　　《Docker——容器与容器云（第2版）》读后感(一)：云云云

　　感觉作者说啥都要把 docker 和“云”扯在一起，docker 集群不更好理解吗，非要说成 docker云，相反呢，那些云服务厂家是如何使用docker 的，这本书就完全没有介绍，他们是不是使用docker 都存疑。说成“云”会多卖钱吗？感觉很莫名奇妙啊。

　　其他的介绍还是挺好的，比较系统。主要是对作者一根筋的跟云扯在一起，不知道原因是什么？是跟国家项目有关吗？

　　讲到了一些实用中的技巧和坑，非常不错。

　　《Docker——容器与容器云（第2版）》读后感(二)：Docker——容器与容器云（第2版）

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

　　《Docker——容器与容器云（第2版）》读后感(三)：Docker技术系统学习的指南书

　　随着互联网技术的快速发展，IT企业也急需在技术之海中迅速找到自己的立足之处，快速学习，快速转型，快速开发，对于一些非紧要系统来说，开源项目方便快捷，迅速掌握相关的技术要点，也急需这样无论是从理论层面还是技术层面都可以深度点拨，开启智慧的技术指南书。

　　身在互联网软件开发公司，尽管并不需要写程序代码，但也需要对一些热门的计算机技术有所了解，不至于同事一提便蒙嚓嚓，这些技术包括这几年正火爆的云计算。什么是云计算，一种基于互联网的相关服务，相关于一种可通过配置形成的资源共享池，这种资源可以是网络、服务器、存储空间，应用软件，槿者服务等。通过在虚拟空间的共享服务，提供快速、高效、便捷而且安全的服务。其中云是网络，互联网的形象化说明，比如电信网，计算机网，基础设施网等。计算目前大约是10万亿次的运算能力。

　　Docker 是一种开源的应用容器引擎，基于go语言并遵从Apache2.0协议开源。让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。通常包括dockerClient客户端、 Docker Daemon守护进程、Docker Image镜像、DockerContainer容器。

　　平台即服务提供商----PAAS，将软件研发的平台作为一种服务，以SaaS的模式提交给用户。在计算机高级项目经理的软件考试中，是有多次考过IaaS，PaaS,SaaS的概念的。在这本《Docker——容器与容器云（第2版）》里对Docker 的基本概念，发展脉络，基本使用方法，源码模块解读以及高级实践技巧等都有清晰的讲解。

　　这本书出自浙江大学SEL实验室，属图灵原创系列，品质值得信赖。无论是对Docker这门技术爱好者，还是系统架构师，云端开发者，系统管理员还是运维人员，都能从中找到自己的兴趣点。书中的案例讲解部分最为实用。而对一般的读者而言，了解Docker云以及这种容器云背后的架构细节及设计理念，对我们理解整个互联网发展趋势，也非常有帮助。

　　《Docker——容器与容器云（第2版）》读后感(四)：《docker 容器与容器云》读书笔记 part 2

　　#docker 高级实践技巧

　　容器化思维：容器本质是一个进程。linux network namespace命令：ip netns

　　ipework跨主机通信：桥接，直接路由。

　　docker run参数可以覆盖CMD，但不能覆盖ENTRYPOINT。

　　容器监控命令：

　　* docker ps

　　* docker images

　　* docker stats

　　* docker inspect

　　* docker top

　　* docker port

　　高可用配置中心etcd：

　　* 服务发现

　　* 消息发布和订阅

　　* 负载均衡

　　* 分布式通知与协调

　　* 分布式锁

　　* 分布式队列

　　* 集群监控

　　etcd是一个分布式键值存储系统。它解决了

　　* 分布式场景中常见的数据一致性问题

　　* 为服务发现提供了一个稳定、高可用的消息注册仓库

　　* 为以微服务协同工作的架构提供了无限的可能。

　　etcd架构：

　　使用WAL预写式日志助于恢复。

　　etcd中处理API的包称为Store

　　#构建自己的容器云

　　容器云，就是以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建、发布和运行分布式应用的平台。

　　#一切皆容器:Kubernetes

　　od：

　　在Kubernetes中，能够被创建、调度和管理的最小单元是pod，而非单个容器。 一个pod是由若干个Docker容器构成的容器组。

　　* pod是IP等网络资源的分配的基本单位；

　　* pod内的所有容器共享volume。

　　* IPC namespace，即同一个pod内的应用容器能够使用System V IPC或POSIX消息队列进行通信。

　　* UTS namespace，即同一个pod内的应用容器共享主机名。

　　通过label，可以在Kubernetes集群管理工具kubectl中方便地实现pod等资源对象的定位和组织。

　　label selector是Kubernetes核心的分组机制。

　　* 基于值相等查询：=、==和!=

　　* 基于子集查询：in、notin和exists

　　尽量不要在单个pod中运行同一个应用的多个实例，因为pod设计的目的就是用于不同应用程序之间的协同，所以把一个应用的多个副本部署在一个pod中违背初衷。

　　使用K8s的客户端工具kubectl来创建pod，支持对K8s对象(pod、 replication controller、service)的增、删、改、查操作以及其他对集群的管理操作。

　　kubectl create -f testpod.json

　　kubectl get pod

　　kubectl log podtest master1

　　Kubernetes的网络容器(名为gcr.io/google_ containers/pause，也称为基础容器)，并且pod中的其他容器都借助 --net="container"的方式使用它间接定义自身的网络，就实现了这些容器network namespace的共 享。

　　od的状态有pending，running，succeeded，failed，unknown

　　replication controller：它决定了一个pod有多少同时运行的副本，并保证这些副本的期望状态与当前状态一致。

　　replication controller通过使用预定义的pod模板来创建pod，只能与重启策略为 Always的pod进行协作。

　　replication controller对pod的数量和健康状况的监控则是通过副本选择器(replica selector， label selector的一种)来实现。

　　使用场景：

　　* 重调度

　　* 弹性伸缩

　　* 滚动更新

　　* 应用多版本release追踪

　　以下命令测试：

　　kubectl create -f redis-controller.json

　　kubectl get replicationController -o wide

　　kubectl get pods -o wide

　　kubectl delete pod redis-controller-g43j1

　　kubectl get pods

　　ervice：

　　* 由于重新调度等原因，pod在Kubernetes中的IP地址不固定，需要一个代理来确保需要使用pod的应用不需要知晓pod的真实IP地址。

　　* 当使用replication controller创建了多个pod的副本时，需要一个代理来为这些pod做负载均衡。

　　ervice主要由一个IP地址和一个label selector组成。

　　kubectl get services

　　Kubernetes集群的每个节点上都运行着一个服务代理(kube-proxy）。kube-proxy有userspace和ipstables这两种工作模式。

　　ervice的自发现机制有两个方式：环境变量，DNS（推荐）。

　　ervice的外部可路由性设计：

　　* NodePort

　　* LoadBalancer 云服务提供商的支持

　　* external ip 外部ip池

　　Kubernetes为每个service分配一个唯一的clusterIP。

　　新一代副本控制器replica set

　　Deployment多用于为pod和replica set提供更新

　　DaemonSet提供这样的服务，每当一个新的工作节点加入到集群中，系统就会按照 DaemonSet的配置在节点上运行相应的pod。

　　ConfigMap包含了一系列的键/值对，用于存储被pod或者系统组件(如controller等)访问的信息。用户可以在pod template中的env中使用。

　　Kubernetes专门支持batch job的资源：Job

　　自动扩展分为两种，其一为水平扩展，针对于实例数目的增减;其二为垂直扩展，即单个实例可以使用的资源的增减。

　　Kubernetes由两种节点组成:master节点和工作节点，前者是管理节点，后者是容器运行的 节点。其中master节点中主要有3个重要的组件，分别是APIServer、scheduler和controller manager。 APIServer组件负责响应用户的管理请求、进行指挥协调等工作;scheduler的作用是将待调度的 pod绑定到合适的工作节点上;controller manager是一组控制器的合集，负责控制管理对应的资 源，如副本(replication)和工作节点(node)等。工作节点上运行了两个重要组件，分别为kubelet 和kube-proxy。前者可以被看作一个管理维护pod运行的agent，后者则负责将service的流量转发 到对应的endpoint。在实际生产环境中，不少用户都弃用了kube-proxy，而选择了其他的流量转发组件。

　　k8s的volume不同于docker的volume，有19种。

　　volumeMounts:

　　# mountPath即volume在容器内的挂载点路径

　　- mountPath: /redis-master-data

　　# name字段必须与下面的volume名匹配

　　ame: redis-data

　　##Docker的网络模型。

　　Docker默认使用单主机的网络方案，默认创建一个名为docker0的网桥，并为之分配一个私有网络的子网段 (172.17.0.0/16)。对每个由Docker创建的容器，Docker为它分配一个绑定到docker0网桥上的虚拟以太网网卡(veth)。最后，Docker使用Linux namespace技术将veth映射成在容器中显示的以太网网卡eth0，而容器内的eth0网卡会被绑定一个在docker0网桥网段中的IP地址，并且使用 docker0的IP地址作为其默认网关。这种方案带来的结果是Docker容器只能与同一台宿主机(更准确地说是同一个虚拟网桥中的网段)中的容器进行通信，不同宿主机上的容器无法通信。

　　##Kubernetes的单pod单IP模型。

　　Kubernetes会使用iptables完成pod内容器端口在宿主机上的端口映射，发往宿主机端口的流量会被转发至对应pod中的容器，而从pod发往宿主机外部的流量需要使用宿主机的IP地址进行源地址转换。

　　od内的第一个容器(网络容器)存在的唯一作用就是创建一个开放的网络namespace，并让 pod内的其他容器加入其中。这个网络容器成为了pod与外界进行网络通信的唯一终端。

　　##Kubernetes 多租户管理与资源控制

　　amespace是Kubernetes进行多租户资源隔离的主要手段。

　　Kubernetes支持namespace隔离的资源对象类型至少包括这几种:pod、service、 replication controller、event、endpoint等。可以通过查看etcd上/registry目录了解。

　　k8s用户认证机制：客户端证书，token，openid，basic，keystone。

　　k8s 用户授权机制：ABAC，webhook。

　　业务级健康检查方法：http get，container exec，tcp socket。

　　##k8s 容器日志

　　为了启用Kubernetes集群内Docker容器的标准输出(stdout)和标准错误输出(stderr)，并将 日 志 输 出 重 定 向 到 elasticsearch ， 需 要 设 置 环 境 变 量 ENABLE_NODE_LOGGING 以 及 LOGGING_DESTINATION。

　　自由度和自动化的取舍。

　　《Docker——容器与容器云（第2版）》读后感(五)：《docker 容器与容器云》读书笔记 part 1

　　起源

　　docker基于go语言开发，apache 2.0协议。2019年正式发布开源版本。

　　docker优势：

　　* 持续部署和测试

　　* 跨云平台支持

　　* 环境标准化和版本控制

　　* 高资源利用率和隔离

　　* 容器跨平台性与镜像

　　* 易用

　　* 应用镜像仓库

　　前提

　　* 64位 cpu

　　* Linux内核版本为3.10+

　　* Linux内核开启cgroups和namespace

　　核心原理

　　通过namespace实现了资源隔离，通过cgroups实现了资源限制。

　　amespace 资源隔离

　　amespace的API包括clone()、setns()以及unshare()，还有/proc下的部分文件。

　　1.UTS(UNIX Time-sharing System)namespace提供了主机名和域名的隔离。

　　2.IPC namespace实现了容器与宿主机、容器与容器之间的IPC隔离。

　　3.PID namespace隔离对进程PID重新标号，即两个不同namespace下的进程可以 有相同的PID。

　　4.mount namespace通过隔离文件系统挂载点对隔离文件系统提供支持。

　　* master-slave为单箭头，表示传播方向

　　* share为双箭头，表示互相影响

　　* private为横线，表示隔离

　　* unbindable为叉，表示禁止绑定

　　5.network namespace主要提供了关于网络资源的隔离，包括网络设备、IPv4和IPv6协议栈、IP 路由表、防火墙、/proc/net目录、/sys/class/net目录、套接字(socket)等。

　　容器的经典做法就 是创建一个veth pair，一端放置在新的namespace中，通常命名为eth0，一端放在原先的namespace 中连接物理网络设备，再通过把多个设备接入网桥或者进行路由转发，来实现通信的目的。

　　6.user namespace主要隔离了安全相关的标识符(identifier)和属性(attribute)，包括用户ID、 用户组ID、root目录、key(指密钥)以及特殊权限。

　　cgroups 资源限制

　　control groups可以限制、记录任务组所使用的物理资源(包括CPU、Memory、IO等）。

　　* 资源限制

　　* 优先级分配

　　* 资源统计

　　* 任务控制

　　mount -t group 查看子系统。

　　在/sys/fs/cgroup的cpu子目录下创建控制组，控制组目录创建成后，它下面就会有很多类似的文件。

　　tree cgroup/cpu/docker 查看docker控制组层级。

　　Docker使用了传统的client-server架构模式，用户通过Docker client与 Docker daemon建立通信，并将请求发送给后者。而Docker的后端是松耦合结构，不同模块各司其职。

　　libcontainer是对cgroups和namespace的二次封装，execdriver是通过libcontainer来实现对容器的具体管理，包括利用UTS、IPC、PID、Network、Mount、User等namespace实现容器之间的资源隔 离和利用cgroups实现对容器的资源限制。

　　Docker通过distribution、registry、layer、image、reference等模块实现了Docker镜像的管理。

　　* execdriver是对Linux操作系统的namespaces、cgroups、apparmor、SELinux等容器运行所 需的系统操作进行的一层二次封装。execdriver最主要的实现，是Docker官方编写的libcontainer库。

　　* volumedriver是volume数据卷存储操作的最终执行者，负责volume的增删改查，屏蔽不同驱动实现的区别，为上层调用者提供一个统一的接口。Docker中作为默认实现的 volumedriver是local，默认将文件存储于Docker根目录下的volume文件夹里。

　　* graphdriver是所有与容器镜像相关操作的最终执行者。在Linux环境下，目前Docker已经支持的graphdriver包括aufs、btrfs、zfs、devicemapper、overlay和vfs。

　　docker命令的两种模式:client模式和daemon模式。

　　docker [OPTIONS] COMMAND [arg...]

　　如果子命令为daemon，Docker就会创建一个运行在宿主机的daemon进程(docker/daemon. go#mainDaemon)，即执行daemon模式。其余子命令都会执行client模式。

　　docker daemon会启动一个api server接收client的请求。Docker daemon运行中所在的工作目录，默认为 /var/lib/docker。

　　需要注意，目前vfs在Docker中是用来管理volume的，并不作为镜像存储使用。另外，由于目前在overlay文件系统上运行的Docker容器不兼容SELinux，因此当config中配置信息需要启用 SELinux并且driver的类型为overlay时，该过程就会报错。

　　libnetwork实现了host、null、 bridge和overlay的驱动。其中，bridge driver为默认驱动。bridge driver并不提供跨主机通信的能力，overlay driver则适用于多主机环境。

　　execdriver是Docker中用来管理Docker容器的驱动。

　　容器是一个与宿主机系统共享内核但与系统中的其他进程资源相隔离的执行环境。

　　libcontainer对Docker容器做了一层更高级的抽象，定义了Process和Container 来对应Linux中“进程”与“容器”的关系。

　　libcontainer实现原理：

　　(1) Docker daemon进程进行“用Facotry创建逻辑容器Container”“启动逻辑容器Container” 等准备工作，构建ParentProcess对象，然后利用它创建容器内的第一个进程dockerinit。

　　(2) dockerinit利用reexec.init()执行StartInitialization()。这里dockerinit会将自己加入 到用户指定的namespace(如果指定了的话)，然后再开始进行容器内部的各项初始化工作。

　　(3) StartInitialization()使用execv系统调用执行容器配置中的Args指定的命令，即Entry- Point和docker run的[COMMAND]参数

　　子进程感知内存中写入了新数据：

　　Docker选择的方式是管道——文件和文件描述符方式。

　　Docker镜像的文件内容以及一些运行Docker容器的配置文件组成了Docker容器的静态文件系统运行环境——rootfs。

　　镜像的特点：分层，copy on write，内容寻址，联合挂载。

　　联合挂载是用于将多个镜像层的文件系统挂载到一个挂载点来实现一个统一文件系统视图 的途径，是下层存储驱动(如aufs、overlay等)实现分层合并的方式。

　　registry是repository的集合，repository是镜像的集合。

　　docker push 通过线上Docker Hub的方式迁移，而docker save则是通过线下包分发的方式迁移。

　　GraphDriver中主要定义了Driver和ProtoDriver两个接口，所有的存储驱动通过实现Driver 接口提供相应的功能，而ProtoDriver接口则负责定义其中的基本功能。

　　Docker中的任何存储驱动都需要实现上述Driver接口。

　　常用存储驱动有aufs、devicemapper以及overlay。

　　镜像层或者容器层在存储驱动中拥有一个标示ID，在镜像层(roLayer)中称为cacheID，容器层(mountedLayer)中为mountID。

　　Docker容器的文件系统有3层:可读写层(将来被commit的内容)、init层和 只读层。

　　1 aufs(advanced multi layered unification filesystem)是一种支持联合挂载的文件系统，支持将不同目录挂载到同一个目录下。

　　2 Device Mapper是Linux 2.6内核中提供的一种从逻辑设备到物理设备的映射框架机制。

　　Device Mapper包括3个概念:映射设备、映射表和目标设备。

　　3 OverlayFS是一种新型联合文件系统(union filesystem)，允许用户将一个文件系统与另一 个文件系统重叠(overlay)，在上层的文件系统中记录更改，而下层的文件系统保持不变。相比于aufs，OverlayFS在设计上更简单，理论上性能更好。

　　OverlayFS使用4类目录：

　　* 被联合挂载的两个目录lower和upper

　　* 作为统一视图联合挂载点的merged目录

　　* 作为辅助功能的work目录

　　docker volume create创建volume。

　　在创建volume时会在宿主机/var/lib/docker/volume/创建一个以volume ID为名的目录，volume中的内容存储在_data目录。

　　$ sudo docker run -v /host/dir:/container/dir ubuntu /bin/bash

　　共享volume (--volumes-from)

　　// 将宿主机上的volume_id目录绑定挂载到rootfs中指定的挂载点/data上

　　mount(“/var/lib/docker/volumes/volume_id/_data”, “rootfs/data”, “none”, MS_BIND, NULL)

　　// 将宿主机上的/var/log目录绑定挂载到rootfs中指定的挂载点/data上

　　mount(“/var/log”, “rootfs/data”, “none”, MS_BIND, NULL)

　　五大网络驱动：

　　* bridge 桥接

　　* host 共享宿主机网络空间

　　* overlay VXLAN

　　* remote 插件化

　　* null 配置为空，需要进一步定义

　　docker的安全机制：

　　* daemon安全：unix套接字本地连接，tls的TCP连接

　　* 镜像安全：registry

　　* 内核安全：cgroups，namespace

　　* 容器网络安全 —icc标志

　　* 容器能力限制（docker run 参数）

　　* seccomp（安全计算模式）