CI(Continuous Integration) 编码 —> 开发完成
CD(Continuous Delivery) 开发完成 —> 上线发布
- 衡量一个CI系统最重要的因素
⾃自动化程度如何?
时间(环境准备,测试运⾏行)够快?
- 衡量一个CD系统最重要的因素
能够实现快速并且可重复的发布?
传统 CI/CD 存在的问题
- CI的现状
手动测试 —> jenkins —> jenkins + 虚拟化
本篇环境为 windows10 环境。
$ docker info
Containers: 8
Running: 0
Paused: 0
Stopped: 8
Images: 4
Server Version: 18.09.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
...
Docker 使用客户端-服务器 (C/S) 架构模式,使用远程API来管理和创建Docker容器。
Docker 容器通过 Docker 镜像来创建。
容器与镜像的关系类似于面向对象编程中的对象与类。
核心流程

对于 docker 我们不要把他简单的看做是容器,就像是 Maven 一样,我们也不能简单的只认为是一个管理 jar 包的工具。
确切的说,二者都是平台,在不断进化着属于自己的完整生态。
有着对管理信息的完整生命周期控制,对于管理信息的版本控制,简单易用的 api 标准。
什么是 Docker 镜像
上一张 Docker 命令导图:

dockerfile 中有很多有用的命令,个人理解这些命令都不应该死记硬背,直接使用的时候查阅即可。
FROM 和 RUN 指令的作用
FROM:定制的镜像都是基于 FROM 的镜像。
RUN
RUN:用于执行后面跟着的命令行命令。有以下俩种格式:
- shell 格式:
RUN
# 等同于,在终端操作的 shell 命令。
上面我们看到如何拉取并且构建好带有定制内容的 Docker 镜像,那么我们如何修改自己的镜像,并且管理和更新这些镜像呢?
-
使用 docker commit 命令
-
使用 docker build 命令和 Dockerfile 文件
现在我们不推荐使用 docker commit 命令,相反应该使用更灵活更强大的 Dockerfile 来构建镜像。
不过,为了对 Docker 又一个更深的了解,我们还是会先介绍一下 docker commit 构建镜像。
之后,我们重点介绍 Docker 所推荐的构建方法:编写 Dockerfile 之后使用 docker build 命令。
Cgroup和Namespace等容器相关技术已经存在很久,在VPS、PaaS等领域也有很广泛的应用,但是直到Docker的出现才真正把这些技术带入到大众的视野。
同样,Docker的出现才让我们发现原来可以这样管理镜像,可以这样糅合老技术以适应新的需求。
Docker引入联合挂载技术(Union mount)使镜像分层成为可能;而Git式的管理方式,使基础镜像的重用成为可能。
现在就了解一下相关的技术吧。
联合挂载
联合文件系统这种思想由来已久,这类文件系统会把多个目录(可能对应不同的文件系统)挂载到同一个目录,对外呈现这些目录的联合。
和 maven 类似,我们可以把自己的镜像提交到中央仓库。
镜像构建完毕之后,我们也可以将它上传到 Docker Hub 上面去,这样其他人就能使用这个镜像了。
命令
我们可以使用 docker push
命令将镜像推送至 Docker Hub。
命令如下:
$ docker push houbinbin/static-web
image 里面是一层层文件系统,叫做 Union FS(联合文件系统)。
联合文件系统,可以将几层目录挂载到一起,形成一个虚拟文件系统。
虚拟文件系统的目录结构就像普通 linux 的目录结构一样,docker 通过这些文件再加上宿主机的内核提供了一个 linux 的虚拟环境。
每一层文件系统我们叫做一层 layer,联合文件系统可以对每一层文件系统设置三种权限,只读(readonly)、读写(readwrite)和写出(whiteout-able),但是 docker 镜像中每一层文件系统都是只读的。
构建镜像的时候,从一个最基本的操作系统开始,每个构建的操作都相当于做一层的修改,增加了一层文件系统。