Linuxs利用Cgroup实现了对容器的资源限制，但在容器内部依然缺省挂载了宿主机上的procfs的/proc目录，其包含如：meminfo, cpuinfo，stat， uptime等资源信息。一些监控工具如free/top或遗留应用还依赖上述文件内容获取资源配置和使用情况。当它们在容器中运行时，就会把宿主机的资源状态读取出来，引起错误和不便。

brew install socat ssh -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock socat -d -d ~/Library/Containers/com.docker.docker/Data/debug-shell.sock pty,rawer https://blog.csdn.net/weixin_34261739/article/details/89050333 The Docker Engine uses Linux-specific kernel features, so to run it on OS X we need to use a lightweight virtual machine (vm). You use the OS X Docker client to control the virtualized Docker Engine to build, run, and manage Docker containers.

https://github.com/Yelp/dumb-init

一个dockerfile 可以根据–target 编译成多个镜像

https://github.com/vishvananda/netlink 添加一个网桥 设置网桥地址 状态 往网桥上attach设备 设置iptables 将veth设备中的一端加入到某个namespace中 删除设备 https://www.jianshu.com/p/be7af63f666f?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation 什么是netlink？

当kubelet要创建一个容器时，需要以下几步：

docker save 用来将一个或多个image打包保存。

https://github.com/goharbor/harbor 虽然Docker官方提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署我们私有环境内的Registry也是非常必要的。

遇到ELF: not found 本质上，应该是把二进制文件当做 shell 文件来执行了 二进制elf文件被当作shell脚本解析了，原因： https://blog.csdn.net/oscarun/article/details/106634564

1,charles 代理的坑

ip是一个非常强大的实用程序，用于执行许多任务。较早使用了多个较早的实用程序，例如ifconfig和route命令来执行这些功能。在本文中，我将分享使用ip命令配置网络接口和路由的不同示例。

FreeBSD 下的虚拟技术 bhyve (The BSD Hypervisor) 包含在了 FreeBSD 10.0 发行版中。而这个 xhyve 是基于 bhyve 的 Mac OS X 移植版本

两种方法来查看系统的当前 cgroup 信息。第一种方法是通过 systemd-cgls 命令来查看，它会返回系统的整体 cgroup 层级，cgroup 树的最高层由 slice 构成 可以看到系统 cgroup 层级的最高层由 user.slice 和 system.slice 组成。因为系统中没有运行虚拟机和容器，所以没有 machine.slice，所以当 CPU 繁忙时，user.slice 和 system.slice 会各获得 50% 的 CPU 使用时间。 user.slice 下面有两个子 slice：user-1000.slice 和 user-0.slice，每个子 slice 都用 User ID (UID) 来命名，因此我们很容易识别出哪个 slice 属于哪个用户。例如：从上面的输出信息中可以看出 user-1000.slice 属于用户 tom，user-0.slice 属于用户 root。 systemd-cgls 命令提供的只是 cgroup 层级的静态信息快照，要想查看 cgroup 层级的动态信息，可以通过 systemd-cgtop 命令查看 https://juejin.cn/post/6844903858116755463

Dockerfile中RUN，CMD和ENTRYPOINT都能够用于执行命令，下面是三者的主要用途：

https://github.com/jpetazzo/nsenter you can use Docker exec to enter a Docker container. Example:

https://github.com/flynn/flynn/blob/2c20757de8b32a40ba06f7e5b363b2d4dd6b332e/README.md

https://github.com/docker-archive/docker-registry https://docs.docker.com/registry/

改写文件 最简单的加速是改写 Dockerfile, 因为 Dockerfile 中的一些命令 (ADD/COPY/RUN) 会产生新的 layer, 而 Docker 会自动跳过已经构建好的 layer。 所以一般优化的原则基于以下几点：

HyperKit：OSX上运行的轻量级虚拟化工具包 DataKit：现代化分布式组件框架 VPNKit：嵌入式虚拟网络库

docker pull golang:1.17.0-alpine3.13 arch=darwin/arm64

https://registry.hub.docker.com/_/golang?tab=tags&page=1&ordering=last_updated&name=1.17

% docker pull golang:1.17.0-alpine3.13 Status: Downloaded newer image for golang:1.17.0-alpine3.13 docker.io/library/golang:1.17.0-alpine3.13

https://github.com/linuxkit/linuxkit

docker容器内安装太慢，实在受不了这速度了。 解决方案 将默认的debian源替换为阿里源。 cat命令(因为默认不带vim)查看源配置文件： cat /etc/apt/sources.list 默认内容为： deb http://deb.debian.org/debian jessie main deb http://deb.debian.org/debian jessie-updates main deb http://security.debian.org jessie/updates main 只要将 deb.debian.org 替换为 mirrors.aliyun.com 即可 https://blog.csdn.net/enthan809882/article/details/104441118

首先 alpine 非常的小，安装上了bash 之后也才 5mb https://studygolang.com/articles/9215

OverlayFS是一个类似于AUFS 的现代联合文件系统，更快实现简单。

docker builder prune ：删除 build cache。

https://github.com/jpetazzo/pipework

Macbook 升级 docker desktop 后原来的镜像和容器丢失。解决办法：

http://www.taopanfeng.com/2020/12/14/2020-12-14…11.22.57/

docker run -d –cap-add=SYS_PTRACE -p 8991:8999 …..

解决办法其实还是用mysqldump命令，但是我们需要进入docker的mysql容器内去执行它，并且通过配置volumes让导出的数据文件可以拷贝到宿主机的磁盘上

Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过 Compose，您可以使用 YML 文件来配置应用程序需要的所有服务。然后，使用一个命令，就可以从 YML 文件配置中创建并启动所有服务。

使用docker-compose搭建基于gogs+MySQL的个人git仓库，在映射2222:22端口的时候，报如下错误：

docker作为一个容器平台，它有一套自己的存储系统。它支持的driver有overlay,overlay2, aufs等等。 启动docker，删除本地所有的镜像。进入/var/lib/docker/overlay目录，可以看到此时这个目录下面什么都没有，是空的。

dockerd failed to start daemon: error initializing graphdriver: driver not supported

Docker 19.03 引入的插件 buildx[4]，可以很轻松地构建多平台 Docker 镜像。buildx 是 docker build … 命令的下一代替代品，它利用 BuildKit[5] 的全部功能扩展了 docker build 的功能。

原理也很简单，之前已经提到过了，buildx 会通过 QEMU 和 binfmt_misc 分别为 3 个不同的 CPU 架构（arm，arm64 和 amd64）构建 3 个不同的镜像。构建完成后，就会创建一个 manifest list[7]，其中包含了指向这 3 个镜像的指针。

apk Alpine Linux 下的包管理工具

Docker 的 buildx 还是实验性功能，需要在 Docker Desktop 设置中开启，具体位于 Preferences > Experimental Features > Enable CLI experimental features。

通过运行另外一个容器，并让其跟想要调试的容器共享 pid/network namespace 是我们能像本地调试的关键。

dc02、dc03继承自dc01

那些最原始的镜像又是怎么做出来的呢？比如我们拉了个 nginx 镜像，但是实际上只是某个人在 centos 镜像上搭建了个 nginx 放出来，那这个最原始的 centos 镜像是怎么做出来的？

大部分的文章讨论的都是怎么从docker hub或者openvz上下载基础镜像，然后添加自己的功能制作镜像，包括涵盖了大部分docker内容的。但是如果实在找不到想要的基础镜像，比如我想制作Fedora Core 2的基础镜像，可是找了好久都没有找到，就需要自己从头制作基础镜像。

Dockerfile是一个包含用于组合映像的命令的文本文档。可以使用在命令行中调用任何命令。 Docker通过读取Dockerfile中的指令自动生成映像。

https://github.com/lizrice/containers-from-scratch/blob/master/main.go

https://github.com/lizrice/containers-from-scratch

