发表于 |

年终总结

  • 2016
    • 计划读 5 本，实际读 13 本。
  • 2017
    • 计划 32 本，实际读完 23 本。
  • 2018
    • 计划 30 本，实际25本。
  • 2019
    • 计划 30 本，实际 43 本。

今年是第 4 年写读书记录了，感觉手上这本 TLPI 年底之前是看不完了，就总结一下。与之前不同的是今年把周末的时间利用的比较好，通常周末两天会拿出一整天的时间来看书，保证自己的精力集中，效率会高很多。

因为博客集成了豆瓣，所以就不列出 在读 和 想读 列表了，想的太多，耽误事。希望接下来读一些经典的技术书，把自己的基础知识补齐。

已读

  1. 《用Python写网络爬虫》
  2. 《Wireshark网络分析就这么简单》
  3. 《如何有效阅读一本书 : 超实用笔记读书法》
  4. 《冷场》
  5. 《Go程序设计语言》
  6. 《爱你就像爱生命》
  7. 《Go by Example》
  8. 《显微镜下的大明》
  9. 《流浪地球》
  10. 《情感勒索》
  11. 《Go语言实战》
  12. 《活着》
  13. 《悉达多》
  14. 《Go in Practice》
  15. 《奈飞文化手册》
  16. 《刻意练习》
  17. 《软件测试的艺术》
  18. 《Redis实战》
  19. 《雪崩》
  20. 《TCP/IP详解 卷1：协议》
  21. 《Structure and Interpretation of Computer Programs - 2nd Edition (MIT)》
  22. 《编码的奥秘》
  23. 《Kubernetes in Action》
  24. 《计算机组成：结构化方法》
  25. 《人月神话》
  26. 《自己动手写Docker》
  27. 《好文案一句话就够了》
  28. 《跟老男孩学Linux运维：Web集群实战》
  29. 《计算机组成与设计》
  30. 《简约至上》
  31. 《Go Web编程》
  32. 《大话数据结构》
  33. 《Python Web开发实战》
  34. 《Programming Kubernetes》
  35. 《Istio入门与实战》
  36. 《刷新》
  37. 《奇特的一生》
  38. 《图解密码技术（第3版）》
  39. 《细节》
  40. 《生活大爆炸里的科学》
  41. 《操作系统导论》
  42. 《RESTful Web APIs中文版》
  43. 《正则表达式必知必会》

发表于 |

背景

工作上使用的电脑因为各种各样的原因，被我安装为 Ubuntu 19.04，平时使用上没什么问题，但是最近发现它默认的 SSH 配置随着版本升级发生了变化，known_hosts 文件中记录的不再是 IP 地址，而是一串字符，这导致了当我想要删除某个主机的 key 时，无法准确的找到，因此想办法解决这个事情。

SSH

我们使用 Linux 系统的一个最基本的服务应该就是 SSH 了，除了偶尔我们通过 VNC 或者 KVM(Keyboard Virtual Manager)连接控制主机外，都是通过 SSH 到 Linux 主机上进行某些操作。那么 SSH 就是 Secure Shell，安全外壳协议。可在不安全的网络中为网络服务提供安全的传输环境。SSH 通过在网络中建立安全隧道来实现SSH客户端与服务器之间的连接。

SSH 最重要的就是安全，采用的是非对称加密，关于加密相关的部分，可以看我之前写的一篇《图解密码技术》读书笔记 里面有比较完整的相关知识。

这里主要说一下使用密码登陆和密钥登陆的流程。

密码登陆

  1. 客户端向服务端发起连接请求
1
2
3
4
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)?
  1. 客户端会提示，知道服务端的唯一标示，确认连接么
  2. 确认连接，输入 yes
1
2
3
4
5
6
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.67.90' (ECDSA) to the list of known hosts.
root@192.168.67.90's password:
  1. 服务端传输公钥给客户端，客户端输入密码，使用服务端公钥加密并发送给服务端
  2. 服务端使用私钥解密，验证密码正确，登陆成功
1
2
3
4
5
6
7
8
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.67.90' (ECDSA) to the list of known hosts.
root@192.168.67.90's password:
Last login: Fri Dec  6 21:51:00 2019 from 192.168.73.54
[root@node90 22:30:29 ~]$

