lightroom

01 基础设置

修改照片模式下隐藏

  • 上 f5
  • 下 f6
  • 左 f7
  • 右 f8
  • 隐藏左右 tab
  • 隐藏全部 shift+tab
  • 旗标 p
  • 移去旗标 u
  • 设置为排除 x

02 镜头矫正

畸变

  • 广角容易产生筒形畸变
  • 长焦容易产生枕形畸变

    色差

  • 良好光照条件下逆光时暗部物体边缘
  • 对比度高时暗部物体边缘
  • 大光圈拍照时暗部物体边缘
  • 和相机镜头成像质量有关

    暗角

  • 焦距短 光圈大 光照不好

03 色彩


  • 45度 邻近色

  • 120度 对比色

  • 180度 互补色

  • hsl调色顺序 色相->亮度->饱和度

  • 提高鲜艳度降低饱和度达到颜色统一

  • 色温色调适合调整夜景照片，对黑色不起作用

04 影调

  • 原片是否曝光准确？亮的部分是哪里？暗的部分是哪里？亮的部分该亮吗？暗的部分该暗吗？
  • 确定自己想要的风格整体影调该如何变化？亮的部分应该多亮？暗的部分应该多暗？

05清晰度

通过提高各部分边缘的色相和亮度的差别从而让图片更清楚

  • 用于增强照片质感(增加粗糙感或沧桑感)

06锐化

通过勾边让图片更清楚

  • 用于增强物体轮廓

07噪点

  • 热噪点: 相机长时间曝光 处理信息过多 相机CMOS过热（无法处理）
  • 亮度噪点: 黑白颗粒
  • 颜色噪点: 彩色颗粒

一般先除去眼色噪点再去除亮度噪点

08校准

红绿蓝三原色向任意方向偏移时

  1. 原色及邻近色，偏向目标颜色
  2. 滑杆另一侧颜色，饱和度降低
  3. 原色和目标颜色的互补色区域，色相相互靠拢

目的是可以统一照片色相,搭配hsl达到简化视觉要素

09分离色调

以亮度划分的整体调色工具
多用于光比大的场景

颜色划分

  • HSL:某一具体色相
  • 校准:局部色相偏移

亮度划分

  • 分离色调:局部亮度（高光、阴影、中间调）
  • 曲线调色:自定义亮度
  • 色温色调: 也会影响亮度

展开全文 >>

2023

回看23年初的碎碎念，半年时光一下子就溜走了。可喜的是年初的展望在一点点化为现实。从住了两年多的公寓搬走了，找到了一个还算比较满意的住所。今年开启了自己的厨艺修炼之路，端上饭桌的那一刻真的很幸福。目前对工作技能上到是没有太强烈的需求，上半年看了看《编码：隐匿在计算机软硬件背后的语言》、《Linu内核设计的艺术》、《Linux内核设计与实现》。最近在看《Linux设备驱动程序》。其实目前的工作也用不上，主要还是自己想接触接触这块的东西，但是犯懒没做什么笔记 =_=

年初想买的富士在5月31号那天被佳能r62代替了（其实做了很久的功课），本来是打算生日时候送给自己一个相机,结果变成儿童节礼物了哈哈。最近在疯狂汲取摄影知识以及后期！当然还有stable diffusion!

这是昨天在小区门口拍到的，还碰到了一对情侣也在拍日落^^，这算是耶稣光吗哈哈

展开全文 >>

2023

一晃又一年，2022年过得实在太快了，今年一整年的时间都被工作和疫情填满了，跨年夜突然打算买一个富士相机，在新的一年出去走走，拍拍照记录一下旅行和生活，好不容易看上一个xt5还没货，只能再观望一下了，可能老天都不想让我冲动消费吧，先找时间学一学摄影吧

展望一下2023，是找一个新的工作还是换一个新的住所、是开启一段旅行还是换个地方出差、是主动追求幸福还是继续静静等待。不得不说这两年半的大部分精力都投入在个人技术成长和工作上了，是时候思考一下工作以外的事情了，毕竟说好的热爱技术但更热爱生活，希望2023的我有勇气做出抉择,拭目以待吧

展开全文 >>

Linux Cgroups

概念

cgroups是Linux内核提供的一种机制，这种机制可以根据需求把一系列系统任务及其子任务整合（或分隔）到按资源划分等级的不同组内，从而为系统资源管理提供一个统一的框架。

本质上来说，cgroups是内核附加在程序上的一系列钩子（hook），通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。

特性

  • cgroups的API以一个伪文件系统(cgroupfs)的方式实现，用户态的程序可以通过文件操作实现cgroups的组织管理
  • cgroups的组织管理操作单元可以细粒度到线程级别，另外用户可以创建和销毁cgroup，从而实现资源再分配和管理
  • 所有资源管理的功能都以子系统的方式实现，接口统一
  • 子任务创建之初与其父任务处于同一个cgroups的控制组

功能

  • 资源限制：cgroups可以对任务使用的资源总额进行限制
  • 优先级分配：通过分配的CPU时间片数量及磁盘IO带宽大小，实际上就相当于控制了任务运行的优先级
  • 资源统计：cgroups可以统计系统的资源使用量，如CPU使用时长、内存用量等，这个功能非常适用于计费
  • 任务控制：cgroups可以对任务执行挂起、恢复等操作

名词

  • Task(任务)：在linux系统中，内核本身的调度和管理并不对进程和线程进行区分，只是根据clone时传入的参数的不同来从概念上区分进程和线程。这里使用task来表示系统的一个进程或线程
  • Cgroup(控制组)：cgroups中的资源控制以cgroup为单位实现。Cgroup表示按某种资源控制标准划分而成的任务组，包含一个或多个子系统。一个任务可以加入某个cgroup，也可以从某个cgroup迁移到另一个cgroup
  • Subsystem(子系统)：cgroups中的子系统就是一个资源调度控制器(又叫controllers)。比如CPU子系统可以控制CPU的时间分配，内存子系统可以限制内存的使用量 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    zeyu@zeyu-desktop:~$ cat /proc/cgroups 
    #subsys_name	hierarchy	num_cgroups	enabled
    cpuset	9	1	1                   # 给cgroup中的任务分配独立的CPU(多处理器系统) 和内存节点
    cpu	8	102	1                       # 限制CPU时间片的分配，与cpuacct挂载在同一目录
    cpuacct	8	102	1                   # 生成cgroup中的任务占用CPU资源的报告，与cpu挂载在同一目录 
    blkio	11	102	1                   # 对块设备的IO进行限制
    memory	7	166	1                   # 对cgroup中的任务的可用内存进行限制，并自动生成资源占用报告
    devices	12	102	1                   # 允许或禁止cgroup中的任务访问设备
    freezer	4	2	1                   # 暂停/恢复cgroup中的任务
    net_cls	2	1	1                   # 使用等级识别符（classid）标记网络数据包，这让Linux流量控制器(Traffic Controller,TC)可以识别来自特定cgroup任务的数据包，并进行网络限制
    perf_event	3	1	1               # 允许使用perf工具来监控 cgroup
    net_prio	2	1	1               # 允许基于cgroup设置网络流量(netowork traffic)的优先级
    hugetlb	5	1	1                   # 限制使用的内存页数量
    pids	10	105	1                   # 限制任务的数量
    rdma	6	1	1                   # 限制RDMA/IB-specific的使用数量
  • Hierarchy(层级)：层级由一系列cgroup以一个树状结构排列而成，每个层级通过绑定对应的子系统进行资源控制。层级中的cgroup 节点可以包含零个或多个子节点，子节点继承父节点挂载的子系统。一个操作系统中可以有多个层级。系统中的多个cgroup构成的层级并非单根结构，可以允许存在多个,如果只有一个层级，那么所有的任务都将被迫绑定其上的所有子系统，这会给某些任务造成不必要的限制

