【云原生•容器】Docker架构剖析,它还是从前那个Docker吗?(上)

【云原生•容器】Docker架构剖析,它还是从前那个Docker吗?

Docker架构

Docker采用client/server架构,客户端向服务器发送请求,服务器负责构建、运行和分发容器:

Docker架构说明:

  • 我们日常使用各种docker命令,如docker run、docker pull等,其实就是在使用Docker客户端(Docker CLI);

  • 客户端将用户输入指令解析发送到docker后端服务docker daemon;

  • 比如是创建容器指令,daemon进程先去在本地镜像库中查找依赖的镜像文件(Image),如果不存在还需到远程仓库(Registry)拉取到本地;

  • 镜像准备完成后,daemon进程根据用户指令参数就可以创建容器(Container)。

通信协议

Docker客户端和后端daemon进程默认运行在同一台服务节点上,并采用UNIX本地套接字方式进行通信,这样可以省略掉网络协议栈流程,性能和安全性更高。可以查看Docker启动日志:

从上面启动日志最后一行"API listen on /run/docker.sock"可以看到daemon进程采用UNIX本地套接字,套接字文件为:/run/docker.sock。

注意:/var/run/docker.sock和/run/docker.sock是一致的,因为/var/run目录链接到/run目录下:

[root@docker01 docker]# ls -lt /var/run lrwxrwxrwx. 1 root root 6 6月 17 2020 /var/run -> ../run [root@docker01 docker]# ls -lah /run/docker.sock srw-rw----. 1 root docker 0 8月 27 18:25 /run/docker.sock

注意:从上面看到/run/docker.sock文件属主为root,用户组为docker,并且只有属主用户和组用户有rw读写权限,这就是为啥非root用户运行docker会出错,除非创建的用户添加到docker属组里。

如何在容器里使用Docker?

后端daemon进程套接字文件为/var/run/docker.sock,只需要将该文件挂载到容器中,同时这个容器里安装了docker客户端,那它就可以做任何我们在宿主机上docker命令可以做的事情。

下面案例演示下:创建容器并挂载 /var/run/docker.sock 文件,然后在容器里就可以运行docker命令了,比如创建容器,而且这个容器是创建在了宿主机上,而不是这个container里:

go 复制代码
1、使用docker镜像创建一个容器
# docker container run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker:latest sh

2、在刚创建的容器里,使用docker ps可以正常与宿主机上后端daemon进程交互,查看到当前有1个正在运行中容器
/ # docker ps
CONTAINER ID   IMAGE           COMMAND                  CREATED          STATUS          PORTS                                   NAMES
3e72e6a9563d   docker:latest   "docker-entrypoint.s..."   14 seconds ago   Up 14 seconds                                           tender_kilby

3、在容器里使用docker run命令创建一个新容器
/ # docker container run --rm -d busybox:latest ping 1.1.1.1
b250c29051e51cb429e15471ed301c0806a29cef1ffbf388c46861a7f538f4f9

4、在容器里重新查看运行中容器,刚新建的容器也显示出来
/ # docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED              STATUS              PORTS                                   NAMES
b250c29051e5   busybox:latest   "ping 1.1.1.1"           4 seconds ago        Up 4 seconds                                                stoic_agnesi
3e72e6a9563d   docker:latest    "docker-entrypoint.s..."   About a minute ago   Up About a minute                                           tender_kilby

5、退出容器,在宿主机上使用docker ps查看运行中容器,和容器中使用docker ps命令查看内容一致
/ # exit
# docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS         PORTS                                   NAMES
b250c29051e5   busybox:latest   "ping 1.1.1.1"           10 seconds ago   Up 9 seconds                                           stoic_agnesi
3e72e6a9563d   docker:latest   "docker-entrypoint.s..."   11 minutes ago   Up 11 minutes                                           tender_kilby

容器里使用Docker一般用于容器监控、或者DevOps场景下,比如Jenkins是以容器方式部署运行,这时可能就需要在容器里构建镜像、自动基于构建镜像部署运行等。

从上面得知,Docker客户端和后端daemon进程默认运行在同一台节点,并采用UNIX本地套接字方式通信,因为这样避免复杂的网络协议栈流程,性能和安全性更高;它们还可以运行在不同服务节点上进行远程通信,后端daemon进程除了支持上面说的UNIX本地套接字外,还可以支持Socket方式,下面就来说下Docker服务端远程访问有哪些方式。

远程访问