密钥登陆

  1. 客户端向服务端发起连接请求
  2. 服务端收到客户端的请求，找到对应客户端的公钥，生成随机数
  3. 服务端使用客户端的公钥对随机数进行加密，发送给客户端
  4. 客户端使用私钥进行解密，得到随机数，并将随机数与 session key 拼接，并将结果通过 MD5 算出散列值
  5. 服务端同样使用随机数与 session key 拼接，并将结果通过 MD5 算出散列值
  6. 服务端对两个散列值进行校验，如果想通，则登陆成功

相关文件

~/.ssh/id_rsa

当前节点生成的私钥，使用 RSA 算法。

~/.ssh/id_rsa.pub

当前节点生成的公钥，使用 RSA 算法，与 id_rsa 成对出现。

~/.ssh/authorized_keys

用于保存已经授权（信任）的客户端公钥。

~/.ssh/known_hosts

known_hosts 中存放 SSH 自动维护并检查的一个数据库，该数据库包含曾经连接过的所有主机的标识。

这个文件也是今天的主角。

known_hosts

当我们客户端尝试连接服务端，会有一条提示，服务端主机的唯一标示是xxx，确认连接么，如果输入yes，那么这个主机的标示就会记录到 known_hosts，一般我们的 known_hosts 会长这样：

1
2
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
|1|+YgY28AEikbKxdosHK1Cxb6zJqs=|yEi41f2MIl6hU9uQOvXyzK0hByM= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

或者长这样：

1
2
3
root@yiran-30-250:~
   head -n 1 .ssh/known_hosts
192.168.70.250 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHNWt8CDe7sPvATsqx5zH5v9wJzYrFhu9fmYnshIYLEnuoXmCmVu2cGU8s/IjK2jU8hnFad4T1gMhst7cXLmqAo=

了解 https 相关知识的同学应该知道，证书的重要性。在 SSH 场景下，我们没有证书，那么就需要我们自己人为的确保我们要连接的服务端是可信的。如果我们第一次登陆 192.168.1.1 后，系统保存了主机唯一标示到了 ~/.ssh/known_hosts，如果我们下一次登陆 192.168.1.1 客户端发现主机唯一标示产生了变化，那么就会禁止我们登陆了。

在工作中经常遇到这种场景，可能的原因有很多：系统重装、快照回滚、IP 冲突等等。通常我们的做法就是闭着眼睛删除 known_hosts 里面的对应主机信息，然后重新登陆就可以了。

但是最近发现 Ubuntu 19.04 中记录的 known_hosts 是这样的：

1
2
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
|1|+YgY28AEikbKxdosHK1Cxb6zJqs=|yEi41f2MIl6hU9uQOvXyzK0hByM= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

是的，我们无法在一堆看似乱码中找到我们想要的主机并删掉它，这其实是 OpenSSH 新版本中的一项安全改进。

在 记一次系统被入侵分析过程 博客中有提到，现在好多病毒在入侵之后都是通过 SSH 相关信息进行横向扩散的，所以我们应该尽可能的少在系统中保存明文的 IP 地址相关信息。

但是对我测试环境来说，是没什么关系的，因此我需要禁止这个安全配置，来达到我的目的。

正确的姿势是修改 SSH 客户端的配置，将 HashKnownHosts 置为 no ，清空 known_hosts 文件，再连接服务端，就可以看到 known_hosts 已经显示 IP 地址了。

1
2
3
4
root@test-hostname-ubuntu-s-1804:~# cat /etc/ssh/ssh_config |grep -i hash
    HashKnownHosts no
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
192.168.67.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

当然如果你想搞破坏，可以尝试下这篇博客中提供的脚本：https://blog.rootshell.be/wp-content/uploads/2010/11/known_hosts_bruteforcer.pl.txt （谨慎使用）

参考链接

发表于 |

背景

在平时工作中我自己可能80% 的时间都在使用 Linux 进行工作，无论是软件开发还是环境维护，那么对于 Linux 发行版自然也是有比较熟悉的，比如 RHEL 系列。平时大家可能多多少少都会听到或接触到一些命令（术语），比如：grub,chroot,isolinux,bios 等等。今天打算就用 CentOS 发行版的 ISO 来谈谈自己对于 Linux 系统引导，安装，启动的理解。