部署 registry 容器 首先我们在本地部署一个 registry 容器，再使用 skopeo 工具替代 Docker 命令行客户端进行 copy 镜像和 delete 镜像。 启动 registry 容器，docker run！ -v /var/lib/registry:/var/lib/registry ，将本地的存储目录挂载到容器内的 registry 存储目录下。 -v pwd/certs:/certs，将生成的 SSL 证书挂载到容器内。 -e REGISTRY_STORAGE_DELETE_ENABLED=true，添加该参数才能进行 DELETE 镜像操作，不然的话会提示 Error in deleting repository in a private registry V2 #1573 这种错误。 GC 是什么？ GC（Garbage collection）指垃圾回收。此前，《Kubernetess 中的垃圾回收》一文对 GC 的概念、策略以及实现方法有过简单的介绍。现在，我们通过 Docker 官方文档 Garbage collection 的例子对其进一步了解。 假如有镜像 A 和镜像 B，分别引用了layer a、b 和 a、c。

https://juejin.im/post/5ec9111851882542ed670e03 首先Go本身在交叉编译方法十分强大，这里就不再赘述了，有需要的同学可以参考《Golang交叉编译各个平台的二进制文件》。虽然自带的交叉编译已足够强大，并且能满足大部分的使用场景，但还是有一个坑人的地方就是当源代码中包含CGO代码时，默认交叉编译就会出错，具体可以参考《CGO_ENABLED环境变量对Go静态编译机制的影响》。实际上有一种可以一劳永逸地解决，并保证线下编译与线上部署环境一致的项目构建方法，那就是基于Docker的“交叉编译方案”。 Docker是近年来十分流行的Linux容器化技术，相比传统的虚拟机技术，其占用的系统资源更小，体积小，启动速度也非常迅捷。同时Docker已经能在主流操作系统Windows, macOS和Linux上得到快速的构建，这一点对本文接下来要讲的交叉编译十分重要。有关容器的详细介绍具体可参考docker入门教程，其安装方法也非常简单。

https://mp.weixin.qq.com/s/UCm27by8Ro7NzFflsPISCQ https://github.com/GoogleCloudPlatform 当涉及到建造Docker containers问题的时候，你应该尽力获得较小的镜像。文件层既共享又小的镜像能够更快的进行传输和部署。

简介 一图看尽 docker 镜像 docker 镜像代表了容器的文件系统里的内容，是容器的基础，镜像一般是通过 Dockerfile 生成的 docker 的镜像是分层的，所有的镜像（除了基础镜像）都是在之前镜像的基础上加上自己这层的内容生成的 每一层镜像的元数据都是存在 json 文件中的，除了静态的文件系统之外，还会包含动态的数据 使用镜像：docker image 命令 docker client 提供了各种命令和 daemon 交互，来完成各种任务，其中和镜像有关的命令有：

安全计算模式（secure computing mode，seccomp）是 Linux 内核功能，可以使用它来限制容器内可用的操作。

https://github.com/kiwenlau/kubernetes-shell https://github.com/kiwenlau/kubernetes-supervisor 一般来说，Docker容器比较适合运行单个进程。例如，项目”使用多个Docker容器运行Kubernetes“，Kubernetes的各个组件分别运行在各个容器之中，每个容器只运行单个进程。

对于Docker来说，存在镜像、容器、存储卷和网络这些对象。因此，也就会生产相对应的这些对象，这些对象会占据磁盘空间。当这些对象不在被使用时，为了不占据额外的磁盘空间，就需要对这些对象进行清理，即进行垃圾清理。在docker 1.13版本之后，提供了对各种对象的prune命令，也提供了清理所有对象类型的docker system prune命令。但在docker 1.13之前的版本，则需要提供其他方式进行垃圾清理。

当检查你的Kubernetes集群的节点时，在节点上执行命令docker ps，你可能会注意到一些被称为“暂停（/pause）”的容器。 $ docker ps CONTAINER ID IMAGE COMMAND … … 3b45e983c859 gcr.io/google_containers/pause-amd64:3.0 “/pause” … … dbfc35b00062 gcr.io/google_containers/pause-amd64:3.0 “/pause” … … c4e998ec4d5d gcr.io/google_containers/pause-amd64:3.0 “/pause” … … 508102acf1e7 gcr.io/google_containers/pause-amd64:3.0 “/pause” …

http://wsfdl.com/kubernetes/2019/01/10/list_watch_in_k8s.html K8S 组件之间仅采用 HTTP 协议通信，没有依赖中间件时，我非常好奇它是如何做到的。

圾回收（GC，Garbage Collection）机制针对Kubernetes1.1.7，docker容器。

Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，我们可以理解它为一个高可用强一致性的服务发现存储仓库。

https://github.com/RisingStack/kubernetes-graceful-shutdown-example 一直以来我对优雅地停止 Pod 这件事理解得很单纯: 不就利用是 PreStop hook 做优雅退出吗? 但这周听了组里大哥的教诲之后，发现很多场景下 PreStop hook 并不能很好地完成需求，这篇文章就简单分析一下”优雅地停止 Pod”这回事儿.

K8S 底层网络所需要解决的两个问题

https://www.nuagenetworks.net/blog/container-networking-standards/ https://xuxinkun.github.io/2016/07/22/cni-cnm/

kubernetes可以为pod提供dns内部域名解析服务。其主要作用是为pod提供可以直接通过service的名字解析为对应service的ip的功能。

由于 go 最终是编译为一个二进制可执行文件，没有运行时依赖，也不需要管理库，丢到服务器上就可以直接运行。所以，如果你有一个二进制文件，那么在容器中打包二进制文件的要点是什么？如果使用 docker 的话，还得在服务器上装 docker，那么把最终程序打包成 docker 有什么好处呢？

PID namespace 用来隔离进程的 PID 空间，使得不同 PID namespace 里的进程 PID 可以重复且互不影响。PID namesapce 对容器类应用特别重要， 可以实现容器内进程的暂停/恢复等功能，还可以支持容器在跨主机的迁移前后保持内部进程的 PID 不发生变化。 PID namesapce 与 /proc Linux下的每个进程都有一个对应的 /proc/PID 目录，该目录包含了大量的有关当前进程的信息。 对一个 PID namespace 而言，/proc 目录只包含当前 namespace 和它所有子孙后代 namespace 里的进程的信息。

命名空间的本质就是指：一种在空间上隔离的概念，当下盛行的许多容器虚拟化技术（典型代表如LXC、Docker）就是基于linux命名空间的概念而来的。 主要是三个系统调用

Linux Namespace 是kernel 的一个功能，它可以隔离一系列系统的资源，比如PID(Process ID)，User ID, Network等等。一般看到这里，很多人会想到一个命令chroot，就像chroot允许把当前目录变成根目录一样(被隔离开来的)，Namesapce也可以在一些资源上，将进程隔离起来，这些资源包括进程树，网络接口，挂载点等等。 使用Namespace， 我们就可以做到UID级别的隔离，也就是说，我们可以以UID为n的用户，虚拟化出来一个namespace，在这个namespace里面，用户是具有root权限的。但是在真实的物理机器上，他还是那个UID为n的用户，这样就解决了用户之间隔离的问题。当然这个只是Namespace其中一个简单的功能。

1、首先使用docker创建一个容器，并获取该容器的network namespace $ docker run -itd –name test ubuntu /bin/bash $ docker ps $ docker inspect –format ‘{{ .State.Pid }}’ test 3656 由上可知，该容器的network namespace在/proc/3656/ns/net

https://github.com/opencontainers/runc/tree/v1.0.0-rc6 容器运行时(Container Runtime)是指管理容器和容器镜像的软件。当前业内比较有名的有docker，rkt等。如果不同的运行时只能支持各自的容器，那么显然不利于整个容器技术的发展。于是在2015年6月，由Docker以及其他容器领域的领导者共同建立了围绕容器格式和运行时的开放的工业化标准，即Open Container Initiative(OCI)，OCI具体包含两个标准：运行时标准(runtime-spec)和容器镜像标准(image-spec)。简单来说，容器镜像标准定义了容器镜像的打包形式(pack format)，而运行时标准定义了如何去运行一个容器。