规则

  • 同一个层级可以附加一个或多个子系统
  • 一个子系统可以附加到多个层级，当且仅当目标层级只有唯一一个子系统时(一个已经附加在某个层级上的子系统不能附加到其他含有别的子系统的层级上)
  • 系统每次新建一个层级时，该系统上的所有任务默认加入这个新建层级的初始化cgroup，这个cgroup也被称为root cgroup
  • 对于创建的每个层级，任务只能存在于其中一个cgroup中，即一个任务不能存在于同一个层级的不同cgroup中，但一个任务可以存在于不同层级中的多个cgroup中。如果操作时把一个任务添加到同一个层级中的另一个cgroup中，则会将它从第一个cgroup中移除
  • 任务在fork/clone自身时创建的子任务默认与原任务在同一个cgroup中，但是子任务允许被移动到不同的cgroup中
  • 如果新建的层级结构要绑定的子系统与目前已经存在的层级结构完全相同，那么新的挂载会重用原来已经存在的那一套
  • 目前无法将一个新的子系统绑定到激活的层级上，或者从一个激活的层级中解除某个子系统的绑定
  • 创建的层级中创建文件夹，就类似于fork了一个后代cgroup，后代cgroup中默认继承原有cgroup中的配置属性，但是可以根据需求对配置参数进行调整
  • 一个顶层的cgroup文件系统被卸载（unmount）时，如果其中创建过深层次的后代cgroup目录，那么就算上层的cgroup被卸载了，层级也是激活状态，其后代cgroup中的配置依旧有效。只有递归式地卸载层级中的所有cgroup，那个层级才会被真正删除

cgroup中文件

  • tasks：这个文件中罗列了所有在该cgroup中任务的TID，即线程ID(gettid)
  • cgroup.procs：这个文件罗列所有在该cgroup中的TGID（线程组ID），即线程组中第一个进程的PID
  • notify_on_release：填0或1，表示是否在cgroup中最后一个任务退出时通知运行release agent，默认情况下是0，表示不运行
  • release_agent：指定release agent执行脚本的文件路径（该文件在最顶层cgroup目录中存在），这个脚本通常用于自动化卸载无用的cgroup

/proc/[pid]/cgroup

1
2
3
4
5
6
7
8
9
10
11
12
13
14
zeyu@zeyu-desktop:~/work$ cat /proc/self/cgroup 
12:devices:/user.slice
11:blkio:/user.slice
10:pids:/user.slice/user-1001.slice/user@1001.service
9:cpuset:/
8:cpu,cpuacct:/user.slice
7:memory:/user.slice/user-1001.slice/user@1001.service
6:rdma:/
5:hugetlb:/
4:freezer:/
3:perf_event:/
2:net_cls,net_prio:/
1:name=systemd:/user.slice/user-1001.slice/user@1001.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-b3ed7abd-c7b2-4837-a6b7-9bbdce65c6bc.scope
0::/user.slice/user-1001.slice/user@1001.service/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-b3ed7abd-c7b2-4837-a6b7-9bbdce65c6bc.scope

每一行包含用冒号隔开的三列，他们的含义分别是：

  • cgroup树的ID， 和/proc/cgroups文件中的ID一一对应
  • 和cgroup树绑定的所有subsystem，多个subsystem之间用逗号隔开。这里name=systemd表示没有和任何subsystem绑定，只是给他起了个名字叫systemd
  • 进程在cgroup树中的路径，即进程所属的cgroup，这个路径是相对于挂载点的相对路径

命令

  • 创建层级 
    1
    sudo mount -t cgroup -o cpuset cgroup /cgroup
  • 相关工具 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    # 安装cgroup工具
    apt install cgroup-tools
    # 创建子控制组群 (mkdir)
    sudo cgcreate -g cpuset:test
    # 设置cpu子系统参数 (echo >)
    sudo cgset -r cpuset.cpus=1 test/
    # 在cgroup中执行命令
    sudo cgexec -g memory:test ls
    # 将进程加入cpu子控制群组 (echo >>)
    sudo cgclassify -g memory:test 133719
    # 删除cpu子控制组 (rmdir)
    sudo cgdelete memory:test
    # 查看所有的cgroup
    lscgroup
    # 查看所有支持的子系统
    lssubsys -a
    # 查看所有子系统挂载的位置
    lssubsys -m
    # 查看单个子系统（如memory）的挂载位置
    lssubsys -m memory

cgroups v1 & cgroups v2

尽管cgroups v2(Linux 4.5)旨在取代cgroups v1(Linux 2.6.24)，但出于兼容性原因，不太可能完全取代。目前，cgroups v2只实现cgroups v1中可用的控制器的子集

cgroups v1和cgroups v2可以互补使用,但是一个子系统不能同时用于cgroups v1层次结构和cgroups v2层次结构

cgroups v1

在cgroups v1下，每个控制器可以安装在一个单独的cgroup文件系统上，该文件系统为系统上的进程提供了自己的层次结构,也可以多个控制器一起安装在同一个cgroup文件系统。在已经挂载的层次结构中,每一个目录为一个控制组,子目录为子控制组。

在cgroups v1中可以区分进程和线程,但对于内存控制器来说毫无意义，因为进程的所有线程共享一个地址空间，对于控制进程中线程这一问题在cgroup v2中被调整

cgroups使用需要开启内核编译选项CONFIG_CGROUP,此外，每个v1控制器都有一个相关的配置选项，必须设置该选项才能使用该控制器

为了使用v1控制器，它必须安装在cgroup文件系统上。此类安装的通常位置在tmpfs文件系统(/sys/fs/cgroup)

1
mount -t cgroup -o cpu none /sys/fs/cgroup/cpu

可以针对同一层次结构同时安装多个控制器
1
2
mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct
mount -t cgroup -o all cgroup /sys/fs/cgroup