CentOS ISO 目录树如下：

1
2
3
4
5
6
7
8
9
10
11
12
├── CentOS_BuildTag
├── EFI
├── EULA
├── GPL
├── images
├── isolinux
├── LiveOS
├── Packages
├── repodata
├── RPM-GPG-KEY-CentOS-7
├── RPM-GPG-KEY-CentOS-Testing-7
└── TRANS.TBL

isolinux

ISO 9660

ISO 9660 是一种文件系统，也是一种规范，它规定了 ISO 文件应该是什么样子，常见的 Linux 发行版 ISO 都符合该规范。

引导

有了 ISO，有了计算机，那么我们需要使用 ISO 安装想要的操作系统，通常我们会将 ISO 通过光盘/USB/网络等方式挂载到计算机上，通过设置 BIOS/UEFI 选项，将启动项设置为 ISO，然后启动进行安装。接下来一个一个来说。

BIOS/UEFI 通常存放在闪存中，在计算机开机自检完成后，加载引导程序（bootloader），这个初始化过程称为引导。BIOS/UEFI 通常允许用户设置加载选项，即从系统的众多设备中按照顺序进行加载，常见的比如：硬盘、光盘、网络、USB 等。当第一个设备加载失败后，会尝试第二个设备，以此类推，如果最终所有设备都无法加载，那么系统处于开机但未引导状态。

磁盘引导

如果从硬盘引导，那么计算机首先会读取 MBR（主引导记录 or 主引导扇区），MBR 在硬盘上的三维地址为（柱面，磁头，扇区）＝（0，0，1）。有时也将其开头的 446 字节内容特指为“主引导记录”（MBR），其后是4个16字节的“磁盘分区表”（DPT），以及2字节的结束标志（55AA）。

也就是说，如果我们的磁盘是一个包含 MBR 的磁盘，那么它的 446 字节到 446 + 16 * 4 = 510 字节部分是引导记录，而 510 字节地址记录的应该是 55AA 这个结束标志，我们来找个磁盘看下是否是这样：

1
2
3
4
5
6
7
8
9
10
11
root@yiran-30-250:/tmp
 $ dd if=/dev/vda of=a bs=512 count=1
记录了1+0 的读入
记录了1+0 的写出
512字节(512 B)已复制，0.000403482 秒，1.3 MB/秒
root@yiran-30-250:/tmp
 $ hexdump a
0000000 63eb 1090 d08e 00bc b8b0 0000 d88e c08e
...
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200

在确认了磁盘可引导之后，BIOS 将 MBR 中的 446 字节内容复制到内存中，并将控制权转给引导设备（即磁盘），之后根据 MBR 中的引导程序（bootloader）进行后续工作。这里 UEFI 与 BIOS 略有不同，UEFI 是通过查找磁盘上 FAT 分区中加载 EFI loader 来进行引导，可以说 UEFI 是基于文件系统的。

到这里，我们已经进行了引导的第一步，也是最关键的一步，那么现在运行的 bootloader 是什么呢？Linux 常见的有两种：LILO 全称 LInux LOader，是一种 Linux 引导程序，它自身很简单，甚至说简陋，目前使用场景很少。GRUB 全称 GNU GRUB，是一种引导程序，它允许启动不同的操作系统或者不同的内核，目前大多数 Linux 发行版均采用 GRUB 作为引导程序。

当引导程序为 GRUB 时，因为 MBR 大小有限，因此存放在 MBR 中的内容是 boot.img，作用是加载真正的 GRUB core.img，GRUB 运行后，会根据 grub.cfg 选项来加载真正的内核映像，并进入到 OS 启动阶段。

GRUB 加载的文件有两个：vmlinuz 和 initrd.img 。

vmlinuz(vmlinux)，压缩后可引导的 Linux kernel 内核映像，VM 代表 Virtual Memory，通常是 bzImage 格式。

1
2
3
root@yiran-30-250:/boot
 $ file vmlinuz-3.10.0-693.11.6.el7.x86_64