先查看当前docker容器进程号 docker inspect –format ‘{{ .State.Pid }}’ CONTAINER ID #CONTAINER ID可以用命令docker ps 查看 获得pid进程号为

docker inspect –format ‘{{ .State.Pid }}’ da27b7caa4bd

10822 用这个查看10822进程对于的所有namespace文件

ll /proc/10822/ns

lrwxrwxrwx 1 root root 0 Nov 8 17:56 ipc -> ipc:[4026532224] lrwxrwxrwx 1 root root 0 Nov 8 17:56 mnt -> mnt:[4026532222] lrwxrwxrwx 1 root root 0 Nov 8 17:56 net -> net:[4026532227] lrwxrwxrwx 1 root root 0 Nov 8 17:56 pid -> pid:[4026532225] lrwxrwxrwx 1 root root 0 Nov 8 17:56 user -> user:[4026531837] lrwxrwxrwx 1 root root 0 Nov 8 17:56 uts -> uts:[4026532223] 可以看到，一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。

进入Docker容器比较常见的几种做法如下：

Namespace是对全局系统资源的一种封装隔离，使得处于不同namespace的进程拥有独立的全局系统资源，改变一个namespace中的系统资源只会影响当前namespace里的进程，对其他namespace中的进程没有影响。

https://www.docker.com/products/container-runtime 19.03.2 https://docs.docker.com/engine/release-notes/ Docker新特性如下的几个点： 多阶段构建 资源管理 Docker secrets swarm mode 健康检查 首先介绍Docker新推出的多阶段构建；其次介绍一下Docker在资源管理方面新加的一些命令，这些命令可以方便开发者来做资源管理；还有就是介绍一下Docker secret跟之前那些密码管理的方式有什么不同；还有就是swarm mode里面的一些新特性；最后再介绍一下swarm mode下面的健康检查。

为了解决docker stats的问题(存储、展示)，谷歌开源的cadvisor诞生了，cadvisor不仅可以搜集一台机器上所有运行的容器信息，还提供基础查询界面和http接口，方便其他组件如Prometheus进行数据抓取，或者cadvisor + influxdb + grafna搭配使用。 cAdvisor可以对节点机器上的资源及容器进行实时监控和性能数据采集，包括CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况 Cadvisor使用Go语言开发，利用Linux的cgroups获取容器的资源使用信息，在K8S中集成在Kubelet里作为默认启动项，官方标配 .使用docker部署

Docker跨主机容器间网络通信实现的工具有Pipework、Flannel、Weave、Open vSwitch（虚拟交换机）、Calico Weave的思路 在每个宿主机上布置一个特殊的route的容器，不同宿主机的route容器连接起来。 route拦截所有普通容器的ip请求，并通过udp包发送到其他宿主机上的普通容器。这样在跨机的多个容器端看到的就是同一个扁平网络。 weave解决了网络问题，不过部署依然是单机的。

