在介绍完Docker的原理后，我们再回过头来看Docker的意义。

Docker的意义

事实上，Cgroups是2007年就被合并到Linux内核的功能。那个时候结合了Cgroups的资源管理能力+Linux Namespace的视图隔离能力的LXC（Linux Container）就已经产生了。
但LXC的视角还是操作系统和服务器，目标是打造一个相比虚拟机更轻量级的系统容器。
而Docker从理念上就截然不同，将目标中心转到了应用。

不要小看这个理念上的差异。以应用为中心意味着两件事情的彻底改变：

构建和部署

测试环境和生产环境的构建和部署都是以应用为粒度的。而一个操作系统上可能部署着不同测试阶段的应用。不可能那么凑巧让上面所有的应用恰好同一周期完毕，然后将整个操作系统从测试搬到生产。这个不符合正常的开发测试流程。
而Docker直接将一个应用运行所需的完整环境，即整个操作系统的文件系统也打包了进去。只要这个应用的Docker镜像测试完成，就可以单独发布上生产。还可以利用现有的构建工具来辅助，例如Jenkins/Ansible等。遇到性能瓶颈需要横向扩展时，也可以针对单应用迅速部署启动。在性能压力消除后也可以快速回收。
在Docker之前，也已经有Cloud Foundry等PaaS项目开始以应用为中心。但相比做完一个镜像就可以随处运行的Docker，它们的便利性和适应性差了不少。

版本化和共享

制作一个操作系统容器是一件私有的事情。你制作的操作系统容器一般只会使用在你自己的团队，顶多扩展到全公司内部。别人看不到你是具体怎么做的系统容器，不清楚你是否在里面埋了雷。借我十个胆子也不敢用。
而Docker在容器镜像的制作上引入了“层（Layer）”的概念。这种基于“层”的实现借鉴了Git的思想，使容器的创建变得透明。每个人都可以审查应用容器在原始操作系统的容器上做了哪些修改。
类似在Github上开源代码，当每个人和每个公司都可以参与到全世界的应用容器分发过程中时，Docker的爆发也在情理之中了。

Cgroups-限制可用资源

如果应用优化得不够好，直接把CPU或内存吃光也完全不是新鲜事。但我们肯定不能容忍容器无限制地挤占宿主机的资源，甚至把宿主机搞down掉。
所以我们可以通过Linux的Cgroups（Control Groups，控制组）对某个容器可以使用的各种硬件资源设置配额。

根据wiki，Cgroups的功能包括：

• 资源限制（Resource Limitation）：进程组使用的内存的上限，也包括文件系统与物理内存交换用的页缓存（Page Cache）
• 优先级分配（Prioritization）：控制分配的CPU时间片数量及硬盘IO吞吐，实际上就相当于控制了进程运行的优先级
• 资源统计（Accounting）：统计资源使用量，如CPU使用时长、内存用量等，主要用于计费
• 进程控制（Control）：执行挂起、恢复进程组的操作

Cgroups的设置一般分为三个主要步骤：

1. 创建cgroup
2. 设置cgroup配额（将cpu/内存等各种子系统添加到该cgroup中）
3. 将进程添加为cgroup的任务

Docker容器在启动时候会动态创建Cgroup，并在容器终止的时候删除。

容器与容器间的文件系统必须相互隔离。如果一个容器能不受限制地访问到宿主机或另一个容器里的文件，那必定会引起严重的安全风险。所以对于docker中的进程，必须限制其能够访问的文件系统。
我们先来看一种简易版的实现方式：chroot。

chroot-监狱

chroot，即change root的缩写。它是一个 UNIX 操作系统上的系统调用，用于将一个进程及其子进程的根目录改变到文件系统中的一个新位置。
我们知道root根目录（/）是Linux的顶层目录。这里的顶层，换句话说就是没有办法访问比根目录更高一层级的目录。但对每个进程，可以通过chroot来“欺骗”，将指定的目录骗他们认定为根目录。