安装没有附加控制器的cgroup层次结构,这种层次结构的唯一目的是跟踪进程
1
mount -t cgroup -o none,name=somename none /some/mount/point

通过写入cgroup.procs将对应进程以及其线程加入一个cgroup，一次只能将一个PID写入此文件，写入0将导致写入的进程加入对应cgroup

展开全文 >>

Namespace

概念

Linux namespaces将全局系统资源以抽象的方式封装隔离，这使得命名空间中的进程似乎拥有独立的全局系统资源实例。改变一个namespace中的系统资源只会影响当前namespace里的进程，对其他namespace中的进程没有影响

命名空间类型

命名空间 标志 man文档 隔离内容
Cgroup CLONE_NEWCGROUP cgroup_namespaces(7) Cgroup root directory (cgroup根目录）
IPC CLONE_NEWIPC ipc_namespaces(7) System V IPC(信号量、消息队列、共享内存), POSIX message queues
Network CLONE_NEWNET network_namespaces(7) Network devices,stacks, ports, etc. (网络设备、网络栈、端口)
Mount CLONE_NEWNS mount_namespaces(7) Mount points (挂载点)
PID CLONE_NEWPID pid_namespaces(7) Process IDs (进程号)
User CLONE_NEWUSER user_namespaces(7) User and group IDs (用户和组）
UTS CLONE_NEWUTS uts_namespaces(7) Hostname and NIS domain name (主机名、NIS域名)

命名空间相关API

  • clone 可以创建一个子进程，可以同时通过flags参数创建对应命名空间
  • setns 可以让调用的进程通过打开/proc/[pid]/ns文件描述符加入一个已经存在的命名空间
  • unshare 不启动新的进程,直接让调用进程加入新的命名空间
  • ioctl/ioctl_ns 获取命名空间信息

一般情况下使用clone,或者unshare创建新命名空间都需要CAP_SYS_ADMIN能力,自从linux 3.8支持了非特权用户创建用户命名空间

命名空间的创建者有能力去修改全局资源达到控制后续创建的进程以及join到这个命名空间的进程在这个命名空间资源访问

/proc/[pid]/ns/

这个目录下包含进程对应的每一个命名空间

1
2
3
4
5
6
7
8
9
10
zeyu@zeyu-desktop:~$ ls -l /proc/$$/ns
total 0
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 net -> 'net:[4026531897]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 pid_for_children -> 'pid:[4026531836]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 user -> 'user:[4026531837]'
lrwxrwxrwx 1 zeyu zeyu 0 Nov 28 15:49 uts -> 'uts:[4026531838]'

将对应的文件保持打开或者将文件通过bind绑定到其他地方可以让对应命名空间一直存在,即使命名空间内的进程都已经退出

如果两个进程在同一个命名空间,那么他们对应节点的设备id,和inode是相同的,可以通过stat.st_dev和stat.st_ino查看

软连接指向内容是命名空间的类型和对应的inode

1
2
zeyu@zeyu-desktop:/proc/self/ns$ readlink /proc/self/ns/cgroup 
cgroup:[4026531835]

/proc/sys/user (linux 4.9)

包含每一个命名空间可以被创建的最大限制

1
2
3
4
5
6
7
8
9
10
11
12
13
zeyu@zeyu-desktop:/proc/self/ns$ ll /proc/sys/user/
total 0
dr-xr-xr-x 1 root root 0 Nov 28 16:12 ./
dr-xr-xr-x 1 root root 0 Nov 28 11:03 ../
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_cgroup_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_inotify_instances
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_inotify_watches
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_ipc_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_mnt_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_net_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_pid_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_user_namespaces
-rw-r--r-- 1 root root 0 Nov 28 16:12 max_uts_namespaces
  • 只有特权用户能修改
  • 限制是围绕进程所在用户命名空间展开的
  • 限制是基于用户的,同一用户命名空间下的每一个用户都可以创建其他命名空间直到上限
  • 限制将针对所有用户, 包括uid=0
  • clone,unshare因达到上限失败返回ENOSPC
  • 当一个uid创建子用户命名空间, 子用户命名空间下创建命名空间时, 也会根据uid累计到所有祖先命名空间。确保创建新的用户命名空间不会做为逃避限制的手段

命名空间生命周期

如果没有任何其他因素，当命名空间中的最后一个进程终止或离开命名空间时，命名空间将被自动删除。然而即使命名空间没有成员进程，也有许多其他因素可能会导致命名空间存在

  • 对应的/proc/[pid]/ns/*文件存在打开的文件描述符或bind
  • 命名空间是分层的（即pid或user名空间）,并且具有子命名空间
  • user namespace,拥有一个或多个其他非用户命名空间
  • PID namespace,有一个进程通过/proc/[PID]/ns/PID_for_children符号链接引用该名称空间
  • ipc namespace,mqueue文件系统的mount引用了这个命名空间
  • pid namespace, proc文件系统的mount引用了这个命名空间

展开全文 >>

Linux mount

基本概念

1
mount -t type device dir

mount命令用于将某些设备上的文件系统附加到指定目录,dir即是对应文件系统的根目录,mount后原目录下的内容都将不可见

多数情况下不用指定-t参数显式地说明文件系统的类型

通过查看/proc/filesystems文件来查看当前系统具体都支持哪些文件系统,nodev表示不需要设备

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
zeyu@zeyu-desktop:/proc$ cat filesystems 
nodev	sysfs
nodev	tmpfs
nodev	bdev
nodev	proc
nodev	cgroup
nodev	cgroup2
nodev	cpuset
nodev	devtmpfs
nodev	configfs
nodev	debugfs
nodev	tracefs
nodev	securityfs
nodev	sockfs
nodev	bpf
nodev	pipefs
nodev	ramfs
nodev	hugetlbfs
nodev	devpts
	ext3
	ext2
	ext4
	squashfs
	vfat
nodev	ecryptfs
	fuseblk
nodev	fuse
nodev	fusectl
nodev	efivarfs
nodev	mqueue
nodev	pstore
nodev	autofs
nodev	binfmt_misc
nodev	overlay
nodev	prl_fs
nodev	aufs

同一个文件系统可以被挂载多次,甚至可以在同一个挂载点被挂载多次,这些完全是由内核以及不同文件系统特性决定的

列表显示挂载信息

1
mount [-l] [-t type]

更推荐使用findmnt

设备标识

磁盘分区的设备名称不稳定；硬件重新配置、添加或删除设备可能会导致名称更改。强烈建议使用UUID或LABEL等标识符

命令lsblk --fs提供了可用块设备上的文件系统、LABEL和UUID的概述

命令blkid -p ＜device＞提供了有关指定设备上文件系统的详细信息

无法保证UUID和标签真的是唯一的，尤其是当移动、共享或复制设备时。使用lsblk -o +UUID,PARTUUID以验证UUID在系统中是否真正唯一

/etc/fstab, /etc/mtab and /proc/mounts

/etc/mtab和 /proc/mounts一样，都是指向/proc/self/mounts的链接文件,用于维护当前挂载的文件系统的列表同时支持命名空间，容器和其他高级Linux功能一起使用

1
2
3
4
5
6
7
8
9
struct mntent
  {
    char *mnt_fsname;           /* 文件系统对应的设备路径或者服务器地址  */
    char *mnt_dir;              /* 文件系统挂载到的系统路径 */
    char *mnt_type;             /* 文件系统类型: ufs, nfs, 等  */
    char *mnt_opts;             /* 文件系统挂载参数，以逗号分隔  */
    int mnt_freq;               /* 文件系统备份频率（以天为单位）  */
    int mnt_passno;             /* 开机fsck的顺序，如果为0，不会进行check */
  };

挂载fstab或mtab中提到的文件系统时，只需在命令行上仅指定设备或仅指定挂载点即可

mount /dir会让mount去/etc/fstab下寻找定义的挂载点,mount dev也是同理,可以通过--target或者--source避免歧义

mount -a 会将/etc/fstab中定义的所有挂载点都挂上,一般是在系统启动时的脚本中调用

如果要覆盖/etc/fstab中的安装选项，则必须使用-o选项

1
mount device|dir -o options

如果同时指定了设备（或LABEL，UUID，PARTUUID或PARTLABEL）和目录，则挂载程序不会读取/etc/fstab文件

可以通过命令行选项–options-source-force更改此默认行为，以始终从fstab读取配置。对于非root用户，mount始终读取fstab配置

非特权用户

通常只有超级用户才能挂载文件系统。但是，当fstab在一行上包含user选项时，任何人都可以挂载相应的文件系统

挂载文件系统对应的用户才能卸载它。如果有任何用户应该能够卸载它，则在fstab行中使用users而不是user

owner选项限制用户必须是挂载文件的所有者,group选项也是同理

挂载

只读挂载

1
mount -o ro /dev/sdb1 /mnt

重新挂载

1
mount /mnt -o rw,remount

挂载虚拟文件系统

proc、tmpfs、sysfs、devpts等都是Linux内核映射到用户空间的虚拟文件系统，它们不和具体的物理设备关联，但它们具有普通文件系统的特征，应用层程序可以像访问普通文件系统一样来访问他们

由于是内核虚拟的一个文件系统，并没有对应的设备，所以这里的-t参数不能省略。由于没有对应的源设备，这里的设备可以是任意字符串，取个有意义的名字就可以了，因为用mount命令查看挂载点信息时第一列显示的就是这个字符串

1
mount -t tmpfs -o size=512m tmpfs /mnt

挂载loop设备

loop device是虚拟的块设备，主要目的是让用户可以像访普通块设备那样访问一个文件。loop device设备的路径一般是/dev/loop0、dev/loop1等

需要用到loop device的最常见的场景是挂载一个ISO文件。比如将/tmp/test.iso这个光盘镜像文件使用loop模式挂载到/mnt下，这样就不需要把ISO文件刻录到光盘上了，当然也不需要光驱了

1
2
mkisofs -o test.iso projects/
mount test.iso /mnt

创建虚拟硬盘

1
2
3
dd if=/dev/zero bs=1M count=512 of=./vdisk.img
mkfs -t ext4 vdisk.img
mount vdisk.img /mnt

bind

可以将任何一个挂载点、普通目录或者文件挂载到其它的地方

绑定挂载并不会处理子挂载点,需要使用--rbind

只读bind

1
mount -o bind,ro foo foo

但是内核并不支持直接只读bind,所以上述命令并不是一个原子操作,而是通过remount实现的

1
2
mount --bind olddir newdir
mount -o remount,bind,ro olddir newdir

同样的nosuid, nodev, noexec, noatime, nodiratime, relatime等vfs标志也可以通过这个方式添加,但是像这样-o rbind,ro递归添加参数是不可以的

move

把旧的挂载点移动到新的目录去

1
mount --move olddir newdir

果挂载点的父挂载点为shared类型，就不能移动该挂载点,可以通过findmnt -o TARGET,PROPAGATION查看所有挂载点传播标志

可以通过mount --make-private /修改父挂载点传播类型为private,然后再用findmnt -o TARGET,PROPAGATION /确认

请求–make-操作时，mount不会读取fstab,必须在命令行上指定所有必需的信息

Shared subtree

shared subtree就是一种控制子挂载点能否在其他地方被看到的技术，它只会在bind mount和mount namespace中用到。

移动挂载点时提到了挂载点的类型，其实叫propagation type(传播类型)。

propagation type

每个挂载点都有一个propagation type标志，由它来决定当在一个挂载点的下面创建和移除挂载点的时候，是否会传播到属于相同peer group的其他挂载点下面，也即同一个peer group里的其他的挂载点下面是不是也会创建和移除相应的挂载点。当前一共有4种不同类型的 propagation type

  • shared：从名字就可以看出，挂载信息会在同一个peer group的不同挂载点之间共享传播。当一个挂载点下面添加或者删除挂载点的时候，同一个peer group里的其他挂载点下面也会挂载和卸载同样的挂载点
  • private：跟上面的刚好相反，挂载信息根本就不共享，也即private的挂载点不会属于任何peer group
  • slave：信息的传播是单向的，在同一个peer group里面，master的挂载点下面发生变化的时候，slave的挂载点下面也跟着变化。但反之则不然，slave下发生变化的时候不会通知master，master不会发生变化
  • unbindable：这个和private相同，只是这种类型的挂载点不能作为bind mount的源，主要用来防止递归嵌套情况的出现

propagation type是挂载点的属性，对每个挂载点来说都是独立的

挂载点是有父子关系的，比如挂载点/和/mnt，/mnt是/的子挂载点，/是/mnt的父挂载点

默认情况下，如果父挂载点是shared，那么子挂载点也是shared的

peer group

peer group就是一个或多个挂载点的集合，他们之间可以共享挂载信息。在下面两种情况下会使两个挂载点属于同一个peer group(前提条件是挂载点的propagation type是shared)

  • 利用mount --bind命令，将会使源和目标挂载点属于同一个peer group，当然前提条件是源必须要是一个挂载点
  • 当创建新的mount namespace时，新namespace会拷贝一份老namespace的挂载点信息，于是新的和老的namespace里面的相同挂载点就会属于同一个peer group

propagation type和peer group表现在/proc/self/mountinfo的(7)中,注意这个字段可能为空(当挂载方式为--make-private)

(master:1表示当前挂载点是peer group 1的slave)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
See http://man7.org/linux/man-pages/man5/proc.5.html

36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3)   (4)   (5)      (6)      (7)   (8) (9)   (10)         (11)

