mirror of
https://github.com/yeasy/docker_practice.git
synced 2025-08-05 15:12:31 +00:00
Restruct and start rewring.
This commit is contained in:
Baohua Yang
@@ -1,4 +1,4 @@
|
||||
#架构
|
||||
##基本架构
|
||||
docker采用了C/S架构，包括client端和daemon端。
|
||||
docker daemon作为server端接受来自client的请求，并处理这些请求（创建、运行、分发容器）。
|
||||
client端和server端既可以运行在一个机器上，也可通过socket或者RESTful API来进行通信。
|
||||
@@ -7,4 +7,29 @@ client端和server端既可以运行在一个机器上，也可通过socket或
|
||||
|
||||
|
||||
Docker daemon一般在宿主主机后台运行，等待接收来自client端的消息。
|
||||
Docker client 则为用户提供一系列可执行命令，用户用这些docker命令实现跟docker daemon交互。
|
||||
Docker client 则为用户提供一系列可执行命令，用户用这些docker命令实现跟docker daemon交互。
|
||||
|
||||
##核心技术
|
||||
docker底层的2个核心技术分别是Namespaces和Control groups。
|
||||
|
||||
以下内容摘自InfoQ Docker，自1.20版本开始docker已经抛开lxc，不过下面的内容对于理解docker还是有很大帮助。
|
||||
|
||||
###pid namespace
|
||||
不同用户的进程就是通过pid namespace隔离开的，且不同 namespace 中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程，每个lxc进程具有不同的namespace。同时由于允许嵌套，因此可以很方便的实现 Docker in Docker。
|
||||
|
||||
###net namespace
|
||||
有了 pid namespace, 每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的， 每个net namespace有独立的 network devices, IP addresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge: docker0连接在一起。
|
||||
|
||||
###ipc namespace
|
||||
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是，container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互，因此需要在IPC资源申请时加入namespace信息 - 每个IPC资源有一个唯一的 32 位 ID。
|
||||
|
||||
###mnt namespace
|
||||
类似chroot，将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同，这样每个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不同，每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
|
||||
|
||||
###uts namespace
|
||||
UTS("UNIX Time-sharing System") namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
|
||||
|
||||
###user namespace
|
||||
每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户。
|
||||
|
||||
Control groups主要用来隔离各个容器和宿主主机的资源利用。
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
##docker容器
|
||||
|
||||
当我们运行`docker run -i -t ubuntu /bin/bash`命令时，docker 在后台运行的操作如下：
|
||||
|
||||
* 如果本地有ubuntu这个image就利用它，否则从公有仓库下载
|
||||
* 之后从image创建一个容器
|
||||
* 分配一个文件系统，并在只读的image层外面挂载一层可读写的层
|
||||
* 从宿主主机配置的网桥接口中桥接一个虚拟接口到容器中去
|
||||
* 从地址池配置一个ip地址给容器
|
||||
* 执行你指定的程序，在这里启动一个/bin/bash进程
|
||||
* -i -t 指定标准输入和输出
|
||||
@@ -1,10 +0,0 @@
|
||||
##docker image的工作原理
|
||||
|
||||
docker image是怎么实现增量的修改和维护的？
|
||||
每个docker都有很多层次构成，docker使用 [Union FS](http://en.wikipedia.org/wiki/UnionFS) 将这些不同的层结合到一个image中去。
|
||||
Union FS是一种特殊的文件系统，它支持将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem),
|
||||
|
||||
AUFS (AnotherUnionFS) 就是一种 Union FS, AUFS支持为每一个成员目录(类似Git Branch)设定readonly、readwrite 和 whiteout-able 权限, 同时 AUFS 里有一个类似分层的概念, 对 readonly 权限的 branch 可以逻辑上进行修改(增量地, 不影响 readonly 部分的)。
|
||||
|
||||
通常 Union FS 有两个用途, 一方面可以实现不借助 LVM、RAID 将多个disk挂到同一个目录下, 另一个更常用的就是将一个 readonly 的 branch 和一个 writeable 的 branch 联合在一起，Live CD正是基于此方法可以允许在 OS image 不变的基础上允许用户在其上进行一些写操作。
|
||||
Docker 在 AUFS 上构建的 container image 也正是如此。
|
||||
@@ -1,18 +0,0 @@
|
||||
##内部组件
|
||||
docker有三个内部组件
|
||||
* images（镜像
|
||||
* registries（仓库）
|
||||
* containers（容器）
|
||||
|
||||
### Images
|
||||
docker images 就是一个只读的模板。比如：一个image可以包含一个完整的ubuntu的操作系统，里面仅安装了apache或者你需要的其它应用程序。
|
||||
images可以用来创建docker containers，docker提供了一个很简单的机制来创建images或者更新现有的images，你甚至可以直接从其他人那里下载一个已经做好的images来直接使用。
|
||||
|
||||
###Registries
|
||||
Docker registries 也叫docker仓库，它有公有仓库和私有仓库2种形式，他们都可以用来让你上传和下载images。公有的仓库，即[Docker Hub](https://hub.docker.com)，提供了一个数量庞大的image库供用户下载。当然，你也可以在自己的局域网内建一个自己的私有仓库。
|
||||
|
||||
*从这个意义上看，Docker Hub的功能跟GitHub类似。
|
||||
|
||||
###Containers
|
||||
即docker容器，容器是从image镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。
|
||||
*image是只读的，container在启动的时候创建可写的一层作为最上层。
|
||||
@@ -1,5 +0,0 @@
|
||||
##docker仓库
|
||||
|
||||
docker仓库用来保存我们的images，当用户创建了自己的image之后就可以使用push命令将它上传到公有或者私有仓库，这样下次在另外一台机器上使用这个image时候，只需要从仓库上pull下来就可以了。
|
||||
|
||||
*跟git的操作类似。
|
||||
@@ -1,24 +0,0 @@
|
||||
##底层技术
|
||||
docker底层的2个核心技术分别是Namespaces和Control groups。
|
||||
|
||||
以下内容摘自InfoQ Docker，自1.20版本开始docker已经抛开lxc，不过下面的内容对于理解docker还是有很大帮助。
|
||||
|
||||
###pid namespace
|
||||
不同用户的进程就是通过pid namespace隔离开的，且不同 namespace 中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程，每个lxc进程具有不同的namespace。同时由于允许嵌套，因此可以很方便的实现 Docker in Docker。
|
||||
|
||||
###net namespace
|
||||
有了 pid namespace, 每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的， 每个net namespace有独立的 network devices, IP addresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge: docker0连接在一起。
|
||||
|
||||
###ipc namespace
|
||||
container中进程交互还是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是，container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互，因此需要在IPC资源申请时加入namespace信息 - 每个IPC资源有一个唯一的 32 位 ID。
|
||||
|
||||
###mnt namespace
|
||||
类似chroot，将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同，这样每个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不同，每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。
|
||||
|
||||
###uts namespace
|
||||
UTS("UNIX Time-sharing System") namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。
|
||||
|
||||
###user namespace
|
||||
每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户。
|
||||
|
||||
Control groups主要用来隔离各个容器和宿主主机的资源利用。
|
||||
Reference in New Issue
Block a user