vmlinuz-3.10.0-693.11.6.el7.x86_64: Linux kernel x86 boot executable bzImage, version 3.10.0-693.11.6.el7.x86_64 (builder@kbuilder.dev.centos.org) #1, RO-rootFS, swap_dev 0x5, Normal VGA

initramfs.img（init ramdisk.img），有了可引导的内核映像还不够，因为我们不能确保我们的硬件设备是 kernel 可以直接识别的，往往需要加载一些启动来保证硬件的识别，这时候就需要 initramfs.img 来提供一个临时文件系统，运行在内存中。

有时候我们也会看到 initrd.img 文件，initrd 是 initramfs 出现之前的方式，因为它内部有文件系统，运行在内存中造成了一定的空间浪费，而 initramfs 是 tmpfs，在使用上更方便。

1
2
3
4
5
6
root@yiran-30-250:/boot
 $ file initrd-plymouth.img
initrd-plymouth.img: gzip compressed data, from Unix, last modified: Wed Mar 28 13:41:54 2018, max compression
root@yiran-30-250:/boot
 $ file initramfs-3.10.0-693.11.6.el7.x86_64.img
initramfs-3.10.0-693.11.6.el7.x86_64.img: ASCII cpio archive (SVR4 with no CRC)

到这里已经比较清楚了，接下来就是挂载相应配置的文件系统，执行 systemd（pid 为1）的进程，这里不再详细描述。

光盘引导

在介绍了常规的磁盘引导后，我们来看看光盘引导的流程。

根据 El-Torito 规范，BIOS 会读取 ISO 的准确地址进行判断，ISO 是否可以进行引导启动（在第 71 字节地址保存引导目录）。如果判断可引导，那么就加载对应的引导程序（bootloader）。

常见的引导程序有：SYSLINUX,ISOLINUX,PXELINUX,EXTLINUX 等，这些可以统称为 Syslinux，目前最常见的应该是 ISOLINUX。PXELINUX 用于从网络引导，EXTLINUX 用于 ext 系列文件系统引导。

注意：由于目前 UEFI 的普遍性，部分 LiveCD ISO 会同时带有 ISOLINUX 和 GRUB 两种引导程序。

我们来看看 ISO 中 isolinux 路径下放了什么文件：

1
2
3
4
5
6
7
8
9
10
11
12
 $ tree 
├── boot.cat # 启动目录
├── boot.msg # 启动信息
├── grub.conf # GRUB 配置文件
├── initrd.img # 临时文件系统
├── isolinux.bin # ISOLINUX 引导程序
├── isolinux.cfg # ISOLINUX 引导配置文件
├── memtest # 内存测试可执行文件
├── splash.png # ISOLINUX 引导背景图片
├── TRANS.TBL # 扩展文件名
├── vesamenu.c32 # Menu 配置
└── vmlinuz # 内核映像

根据以上文件信息及用途描述，我们来看下光盘引导的大概流程：

  1. 加载 isolinux.bin
  2. 加载 isolinux.cfg,vesamenu.c32,splash.png 生成启动菜单
  3. 根据选项决定是否加载 vmlinuz, initrd.img

关于 isolinux 目录和 Linux 引导部分大概是这样，主要是要理清楚整个流程。

EFI

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 $ tree 
.
├── BOOT
│   ├── BOOTIA32.EFI  # 32位系统 EFI 启动程序
│   ├── BOOTX64.EFI # 64位系统 EFI 启动程序
│   ├── fonts # 字体
│   │   ├── TRANS.TBL
│   │   └── unicode.pf2
│   ├── grub.cfg # GRUB 配置
│   ├── grubia32.efi # GRUB 32位引导程序
│   ├── grubx64.efi # GRUB 64位引导程序
│   ├── mmia32.efi # 内存测试 32 位执行程序
│   ├── mmx64.efi # 内存测试 64 位执行程序
│   └── TRANS.TBL
└── TRANS.TBL

有了前面 isolinux 关于引导部分的介绍，这里 EFI 完全可以一一对应，如果计算器启动模式为 BIOS，那么是通过 ISOLINUX 引导，如果启动模式是 UEFI，那么是通过 EFI（GRUB）引导。

