AUFS工作原理是什么
本篇内容主要讲解“AUFS工作原理是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“AUFS工作原理是什么”吧!
创新互联网站建设公司,提供成都网站建设、网站建设,网页设计,建网站,PHP网站建设等专业做网站服务;可快速的进行网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,是专业的做网站团队,希望更多企业前来合作!
Rootfs
rootfs(根文件系统)是挂载在容器根目录上,用来为容器进程提供隔离后执行环境的文件系统,就是所谓的“容器镜像”。所以,一个最常见的 rootfs,或者说容器镜像,会包括如下所示的一些目录和文件,比如 /bin,/etc,/proc 等等:
$ ls / bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var
而你进入容器之后执行的 /bin/bash,就是 /bin 目录下的可执行文件,与宿主机的 /bin/bash 完全不同。 对 Docker 项目来说,它最核心的原理实际上就是为待创建的用户进程:
启用 Linux Namespace 配置;
设置指定的 Cgroups 参数;
切换进程的根目录(Change Root)。
另外,需要明确的是,rootfs 只是一个操作系统所包含的文件、配置和目录,并不包括操作系统内核。在 Linux 操作系统中,这两部分是分开存放的,操作系统只有在开机启动时才会加载指定版本的内核镜像。所以说,rootfs 只包括了操作系统的“躯壳”,并没有包括操作系统的“灵魂”。
那么,对于容器来说,这个操作系统的“灵魂”又在哪里呢? 实际上,同一台机器上的所有容器,都共享宿主机操作系统的内核。这就意味着,如果你的应用程序需要配置内核参数、加载额外的内核模块,以及跟内核进行直接的交互,你就需要注意了:这些操作和依赖的对象,都是宿主机操作系统的内核,它对于该机器上的所有容器来说是一个“全局变量”,牵一发而动全身。这也是容器相比于虚拟机的主要缺陷之一:毕竟后者不仅有模拟出来的硬件机器充当沙盒,而且每个沙盒里还运行着一个完整的 Guest OS 给应用随便折腾。
联合文件系统
Docker 在镜像的设计中,引入了层(layer)的概念。也就是说,用户制作镜像的每一步操作,都会生成一个层,也就是一个增量 rootfs。
当然,这个想法不是凭空臆造出来的,而是用到了一种叫作联合文件系统(Union File System)的能力。
Union File System 也叫 UnionFS,最主要的功能是将多个不同位置的目录联合挂载(union mount)到同一个目录下。比如,我现在有两个目录 A 和 B,它们分别有两个文件:
$ tree . ├── A │ ├── a │ └── x └── B ├── b └── x
然后,我使用联合挂载的方式,将这两个目录挂载到一个公共的目录 C 上:
$ mkdir C $ mount -t aufs -o dirs=./A:./B none ./C
这时,我再查看目录 C 的内容,就能看到目录 A 和 B 下的文件被合并到了一起:
$ tree ./C ./C ├── a ├── b └── x
可以看到,在这个合并后的目录 C 里,有 a、b、x 三个文件,并且 x 文件只有一份。这,就是“合并”的含义。此外,如果你在目录 C 里对 a、b、x 文件做修改,这些修改也会在对应的目录 A、B 中生效。
Docker 中最常用的联合文件系统有三种:AUFS、Devicemapper 和 OverlayFS。
AuFS
AUFS 目前并未被合并到 Linux 内核主线,因此只有 Ubuntu 和 Debian 等少数操作系统支持 AUFS。你可以使用以下命令查看你的系统是否支持 AUFS:
root@cr7-ubuntu:~# grep aufs /proc/filesystems nodev aufs
执行以上命令后,如果输出结果包含aufs,则代表当前操作系统支持 AUFS。AUFS 推荐在 Ubuntu 或 Debian 操作系统下使用,如果你想要在 CentOS 等操作系统下使用 AUFS,需要单独安装 AUFS 模块。
当确认完操作系统支持 AUFS 后,你就可以配置 Docker 的启动参数了。 先在 /etc/docker 下新建 daemon.json 文件,并写入以下内容:
{ "storage-driver": "aufs" }
然后使用以下命令重启 Docker:
systemctl daemon-reload && systemctl restart docker
Docker 重启以后使用 docker info 命令即可查看配置是否生效:
root@cr7-ubuntu:~# docker info Client: Debug Mode: false Server: Containers: 1 Running: 1 Paused: 0 Stopped: 0 Images: 1 Server Version: 19.03.8 Storage Driver: aufs #可以看到 Storage Driver 已经变为 aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 3 Dirperm1 Supported: true Logging Driver: json-file Cgroup Driver: cgroupfs ......
可以看到 Storage Driver 已经变为 aufs,证明配置已经生效,配置生效后就可以使用 AUFS 为 Docker 提供联合文件系统了。
AUFS工作原理
AUFS 是联合文件系统,意味着它在主机上使用多层目录存储,每一个目录在 AUFS 中都叫作分支,而在 Docker 中则称之为层(layer),但最终呈现给用户的则是一个普通单层的文件系统,我们把多层以单一层的方式呈现出来的过程叫作联合挂载。
如上图,每一个镜像层和容器层都是 /var/lib/docker 下的一个子目录,镜像层和容器层都在 aufs/diff 目录下,每一层的目录名称是镜像或容器的 ID 值,联合挂载点在 aufs/mnt 目录下,mnt 目录是真正的容器工作目录。
下面我们针对 aufs 文件夹下的各目录结构,在创建容器前后的变化做详细讲述: 1.当一个镜像未生成容器时,AUFS 的存储结构如下。
diff文件夹:存储镜像内容,每一层都存储在以镜像层 ID 命名的子文件夹。
layers文件夹:存储镜像层关系的元数据,在 diif 文件夹下的每个镜像层在这里都会有一个文件,文件的内容为该层镜像的所有父级镜像的 ID。
mnt文件夹:联合挂载点目录,未生成容器时,该目录为空。
2.当一个镜像已经生成容器时,AUFS 存储结构会发生如下变化。
diff文件夹:当容器运行时,会在 diff 目录下生成容器层,容器层是可读写的,存放容器相对于镜像层不同的文件(新增或删除)。另外 diff 目录中还有 以"-init"结尾的层,夹在容器层和镜像层之间。Init 层是 Docker 项目单独生成的一个内部层,专门用来存放 /etc/hosts、/etc/resolv.conf 等信息。
layers文件夹:增加容器层相关的元数据。
mnt文件夹:容器的联合挂载点,这和容器中看到的文件内容一致。
AUFS工作场景
读取文件
文件在容器层中存在时:当文件存在于容器层时,直接从容器层读取。
当文件在容器层中不存在时:当容器运行时需要读取某个文件,如果容器层中不存在时,则从镜像层查找该文件,然后读取文件内容。
文件既存在于镜像层,又存在于容器层:当我们读取的文件既存在于镜像层,又存在于容器层时,将会从容器层读取该文件。
修改文件或目录 AUFS 对文件的修改采用的是写时复制的工作机制,这种工作机制可以最大程度节省存储空间。具体的文件操作机制如下。
第一次修改文件:当我们第一次在容器中修改某个文件时,AUFS 会触发写时复制操作,AUFS 首先从镜像层复制文件到容器层,然后再执行对应的修改操作。
AUFS 写时复制的操作将会复制整个文件,如果文件过大,将会大大降低文件系统的性能,因此当我们有大量文件需要被修改时,AUFS 可能会出现明显的延迟。好在,写时复制操作只在第一次修改文件时触发,对日常使用没有太大影响。
删除文件或目录:当文件或目录被删除时,AUFS 并不会真正从镜像中删除它,因为镜像层是只读的,AUFS 会创建一个特殊的文件或文件夹(在 diff 目录下创建 .wh 开头的文件或文件夹),这种特殊的文件或文件夹会阻止容器的访问。
AUFS演示
Docker的AUFS
拉取镜像前
拉取镜像前diff,layers,mnt 目录都为空
root@cr7-ubuntu:/var/lib/docker/aufs# tree -L 2 . ├── diff ├── layers └── mnt 3 directories, 0 files
拉取镜像后
拉取一个apline:latest的基础镜像
root@cr7-ubuntu:/var/lib/docker/aufs# docker pull alpine Using default tag: latest latest: Pulling from library/alpine 188c0c94c7c5: Pull complete Digest: sha256:c0e9560cda118f9ec63ddefb4a173a2b2a0347082d7dff7dc14272e7841a5b5a Status: Downloaded newer image for alpine:latest docker.io/library/alpine:latest
拉取完镜像后,可以看到diff,layer,mnt目录下都新增了一个6b2b93d3f...
目录。其中:
diff下的
6b2b93d3f...
目录中包含apline镜像的相关目录和文件。layers下的
6b2b93d3f...
文件中内容是空的,因为没有父级镜像。mnt下的
6b2b93d3f...
目录内容是空的,因为还没有启动容器。
root@cr7-ubuntu:/var/lib/docker/aufs# tree -L 3 . ├── diff │ └── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ ├── bin │ ├── dev │ ├── etc │ ├── home │ ├── lib │ ├── media │ ├── mnt │ ├── opt │ ├── proc │ ├── root │ ├── run │ ├── sbin │ ├── srv │ ├── sys │ ├── tmp │ ├── usr │ └── var ├── layers │ └── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 #文件为空 └── mnt └── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 #目录为空
创建容器后
使用apline镜像创建一个容器,但是先不运行该容器。
root@cr7-ubuntu:/var/lib/docker/aufs# docker create -it --name aufs-test alpine 965157ea214e48fdb8f10dbe1b254da442fff223496aacdc7ec2dd29b954b9d9
从下面可以看出,创建一个容器,实际上就是创建了一层读写层(容器层),也就是下面的76a069867...
目录。
diff目录中的
76a069867...-init
目录用来初始化容器环境,包含初始化的文件。76a069867...
目录是容器运行后才会写入的层,因为此时容器还没有运行,所以该目录是空的。layer目录中的新增的
76a069867...-init
文件存放了基本镜像6b2b93d3f...
的ID,76a069867
文件存放了父级镜像76a069867...-init
和6b2b93d3f...
的ID。mnt目录下也创建了对应的联合挂载目录,
76a069867...-init
和76a069867
目录都为空。
root@cr7-ubuntu:/var/lib/docker/aufs# tree -L 3 . ├── diff │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ │ ├── bin │ │ ├── dev │ │ ├── etc │ │ ├── home │ │ ├── lib │ │ ├── media │ │ ├── mnt │ │ ├── opt │ │ ├── proc │ │ ├── root │ │ ├── run │ │ ├── sbin │ │ ├── srv │ │ ├── sys │ │ ├── tmp │ │ ├── usr │ │ └── var │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init │ ├── dev │ └── etc ├── layers │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init └── mnt ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init
查看layers下ID的关系:
root@cr7-ubuntu:/var/lib/docker/aufs/layers# ll total 16 drwx------ 2 root root 4096 Nov 9 22:16 ./ drwx------ 5 root root 4096 Nov 9 10:30 ../ -rw-r--r-- 1 root root 0 Nov 9 21:03 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 -rw-r--r-- 1 root root 135 Nov 9 22:16 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 -rw-r--r-- 1 root root 65 Nov 9 22:16 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init # 6b2b93d3fece..是基本镜像,就没有父级镜像的ID了 root@cr7-ubuntu:/var/lib/docker/aufs/layers# cat 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 # 76a069867...-init文件存放了基本镜像6b2b93d3f...的ID root@cr7-ubuntu:/var/lib/docker/aufs/layers# cat 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 # 76a069867文件存放了父级镜像76a069867...-init和6b2b93d3f...的ID root@cr7-ubuntu:/var/lib/docker/aufs/layers# cat 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 root@cr7-ubuntu:/var/lib/docker/aufs/layers#
启动容器后
使用 docker start 启动容器,再次观察 aufs 下的目录:
diff 目录的和前面一样。
layer 目录和前面一样。
mnt 目录的
76a069867
目录新增了 diff 中3个目录合并的内容。
root@cr7-ubuntu:/var/lib/docker/aufs# docker start aufs-test root@cr7-ubuntu:/var/lib/docker/aufs# tree -L 3 . ├── diff │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ │ ├── bin │ │ ├── dev │ │ ├── etc │ │ ├── home │ │ ├── lib │ │ ├── media │ │ ├── mnt │ │ ├── opt │ │ ├── proc │ │ ├── root │ │ ├── run │ │ ├── sbin │ │ ├── srv │ │ ├── sys │ │ ├── tmp │ │ ├── usr │ │ └── var │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init │ ├── dev │ └── etc ├── layers │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init └── mnt ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ ├── bin │ ├── dev │ ├── etc │ ├── home │ ├── lib │ ├── media │ ├── mnt │ ├── opt │ ├── proc │ ├── root │ ├── run │ ├── sbin │ ├── srv │ ├── sys │ ├── tmp │ ├── usr │ └── var └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init 45 directories, 3 files
在容器中新建 aufs.txt 文件,可以看到 diff 和mnt中的76a069867
目录都新增了 aufs.txt 文件。
root@cr7-ubuntu:/var/lib/docker/aufs# docker exec aufs-test touch aufs.txt root@cr7-ubuntu:/var/lib/docker/aufs# docker exec aufs-test ls -lartr total 64 drwxr-xr-x 12 root root 4096 Oct 21 09:23 var drwxrwxrwt 2 root root 4096 Oct 21 09:23 tmp drwxr-xr-x 2 root root 4096 Oct 21 09:23 srv drwxr-xr-x 2 root root 4096 Oct 21 09:23 run drwx------ 2 root root 4096 Oct 21 09:23 root drwxr-xr-x 2 root root 4096 Oct 21 09:23 opt drwxr-xr-x 2 root root 4096 Oct 21 09:23 mnt drwxr-xr-x 5 root root 4096 Oct 21 09:23 media drwxr-xr-x 2 root root 4096 Oct 21 09:23 home drwxr-xr-x 7 root root 4096 Oct 21 09:23 usr drwxr-xr-x 2 root root 4096 Oct 21 09:23 sbin drwxr-xr-x 7 root root 4096 Oct 21 09:23 lib drwxr-xr-x 2 root root 4096 Oct 21 09:23 bin drwxr-xr-x 15 root root 4096 Nov 10 03:16 etc -rwxr-xr-x 1 root root 0 Nov 10 03:16 .dockerenv dr-xr-xr-x 13 root root 0 Nov 10 03:17 sys dr-xr-xr-x 255 root root 0 Nov 10 03:17 proc drwxr-xr-x 5 root root 360 Nov 10 03:17 dev -rw-r--r-- 1 root root 0 Nov 10 03:19 aufs.txt drwxr-xr-x 25 root root 4096 Nov 10 03:19 .. drwxr-xr-x 25 root root 4096 Nov 10 03:19 . root@cr7-ubuntu:/var/lib/docker/aufs# tree -L 3 . ├── diff │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ │ ├── bin │ │ ├── dev │ │ ├── etc │ │ ├── home │ │ ├── lib │ │ ├── media │ │ ├── mnt │ │ ├── opt │ │ ├── proc │ │ ├── root │ │ ├── run │ │ ├── sbin │ │ ├── srv │ │ ├── sys │ │ ├── tmp │ │ ├── usr │ │ └── var │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ │ └── aufs.txt │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init │ ├── dev │ └── etc ├── layers │ ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 │ ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init └── mnt ├── 6b2b93d3feced2838351bad5a459ebc13a55eca45007692ca1622a0c30e986b7 ├── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0 │ ├── aufs.txt │ ├── bin │ ├── dev │ ├── etc │ ├── home │ ├── lib │ ├── media │ ├── mnt │ ├── opt │ ├── proc │ ├── root │ ├── run │ ├── sbin │ ├── srv │ ├── sys │ ├── tmp │ ├── usr │ └── var └── 76a069867e2f7a662dda1c9e8ec0e3df868319a51631a584824a2c70e1ca01c0-init 45 directories, 5 files
可是,你有没有想到这样一个问题:如果我现在要做的,是删除只读层里的一个文件呢?
为了实现这样的删除操作,AuFS 会在可读写层创建一个 whiteout 文件,把只读层里的文件“遮挡”起来。比如,你要删除只读层里一个名叫 foo 的文件,那么这个删除操作实际上是在可读写层创建了一个名叫.wh.foo 的文件。这样,当这两个层被联合挂载之后,foo 文件就会被.wh.foo 文件“遮挡”起来,“消失”了。这个功能,就是“ro+wh”的挂载方式,即只读 +whiteout 的含义。我喜欢把 whiteout 形象地翻译为:“白障”。
AUFS手动演示
准备演示目录和文件
root@cr7-ubuntu:/tmp/aufs# tree . ├── diff │ ├── container #容器层目录 │ │ └── container.txt │ ├── image1 #镜像层目录 │ │ └── image1.txt │ └── image2 #镜像层目录 │ └── image2.txt └── mnt 5 directories, 3 files
创建 AUFS 联合文件系统
使用 mount 命令可以创建 AUFS 类型的文件系统,命令如下:
root@cr7-ubuntu:/tmp/aufs# mount -t aufs -o dirs=./diff/container/:./diff/image1/:./diff/image2/ none ./mnt/
mount 命令创建 AUFS 类型文件系统时,这里要注意,dirs 参数第一个冒号默认为读写权限,后面的目录均为只读权限,与 Docker 容器使用 AUFS 的模式一致。
执行完上述命令后,mnt 变成了 AUFS 的联合挂载目录,我们可以使用 mount 命令查看一下已经创建的 AUFS 文件系统:
root@cr7-ubuntu:/tmp/aufs# mount -t aufs none on /tmp/aufs/mnt type aufs (rw,relatime,si=1448e4c4c7bc84)
我们每创建一个 AUFS 文件系统,AUFS 都会为我们生成一个 ID,这个 ID 在 /sys/fs/aufs/ 会创建对应的目录,在这个 ID 的目录下可以查看文件挂载的权限。
root@cr7-ubuntu:/tmp/aufs# cat /sys/fs/aufs/si_1448e4c4c7bc84/* /tmp/aufs/diff/container=rw /tmp/aufs/diff/image1=ro /tmp/aufs/diff/image2=ro 64 65 66 /tmp/aufs/diff/container/.aufs.xino
可以看到container目录的权限为rw(代表可读写),image1和image2的权限为ro(代表只读)。 为了验证 mnt 目录下可以看到 container、image1 和 image2 目录下的所有内容,我们使用 ls 命令查看一下 mnt 目录:
root@cr7-ubuntu:/tmp/aufs# ls mnt/ container.txt image1.txt image2.txt
此时的目录结构:
root@cr7-ubuntu:/tmp/aufs# tree . ├── diff │ ├── container │ │ └── container.txt │ ├── image1 │ │ └── image1.txt │ └── image2 │ └── image2.txt └── mnt #mnt目录下包含镜像层和容器层的内容 ├── container.txt ├── image1.txt └── image2.txt 5 directories, 6 files
可以看到 mnt 目录下已经出现了我们准备的所有镜像层和容器层的文件。下面让我们来验证一下 AUFS 的写时复制。
验证 AUFS 的写时复制
AUFS 的写时复制是指在容器中,只有需要修改某个文件时,才会把文件从镜像层复制到容器层,下面我们通过修改联合挂载目录 mnt 下的内容来验证下这个过程。
我们使用以下命令修改 mnt 目录下的 image1.txt 文件:
root@cr7-ubuntu:/tmp/aufs# echo "Hello, Image layer1 changed!" > mnt/image1.txt
然后我们查看下 image1/image1.txt 文件内容:
root@cr7-ubuntu:/tmp/aufs# cat diff/image1/image1.txt Hello,Image layer1!
发现“镜像层”的 image1.txt 文件并未被修改。 然后我们查看一下"容器层"对应的 image1.txt 文件内容:
root@cr7-ubuntu:/tmp/aufs# cat diff/container/image1.txt Hello, Image layer1 changed!
发现 AUFS 在“容器层”自动创建了 image1.txt 文件,并且内容为我们刚才写入的内容。此时的目录结构:
root@cr7-ubuntu:/tmp/aufs# tree . ├── diff │ ├── container │ │ ├── container.txt │ │ └── image1.txt #自动创建的image1.txt文件 │ ├── image1 │ │ └── image1.txt │ └── image2 │ └── image2.txt └── mnt ├── container.txt ├── image1.txt └── image2.txt 5 directories, 7 files
到此,相信大家对“AUFS工作原理是什么”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
分享标题:AUFS工作原理是什么
文章位置:http://myzitong.com/article/pesghg.html