(1) mount ID:  unique identifier of the mount (may be reused after umount)
(2) parent ID:  ID of parent (or of self for the top of the mount tree)
(3) major:minor:  value of st_dev for files on filesystem
(4) root:  root of the mount within the filesystem
(5) mount point:  mount point relative to the process's root
(6) mount options:  per mount options
(7) optional fields:  zero or more fields of the form "tag[:value]"
(8) separator:  marks the end of the optional fields
(9) filesystem type:  name of filesystem of the form "type[.subtype]"
(10) mount source:  filesystem specific information or "none"
(11) super options:  per super block options

展开全文 >>

Docker - 07 dockerfile

说明

Dockerfile是一个用来构建镜像的文本文件

1
2
3
4
5
6
7
8
9
10
11
12
13
ARG GO_VERSION=1.18.5

FROM    golang:${GO_VERSION}-alpine

RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories

RUN     apk add -U git bash coreutils gcc musl-dev

ENV     CGO_ENABLED=0 \
        DISABLE_WARN_OUTSIDE_CONTAINER=1
WORKDIR /go/src/github.com/docker/cli
CMD     ./scripts/build/binary

命令

FROM

构建镜像基于哪个基础镜像

1
2
3
4
FROM [--platform=<platform>] <image> [AS <name>]
FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]
FROM [--platform=<platform>] <image>[@<digest>] [AS <name>]

  • 单个dockfile可以多次出现FROM,以使用之前的构建阶段作为另一个构建阶段的依赖项
  • AS name表示为构建阶段命名，在后续FROM和COPY --from=<name>说明中可以使用这个名词，引用此阶段构建的映像
  • tag或digest值是可选的。如果您省略其中任何一个，构建器默认使用一个latest标签。如果找不到该tag值，构建器将返回错误。
  • –platform标志可用于在FROM引用多平台镜像的情况下指定平台。例如，linux/amd64、linux/arm64、或windows/amd64