images

1
2
3
4
5
6
7
 $ tree 
├── efiboot.img
├── pxeboot
│   ├── initrd.img
│   ├── TRANS.TBL
│   └── vmlinuz
└── TRANS.TBL

这个路径文件很突兀，没有什么配置文件，看上去系统也没有用到，其实这里是为了文件复用而把 vmlinuz 和 initrd.img 提取出来了，在 EFI 路径下的 BOOT/grub.cfg 中有很多选项都是使用的 pxeboot/vmlinuz 。当然它最大的作用也是跟路径名一样，images，当你要配置一个发行版作为网络安装时，需要对应的 vmlinuz 和 initrd.img，那么可以从这个路径下获取，不会造成我要通过 PXELINUX 引导，却需要去 EFI 路径下获取文件的困扰。

LiveOS

1
2
3
 $ tree 
├── squashfs.img
└── TRANS.TBL

LiveOS，字面意思就是运行在内存中的 OS，现在大多数发行版为了让用户第一时间不用安装到磁盘上即可体验发行版的某些功能，而支持将 OS 运行在内存中，简单快捷。

squashfs.img，是一套供Linux核心使用的GPL 开源只读压缩档案系统。Squashfs能够为档案系统内的档案、inode及目录结构进行压缩，并支援最大1024 千位元组的区段，以提供更大的压缩比。

根据维基百科描述，squashfs.img 应该是包含了一个完整的 Linux映像的，我们来尝试挂载查看下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
root@yiran-30-250:/tmp
 $ ls squashfs.img
squashfs.img
root@yiran-30-250:/tmp
 $ file squashfs.img
squashfs.img: Squashfs filesystem, little endian, version 4.0, 368572502 bytes, 3 inodes, blocksize: 131072 bytes, created: Tue Sep  5 21:35:03 2017
root@yiran-30-250:/tmp
 $ mount -t squashfs squashfs.img /tmp/yiran
root@yiran-30-250:/tmp
 $ ls /tmp/yiran/LiveOS/rootfs.img
/tmp/yiran/LiveOS/rootfs.img
root@yiran-30-250:/tmp
 $ file /tmp/yiran/LiveOS/rootfs.img
/tmp/yiran/LiveOS/rootfs.img: Linux rev 1.0 ext4 filesystem data, UUID=e2fddbe2-a003-4b98-b272-3defe7b377c4, volume name "Anaconda" (extents) (64bit) (huge files)
root@yiran-30-250:/tmp
 $ mount /tmp/yiran/LiveOS/rootfs.img /tmp/yiran-root
root@yiran-30-250:/tmp
 $ ls /tmp/yiran-root
bin  dev  etc  firmware  lib  lib64  lost+found  mnt  modules  proc  root  run  sbin  sys  tmp  usr  var

既然是一个完整的 Linux 映像，我们可以直接通过 chroot 命令切换根目录：

1
2
3
4
5
6
7
8
9
10
11
[root@yiran-30-250 00:24:30 yiran-root]$pwd
/tmp/yiran-root
[root@yiran-30-250 00:24:31 yiran-root]$ls
bin  dev  etc  firmware  lib  lib64  lost+found  mnt  modules  proc  root  run  sbin  sys  tmp  usr  var
[root@yiran-30-250 00:24:32 yiran-root]$chroot .
bash: /var/log/bash.log: 只读文件系统
[root@yiran-30-250 16:24:34 /]$cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
bash: /var/log/bash.log: 只读文件系统
[root@yiran-30-250 16:24:36 /]$exit

因为文件系统是只读的，所以我们只是进行了简单的读取操作。

总结

通过 CentOS 发行版，我们一点点从计算机上电开始，走通整个流程，这只是一个最简单的流程，之前博客也多少提到过通过 KickStart 或者其他自动化方式安装等方式，这里不再描述。

在做事情之前最好把整个流程想通，再去研究细节部分。

参考链接

发表于 |

背景