Flannel实质上是一种“覆盖网络(overlay network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。 默认的节点间数据通信方式是UDP转发。 数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。 Flannel通过Etcd服务维护了一张节点间的路由表，详细记录了各节点子网网段 。 源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容器。

软件定义网络（Software Defined Network，SDN）是由美国斯坦福大学CLean State课题研究组提出的一种新型网络创新架构，是网络虚拟化的一种实现方式。其核心技术OpenFlow通过将网络设备的控制面与数据面分离开来，从而实现了网络流量的灵活控制，使网络作为管道变得更加智能，为核心网络及应用的创新提供了良好的平台。 软件定义网络（ SDN）是一种软件集中控制、网络开放的三层体系架构。应用层实现对网络业务的呈现和网络模型的抽象；控制层实现网络操作系统功能，集中管理网络资源；转发层实现分组交换功能。应用层与控制层之间的北向接口是网络开放的核心，控制层的产生实现了控制面与转发面的分离，是集中控制的基础。

macvlan 这里的macvlan是linux kernel提供的一种network driver类型，它有别于传统交换机上提供的mac based vlan功能。可以在linux命令行执行lsmod | grep macvlan 查看当前内核是否加载了该driver；如果没有查看到，可以通过modprobe macvlan来载入 内核源码，可以到以下路径：/drivers/net/macvlan.c

Hypervisor，又称虚拟机监视器（英语：virtual machine monitor，缩写为 VMM），是用来建立与执行虚拟机器的软件、固件或硬件。 被Hypervisor用来执行一个或多个虚拟机器的电脑称为主体机器（host machine），这些虚拟机器则称为客体机器（guest machine）。hypervisor提供虚拟的作业平台来执行客体操作系统（guest operating systems），负责管理其他客体操作系统的执行阶段；这些客体操作系统，共同分享虚拟化后的硬件资源。 Hypervisor——一种运行在基础物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享硬件。也可叫做VMM（ virtual machine monitor ），即虚拟机监视器。 Hypervisors是一种在虚拟环境中的“元”操作系统。他们可以访问服务器上包括磁盘和内存在内的所有物理设备。Hypervisors不但协调着这些硬件资源的访问，也同时在各个虚拟机之间施加防护。当服务器启动并执行Hypervisor时，它会加载所有虚拟机客户端的操作系统同时会分配给每一台虚拟机适量的内存，CPU，网络和磁盘。

容器技术的最大意义在于其不需要同时使用多个操作系统，而在hypervisor虚拟化环境当中每台虚拟机都需要使用独立的操作系统。显而易见，这种方式能够大幅度降低系统开销所占用的内存，能够为应用及其数据预留更多的空间。 使用容器技术能够节约大量操作系统所占用的内存空间。通常相比于hypervisor，使用容器能够在同一台服务器当中创建三倍的实例数量。在某些情况当中，比如完全一样的虚拟桌面，实例数量能够达到之前的十倍。从另外一个角度来说，特定负载所需的服务器数量也就大幅降低了。授权部分也会受到影响，企业只需要为每台服务器购买一个授权。由于应用成为共享镜像的一部分，因此也能够从中获益。

传统的Linux加载bootfs时会先将rootfs设为read-only，然后在系统自检之后将 rootfs从read-only改为read-write，然后我们就可以在rootfs上进行写和读的操作了。但docker的镜像却不是这样，它在 bootfs自检完毕之后并不会把rootfs的read-only改为read-write。而是利用union mount（UnionFS的一种挂载机制）将一个或多个read-only的rootfs加载到之前的read-only的rootfs层之上。在加载 了这么多层的rootfs之后，仍然让它看起来只像是一个文件系统，在docker的体系里把union mount的这些read-only的rootfs叫做Docker的镜像。但是，此时的每一层rootfs都是read-only的，我们此时还不能对 其进行操作。当我们创建一个容器，也就是将Docker镜像进行实例化，系统会在一层或是多层read-only的rootfs之上分配一层空的 read-write的rootfs。 0328091.png docker镜像这种层次化的组织方式带来了很多好处，首先是节约了镜像在物理机上占用的空间，其次是创建一个新的空的rootfs很容易，这就意味着容器相比其它虚拟化技术可以更加快速启动。

Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。因此在操作系统层面上看，就会出现多个相同pid的进程。系统中可以同时存在两个进程号为0,1,2的进程，由于属于不同的namespace，所以它们之间并不冲突。而在用户层面上只能看到属于用户自己namespace下的资源，例如使用ps命令只能列出自己namespace下的进程。这样每个namespace看上去就像一个单独的Linux系统 Linux内核中namespace结构体 在Linux内核中提供了多个namespace，其中包括fs (mount), uts, network, sysvipc, 等。一个进程可以属于多个namesapce,既然namespace和进程相关，那么在task_struct结构体中就会包含和namespace相关联的变量。在task_struct 结构中有一个指向namespace结构体的指针nsproxy。

Libcontainer 是Docker中用于容器管理的包，它基于Go语言实现，通过管理namespaces、cgroups、capabilities以及文件系统来进行容器控制。你可以使用Libcontainer创建容器，并对容器进行生命周期管理。 在 2013年Docker刚发布的时候，它是一款基于LXC的开源容器管理引擎。把LXC复杂的容器创建与使用方式简化为Docker自己的一套命令体系。 随着Docker的不断发展，它开始有了更为远大的目标，那就是反向定义容器的实现标准，将底层实现都抽象化到Libcontainer的接口。这就意味 着，底层容器的实现方式变成了一种可变的方案，无论是使用namespace、cgroups技术抑或是使用systemd等其他方案，只要实现了 Libcontainer定义的一组接口，Docker都可以运行。这也为Docker实现全面的跨平台带来了可能。

AppArmor是一个高效和易于使用的Linux系统安全应用程序。AppArmor对操作系统和应用程序所受到的威胁进行从内到外的保护，甚至是未被发现的0day漏洞和未知的应用程序漏洞所导致的攻击。AppArmor安全策略可以完全定义个别应用程序可以访问的系统资源与各自的特权。AppArmor包含大量的默认策略，它将先进的静态分析和基于学习的工具结合起来，AppArmor甚至可以使非常复杂的应用可以使用在很短的时间内应用成功。 AppArmor已经整合进2.6.36版内核。 Docker可以通过AppArmor或者SELinux进行访问控制，既然是访问控制的过程中难免需要进行对其的配置。此项目是通过AppArmor进行防护的，在配置时遇到了许多问题，在此记录。 1.如何调用AppArmor进行Docker的权限控制 这一项在官方文档中有记载。在启动或者运行docker通过参数”–security-opt”加入访问控制的配置文件。–security-opt的默认参数为docker-default。docker-default并非一个实际的配置文件，而是由执行时由GO语言运行的配置模板自动生成并写入AppArmor缓存。(Docker versions 1.13.0 and later) 2.为Docker配置权限文件 由于是为docker的container进行安全配置，我们将配置文件放置于/etc/containers/目录下。为方便管理配置文件的命名与配置名同名。官方列举了一个Nginx 的docker配置文件 #include <tunables/global> profile docker-nginx flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base>

从原理角度来讲：

https://github.com/lxc/lxc LXC是Linux containers的简称，操作系统级别的虚拟化技术。它可以在操作系统层次上为进程提供的虚拟的执行环境。一个虚拟的执行环境被称为一个容器(container)。可以为容器绑定特定的cpu和memory节点，分配特定比例的cpu时间、IO时间，限制可以使用的内存大小（包括内存和是swap空间），提供device访问控制，提供独立的namespace（网络、pid、ipc、mnt、uts）。 容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。与虚拟化相比，这样既不需要指令级模拟，也不需要即时编译。容器可以在核心 CPU 本地运行指令，而不需要任何专门的解释机制。此外，也避免了准虚拟化（paravirtualization）和系统调用替换中的复杂性。

https://github.com/lxc/lxc lxc_start.c int main(int argc, char *argv[]) { int err = 1; struct lxc_conf *conf; //初始化config结构 char *const *args; //传递的参数 char *rcfile = NULL; //指定配置文件 char *const default_args[] = { //默认的args参数 “/sbin/init”, NULL, };
struct lxc_container *c; //lxc-container 的结构体 …. } lxc_conf这个数据结构 struct lxc_conf { int is_execute; //容器是否在执行 char *fstab; //fstab？ int tty; //tty的个数 int pts; //pts的个数？ int reboot; //重启？ int need_utmp_watch; //字面翻译 需要utmp 查看 signed long personality; //字面翻译 特点 struct utsname *utsname; //ustname struct lxc_list cgroup; //cgroup list lxc_list只是简单的链表结构 struct lxc_list id_map; //id_map list struct lxc_list network; //network list struct saved_nic *saved_nics;//saved_nics 结构 int num_savednics; //savednics数量？ int auto_mounts; //auto_mounts? struct lxc_list mount_list; //mount_list list? struct lxc_list caps; //caps list？ struct lxc_list keepcaps; //keepcaps list? struct lxc_tty_info tty_info; //tty的相关信息 struct lxc_console console; //console的结构体 struct lxc_rootfs rootfs; //rootfs的结构体 char *ttydir; //tty目录 int close_all_fds; //关闭所有fd struct lxc_list hooks[NUM_LXC_HOOKS]; //hooks 函数

char *lsm_aa_profile;   //?
char *lsm_se_context;	//?
int tmp_umount_proc;	//?
char *seccomp;  // filename with the seccomp rules #if HAVE_SCMP_FILTER_CTX
scmp_filter_ctx seccomp_ctx; #endif
int maincmd_fd;		//?
int autodev;  // if 1, mount and fill a /dev at start
int haltsignal; // signal used to halt container
int stopsignal; // signal used to hard stop container
int kmsg;  // if 1, create /dev/kmsg symlink
char *rcfile;   // Copy of the top level rcfile we read
 
// Logfile and loglevel can be set in a container config file.
// Those function as defaults.  The defaults can be overriden
// by command line.  However we don't want the command line
// specified values to be saved on c->save_config().  So we
// store the config file specified values here.
char *logfile;  // the logfile as specifed in config
int loglevel;   // loglevel as specifed in config (if any)
 
int inherit_ns_fd[LXC_NS_MAX];
 
int start_auto;
int start_delay;
int start_order;
struct lxc_list groups;
int nbd_idx;
 
/* set to true when rootfs has been setup */
bool rootfs_setup; };