Docker CLI和后端daemon进程默认情况下同服务器部署,采用 UNIX本地套接字方式通信,关闭了远程访问机制,下面介绍如何开启 Docker 远程访问。

1、编辑/usr/lib/systemd/system/docker.service

2370是远程访问端口号,根据需要调整,默认使用2375端口。

2、重启Docker服务使修改生效

go 复制代码
systemctl daemon-reload
systemctl restart docker

再查看docker启动日志:

从启动日志最后两行输出的信息来看,后端daemon进程将UNIX本地套接字和TCP两种网络监听方式都开启,下面就来看下有哪些方式可以远程访问Docker服务。

Rest API

Rest API方式通用性较高,基本所有服务进程都支持Rest API访问机制。比如之前使用 docker version 指令查看版本信息,现在可以直接通过浏览器或curl访问URL:http://192.168.31.150:2370/version获取:

还比如 docker ps -a 指令查看容器信息,现在可以通过URL:http://192.168.31.150:2370/containers/json?all=true获取到:

之前通过docker cli方式执行的指令,现在都可以通过Rest API方式执行,具体Rest API接口及其参数可以查看官网:https://docs.docker.com/reference/api/engine/v1.43/

Docker CLI

如果Docker CLI需要访问远端Docker服务,可以通过执行指令时添加 -H 或 --host 参数设置远端服务IP和端口信息:

如果不想在每次指令中都指定远程地址,也可以将其设置到环境变量中:

go 复制代码
[root@localhost ~]# export DOCKER_HOST="tcp://192.168.31.150:2370"

go 复制代码
注意:
-H参数也可以指定本地套接字文件,如:docker -H unix:///var/run/docker.sock ps -a
-H指定TCP协议,如:docker -H tcp://192.168.31.150:2370 ps -a,这种方式如果不指定端口,默认是2375,tcp://协议前缀可以省略。
SDK

对于开发来说,难免将docker和项目进行整合集成,官网提供SDK方式可以快速轻松地构建和扩展Docker应用,官网SDK支持Golang、Python,非官网支持语言较多,实在不支持的语言上面介绍过使用Rest API方式也很方便。

通过docker run指令可以创建运行容器,如下:

go 复制代码
docker run -d --name nginx_from_sdk -p 18080:80 nginx

下面我们通过golang程序实现上述效果:

go 复制代码
package main

import (
 "context"
 "fmt"
 "github.com/docker/go-connections/nat"
 "io"
 "os"

 "github.com/docker/docker/api/types/container"
 "github.com/docker/docker/api/types/image"
 "github.com/docker/docker/client"
)

func main() {
 ctx := context.Background()
 cli, err := client.NewClientWithOpts(
  client.FromEnv,
  client.WithAPIVersionNegotiation(),
  client.WithHost("tcp://192.168.31.150:2370"))
 if err != nil {
  panic(err)
 }
 defer cli.Close()

 imageName := "nginx"

 out, err := cli.ImagePull(ctx, imageName, image.PullOptions{})
 if err != nil {
  panic(err)
 }
 defer out.Close()
 io.Copy(os.Stdout, out)

 /**
 docker run -d --name nginx_from_sdk -p 18080:80 nginx
 */
 resp, err := cli.ContainerCreate(ctx, &container.Config{
  Image: imageName,
 }, &container.HostConfig{
  PortBindings: nat.PortMap{"80/tcp": []nat.PortBinding{{
   HostIP:   "0.0.0.0",
   HostPort: "18080",
  }}},
 }, nil, nil, "nginx_from_sdk")

 if err != nil {
  panic(err)
 }

 if err := cli.ContainerStart(ctx, resp.ID, container.StartOptions{}); err != nil {
  panic(err)
 }

 fmt.Println(resp.ID)
}

执行上述代码后,查看容器列表,发现已经按照指定信息创建对应容器:

核心架构剖析

上面官网Docker架构图较为粗糙,从业务功能上描述了大概流程,通过该架构图并不能真正了解Docker背后运行的机制,我重新给Docker绘制了张"自画像"可更好的反应Docker背后的真实面孔:

从上面架构图看较为复杂,涉及到组件包括:docker cli、daemon、containerd、containerd-shim、runc等,还涉及CRI、OCI两个容器运行时的协议规范,这套架构的背后还涉及到诸多历史原因,下面就来缕下它们的关系,可以对Docker的发展、容器技术的演进有更加清晰的认识。