最近在折腾 Cluster API 的时候，因为目前社区中比较成熟的方案是通过 Cloud-init 执行 kubeadm 命令部署 k8s ，因此需要使用 Cloud-init 进行功能验证，但是 Cloud-init 通常执行的前提条件是系统初次启动时，自动执行配置，这点对于调试很不友好，因此需要找到一个无需重启即可执行 Cloud-init 配置的方式。

Cloud-init

使用过公有云或者私有云的同学应该都知道在创建虚拟机的时候可以传递一个脚本用于在机器置备的时候执行某些动作，尤其在批量执行的时候，通常会很方便。这个其实就是 Cloud-init 所做的工作，就跟它的名字一样，针对 Cloud 场景执行 init 动作。

引用官网介绍：

Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization. It is supported across all major public cloud providers, provisioning systems for private cloud infrastructure, and bare-metal installations.

NoCloud

Cloud-init 官方支持云平台种类很多常见的公有云如 Aliyun、AWS、Azure，常见的私有云解决方案如 OpenStack、ZStack、OVF 等都有支持。

但是如果我不使用已经支持的私有云，而是自己通过 Libvirt 配合 Ceph 实现了一套虚拟化平台，想要使用 Cloud-init，则可以使用 ConfigDrive 或者 NoCloud 方式。本文采用的是 NoCloud 方式。

配置文件

使用默认配置就好，Cloud-init 在没有指定 Datasource 的情况下，会自己依次尝试：

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@localhost ~]# cat /etc/cloud/cloud.cfg
users:
 - default

disable_root: 1
ssh_pwauth:   0

mount_default_fields: [~, ~, 'auto', 'defaults,nofail,x-systemd.requires=cloud-init.service', '0', '2']
resize_rootfs_tmp: /dev
ssh_deletekeys:   0
ssh_genkeytypes:  ~
syslog_fix_perms: ~
disable_vmware_customization: false

Metadata

这里我们指定 NoCloud 的路径，并配置 Metadata 文件：

1
2
3
4
5
[root@localhost nocloud]# pwd
/var/lib/cloud/seed/nocloud
[root@localhost nocloud]# cat meta-data
instance-id: yiran
hostname: yiran

Userdata

我们在 Cloud-init 自动配置时，执行命令 echo 保存信息到文件中

l l
1
2
3
4
5
6
7
8
[root@localhost nocloud]# pwd
/var/lib/cloud/seed/nocloud
[root@localhost nocloud]# cat user-data
## template: jinja
#cloud-config

runcmd:
  - 'echo yiran test cloud-init with nocloud > /root/file'

手动执行 Cloud-init

在了解 Cloud-init 工作流程后执行比较简单，因此这里直接贴出操作步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
[root@localhost ~]# pwd
/root
[root@localhost ~]# ls
anaconda-ks.cfg
[root@localhost ~]# cloud-init init
Cloud-init v. 18.5 running 'init' at Fri, 29 Nov 2019 14:02:10 +0000. Up 635.10 seconds.
ci-info: +++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: | Device |  Up  |           Address            |      Mask     | Scope  |     Hw-Address    |
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: |  eth0  | True |        192.168.77.158        | 255.255.240.0 | global | 52:54:00:2f:d9:44 |
ci-info: |  eth0  | True | fe80::108b:ab9c:1a1a:9ab8/64 |       .       |  link  | 52:54:00:2f:d9:44 |
ci-info: |   lo   | True |          127.0.0.1           |   255.0.0.0   |  host  |         .         |
ci-info: |   lo   | True |           ::1/128            |       .       |  host  |         .         |
ci-info: +--------+------+------------------------------+---------------+--------+-------------------+
ci-info: +++++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++++
ci-info: +-------+--------------+----------------+---------------+-----------+-------+
ci-info: | Route | Destination  |    Gateway     |    Genmask    | Interface | Flags |
ci-info: +-------+--------------+----------------+---------------+-----------+-------+
ci-info: |   0   |   0.0.0.0    | 192.168.64.215 |    0.0.0.0    |    eth0   |   UG  |
ci-info: |   1   | 192.168.64.0 |    0.0.0.0     | 255.255.240.0 |    eth0   |   U   |
ci-info: +-------+--------------+----------------+---------------+-----------+-------+
ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: |   9   |  fe80::/64  |    ::   |    eth0   |   U   |
ci-info: |   10  |  fe80::/64  |    ::   |    eth0   |   U   |
ci-info: |   14  |   ff00::/8  |    ::   |    eth0   |   U   |
ci-info: +-------+-------------+---------+-----------+-------+
[root@localhost ~]# cloud-init modules -m config
Cloud-init v. 18.5 running 'modules:config' at Fri, 29 Nov 2019 14:02:18 +0000. Up 643.31 seconds.
[root@localhost ~]# cloud-init modules -m final
Cloud-init v. 18.5 running 'modules:final' at Fri, 29 Nov 2019 14:02:21 +0000. Up 646.27 seconds.
ci-info: no authorized ssh keys fingerprints found for user centos.
Cloud-init v. 18.5 finished at Fri, 29 Nov 2019 14:02:21 +0000. Datasource DataSourceNoCloudNet [seed=/var/lib/cloud/seed/nocloud][dsmode=net].  Up 646.44 seconds
[root@localhost ~]# ls
anaconda-ks.cfg  file
[root@localhost ~]# cat file
yiran test cloud-init with nocloud