Docker最开始采用AUFS作为文件系统，也得益于AUFS分层的概念，实现了多个Container可以共享同一个image。但由于AUFS未并入Linux内核，且只支持Ubuntu，考虑到兼容性问题，在Docker 0.7版本中引入了存储驱动， 目前，Docker支持AUFS、Btrfs、Device mapper、OverlayFS、ZFS五种存储驱动。就如Docker官网上说的，没有单一的驱动适合所有的应用场景，要根据不同的场景选择合适的存储驱动，才能有效的提高Docker的性能。如何选择适合的存储驱动，要先了解存储驱动原理才能更好的判断，本文介绍一下Docker五种存储驱动原理详解及应用场景及IO性能测试的对比。在讲原理前，先讲一下写时复制和写时分配两个技术。 一、原理说明 写时复制（CoW） 所有驱动都用到的技术——写时复制（CoW）。CoW就是copy-on-write，表示只在需要写时才去复制，这个是针对已有文件的修改场景。比如基于一个image启动多个Container，如果为每个Container都去分配一个image一样的文件系统，那么将会占用大量的磁盘空间。而CoW技术可以让所有的容器共享image的文件系统，所有数据都从image中读取，只有当要对文件进行写操作时，才从image里把要写的文件复制到自己的文件系统进行修改。所以无论有多少个容器共享同一个image，所做的写操作都是对从image中复制到自己的文件系统中的复本上进行，并不会修改image的源文件，且多个容器操作同一个文件，会在每个容器的文件系统里生成一个复本，每个容器修改的都是自己的复本，相互隔离，相互不影响。使用CoW可以有效的提高磁盘的利用率。 用时分配（allocate-on-demand） 而写时分配是用在原本没有这个文件的场景，只有在要新写入一个文件时才分配空间，这样可以提高存储资源的利用率。比如启动一个容器，并不会为这个容器预分配一些磁盘空间，而是当有新文件写入时，才按需分配新空间。 AUFS AUFS（AnotherUnionFS）是一种Union FS，是文件级的存储驱动。AUFS能透明覆盖一或多个现有文件系统的层状文件系统，把多层合并成文件系统的单层表示。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的，只有最上层的文件系统是可写的。当需要修改一个文件时，AUFS创建该文件的一个副本，使用CoW将文件从只读层复制到可写层进行修改，结果也保存在可写层。在Docker中，底下的只读层就是image，可写层就是Container。 Overlay Overlay是Linux内核3.18后支持的，也是一种Union FS，和AUFS的多层不同的是Overlay只有两层：一个upper文件系统和一个lower文件系统，分别代表Docker的镜像层和容器层。当需要修改一个文件时，使用CoW将文件从只读的lower复制到可写的upper进行修改，结果也保存在upper层。在Docker中，底下的只读层就是image，可写层就是Container Device mapper Device mapper是Linux内核2.6.9后支持的，提供的一种从逻辑设备到物理设备的映射框架机制，在该机制下，用户可以很方便的根据自己的需要制定实现存储资源的管理策略。前面讲的AUFS和OverlayFS都是文件级存储，而Device mapper是块级存储，所有的操作都是直接对块进行操作，而不是文件。Device mapper驱动会先在块设备上创建一个资源池，然后在资源池上创建一个带有文件系统的基本设备，所有镜像都是这个基本设备的快照，而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照，并不有为容器分配空间。当要写入一个新文件时，在容器的镜像内为其分配新的块并写入数据，这个叫用时分配。当要修改已有文件时，再使用CoW为容器快照分配块空间，将要修改的数据复制到在容器快照中新的块里再进行修改。Device mapper 驱动默认会创建一个100G的文件包含镜像和容器。每一个容器被限制在10G大小的卷内，可以自己配置调整。 Btrfs Btrfs被称为下一代写时复制文件系统，并入Linux内核，也是文件级级存储，但可以像Device mapper一直接操作底层设备。Btrfs把文件系统的一部分配置为一个完整的子文件系统，称之为subvolume 。那么采用 subvolume，一个大的文件系统可以被划分为多个子文件系统，这些子文件系统共享底层的设备空间，在需要磁盘空间时便从底层设备中分配，类似应用程序调用 malloc()分配内存一样。为了灵活利用设备空间，Btrfs 将磁盘空间划分为多个chunk 。每个chunk可以使用不同的磁盘空间分配策略。比如某些chunk只存放metadata，某些chunk只存放数据。这种模型有很多优点，比如Btrfs支持动态添加设备。用户在系统中增加新的磁盘之后，可以使用Btrfs的命令将该设备添加到文件系统中。Btrfs把一个大的文件系统当成一个资源池，配置成多个完整的子文件系统，还可以往资源池里加新的子文件系统，而基础镜像则是子文件系统的快照，每个子镜像和容器都有自己的快照，这些快照则都是subvolume的快照。 当写入一个新文件时，为在容器的快照里为其分配一个新的数据块，文件写在这个空间里，这个叫用时分配。而当要修改已有文件时，使用CoW复制分配一个新的原始数据和快照，在这个新分配的空间变更数据，变结束再更新相关的数据结构指向新子文件系统和快照，原来的原始数据和快照没有指针指向，被覆盖。 ZFS ZFS 文件系统是一个革命性的全新的文件系统，它从根本上改变了文件系统的管理方式，ZFS 完全抛弃了“卷管理”，不再创建虚拟的卷，而是把所有设备集中到一个存储池中来进行管理，用“存储池”的概念来管理物理存储空间。过去，文件系统都是构建在物理设备之上的。为了管理这些物理设备，并为数据提供冗余，“卷管理”的概念提供了一个单设备的映像。而ZFS创建在虚拟的，被称为“zpools”的存储池之上。每个存储池由若干虚拟设备（virtual devices，vdevs）组成。这些虚拟设备可以是原始磁盘，也可能是一个RAID1镜像设备，或是非标准RAID等级的多磁盘组。于是zpool上的文件系统可以使用这些虚拟设备的总存储容量。 下面看一下在Docker里ZFS的使用。首先从zpool里分配一个ZFS文件系统给镜像的基础层，而其他镜像层则是这个ZFS文件系统快照的克隆，快照是只读的，而克隆是可写的，当容器启动时则在镜像的最顶层生成一个可写层。 当要写一个新文件时，使用按需分配，一个新的数据快从zpool里生成，新的数据写入这个块，而这个新空间存于容器（ZFS的克隆）里。 当要修改一个已存在的文件时，使用写时复制，分配一个新空间并把原始数据复制到新空间完成修改。 二、存储驱动的对比及适应场景 UFS VS Overlay AUFS和Overlay都是联合文件系统，但AUFS有多层，而Overlay只有两层，所以在做写时复制操作时，如果文件比较大且存在比较低的层，则AUSF可能会慢一些。而且Overlay并入了linux kernel mainline，AUFS没有，所以可能会比AUFS快。但Overlay还太年轻，要谨慎在生产使用。而AUFS做为docker的第一个存储驱动，已经有很长的历史，比较的稳定，且在大量的生产中实践过，有较强的社区支持。目前开源的DC/OS指定使用Overlay。 Overlay VS Device mapper Overlay是文件级存储，Device mapper是块级存储，当文件特别大而修改的内容很小，Overlay不管修改的内容大小都会复制整个文件，对大文件进行修改显示要比小文件要消耗更多的时间，而块级无论是大文件还是小文件都只复制需要修改的块，并不是整个文件，在这种场景下，显然device mapper要快一些。因为块级的是直接访问逻辑盘，适合IO密集的场景。而对于程序内部复杂，大并发但少IO的场景，Overlay的性能相对要强一些。 Device mapper VS Btrfs Driver VS ZFS Device mapper和Btrfs都是直接对块操作，都不支持共享存储，表示当有多个容器读同一个文件时，需要生活多个复本，所以这种存储驱动不适合在高密度容器的PaaS平台上使用。而且在很多容器启停的情况下可能会导致磁盘溢出，造成主机不能工作。Device mapper不建议在生产使用。Btrfs在docker build可以很高效。 ZFS最初是为拥有大量内存的Salaris服务器设计的，所在在使用时对内存会有影响，适合内存大的环境。ZFS的COW使碎片化问题更加严重，对于顺序写生成的大文件，如果以后随机的对其中的一部分进行了更改，那么这个文件在硬盘上的物理地址就变得不再连续，未来的顺序读会变得性能比较差。ZFS支持多个容器共享一个缓存块，适合PaaS和高密度的用户场景。

docker启动失败，诊断信息如下： Information Diagnostic ID D466944B-790A-45B7-A2D8-3CF4FEDFBAC6

下载地址 https://docs.docker.com/docker-for-mac/release-notes/ 由于我的版本是10.11.1，最后兼容的docker for mac 是 Docker Community Edition 18.06.1-ce-mac73 2018-08-29 其他版本不再支持，这也是支持k8s的最高版本的docker for mac 下载地址：https://download.docker.com/mac/stable/26764/Docker.dmg

cd ~/.ssh/ vim config 写入以下内容： HostName 121.41.211.120 User web IdentityFile ~/.ssh/id_rsa ServerAliveInterval 30

https://github.com/maguowei/k8s-docker-desktop-for-mac 下载最新的Docker for Mac Edge 版本，跟普通mac软件一样安装，然后运行它，会在右上角菜单栏看到多了一个鲸鱼图标，这个图标表明了 Docker 的运行状态。 配置镜像加速地址 鉴于国内网络问题，国内从 Docker Hub 拉取镜像有时会遇到困难，此时可以配置镜像加速器。Docker 官方和国内很多云服务商都提供了国内加速器服务。

$ screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty 用 Docker for Mac 已经很久了，用它跑本地开发环境可以说是非常方便，自打有了它，就再也没打开过 VMware Fusion。前段时间 Docker for Mac 又加入了 Kubernetes 支持，能在本地自动起一个单节点 Kubernetes 集群（就当它是集群），这就省去了手工搭建的步骤，简单好用。可以参考官方文档了解一下如何开启 Docker for Mac 的 Kubernetes。

