作为一个程序员,如果你想安装一个vim编辑下文本,在不同环境里你得执行不同的命令。在 ,你需要执行apt-get vim,在 里,你需要执行yum vim.

装个小软件尚且如此,要是你想将自己写的代码部署到各个不同操作系统的服务器上,那依赖的软件和配置就更多了,需要针对每个环境单独写一套部署脚本。

难受,太难受了。

那么问题就来了,有没有更好的解决方案?

当然有,没有什么是加一层中间层不能解决的,如果有,那就再加一层,这次我们要加的中间层是。

是代码和操作系统之间的中间层

哦不,准确来说是容器。

容器技术 是什么?

我们经常能听到程序员说”这个程序在我环境里明明是好的啊,怎么到你这就不行了呢”?注意这里的关键词,程序和环境。程序是跑在操作系统上的,而操作系统上又装了各种不同版本的依赖库和配置,这些被程序所依赖的信息,我们统称为”环境”。

程序和环境

程序依赖环境,环境不同,程序就可能跑不起来。如果我们能将环境和程序一起打包,给到对方运行,那问题不就解决了吗。 就是这样一款可以将程序和环境打包并运行的工具软件。我们来看下它是怎么做的?

基础镜像是什么

既然上面提到环境不同,会导致程序运行结果不同,那么我们首先要做的最重要的事情,就是统一环境。而环境中,最最重要的就是操作系统。比如 还是 ,我们得选一个,让所有程序都跑在同一个操作系统上。并且我们知道操作系统分为用户空间和内核空间,应用程序运行在用户空间。因此,我们可以阉割操作系统,只需要利用操作系统的用户空间部分,就能构建出应用所需的环境。其次就是统一程序语言依赖,比如要跑 应用,你得装个 解释器,要跑个 java 应用,得装个 JVM,要跑 go 应用,那就。。什么都不需要装。选中一个基础操作系统和语言后,我们将它们对应的文件系统,依赖库,配置等放一起打包成一个类似压缩包的文件,这就是所谓的基础镜像(Base Image)。

基础镜像是什么 是什么

有了基础镜像之后还不够,我们经常还需要安装一些依赖,比如yum gcc,甚至还要创建一些文件夹。最后才是运行我们的目标应用程序。我们知道 linux 中,所有工作都可以通过命令行完成,所以我们可以将要做的事情以命令行的形式一行行列出来。就像一份todo list。意思是要求在基础镜像的基础上按着 todo list 挨个执行命令。这份 todo list 长下面这样。

# 指定基础镜像
FROM python:3.9

# 设置工作目录
WORKDIR /app

# 复制依赖文件到容器中
COPY requirements.txt .

RUN yum install gcc
# 安装依赖
RUN pip install --no-cache-dir -r requirements.txt

# 将当前目录下的所有文件复制到容器的 /app 目录下
COPY . /app

# 设置容器启动时执行的命令
CMD ["python""app.py"]

具体含义是,基于一个装了 .9 解释器的操作系统(基础镜像),再执行 pip 等命令安装其他依赖,从而构建出一个适合程序运行的环境,最后用 app.py运行我们的目标应用程序。像这样一份列清楚了,从操作系统到应用服务启动,需要做哪些事情的清单文件(todo list),就是所谓的。

容器镜像 是什么

注意 只是描述了要做哪些事情,并没有真正开始做。当我们用命令行执行 build的时候, 软件就会按着 的说明,一行行构建环境+应用程序。最终将这个环境+程序,打包成一个类似”压缩包”的东西,我们叫它容器镜像( image)。

容器镜像

只要将容器镜像传到任意一台服务器上,对这个”压缩包”执行”解压缩”,我们就能同时运行环境和程序。太完美了!但是现在还有个问题,怎么将容器镜像传到那么多服务器上呢?

是什么

服务器那么多,挨个将容器镜像传过去也不是不行,就是将压力全给到发送方的网络带宽了。有没有更好的解决方案?有。可以参考代码仓库 的做法,我们通常会使用git push将代码传到 ,有需要的人自己通过git pull的方式将代码从 拉到自己的机器上。

仓库

那 也一样,弄一个镜像仓库,通过 push将镜像推到仓库,有需要的时候再通过 pull将镜像拉到机器上。这个负责管理镜像仓库推拉能力的服务,就叫 。基于 的能力,我们可以搭建各种官方或私人镜像仓库,比如官方的叫 ,非官方的有清华大学的 Tuna 等等,一般公司内部也会有自己的镜像仓库。

是什么容器是什么

现在,我们解决了服务器间传输容器镜像的问题。我们可以跑到目的服务器上,执行 pull 拿到容器镜像。然后执行 run 命令,将这个类似”压缩包”的容器镜像给”解压缩”,获得一个独立的环境和应用程序并运行起来。这样一个独立的环境和应用程序,就是所谓的容器()。我们可以在一个操作系统上同时跑多个容器。且这些容器之间都是互相独立,互相隔离的。

容器是什么 和虚拟机的关系?

眼熟不,这个容器是不是很像我们用 或 kvm 整出来的传统虚拟机?但不同的是,传统虚拟机自带一个完整操作系统,而容器本身不带完整操作系统,容器的基础镜像实际上只包含了操作系统的核心依赖库和配置文件等必要组件。它利用一个叫的能力让它看起来就像是一个独立操作系统一样。再利用一个叫的能力限制它能使用的计算资源。