参考链接

发表于 |

背景

有时候在运行代码的时候，想要程序在接收到 Ctrl+C 指令的时候做一些平滑的处理，来写一下在 Python 和 Golang 中如何接收 Ctrl+C 指令。

Python

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import signal
import time
import sys


def run_program():
    while True:
        print("Test code...")
        time.sleep(1)


def exit_gracefully(signum, frame):
    signal.signal(signal.SIGINT, original_sigint)
    print("Receive Ctrl+C.")
    sys.exit(1)


if __name__ == '__main__':
    original_sigint = signal.getsignal(signal.SIGINT)
    signal.signal(signal.SIGINT, exit_gracefully)
    run_program()

Golang

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package main

import (
	"fmt"
	"os"
	"os/signal"
	"sync"
	"time"
)

func WaitForCtrlC() {
	var end_waiter sync.WaitGroup
	end_waiter.Add(1)
	var signal_channel chan os.Signal
	signal_channel = make(chan os.Signal, 1)
	signal.Notify(signal_channel, os.Interrupt)
	go func() {
		<-signal_channel
		end_waiter.Done()
	}()
	end_waiter.Wait()
}

func testCode() {
	for {
		fmt.Println("Test code...")
		time.Sleep(time.Duration(1) * time.Second)
	}
}

func main() {
	fmt.Printf("Press Ctrl+C to end\n")
	go testCode()
	WaitForCtrlC()
	fmt.Printf("Receive Ctrl+C.\n")
}

发表于 |

背景

Ansible 作为一款配置管理和应用部署的软件，日常使用的场景很多，我自己也是重度用户。最近在使用 Ansible 进行文件传输的时候踩了个坑，借此机会整理下 Ansible 传输文件的几种方式。

实验环境：

1
2
3
4
5
6
7
[root@yiran ~]# ansible --version
ansible 2.7.12
  config file = None
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Aug  7 2019, 00:51:29) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

Template

https://docs.ansible.com/ansible/latest/modules/template_module.html

Ansible 一个常用的功能就是配置管理，通过 Ansible 批量分发配置文件，达到统一版本管理的效果，如果我们想要进行少量的文件传输，从控制节点传输到被管理节点，那么可以采用这种方式来完成。

具体的使用官方文档 已经讲的很详细了，这里不再啰嗦。

因为版本是通过 Jinja2 模板传输，支持模板渲染
虽然我们可以在模版中不制定任何参数，直接将其拷贝，但是相比 Copy/Fetch 模块还是需要有模版渲染的一步，速度要慢一些

Copy/Fetch 模块

https://docs.ansible.com/ansible/latest/modules/copy_module.html

https://docs.ansible.com/ansible/latest/modules/fetch_module.html

如果说我们通过模板来传输文件优点歪门邪道，那么通过 Copy/Fetch 就是 Ansible 官方提供的两个正统模块。

Copy 用于把文件（或文件夹）从控制节点（或远程节点）分发到被管理节点，Copy 在拷贝过程中不会修改文件中的内容或编码，仅仅做传输工作。