因为有了 Docker 这个东西。它依赖于 LXC(Linux Container)，能从网络上获得配置好的 Linux 镜像，非常容易在隔离的系统中运行自己的应用。也因为它的底层核心是个 LXC，所以在 Mac OS X 下需要在 VirtualBox 中跑一个精小的 LXC(这里是一个 Tiny Core Linux，完全在内存中运行，个头只约 24MB，启动时间小于 5 秒的 boot2docker) 虚拟机，构建在 VirtualBox 中。以后的通信过程就是 docker–> boot2docker –> container，端口或磁盘映射也是遵照这一关系。 Docker 安装过程

VBoxManage是VirtualBox的命令行接口。利用他，你可以在主机操作系统的命令行中完全地控制VirtualBox。VBoxManage支持GUI可访问的全部功能，而且更多。VBoxManage展示了虚拟化引擎的全部特征，包括GUI无法访问的。 使用VBoxManage时要记住两件事： 第一，VBoxManage必须和一个具体和“子命令”一起使用，比如“list”或“createvm“或“startvm”。 第二，大多数子命令需要在其后指定特定的虚拟机。有两种方式： 指定虚拟机的名称，和其在GUI中显示的一样。注意，如果名称包含空格，必须将全部名称包含在双引号中（和命令行参数包含空格时的要求一样）。 例如： VBoxManage startvm “Windows XP” 指定其UUID，VirtualBox用来引用虚拟机的内部唯一标识符。设上述名称为“Windows XP”的虚拟机有如下UUID，下面的命令有同样的效果：

VBoxManage startvm 670e746d-abea-4ba6-ad02-2a3b043810a5 使用VBoxManage list vms可列出当前注册的所有虚拟机的名称及其对应的UUID。 通过命令行控制VirtualBox的典型用法如下： 使用命令新建虚拟机并立即在VirtualBox中注册，使VBoxManage createvm的–register选项：

$ VBoxManage createvm –name “SUSE 10.2” –register VirtualBox Command Line Management Interface Version 3.1.6 (C) 2005-2010 Sun Microsystems, Inc. All rights reserved.

Virtual machine ‘SUSE 10.2’ is created. UUID: c89fc351-8ec6-4f02-a048-57f4d25288e5 Settings file: ‘/home/username/.VirtualBox/Machines/SUSE 10.2/SUSE 10.2.xml’ 从上面的输出可以看到，一个新的虚拟机被创建，带有一个新的UUID和新的XML的设置文件。 显示虚拟机的配置，使用VBoxManage showvminfo；详见“VBoxManage showvminfo”。 修改虚拟机的设置，使用VBoxManage modifyvm，例如：

VBoxManage modifyvm “Windows XP” –memory “512MB” 详见“VBoxManage modifyvm”。 控制虚拟机的运行，使用下列其中一个： 启动当前关闭的虚拟机，使用VBoxManage startvm；详见“VBoxManage startvm”。 暂停或保存当前运行的虚拟机，使用VBoxManage controlvm；详见“VboxManage controlvm”。 命令概述 不带参数运行VBoxManage或使用了无效的参数，将显示下面的语法图。注意，根据主机平台，输出可能会稍有不同；如有疑问，请检查VBoxManage在您的特定主机的可用命令输出。 （译者注：没翻译语法图，请运行VBoxManage查看输出，原文见http://www.virtualbox.org/manual/ch08.html#id2535703）。 每次调用VBoxManage，只能执行一个命令。但是，一个命令可能支持几个子命令在同一行被调用。接下来的部分是每个命令的详细参考。 VBoxManage list list命令提供你的系统和VirtualBox当前设置的相关信息。 VboxManage list有如下可用子命令： vms 列出当前在VirtualBox注册的所有虚拟机。默认显示包含每个虚拟机的名字和UUID的紧凑列表。如果指定了–long或–l参数，将显示和showvminfo命令一样的详细列表。 runningvms 用和vms相同的格式列出当前正在运行的虚拟机的唯一标识符（UUID）。 hdds，dvds，floppies 显示当前所有在VirtualBox注册的虚拟磁盘镜像的信息，包括其所有设置，在VirtualBox中的UUID和与其关联的所有文件。 ostypes 列出VirtualBox目前支持的所有客户机操作系统，及其在modifyvm命令中引用它的标识符。 hostdvds，hostfloppies，hostifs 相应地，列出主机上的DVD，软驱和网络接口，及用来在VirtualBox中访问他们的名字。 hostusb 提供主机上的USB设备的信息，特别是用来建立USB筛选器的信息和当前是否被主机使用。 usbfilters 列出所有在VirtualBox中注册的全局USB筛选器——即，所有虚拟机都可能访问的设备的筛选器——及其参数。 systemproperties 显示部分VirutalBox的全局设置，比如客户机内存和虚拟硬盘尺寸的最大和最小值，文件夹设置和当前使用的验证库。 hddbackends 列出所有VirtualBox已知的硬盘驱动器后端。除了后端本身的名字，还显示了功能说明、配置和其他有用信息。 VBoxManage showvminfo showvminfo命令显示特定虚拟机的信息。这和VBoxManage list vms –long为所有虚拟机显示的内容相同。 你将得到类似下面的信息： $ VBoxManage showvminfo “Windows XP” VirtualBox Command Line Management Interface Version 3.1.6 (C) 2005-2010 Sun Microsystems, Inc.

安装时还是用的 boot2docker, 如今进化到了在 Mac OS X 下用 Docker Toolbox, 而且命令也由 boot2docker 换成了 docker-machine. 当然由于是非 Linux 系统, 所以 Mac OS X 仍然需要借助于 VirtualBox 中的 Linux 虚拟机作为桥梁, Docker Toolbox 创建的虚拟机名是 default (boot2docker 创建的虚拟机名是 boot2docker-vm) 就是这一桥梁, 我们称之为 DOCKER_HOST. 文中的 default 虚拟机指的就是这个 DOCKER_HOST.

https://ying-zhang.github.io/yi/2017/x-eurosys15-borg-cn/ https://ying-zhang.github.io/doc/EuroSys15_Borg.pdf Large-scale cluster management at Google with Borg 摘要 谷歌的Borg系统群集管理器运行几十万个以上的jobs，来自几千个不同的应用，跨多个集群，每个集群有上万个机器。

du -sh * 这个命令用来查看根目录下，所有文件的大小分布 604K Applications 165M CRClientTools 1.2M Desktop 802M Documents 2.0G Downloads 216M GitBook du: Library/Python: Permission denied 86G Library

du -sh Library du: Library/Python: Permission denied 86G Library

cd ~/Library du -d 1 -h 16K ./com.lc-tech.licman 0B ./Compositions 66G ./Containers

$du -d 1 -h 280K ./com.apple.WeatherKitService 64G ./com.docker.docker

环境:安装docker 关闭selinux 开启路由转发（net.ipv4.ip_forward = 1） 一、将 Docker 容器配置到本地网络环境中 为了使本地网络中的机器和 Docker 容器更方便的通信，我们经常会有将 Docker 容器配置到和主机同一网段的需求。这个需求其实很容易实现，我们只要将 Docker 容器和主机的网卡桥接起来，再给 Docker 容器配上 IP 就可以了。 下面我们来操作一下，我主机 A 地址为 192.168.157.128/24,网关为 192.168.157.2,需要给 Docker容器的地址配置为 192.168.157.150/24。在主机 A 上做如下操作： 安装 pipework 下载地址：wget https://github.com/jpetazzo/pipework.git unzippipework-master.zip cp -p /root/pipework-master/pipework/usr/local/bin/ 启动 Docker 容器。 docker run -itd–name test1 镜像 /bin/bash 配置容器网络，并连到网桥 br0 上。网关在 IP 地址后面加@指定。 pipework br0 test1192.168.157.150/24@192.168.157.2 将主机 eno16777736 桥接到 br0 上，并把 eno16777736 的 IP 配置在 br0 上。 p addradd 192.168.157.128/24 dev br0 ip addrdel 192.168. 157.128/24 dev eno16777736 brctladdif br0 eno16777736 ip routedel default ip routeadd default via 192.168.157.2 dev br0 注：如果是远程操作，中间网络会断掉，所以放在一条命令中执行。 ip addradd 192.168.157.128/24 dev br0；ip addr del 192.168. 157.128/24 deveno16777736；brctl addif br0 eno16777736；ip route del default；ip route add default via 192.168.157.2dev br0 完成上述步骤后，我们发现 Docker 容器已经可以使用新的 IP 和主机网络里的机器相互通信了