2013年Docker强势崛起一下带火了容器技术,大家纷纷转入开始关注和使用容器技术,其中就包括Google这种科技巨佬,Google 开始希望和 Docker 公司合作共同推进一个中立的容器运行时(container runtime)库作为 Docker 项目的核心依赖。Docker公司当时风头正盛,这个提议显然会削弱自身的影响力,即使Google这种科技巨佬也没放在眼里,直接拒绝了这个提议,从此也开启了容器圈后续一系列政治斗争。

Google 紧接着联合 Red Hat、IBM 等几位巨佬认为运行时标准不能被 Docker 一家公司控制, 于是就撺掇着搞了开放容器标准(Open Contianer Initiative),简称 OCI。**OCI 的提出意在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来。这样做,一方面可以改善 Docker 公司在容器技术上一家独大的现状;另一方面也为其他玩家不依赖于 Docker 项目构建各自的平台层能力提供了可能。**这就和之前Google希望和Docker合作共同推进一个中立的容器运行时库的诉求是一致的,合作不行那就联合其它大佬一起制定接口规范。

Docker公司迫于压力权衡后将 Libcontainer 捐出,并改名为 RunC 项目,作为OCI接口标准和规范的参考实现,其实OCI接口规范本身就是依据RunC项目制定的一套容器和镜像的标准和规范,毕竟当时Docker基本是容器生态的事实标准。

Docker最开始使用的容器运行时并没有自己开发,而是使用三方的LXC产品,但从0.9版本开始使用自己开发的Libcontainer取代LXC,LXC叫做LinuX Container,简称Linux的容器。

这还不够,为了彻底扭转 Docker 一家独大的局面,Google、Microsoft、IBM、Amazon、Red Hat等几位大佬又合伙成立了一个基金会叫 CNCF,全称 Cloud Native Computing Foundation(云原生计算基金会),CNCF 的目标很明确,在容器运行时基本处于被Docker垄断状态,Docker生态成为很多容器事实标准,那就换个赛道,Docker的致命问题就是更加偏向底层部署,缺乏平台化能力,对于生产环境下大规模部署稍显不足,CNCF基金会就从容器技术上层应用发力:基于容器部署,发展使用Kubernetes进行编排与调度,顺势发布了 Kubernetes 项目。

Docker 也并没有"坐以待毙",开始主动革新,Docker 从 1.1 版本起推动自身的重构,将容器运行时核心功能拆分到 Containerd 项目中,作为Docker的核心依赖,这样做也是为了推动 Docker Swarm 项目发展,以便在容器编排上重点发力,准备和kubernetes掰掰手腕,以提升Docker的平台化能力,结果直接被秒杀以惨败收场。后来又将Docker容器运行时核心依赖 Containerd 捐赠给 CNCF 社区,开始专注于自己商业化转型。至此,容器市场的格局发生重大改变,kubernetes成为容器圈的"新宠儿"。

经过Containerd、RunC等项目从Docker中分离出来形成一个个独立的开源项目,Docker中容器相关核心技术已被掏空,这也导致了Docker的影响力已被极大的削弱,见下图。**如今容器已不再与Docker紧密耦合,我们可以使用Docker或者其他非Docker工具运行容器,Docker不再代表容器技术的发展。**当前的Docker也是将Containerd、RunC等容器运行时核心依赖集成进来,自身主要关注的是上层功能封装集成、用户体验优化等,docker的能力大不如从前。

OCI开发容器标准定义了容器运行时规范和容器镜像规范,那为啥又要搞出来个CRI规范呢?还有kubernetes最新版本已经弃用Docker又是怎么回事呢?下文我们继续聊起。

相关推荐
朝九晚五ฺ6 小时前
【Linux探索学习】第十四弹——进程优先级:深入理解操作系统中的进程优先级
linux·运维·学习
Kkooe7 小时前
GitLab|数据迁移
运维·服务器·git
wuxingge8 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
久醉不在酒8 小时前
MySQL数据库运维及集群搭建
运维·数据库·mysql
志凌海纳SmartX9 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes
锅总9 小时前
nacos与k8s service健康检查详解
云原生·容器·kubernetes
BUG弄潮儿9 小时前
k8s 集群安装
云原生·容器·kubernetes
意疏9 小时前
【Linux 篇】Docker 的容器之海与镜像之岛:于 Linux 系统内探索容器化的奇妙航行
linux·docker
虚拟网络工程师9 小时前
【网络系统管理】Centos7——配置主从mariadb服务器案例(下半部分)
运维·服务器·网络·数据库·mariadb
墨鸦_Cormorant9 小时前
使用docker快速部署Nginx、Redis、MySQL、Tomcat以及制作镜像
redis·nginx·docker