Fetch 用于从被管理节点传输文件到控制节点。需要注意的是 Fetch 只能拉取文件，而 Copy 是可以传输文件或者文件夹的。

不算坑的坑

在使用 Copy/Fetch 时，总体感受是比较好的，但是有一点需要注意，如果你拷贝的文件过多，或者单个文件大小过大，那么最好不要使用 Copy/Fetch。

Ansible 默认配置中，使用 SFTP 作为文件传输协议：

There’s really no reason to change this unless problems are encountered, and then there’s also no real drawback to managing the switch. Most environments support SFTP by default and this doesn’t usually need to be changed.

SFTP 是基于 SSH 协议的，与 FTP 没啥关系。SFTP 并不以性能渐长，甚至可以说性能很差，至少与 FTP、Rsync 没办法相比。

关于 SFTP 为什么速度这么慢，StackOverFlow 有个回答写的很详细，这里引用一段：

I’m the author of HPN-SSH and I was asked by a commenter here to weigh in. I’d like to start with a couple of background items. First off, it’s important to keep in mind that SSHv2 is a multiplexed protocol - multiple channels over a single TCP connection. As such, the SSH channels are essentially unaware of the underlying flow control algorithm used by TCP. This means that SSHv2 has to implement its own flow control algorithm. The most common implementation basically reimplements sliding windows. The means that you have the SSH sliding window riding on top of the TCP sliding window. The end results is that the effective size of the receive buffer is the minimum of the receive buffers of the two sliding windows.

Synchronize

上面提到的两个模块性能都不好，总会有个性能好的来解决这个问题，就是 Synchronize。Synchronize 是通过 rsync 来达到文件传输的目的，是 rsync 的封装。

在使用上因为是调用的 rsync，所以控制节点需要安装 rsync ，Synchronize 模块的并不会完全实现 rsync 所有功能，只是通过 rsync 来达到我们想要的快速同步的功能。

坑

在使用 Ansible 过程中，通常会使用普通用户配合密钥的形式来进行用户验证，如果需要 root 权限那么通过 become 关键字来提权。

在 sudo 的早期版本中， /etc/sudoers 中有这么一条配置，高版本取消了 tty 的限制：

1
2
3
4
5
#
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

这个配置会导致 Ansible 调用 rsync 执行时失败，可以通过修改 /etc/sudoers 或者升级 sudo 软件包来解决。

总结

那么说了以上这三种方式，就需要来一个总结对比，看看什么场景下使用什么模块更方便：

模块 传输文件 传输文件夹 文件修改 文件编码 速度 文件源 权限配置 文件验证
Template Y N Y Y 慢 控制节点 Y Y
Copy/Fetch Y Y/N N N 慢 控制节点/远程节点 Y Y
Synchronize N Y N N 快 控制节点 Y N

各个模块没有具体的好坏，全看个人需求来使用合适的模块就好。

参考链接

发表于 |

背景

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

现象

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

1
2
3
4
5
6
7
8
9
10
11
[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 磁盘，所以速度也不会慢到哪去。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
[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 中添加这两项配置来更改相应的数值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[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，内心还是有些慌的，如果有读者看到并知道原因，麻烦留言告诉我，谢谢。

参考链接

发表于 |

背景

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

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 地址的对应关系后，后续直接通过二层联通，不需要经过查找路由这一步了。

参考链接

发表于 |

背景

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

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

编译

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

Python

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

  1. Python 软件是否依赖了 C/C++ ，如果依赖了，那么需要在 ARM 机器上使用 FPM 的时候编译构建 RPM
  2. 从网上下载的 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 服务器正常获取的信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
[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 是物理内存的映像，可以直接通过它来访问物理内存，在代码运行中，发现服务器一直报错：

1
2
3
4
5
6
** 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 查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[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：

1
2
3
4
5
6
7
8
9
10
[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 的版本，放弃了。

总结

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

发表于 |

背景

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

容器工具体验系列：

What

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

功能列表：

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

支持镜像仓库类型：

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

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

How

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

镜像详情

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
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 无法获取每层的大小，瞬间感觉使用价值不大了（- -

镜像拷贝

将远端镜像拷贝到本地：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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 就是负责这个事情。

参考链接