RUN

将在当前镜像之上的新层中执行命令，在docker build时运行

RUN有两种形式：

1
2
RUN <command>（shell形式，命令在shell中运行，默认/bin/sh -c在Linux或cmd Windows上）
RUN ["executable", "param1", "param2"]（执行形式）
  • 可以使用\（反斜杠）将单个RUN指令延续到下一行
  • RUN在下一次构建期间,指令缓存不会自动失效。可以使用–no-cache标志使指令缓存无效
  • Dockerfile的指令每执行一次都会在docker上新建一层。所以过多无意义的层,会造成镜像膨胀过大,可以使用&&符号连接命令,这样执行后,只会创建1层镜像

CMD

运行程序，在docker run时运行

RUN有三种形式：

1
2
3
CMD ["executable","param1","param2"] 使用exec执行,推荐方式
CMD command param1 param2 在 /bin/sh 中执行,提供给需要交互的应用
CMD ["param1","param2"] 提供给 ENTRYPOINT 的默认参数
  • 指定启动容器时执行的命令,每个Dockerfile只能有一条CMD命令。如果指定了多条命令,只有最后一条会被执行
  • 如果用户启动容器时候指定了运行的命令,则会覆盖掉CMD指定的命令

ENTRYPOINT

ENTRYPOINT 和 CMD 一样，都是在指定容器启动程序及参数，不过它不会被 docker run 的命令行参数指定的指令所覆盖。如果要覆盖的话，需要通过docker run –entrypoint 来指定。

ENTRYPOINT有两种格式

1
2
ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2

如果 Dockerfile 中如果存在多个 ENTRYPOINT 指令，仅最后一个生效。

当指定了 ENTRYPOINT 后， CMD 的内容作为参数传给 ENTRYPOINT 指令，实际执行时，将变为：

1
<ENTRYPOINT> <CMD>

ARG

定义变量,ARG设置的环境变量仅对Dockerfile内有效

1
ARG <name>[=<default value>]

docker build 中可以用 –build-arg <参数名>=<值> 来覆盖

内置ARG

  • HTTP_PROXY
  • http_proxy
  • HTTPS_PROXY
  • https_proxy
  • FTP_PROXY
  • ftp_proxy
  • NO_PROXY
  • no_proxy

ENV

1
2
ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...

设置的环境变量将持续存在，可以使用docker inspect来查看

使用docker run --env <key>=<value>来更改环境变量的值

如果环境变量只在构建期间需要

1
RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y ...

或者

1
2
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y ...

COPY

复制指令,从上下文目录(docker build 传入)中复制文件或者目录到容器里指定路径

1
2
COPY [--chown=<user>:<group>] <源路径1>...  <目标路径>
COPY [--chown=<user>:<group>] ["<源路径1>",...  "<目标路径>"]

[--chown=<user>:<group>]：可选参数,用户改变复制到容器内文件的拥有者和属组
目标路径不存在的话,会自动创建

ADD

和copy差不多

  • add 支持src为远程url
  • add 支持将src为tar的压缩文件解压到dst

WORKDIR

指定工作目录。用WORKDIR指定的工作目录，会在构建镜像的每一层中都存在

LABEL

添加元数据(metadata),键值对

1
LABEL org.authors="zeyu"

EXPOSE

Docker容器在运行时声明网络端口。可以指定端口是监听TCP还是UDP，如果不指定协议，默认为TCP

在运行时使用随机端口映射时，也就是 docker run -P 时，会自动随机映射 EXPOSE 的端口

1
EXPOSE 80/udp

VOLUME

定义匿名数据卷。在启动容器时忘记挂载数据卷，会自动挂载到匿名卷

1
2
VOLUME ["/var/log/"]
VOLUME /var/log

Dockerfile中除了FROM指令的每一行都是基于上一行生成的临时镜像运行一个容器，执行一条指令并执行类似docker commit的命令得到一个新的镜像，这条类似docker commit的命令不会对挂载的volume进行保存

1
2
3
4
5
​​FROM ubuntu
RUN useradd foo
VOLUME /data
RUN touch /data/file
RUN chown -R foo:foo /data

需要将VOLUME /data放到最后一行执行,在挂载volume时，/data已经存在，/data中的文件以及它们的权限和所有者设置会被复制到volume中

ONBUILD

将一个触发指令添加到镜像中，以便稍后在该镜像用作另一个构建的基础时执行。也就是另外一个dockerfile FROM了这个镜像的时候执行

1
ONBUILD <其它指令>

展开全文 >>

Docker - 06 数据卷

volume是存在于一个或多个容器中的特定文件或文件夹，这个目录以独立于联合文件系统的形式在宿主机中存在，并为数据的共享与持久化提供以下便利

1
2
3
4
5
type Daemon struct {
    ...
	volumes           *volumesservice.VolumesService
    ...
}
  • volume在容器创建时就会初始化，在容器运行时就可以使用其中的文件
  • volume能在不同的容器之间共享和重用
  • 对volume中数据的操作会马上生效
  • 对volume中数据的操作不会影响到镜像本身
  • volume的生存周期独立于容器的生存周期，即使删除容器，volume仍然会存在，没有任何容器使用的volume也不会被Docker删除