和虚拟机的区别

所以说,容器本质上只是个自带独立运行环境的特殊进程,底层用的其实是宿主机的操作系统内核。

容器本质是一个特殊进程 的架构原理

现在,我们回到日常使用场景中,聊聊 的架构原理。它是经典的 / 架构。 对应 -cli, 对应 。我们在命令行里敲 命令,使用的就是 -cli.

是C/S软件架构

-cli 会解析我们输入的 cmd 命令,然后调用 守护进程提供的 API,守护进程收到命令后,会根据指令创建和管理各个容器。再具体点, 内部分为 、 两层。 本质上就是个 HTTP 服务,负责对外提供操作容器和镜像的 api 接口,接收到 API 请求后,会分发任务给 层, 层负责创建 Job,由 Job 实际执行各种工作。

内部架构

不同的 命令会执行不同类型的 Job 任务。

build

如果你执行的是 build 命令,Job 则会根据 指令,像包洋葱皮似的一层层构建容器镜像文件。

build执行逻辑 pull/push

如果你执行的是 pull 或 push 之类的镜像推拉操作,Job 则会跟外部的 交互,将镜像上传或下载。

pull/push执行逻辑 run

如果你执行的是 run 命令,Job 就会基于镜像文件调用 组件,驱使 runC 组件创建和运行容器。

run执行逻辑 到底是什么?

现在我们再回过头来看这句话, 本质上就是一个将程序和环境打包并运行的工具软件。具体点来说就是,它通过 描述环境和应用程序的依赖关系, build 构建镜像, pull/push 跟 交互实现存储和分发镜像, run 命令基于镜像启动容器,基于容器技术运行程序和它对应的环境,从而解决环境依赖导致的各种问题。

到底是什么

好了,到这里,我们就了解了 的架构和基本运行原理了。接下来,我们再来聊聊跟 相关的几个周边。

是什么?

我们现在知道了 容器 本身只是一个特殊进程,但如果我想要部署多个容器,且对这些容器的顺序有一定要求呢?比如一个博客系统,当然是先启动数据库,再启动身份验证服务,最后才能启动博客 web 服务。按理说挨个执行 run 命令当然是没问题的,但有没有更优雅的解决方案?有。我们可以通过一个YAML文件写清楚要部署的容器有哪些,部署顺序是怎么样的,以及这些容器占用的cpu 和内存等信息。

version: "3.8"

services:
  A:
    image: "some-image-for-a"
    deploy:
      resources:
        limits:
          cpus: "0.50" # 限制 CPU 使用率为 50%
          memory: 256M # 限制内存使用量为 256MB

  B:
    image: "some-image-for-b"
    depends_on:
      - A

  C:
    image: "some-image-for-c"
    depends_on:
      - B

然后,通过一行- up命令,开始解析 YAML 文件,将容器们一键按顺序部署,就完成一整套服务的部署。这其实就是 干的事情。

原理 Swarm 是什么?

解决的是一个容器的部署。 解决的是多个容器组成的一整套服务的部署。那 Swarm 就更高维度了,它解决的其实是这一整套服务在多台服务器上的集群部署问题。比如在 A 服务器坏了,就将服务在 B 服务器上重新部署一套,实现迁移,还能根据需要对服务做扩缩容。

swarm是什么 和 k8s 的关系是什么?

还记得之前的文章里提到的 k8s 吗?它会在多台 Node 服务器上调度 Pod,进行部署和扩缩容。

k8s的node内部

每个 Pod 内部可以含有多个 ,每个 本质上就是一个服务进程。

pod内部

是不是感觉k8s跟 Swarm做的事情很像?没错,其实 Swarm 是 k8s 的竞品,既然是竞品,那它们做的事情其实区别就不大了。现在回过头来看 容器和 k8s 之间的关系,思路就清晰了。 部署的容器,其实就是 k8s 调度的 Pod 里的,它们都叫容器,其实是一回事。只不过 k8s 除了支持 的容器外,还支持别人家的容器。 基于多个 创建的一整套服务,其实就是 k8s 里的pod。而 Swarm 做的事情和 k8s 一样,本质上就是在调度 pod。回过头来看下 k8s 的官方定义,叫容器编排引擎,将它理解为,以 API 编程的方式管理安排各个容器的引擎,是不是就特别精辟。

容器编排引擎的含义

现在,我们再回过头来看下 的图标,是一个个集装箱,放在一艘船上,这一个个集装箱指的就是互相隔离的容器,而 k8s 的图标,则是一个轮船上的方向盘,意思是 k8s 控制着轮船的航向,其实指的就是调度容器。这波联想就非常形象了。

和k8s

现在大家通了吗?

总结最后

这篇文章的主题按理说写个万把字不成问题,但我压缩了很多内容,主打就是用最少的文字将技术原理通俗的讲清楚。

加入IP合伙人(站长加盟) | 全面包装你的品牌,搭建一个全自动交付的网赚资源独立站 | 晴天实测8个月运营已稳定月入3W+
限时特惠:本站每日持续更新海量内部创业教程,一年会员只需98元,全站资源免费无限制下载点击查看会员权益

站长微信: qtw123cn

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注