Linux内核中就提供了这六种namespace隔离的系统调用，如下表所示。 Namespace 系统调用参数 隔离内容 UTS CLONE_NEWUTS 主机名与域名 IPC CLONE_NEWIPC 信号量、消息队列和共享内存 PID CLONE_NEWPID 进程编号 Network CLONE_NEWNET 网络设备、网络栈、端口等等 Mount CLONE_NEWNS 挂载点（文件系统） User CLONE_NEWUSER 用户和用户组 表 namespace六项隔离 实际上，Linux内核实现namespace的主要目的就是为了实现轻量级虚拟化（容器）服务。在同一个namespace下的进程可以感知彼此的变化，而对外界的进程一无所知。这样就可以让容器中的进程产生错觉，仿佛自己置身于一个独立的系统环境中，以此达到独立和隔离的目的。

在5台物理主机上的虚拟机中都装了Docker，每台中都有3个容器，现在要解决容器跨主机通信，五种方案： 一、利用OpenVSwitch 二、利用Weave 三、Docker在1.9之后支持的Overlay network（这个好像是官方的做法） 四、将多个物理机的容器组到一个物理网络来 1.创建自己的网桥br0 2.将docker默认网桥绑定到br0 五、修改主机docker默认的虚拟网段，然后在各自主机上分别把对方的docker网段加入到路由表中，配合iptables即可实现docker容器跨主机通信 跨主机容器通信大致有以下几种方式：

1. NAT方式 NAT就是传统的docker网络，利用宿主机的IP和Iptables来达到容器，主机之间的通信。容器对外IP都是宿主机的IP。只要宿主机之间三层可达，容器之间就可以通信。
2. Tunnel（overlay）方式 VPN，ipip，VXLAN等都是tunnel技术，简单讲就是在容器的数据包间封装一层或多层其他的数据协议头，达到连通的效果。 Docker的Libnetwork就支持vxlan的overlay方式，weave也支持UDP和Vxlan的overlay模式，flannel，calico等都支持overlay模式。 • Overlay一般通过vSwitch来实现，比如OVS • 一般需要一个全局的KV store（sdn controller、etcd、consul）来保存控制信息。
3. Routing方式 路由方案主要是通过路由设置的方式让容器对容器，容器对宿主机之间相通信。例如：calico的BGP路由方案
4. “大二层”方式 大二层就是将物理网卡和容器网络桥接到同一个linux bridge。容器网络可以直接接入该linux bridge，也可以将容器网络接入容器网桥docker0，再把docker0桥接到linux bridge上。目的是使得容器网络和宿主机网络在同一个二层网络。 docker 默认的桥接网卡是docker0,它只会在本机桥接所有的容器网卡，举例来说容器的虚拟网卡在主机上看一般叫做veth** 而docker只是把所有这些网卡桥接在一起,这样就可以把这个网络看成是一个私有的网络，通过nat 连接外网，如果要让外网连接到容器中，就需要做端口映射，即-p参数 当rocker启动时，会在主机上创建一个docker0的虚拟网卡。他随机挑选RFC1918私有网络中的一段地址给docker0。比如172.17.42.1/16,16位掩码的网段可以拥有65534个地址可以使用，这对主机和容器来说应该足够了。docker0 不是普通的网卡，他是桥接到其他网卡的虚拟网卡，容器使用它来和主机相互通信。当创建一个docker容器的时候，它就创建了一个对接口，当数据包发送到一个接口时，另外一个接口也可以收到相同的数据包，它们是绑在一起一对孪生接口。这对接口在容器中的那个的名字是eth0，主机上的接口会指定一个唯一的名字，比如vethAQI2QT这样的名字，这种接口名字不再主机的命名空间中。所有的veth的接口都会桥接到docker0，这样docker就创建了在主机和所有容器之间一个虚拟共享网络。 如果在企业内部应用，或则做多个物理主机的集群，可能需要将多个物理主机的容器组到一个物理网络中来，那么就需要将这个网桥桥接到我们指定的网卡上。下面以ubuntu为例创建多个主机的容器联网。 第一步：创建自己的网桥 编辑/etc/network/interface文件 auro br0 iface bro inet static address netmask gateway bridge_ports em1 bridge_stp off dns-nameservers 8.8.8.8 将docker的默认网桥绑定到这个新建的br0上面，这样就将这台机器上容器绑定到em1这个网卡所对应的物理网络上了。ubuntu修改/etc/default/docker文件 添加最后一行内容 DOCKER_OPTS=”-b=br0” 这改变默认的docker网卡绑定，你也可以创建多个网桥绑定到多个物理网卡上，在启动docker的时候 使用-b参数 绑定到多个不同的物理网络上。 重启docker服务后，再进入容器可以看到它已经绑定到你的物理网络上了，这样就直接把容器暴露到你的物理网络上了，多台物理主机的容器也可以相互联网了。需要注意的是，这样就需要自己来保证容器的网络安全了。 Docker发布了1.9版本，实现了原本实验性的Networking组件的支持。用户可以在Swarm中使用它或者将其作为Compose 工具。创建虚拟网络并将其连接到容器上，可实现多个主机上容器相互通信，并且实现不同的应用程序或者应用程序不同部分能够相互隔离。互联子系统设计为可插拔式，兼容VXLAN或者IPVLAN等技术。 Docker 容器实现跨主机通讯主要通过几种方式：自带overlay network插件，第三方插件如weave、ovs等，docker swarm（虽然也是通过key value service进行调用）。在这里主要介绍直接使用自带插件，以及通过docker swarm的两种实现方式。 直接使用自带插件实现容器跨主机访问 测试环境为ubuntu14.04。根据docker建议要求，将内核升级到3.19.如果内核版本过低，将会出现overlay network创建失败或加入失败等一系列问题。 内核升级 #apt-get install linux-generic-lts-vivid 升级完成，重启主机。 # uname -a Linux ukub09 3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 启动key value service 可以选择使用zookeeper、etcd、consul等多种组件。本例使用额外一台虚拟机，启用和官方文档相一致的consul镜像。 docker $(docker-machine config consul2) run -d
   -p “8501:8500”
   -h “consul”
   progrium/consul -server -bootstrap 此时可以通过ip:8501对consul服务进行访问。 将key value service信息加入docker daemon 修改希望加入docker overlay network的所有主机上docker daemon服务。 #vi /etc/dafault/docker DOCKER_OPTS=’ -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock –cluster-store=consul://172.25.2.43:8501 –cluster-advertise=eth0:2376’ 通过修改以下两个参数实现 –cluster-store= 参数指向docker daemon所使用key value service的地址 –cluster-advertise= 参数决定了所使用网卡以及docker daemon端口信息 重启docker服务。 #service docker restart docker 网络的创建与操作 此时可以通过docker network create创建-d overlay属性的驱动。 #docker network create -d overlay over 列出当前网络 root@ukub10:~# docker network ls NETWORK ID NAME DRIVER b95efb2ab985 over overlay
   0a4a123fc278 bridge bridge
   2da9ecadf108 none null
   5ca3275ec2a9 host host
   在另一台已加入key value service指向的主机上同样可以看到这个网络 root@ukub09:~# docker network ls NETWORK ID NAME DRIVER b95efb2ab985 over overlay
   b5f9713c9f2b bridge bridge
   16e1cdf30f97 none null
   cf257529463c host host docker网络的连接方式 可以在两台主机上分别创建容器，互相进行ping或ssh访问。官方文档例子创建一个nginx容器，并在另一个容器内抓取其状态进行验证。这里不再详述。 创建容器接入指定网络 #docker run -itd –name=testcontainer –net=over nginx 将容器从指定网络中退出 #docker network disconnect over testcontainer 重新连入指定网络 #docker network connect over testcontainer 连接与断开将会是实时的。在连接之后，即可通过容器名访问本网络中所有容器。 使用Swarm创建docker cluster实现跨主机管理和网络访问 根据官方文档，需要搭建起基于swarm的cluster，来实现Docker overlay network。为部署整套Docker cluster，需要安装docker machine/compose/swarm等组件。 使用第三方网络插件实现跨主机容器通讯也变得更容易了。 安装docker machine docker machine用来进行docker的推送安装，可以在许多driver上安装部署docker： amazonec2 azure digitalocean exoscale generic google none openstack rackspace softlayer virtualbox vmwarevcloudair vmwarevsphere 首先需要安装好docker engine，之后下载并将docker machine的库文件移动到bin下。 #curl -L https://github.com/docker/machine/releases/download/v0.5.0/docker-machine_linux-amd64.zip >machine.zip &&
   unzip machine.zip &&
   rm machine.zip &&
   mv docker-machine* /usr/local/bin 验证安装

   docker-machine -v

   docker-machine version 0.5.0 (04cfa58) docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM 官方文档的使用virtualbox进行各种角色主机的启用。本篇文档则在已有的虚拟机环境中进行。 使用docker-machine进行推送安装 首先需要拥有一台linux系统，并使docker-machine主机可以无密码访问到这台系统。 #ssh-copy-id -i /root/.ssh/id_rsa.pub root@172.25.2.43 之后即可通过docker-machine进行安装。 安装通过internet下载相关包，并通过docker-machine进行设置安装的。必须保证网络畅通，否则可能安装失败。 #docker-machine create -d generic –generic-ip-address=172.25.2.43 –generic-ssh-user=root test5 安装后，可以查看所有被docker-machine安装控制后的主机状态

   docker-machine ls

   NAME ACTIVE DRIVER STATE URL SWARM c0-master - generic Running tcp://172.25.2.44:2376 c0-master (master) c0-n1 - generic Running tcp://172.25.2.45:2376 c0-master c0-n2 - generic Running tcp://172.25.2.46:2376 c0-master dm01 - generic Running tcp://172.25.2.43:2376
   local - generic Running tcp://172.25.2.34:2376 可以查看相应主机的环境变量 #docker-machine env local 把当前操作环境变更为指定主机 #eval “$(docker-machine env local)” 在docker-machine主机上操纵host #docker $(docker-machine config local) run -tid ubuntu /bin/bash 通过ssh连接到相应主机 # docker-machine ssh dm01 Docker Compose安装 docker compose用于同时启动多个容器，构成同一组应用环境，在这里用于支持swarm的安装。 curl -L https://github.com/docker/comp … ose-X 10X- uname -m > /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose Docker Swarm集群安装 启用一台主机安装key value service，用于节点、主机发现等工作。 本例使用了consul的镜像，也可以使用如etcd、zookeeper等组件。 在dm01上启动一个consul服务： docker $(docker-machine config dm01) run -d
   -p “8500:8500”
   -h “consul”
   progrium/consul -server -bootstrap 创建swarm集群可以通过key value服务，也可以使用swarm cluster ID字符串创建。 创建swarm manager docker-machine create
   -d generic –generic-ip-address=172.25.2.44 –generic-ssh-user=root
   –swarm
   –swarm-master
   –swarm-discovery=”consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-store=consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-advertise=eth0:2376”
   c0-master 创建swarm node docker-machine create
   -d generic –generic-ip-address=172.25.2.45 –generic-ssh-user=root
   –swarm
   –swarm-discovery=”consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-store=consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-advertise=eth0:2376”
   c0-n1 docker-machine create
   -d generic –generic-ip-address=172.25.2.46 –generic-ssh-user=root
   –swarm
   –swarm-discovery=”consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-store=consul://$(docker-machine ip dm01):8500”
   –engine-opt=”cluster-advertise=eth0:2376”
   c0-n2 Overlay Network创建 设置环境变量 #eval “$(docker-machine env –swarm c0-master)” 可以用docker info看到现在的集群状况 #docker network create -d overlay myStack1 root@local:~# docker network ls NETWORK ID NAME DRIVER 685ed9e9f701 myStack1 overlay
   4c88e7c52a7c c0-n1/bridge bridge
   7fd49a4f6a64 c0-n1/none null
   8b2372139902 c0-n2/host host
   d998a91dcfea c0-n2/bridge bridge
   afd7a1190fb4 c0-n2/none null
   0f2b5dae67f7 c0-n1/host host
   a45b8049f8e6 c0-master/bridge bridge
   d13eed83f250 c0-master/none null
   364a592ae9ae c0-master/host host
   测试 在c0-n1上启动一个nginx，并加入myStack1网络 #docker run -itd –name=web –net=myStack1 –env=”constraint:node==c0-n1” nginx 在c0-n2上启动一个shell，同样加入myStack1网络 #docker run -ti –name=webtest –net=myStack1 –env=”constraint:node==c0-n2” ubuntu /bin/bash 在shell中将可以通过容器名或ip获取到web容器的状态 {{{#apt-get install wget wget -O- http://web }}} docker在官方文档上主推以swarm的方式创建cluster，相对比较复杂，但提供了整体Cluster的解决方案，可以将容器进行整体管理、推送、使用。