创建volume

1
docker volume create test_volume

Docker在创建volume的时候会在宿主机/var/lib/docker/volume/中创建一个以volume ID为名的目录，并将volume中的内容存储在名为_data的目录下

挂载volume

docker还支持直接将宿主机的一个目录挂载到容器中

1
docker run -it -v /tmp/abc:/data ubuntu /bin/bash

只读volume

1
docker run -it -v test_volume:/data:ro ubuntu /bin/bash

私有volume

1
docker run -it -v test_volume:/data:Z ubuntu /bin/bash

可以通过 volumes-from 参数实现容器间volume共享

volume备份

通过临时的容器配合--volumes-from在容器内将需要备份的volume打包并导出到backup

1
docker run --rm --volumes-from vol_simple -v $(pwd):/backup ubuntu tar cvf /backup/data.tar /data​​

还原

1
2
docker run -it --name vol_bck -v /data ubuntu /bin/bash
docker run --rm --volumes-from vol_bck -v $(pwd):/backup ubuntu tar xvf /backup/data.tar -C /​

实现

数据卷都在runc基于bind mount实现,将需要绑定的原地址、目的地址写到runtime spec文件,runc在创建rootfs时会将对应地址绑定到新的rootfs然后支持pivot_root

展开全文 >>

Docker - 05 libcontainer

libcontainer已经被docker捐给OCI,并包装成runc:
runc

以下内容基于runc 1.0.3版本展开

OCI Bundle

OCI Bundle是指满足OCI标准的一系列文件，这些文件包含了运行容器所需要的所有数据，它们存放在一个共同的目录，该目录包含以下两项：

  • config.json文件包含容器运行的配置数据
  • root目录为container的root filesystem

整理流程

在runc中所有二级命令都有单独的go文件，通过packege cli中的App命令模版统一调用

创建容器

runc create -b /mycontainer test

  • create.go

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    Action: func(context *cli.Context) error {
           // 入参检查
     if err := checkArgs(context, 1, exactArgs); err != nil {
      return err
     }
           //保存pid文件
     if err := revisePidFile(context); err != nil {
      return err
     }
           //加载config.json到spec数据结构
     spec, err := setupSpec(context)
     if err != nil {
      return err
     }
           //创建容器
     status, err := startContainer(context, spec, CT_ACT_CREATE, nil)
     if err != nil {
      return err
     }
     // exit with the container's exit status so any external supervisor is
     // notified of the exit with the correct exit status.
     os.Exit(status)
     return nil
    },

  • utils_linux.go/createContainer/CreateLibcontainerConfig将Spec等相关配置信息转存到Config数据结构,为后续工厂执行操作提供入参

  • 加载Factory接口，其中LinuxFactory将作为一种实现

    • 创建root目录 root用户执行是/run/runc
    • 创建LinuxFactory数据结构

  • 调用Factory的Create()方法，返回Container接口创建逻辑容器,其中linuxContainer将作为其中一种实现

    • 验证容器id合法性
    • 验证config合法性
    • 通过SecureJoinVFS创建容器的root目录 ${root}/containerid
    • 返回Container对象

  • 创建runner在r.run(spec.Process)中执行container.Start(process)创建物理容器Container主要包含了容器配置、控制等信息，是对不同操作系统下容器实现的抽象,目前在linux平台相当于执行func (c *linuxContainer) Start(process *Process) error

    • 在容器root目录下创建exec.fifo
    • 执行内置函数func (c *linuxContainer) start(process *Process) (retErr error)
      • 创建parentProcess,参与物理容器创建过程的Process一共有两个实例

        • 第一个叫Process，用于物理容器内进程的配置和IO的管理，前面在runner run创建的Process就是指它,该实例主要来自spec.Process

        • 另一个叫ParentProcess，负责从物理容器外部处理物理容器启动工作，与Container对象直接进行交互。启动工作完成后，ParentProcess负责执行等待、发信号、获得容器内进程pid等管理工作,initProcess是ParentProcess的一个实现

          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
          type parentProcess interface {
           // pid returns the pid for the running process.
           pid() int

           // start starts the process execution.
           start() error

           // send a SIGKILL to the process and wait for the exit.
           terminate() error

           // wait waits on the process returning the process state.
           wait() (*os.ProcessState, error)

           // startTime returns the process start time.
           startTime() (uint64, error)

           signal(os.Signal) error

           externalDescriptors() []string

           setExternalDescriptors(fds []string)

           forwardChildLogs() chan error
          }

          type initProcess struct {
           cmd             *exec.Cmd
           messageSockPair filePair
           logFilePair     filePair
           config          *initConfig
           manager         cgroups.Manager
           intelRdtManager intelrdt.Manager
           container       *linuxContainer
           fds             []string
           process         *Process
           bootstrapData   io.Reader
           sharePidns      bool
          }
      • 调用parentProcess的forwardChildLogs通过管道不断获取容器内的日志
      • 调用parentProcess的start，其实就是执行func (p *initProcess) start() (retErr error)
        • 执行err := p.cmd.Start()会执行runc init命令,但是这个子进程会阻塞在nsenter的func init()，直到通过nsenter让父进程把需要用到相关ns的信息写入socketpair后才执行后面的函数 
          1
          2
          3
          4
          if _, err := io.Copy(p.messageSockPair.parent, p.bootstrapData); err != nil {
          	return newSystemErrorWithCause(err, "copying bootstrap data to pipe")
          }
          err = <-waitInit
        • 向子进程发送initConfig,init进行容器初始化,创建网络、路由表、rootfs等
        • 通过messageSockPair.parent进行一系列消息交互,init向父进程发送procReady,等待父进程发送procRun,代表init可以进行execv
        • 最后init会以只写方式打开exec.fifo,这里会阻塞直到另一个进程以读方式打开管道。然后写一个字符0,去执行后续的execv 
          1
          2
          3
          4
          5
          6
          7
          8
          fd, err := unix.Open("/proc/self/fd/"+strconv.Itoa(l.fifoFd), unix.O_WRONLY|unix.O_CLOEXEC, 0)
          if err != nil {
          	return newSystemErrorWithCause(err, "open exec fifo")
          }

          if _, err := unix.Write(fd, []byte("0")); err != nil {
          	return newSystemErrorWithCause(err, "write 0 exec fifo")
          }

  • 最终runc init进程将分离并作为容器内的init一直执行,容器的状态变为created

  • 容器的状态会保存在/run/runc/${containerid}/state.json

运行容器