chroot经常和一个单词结合在一起说：jail（监狱）。可以很形象地理解为chroot就是给每个docker容器划了一个监狱房间。
Docker在每个监狱里配套放置了一套文件系统。

chroot的基本语法如下：

1
2

# 将某个进程
chroot /path/to/new/root command

chroot看起来挺不错，但也存在两个问题：

问题症状与解决方法

Oracle服务器由于无法上外网，所以做了个crontab的定时任务，每天定时和内部的一台ntp服务器同步。但没过两周，时间又不准了，差了近10秒。
首先排除了这个时间差是在凌晨同步完后的几小时内造成的。以“ntpdate crontab”作为关键字搜索，很容易找到了原因：坑爹的crontab重置了PATH环境变量，所以执行ntpdate命令的时候报“command not found”。
解决方法也很简单：通过whereis ntpdate的命令查出ntpdate的位置，改为完整路径调用，即“/usr/sbin/ntpdate”。另外作为以防万一，也将同步间隔从1天缩小到1小时。

为了避免下次栽坑，我们需要知道crontab到底设置了哪些PATH环境变量。
通过“vi /etc/crontab”打开文件，可以看到如下的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

可以看到PATH里明明是包含/usr/sbin，也就是ntpdate的路径。那么为什么依然会报“/bin/sh: ntpdate command not found”的错误？
（另外一个疑点是看起来是用/bin/bash执行的，为什么报/bin/sh）

crontab ≠ crontab

这里是比较容易混淆的地方：

• crontab -e是用户任务调度的命令
• /etc/crontab是系统任务调度的配置文件

本文是一系列对Docker与Kubernetes的学习总结。源材料来源参见文中的链接和最后的参考资料。

容器的原理

虽然有些人会把容器和虚拟机类比，称之为“轻量级的虚拟机”。刚开始接触Docker的时候大多看过下面这张图：

忘记这张图吧。从上一节我们讨论的“容器的意义”就可以看到，容器和虚拟机关注的不是一个层面。

但虚拟机和容器也有共通之处：本质都是欺骗。虚拟机的原理是欺骗CPU/物理内存/物理IO，让硬件感觉自己还是在接收宿主机而非虚拟机的指令。而Docker的原理是欺骗一组进程，让这些进程以为自己活在另一个的操作系统里。
用专业一点的术语，就是：容器的核心功能，就是通过约束进程和修改进程的动态表现，为进程创造出一组“边界”。

以电影作为比方，虚拟机就像《火星救援》里在火星上种土豆的宇航员，在火星上模拟地球的环境，连空气和水都需要自己从头开始制备，成本高昂。

而容器就是《楚门的世界》。男主（容器进程）生活在一个大型影棚里，所有能接触到的世界只有这个影棚。男主住的房子，吃的东西，呼吸的空气来自于地球，生产成本很低。但他所能阅读的报纸，乘坐的载具，观看的电视都是影棚工作人员提供给他的，受到了严格的限制。

对于Docker来说，修改进程的动态表现是通过Namespace，构成进程依赖的文件系统是通过union mount，约束进程是通过Cgroups。

Namespace-欺骗的6种手段

1. 问题起因

Java应用的某个功能里有个循环，每个循环中调用MyBatis的SQL来获取Oracle的序列Sequence，然后把序列值填充到实体中，调用jpa的save方法将实体保存到数据库。
取序列号的sql没啥特殊的：

1

select seq_name.nextval from dual

但实际保存到数据库的时候，发现所有循环保存的实体的序列值都相同。

2. 问题分析

首先排除了Oracle数据库的问题。从这篇stackoverflow的回答，可以看到Oracle的序列实现是考虑很周到的。并发/Oracle部署方式/回滚都不会使序列重复。那么疑点就落在了MyBatis上。

以MyBatis为关键字，从网上能找到一些解答，例如如下这篇回答：

1
2
3
4
5