一个典型的 Linux 系统要能运行的话，它至少需要两个文件系统： boot file system （bootfs）：包含 boot loader 和 kernel。用户不会修改这个文件系统。实际上，在启动（boot）过程完成后，整个内核都会被加载进内存，此时 bootfs 会被卸载掉从而释放出所占用的内存。同时也可以看出，对于同样内核版本的不同的 Linux 发行版的 bootfs 都是一致的。 root file system （rootfs）：包含典型的目录结构，包括 /dev, /proc, /bin, /etc, /lib, /usr, and /tmp 等再加上要运行用户应用所需要的所有配置文件，二进制文件和库文件。这个文件系统在不同的Linux 发行版中是不同的。而且用户可以对这个文件进行修改。 Linux 系统在启动时，roofs 首先会被挂载为只读模式，然后在启动完成后被修改为读写模式，随后它们就可以被修改了。

由于Boot2Docker的存在，造成了三层Mac->VirtualBox->Docker网络,由VirtualBox到Docker的映射可以通过run容器的时候指定-p参数实现，而从宿主机到VirtualBox端口映射需要通过下述方法实现: 查询虚拟机网络： VBoxManagelistvms查询虚拟机网络状态，默认虚拟机名为′default′ VBoxManage showvminfo “default” | grep NIC 2.关闭运行中的虚拟机 由于Boot2Docker会自动运行VirtualBox中的虚拟机，所以在设置网络映射时必须先关闭运行中的虚拟机。否则，将出现The machine ‘boot2docker’ is already locked for a session (or being unlocked)的错误提示 $ VBoxManage controlvm “default” poweroff 修改虚拟机与Mac系统的网络映射 根据实际需要进行网络映射，其中 rulename: 自定义规则名称 hostip: Mac访问地址，可不填 hostport: Mac映射端口 guestip: 虚拟机访问地址，可不填 guestport: 虚拟机映射端口 $ VBoxManage modifyvm “dufault” –natpf1 “,

Docker容器非常轻量，系统开销非常少，比VMware或者VirtualBox用起来方便，部署起来也非常容易。官方推荐我们通过端口映射的方式把Docker容器的服务提供给宿主机或者局域网其他容器使用。一般过程是： 1、Docker进程通过监听宿主机的某个端口，将该端口的数据包发送给Docker容器 2、宿主机可以打开防火墙让局域网其他设备通过访问宿主机的端口进而访问docker的端口