runc start test

  • 基于/run/runc/${containerid}/state.json加载container结构
  • start就是执行container的exec接口,将对应容器的exec.fifo以读方式打开,这样init就不会阻塞,去执行exec的命令,后面使用select读取fifo内容(字符0)
  • 读取到字符0后handleFifoResult(result)将删除exec.fifo文件
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func (c *linuxContainer) exec() error {
	path := filepath.Join(c.root, execFifoFilename)
	pid := c.initProcess.pid()
	blockingFifoOpenCh := awaitFifoOpen(path)
	for {
		select {
		case result := <-blockingFifoOpenCh:
			return handleFifoResult(result)

		case <-time.After(time.Millisecond * 100):
			stat, err := system.Stat(pid)
			if err != nil || stat.State == system.Zombie {
				// could be because process started, ran, and completed between our 100ms timeout and our system.Stat() check.
				// see if the fifo exists and has data (with a non-blocking open, which will succeed if the writing process is complete).
				if err := handleFifoResult(fifoOpen(path, false)); err != nil {
					return errors.New("container process is already dead")
				}
				return nil
			}
		}
	}
}

runc exec

exec时创建的parentProcess对应实例就不是initProcess而是setnsProcess,并且在执行data, err := c.bootstrapData(0, state.NamespacePaths)时不需要任何cloneFlags,只需要setns相关进程对应ns路径

然后执行setnsProcess的start(),去执行/proc/self/exe init, 将在main之前调用nsexec.c的nsexec去setns

执行完main之前命名空间切换操作将来到setns_init_linux.go中的Init，根据父进程传入的initConfig执行容器tty、能力、Seccomp等配置 ,最后执行execv

展开全文 >>

Docker - 04存储管理

基本概念

registry用以保存Docker镜像，其中还包括镜像层次结构和关于镜像的元数据(Docker Hub)

repository即由具有某个功能的Docker镜像的所有迭代版本构成的镜像组

registry是repository的集合，repository是镜像的集合

Docker内部的image(镜像)概念是用来存储一组镜像相关的元数据信息，主要包括镜像的架构、镜像默认配置信息、构建镜像的容器配置信息、包含所有镜像层信息的rootfs,Docker用rootfs中的diff_id计算出内容寻址的索引（chainID）来获取layer相关信息，进而获取每一个镜像层的文件内容

layer（镜像层）是一个Docker用来管理镜像层的中间概念，镜像是由镜像层组成的，而单个镜像层可能被多个镜像共享，所以Docker将layer与image的概念分离。Docker镜像管理中的layer主要存放了镜像层的diff_id、size、cache-id和parent等内容，实际的文件内容则是由存储驱动来管理，并可以通过cache-id在本地索引到

repository元数据

/var/lib/docker/image/overlay2/repositories.json下存放所有镜像相关元数据(多个repository下的不同版本镜像),包含repo名称(docker-cli-dev),镜像名称和tag(docker-cli-dev:latest),镜像id(sha256…),有的还包含数字签名

Docker默认采用SHA256算法根据镜像元数据配置文件计算出镜像ID

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"Repositories":
{	
	"docker-cli-dev":
	{"docker-cli-dev:latest":"sha256:809278dd58853bdeba654f7b8605a792830d1e1ab4ba2c41a24b43c945998901"},

	"docker-cli-native":
	{"docker-cli-native:latest":"sha256:4bb4cbf4906ee605fb05d1b7d2e96e72dc2ee4703845431d910eb3c515b994f8"},

	"docker-dev":
	{"docker-dev:1-12-0":"sha256:0c12c9a82fe05a081fff33012812236c6ee84037e8375ba3d138df042efbbca9"},

	"redis":
	{"redis:latest":"sha256:e800a8da9469811a2d16e2f9aaa65374d33b04844209e85eda17986b21949a5c","redis@sha256:9bc34afe08ca30ef179404318cdebe6430ceda35a4ebe4b67d10789b17bdf7c4":"sha256:e800a8da9469811a2d16e2f9aaa65374d33b04844209e85eda17986b21949a5c"},

	"ubuntu":
	{"ubuntu:16.04":"sha256:fe3b34cb9255c8dd390f85c8fe37e6fbe6ac555f86c7e8944cd68da2de2f7633","ubuntu:latest":"sha256:bad148f8963fb9be6c8c260ce8a65aadd1cdfdd95e5bd16867d0f987cd7ebff3","ubuntu@sha256:34fea4f31bf187bc915536831fd0afc9d214755bf700b5cdb1336c82516d154e":"sha256:bad148f8963fb9be6c8c260ce8a65aadd1cdfdd95e5bd16867d0f987cd7ebff3","ubuntu@sha256:91bd29a464fdabfcf44e29e1f2a5f213c6dfa750b6290e40dd6998ac79da3c41":"sha256:fe3b34cb9255c8dd390f85c8fe37e6fbe6ac555f86c7e8944cd68da2de2f7633"}
	
}
}

image元数据

imageStore则管理镜像ID与镜像元数据之间的映射关系以及元数据的持久化操作，持久化文件位于/var/lib/docker/image/[graph_driver]/imagedb/content/sha256/[image_id]中

内容包括镜像架构,构建镜像相关配置信息、创建该镜像的容器ID和配置、创建时间、创建该镜像的Docker版本、构建镜像的历史信息、操作系统以及rootfs组成

Docker会根据历史信息和rootfs中的diff_ids计算出构成该镜像的镜像层的存储索引chainID

layer元数据

镜像层只包含一个具体的镜像层文件包,当一个镜像层被下载后,Docker会基于镜像层文件包和image元数据构建本地的layer元数据,包括diff、parent、size等

Docker中定义了Layer和RWLayper两种接口，分别用来定义只读层和可读写层的一些操作，又定义了roLayer和mountedLayer，分别实现了上述两种接口。其中，roLayer用于描述不可改变的镜像层，mountedLayer用于描述可读写的容器层

roLayer

位于/var/lib/docker/image/[graph_driver]/layerdb/sha256/[chainID]/

  • chainID 文件夹名称,用于索引该镜像层
    • 如果该镜像层是最底层(没有父镜像层),该层的diffID便是chainID
    • 该镜像层的chainID计算公式为chainID(n)=SHA256(chain(n-1) diffID(n))，也就是根据父镜像层的chainID加上一个空格和当前层的diffID，再计算SHA256校验码
  • diff 该镜像层的校验码diffID
    • diffID采用SHA256算法，基于镜像层文件包的内容计算得到
  • parent 父镜像层chainID
  • cache-id graphdriver存储当前镜像层文件的cacheID
    • cacheID是在当前Docker宿主机上随机生成的一个uuid，在当前宿主机上与该镜像层一一对应，用于标示并索引graphdriver中的镜像层文件
  • size 该镜像层的大小

mountedLayer

位于/var/lib/docker/image/[graph_driver]/layerdb/mounts/[container_id]/

  • container_id 对应docker ps -a的容器ID
  • init-id 容器init层在graphdriver中的ID
  • mount 读写层在graphdriver中的ID
  • parent 父层镜像的chainID