（该问题的原因）是因为其每次都会去取一级缓存中的值。
1.拿出@Transactional，就不会出错。
2.加上useCache="false" flushCache="true",不保存在二级缓存中，并清空缓存
3.mybatis.configuration.localCacheScope=STATEMENT,修改一级缓存的作用域
4.mybatis.configuration.cacheEnabled = false,禁用一级和二级缓存

Spring Cloud Config架构图

从上图可以看到，Spring Cloud Config（Git版）的架构还是非常简单的。简单的代价就是缺少可视化配置界面，无法实现灰度发布和自动回滚。要实现比较复杂和细粒度的权限控制也比较困难。
如果只使用Spring Cloud Config也没法实现配置自动刷新，还要依赖于Spring Cloud Bus。

技术资料

Spring-Cloud-Config-官方文档-server
Spring-Cloud-Config-官方文档-client
Spring-Cloud-Config-配置中心-git

对配置中心的期望

在具体评估技术之前，可以先列一下我们希望该技术能实现的目标，然后进行逐一确认是否能实现。
对于配置中心，我们的期望如下：

从代码和项目管理角度

问题症状

为了做一个Spring MVC的Java Web项目的CI，我写了个编译war包后启动tomcat的脚本。CI脚本很简单：

1
2
3
4
5
6

sit:
   script:
     - cd /root/
     - ./test-publish-xxx-sit.sh
   only:
     - develop

SSH到服务器手工执行脚本一切顺利。但通过gitlab-runner执行脚本，到最后一步执行./startup.sh启动tomcat的时候，遇到了两个很奇怪的现象：

• 和SSH下执行./startup.sh不同，没有打印环境变量（例如Using CATALINA_BASE:）。只显示了最后一句“Tomcat started.”
• 虽然打印了“Tomcat started.”，tomcat却没有正常启动。catalina.out里完全没有启动日志信息
  尝试过从权限和执行用户方向排查，都没有找到原因。

解决方法

在gitlab的论坛看到有人回答需要部署为linux的service，或者加个setsid，才能启动。结果证明这两种方式都是可行的解决方案。

问题是解决了。但疑问还是没解决：

实施计划

• 先以测试环境一个应用作为试点，实施配置中心
• 稳定运行至少两周后，在生产环境的该应用上实施配置中心
• 再稳定运行两周后，在测试和生产环境的所有应用都改为使用配置中心
• 配置中心先使用Spring Cloud Config。不够用的话再考虑评估Apollo和Nacos

选型的考量

Spring Cloud Config的原理和架构相对比较容易理解，所以先以Spring Cloud Config作为一个具体的实例，介绍一个简化版本的配置中心。如果只是小团队的话，Spring Cloud Config已经足够用了。
但对于大一些的团队来说，还是存在以下两个不足：

• UI只能依赖Gitlab的界面
• 依赖于Git的权限控制粒度比较粗，也很难扩展

什么是配置中心

这里引用几篇配置中心的科普文。

第一篇

概述

英文版
https://12factor.net/zh_cn/
中文版
https://12factor.net/

这篇文章是Spring Cloud文档的总述部分提到的。12要素指的是构建SaaS应用的方法论的总结，一共有12条。
当得知这12要素是在2011年就提出的时候，我不禁由衷地钦佩。想想11年的时候我[消音–]都在做些啥。。。
从另外一个角度可以学习到的是如何从实践中提炼和总结经验，然后总结为理论。通过“实践-理论-实践-理论”这样的循环，实现螺旋式地提升。

意义

类似“社会主义核心价值观”（手动狗头），12要素对我们的意义主要在对实现的指导性。我们有些时候会觉得当前的代码管理/配置管理/部署方案/运维方案不够好，但又不知道怎么改进；有些时候看到了多种改进方案，但不知道哪一种更好。在这种时候可以参考12要素来决策。

12要素归类

我认为12要素可以粗略分为几类：

代码管理