1
2
root@zeyu-desktop:/var/lib/docker/image/overlay2/layerdb/mounts/f4ce0841c0b174e4e5e4639e1ef5841a14ebe64c37f3e6cf3711501567345842# ls
init-id  mount-id  parent
1
2
3
4
root@zeyu-desktop:/var/lib/docker/image/overlay2/layerdb/sha256/efc088ed50a3b76edfce1505de41e3317d521684dc0620f1cd87af5f6f28a9ab# pwd
/var/lib/docker/image/overlay2/layerdb/sha256/efc088ed50a3b76edfce1505de41e3317d521684dc0620f1cd87af5f6f28a9ab
root@zeyu-desktop:/var/lib/docker/image/overlay2/layerdb/sha256/efc088ed50a3b76edfce1505de41e3317d521684dc0620f1cd87af5f6f28a9ab# ls
cache-id  diff  parent  size  tar-split.json.gz

graphdriver

1
2
3
4
type Driver interface {
	ProtoDriver //定义了driver基本的功能
	DiffDriver //对数据层之间的差异（diff）进行管理
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
type ProtoDriver interface {
    // 返回一个代表这个驱动的字符串，通常是这个驱动的名字
	String() string
	CreateReadWrite(id, parent string, opts *CreateOpts) error
    // 创建一个新的镜像层，需要调用者传进一个唯一的ID和所需的父镜像的ID
	Create(id, parent string, opts *CreateOpts) error
    // 根据指定的ID删除一个层
	Remove(id string) error
    // 返回指定ID的层的挂载点的绝对路径
	Get(id, mountLabel string) (fs containerfs.ContainerFS, err error)
    // 释放一个层使用的资源，比如卸载一个已经挂载的层
	Put(id string) error
    // 查询指定的ID对应的层是否存在
	Exists(id string) bool
    // 返回这个驱动的状态，这个状态用一些键值对表示
	Status() [][2]string
    // 返回这个驱动正在管理的信息,用键值对表示
	GetMetadata(id string) (map[string]string, error)
    // 释放由这个驱动管理的所有资源，比如卸载所有的层
	Cleanup() error
}
1
2
3
4
5
6
7
8
9
10
type DiffDriver interface {
	// 将指定ID的层相对父镜像层改动的文件打包并返回
	Diff(id, parent string) (io.ReadCloser, error)
	// 返回指定镜像层与父镜像层之间的差异列表
	Changes(id, parent string) ([]archive.Change, error)
	// 从差异文件包中提取差异列表，并应用到指定ID的层与父镜像层，返回新镜像层的大小
	ApplyDiff(id, parent string, diff io.Reader) (size int64, err error)
	// 计算指定ID层与其父镜像层的差异，并返回差异相对于基础文件系统的大小
	DiffSize(id, parent string) (size int64, err error)
}

Docker中的任何存储驱动都需要实现上述Driver接口
linux系统下驱动的优先级被定义在graphdriver/drivier_linux.go中

1
priority = "btrfs,zfs,overlay2,fuse-overlayfs,aufs,overlay,devicemapper,vfs"

驱动注册

graphdriver会维护一个map用于存储注册的驱动名称和对应的初始化函数

1
2
3
4
var (
	// All registered drivers
	drivers map[string]InitFunc
)

以overlay2为例,只需要实现一个init函数

1
2
3
func init() {
	graphdriver.Register(driverName, Init)
}

当overlay2的包被包含的时候自动就会调用包中的init函数,所有注册的驱动都在graphdriver/register,其他模块使用register包就会把相关的驱动注册

这里import时在包路径前面加了一个_,只有这样才能调用到相关包的init函数

1
2
3
4
5
6
package register // import "github.com/docker/docker/daemon/graphdriver/register"

import (
	// register the overlay2 graphdriver
	_ "github.com/docker/docker/daemon/graphdriver/overlay2"
)

创建Driver

检查环境变量DOCKER_DRIVER和配置是否提供驱动名称,如果有的话直接在map按驱动名称调用对应驱动的初始化函数;否则就会按照优先级去查找相关的驱动

Docker镜像管理部分与存储驱动在设计上完全分离了，镜像层或者容器层在存储驱动中拥有一个新的标示ID，在镜像层（roLayer）中称为cacheID，容器层（mountedLayer）中为mountID。在Unix环境下，mountID是随机生成的并保存在mountedLayer的元数据mountID中,持久化文件在/var/lib/docker/image/overlay2/layerdb/mounts/container_id

overlay2 driver

OverlayFS是一种新型联合文件系统（union filesystem），它允许用户将一个文件系统与另一个文件系统重叠（overlay），在上层的文件系统中记录更改，而下层的文件系统保持不变

1
2
mkdir lower upper work merged
mount -t overlay overlay-o lowerdir=./lower, upperdir=./upper, workdir=./work ./merged

/var/lib/docker/overlay2中

  • 容器层
    • mountID 
      1
      2
      root@zeyu-desktop:/var/lib/docker/overlay2/89610a9bd010adaa7f2281c5b3c9d96d337ff87660411539a58f163d3cec1704# ls
      diff  link  lower  work
      • diff 存放容器运行时变化的文件(overlay的upper)
      • link 描述该层对应的软连接 所有的链接文件都在/var/lib/docker/overlay2/l/,使用软连接可以防止lower层过多时命令过长挂载失败
      • lower 描述该层对应所有的lower层的软连接
      • work overlay工作目录
      • merged 只有在运行时创建的overlay挂载点
    • mountID-init 
      1
      2
      root@zeyu-desktop:/var/lib/docker/overlay2/89610a9bd010adaa7f2281c5b3c9d96d337ff87660411539a58f163d3cec1704-init# ls
      committed  diff  link  lower  work
  • 镜像层
    • cacheID 
      1
      2
      root@zeyu-desktop:/var/lib/docker/overlay2/47bdd7a31bb6ad0f91d51d1c3b340e382d4a1427243eab85e4ec6ee1d9fb6d44# ls
      committed  diff  link
1
2
3
4

mount

overlay on /var/lib/docker/overlay2/89610a9bd010adaa7f2281c5b3c9d96d337ff87660411539a58f163d3cec1704/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/VADBLOWNHH7XWGLDL2LLUS4LUU:/var/lib/docker/overlay2/l/D3ZMYBHFKVFZSLDBXLD3T6I26O,upperdir=/var/lib/docker/overlay2/89610a9bd010adaa7f2281c5b3c9d96d337ff87660411539a58f163d3cec1704/diff,workdir=/var/lib/docker/overlay2/89610a9bd010adaa7f2281c5b3c9d96d337ff87660411539a58f163d3cec1704/work,xino=off)

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

二线城市码农，方向偏OS多一点，热爱技术但更热爱生活<br><br>喜欢撸铁，爱玩HIFI但囊中羞涩，梦想开一家属于自己的照相馆，虽然我现在还不会拍照(=_=)