在本文中，我们将详细介绍DockerandOverlayFSinpractice的各个方面，同时，我们也将为您带来关于/var/lib/docker/overlay2占用很大，清理Docker占用的磁
在本文中，我们将详细介绍Docker and OverlayFS in practice的各个方面，同时，我们也将为您带来关于/var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间、/var/lib/docker/overlay2 占用很大，清理Docker占用的磁盘空间，迁移 /var/lib/docker 目录、Android：PlaybackOverlayFragment无效、CentOS 7.x docker使用overlay2存储方式的有用知识。
本文目录一览：- Docker and OverlayFS in practice
- /var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间
- /var/lib/docker/overlay2 占用很大，清理Docker占用的磁盘空间，迁移 /var/lib/docker 目录
- Android：PlaybackOverlayFragment无效
- CentOS 7.x docker使用overlay2存储方式
Docker and OverlayFS in practice
https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/
OverlayFS is a modern union filesystem that is similar to AUFS. In comparison to AUFS, OverlayFS:
- has a simpler design
- has been in the mainline Linux kernel since version 3.18
- is potentially faster
As a result, OverlayFS is rapidly gaining popularity in the Docker communityand is seen by many as a natural successor to AUFS. As promising as OverlayFSis, it is still relatively young. Therefore caution should be taken beforeusing it in production Docker environments.
Docker’s overlay storage driver leverages several OverlayFS features to build and manage the on-disk structures of images and containers.
Note: Since it was merged into the mainline kernel, the OverlayFS kernelmodule was renamed from “overlayfs” to “overlay”. As a result you may see thetwo terms used interchangeably in some documentation. However, this documentuses “OverlayFS” to refer to the overall filesystem, and
overlayto referto Docker’s storage-driver.
Image layering and sharing with OverlayFS
OverlayFS takes two directories on a single Linux host, layers one on top ofthe other, and provides a single unified view. These directories are oftenreferred to as layers and the technology used to layer them is known as aunion mount. The OverlayFS terminology is “lowerdir” for the bottom layer and “upperdir” for the top layer. The unified view is exposed through its owndirectory called “merged”.
The diagram below shows how a Docker image and a Docker container are layered.The image layer is the “lowerdir” and the container layer is the “upperdir”.The unified view is exposed through a directory called “merged” which iseffectively the containers mount point. The diagram shows how Docker constructs map to OverlayFS constructs.
Notice how the image layer and container layer can contain the same files. When this happens, the files in the container layer (“upperdir”) are dominant andobscure the existence of the same files in the image layer (“lowerdir”). Thecontainer mount (“merged”) presents the unified view.
OverlayFS only works with two layers. This means that multi-layered imagescannot be implemented as multiple OverlayFS layers. Instead, each image layeris implemented as its own directory under /var/lib/docker/overlay.Hard links are then used as a space-efficient way to reference data shared with lower layers. As of Docker 1.10, image layer IDs no longer correspond todirectory names in /var/lib/docker/
To create a container, the overlay driver combines the directory representing the image’s top layer plus a new directory for the container. The image’s toplayer is the “lowerdir” in the overlay and read-only. The new directory for the container is the “upperdir” and is writable.
Example: Image and container on-disk constructs
The following docker pull command shows a Docker host with downloading aDocker image comprising four layers.
$ sudo docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
8387d9ff0016: Pull complete
3b52deaaf0ed: Pull complete
4bd501fad6de: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:457b05828bdb5dcc044d93d042863fba3f2158ae249a6db5ae3934307c757c54
Status: Downloaded newer image for ubuntu:latestEach image layer has it’s own directory under /var/lib/docker/overlay/. Thisis where the contents of each image layer are stored.
The output of the command below shows the four directories that store thecontents of each image layer just pulled. However, as can be seen, the imagelayer IDs do not match the directory names in /var/lib/docker/overlay. Thisis normal behavior in Docker 1.10 and later.
$ ls -l /var/lib/docker/overlay/
total 24
drwx------ 3 root root 4096 Oct 28 11:02 1d073211c498fd5022699b46a936b4e4bdacb04f637ad64d3475f558783f5c3e
drwx------ 3 root root 4096 Oct 28 11:02 5a4526e952f0aa24f3fcc1b6971f7744eb5465d572a48d47c492cb6bbf9cbcda
drwx------ 5 root root 4096 Oct 28 11:06 99fcaefe76ef1aa4077b90a413af57fd17d19dce4e50d7964a273aae67055235
drwx------ 3 root root 4096 Oct 28 11:01 c63fb41c2213f511f12f294dd729b9903a64d88f098c20d2350905ac1fdbcbbaThe image layer directories contain the files unique to that layer as well ashard links to the data that is shared with lower layers. This allows forefficient use of disk space.
Containers also exist on-disk in the Docker host’s filesystem under/var/lib/docker/overlay/. If you inspect the directory relating to a runningcontainer using the ls -l command, you find the following file anddirectories.
$ ls -l /var/lib/docker/overlay/<directory-of-running-container>
total 16
-rw-r--r-- 1 root root 64 Oct 28 11:06 lower-id
drwxr-xr-x 1 root root 4096 Oct 28 11:06 merged
drwxr-xr-x 4 root root 4096 Oct 28 11:06 upper
drwx------ 3 root root 4096 Oct 28 11:06 workThese four filesystem objects are all artifacts of OverlayFS. The “lower-id”file contains the ID of the top layer of the image the container is based on.This is used by OverlayFS as the “lowerdir”.
$ cat /var/lib/docker/overlay/73de7176c223a6c82fd46c48c5f152f2c8a7e49ecb795a7197c3bb795c4d879e/lower-id
1d073211c498fd5022699b46a936b4e4bdacb04f637ad64d3475f558783f5c3eThe “upper” directory is the containers read-write layer. Any changes made tothe container are written to this directory.
The “merged” directory is effectively the containers mount point. This is where the unified view of the image (“lowerdir”) and container (“upperdir”) isexposed. Any changes written to the container are immediately reflected in this directory.
The “work” directory is required for OverlayFS to function. It is used forthings such as copy_up operations.
You can verify all of these constructs from the output of the mount command.(Ellipses and line breaks are used in the output below to enhance readability.)
$ mount | grep overlay
overlay on /var/lib/docker/overlay/73de7176c223.../merged
type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay/1d073211c498.../root,
upperdir=/var/lib/docker/overlay/73de7176c223.../upper,
workdir=/var/lib/docker/overlay/73de7176c223.../work)The output reflects that the overlay is mounted as read-write (“rw”).
Container reads and writes with overlay
Consider three scenarios where a container opens a file for read access withoverlay.
-
The file does not exist in the container layer. If a container opens afile for read access and the file does not already exist in the container(“upperdir”) it is read from the image (“lowerdir”). This should incur verylittle performance overhead.
-
The file only exists in the container layer. If a container opens a filefor read access and the file exists in the container (“upperdir”) and not inthe image (“lowerdir”), it is read directly from the container.
-
The file exists in the container layer and the image layer. If acontainer opens a file for read access and the file exists in the image layerand the container layer, the file’s version in the container layer is read.This is because files in the container layer (“upperdir”) obscure files withthe same name in the image layer (“lowerdir”).
Consider some scenarios where files in a container are modified.
-
Writing to a file for the first time. The first time a container writesto an existing file, that file does not exist in the container (“upperdir”).The
overlaydriver performs a copy_up operation to copy the file from theimage (“lowerdir”) to the container (“upperdir”). The container then writes thechanges to the new copy of the file in the container layer.However, OverlayFS works at the file level not the block level. This meansthat all OverlayFS copy-up operations copy entire files, even if the file isvery large and only a small part of it is being modified. This can have anoticeable impact on container write performance. However, two things areworth noting:
-
The copy_up operation only occurs the first time any given file iswritten to. Subsequent writes to the same file will operate against the copy ofthe file already copied up to the container.
-
OverlayFS only works with two layers. This means that performance shouldbe better than AUFS which can suffer noticeable latencies when searching forfiles in images with many layers.
-
-
Deleting files and directories. When files are deleted within a containera whiteout file is created in the containers “upperdir”. The version of thefile in the image layer (“lowerdir”) is not deleted. However, the whiteout filein the container obscures it.
Deleting a directory in a container results in opaque directory beingcreated in the “upperdir”. This has the same effect as a whiteout file andeffectively masks the existence of the directory in the image’s “lowerdir”.
Configure Docker with the overlay storage driver
To configure Docker to use the overlay storage driver your Docker host must berunning version 3.18 of the Linux kernel (preferably newer) with the overlaykernel module loaded. OverlayFS can operate on top of most supported Linuxfilesystems. However, ext4 is currently recommended for use in productionenvironments.
The following procedure shows you how to configure your Docker host to useOverlayFS. The procedure assumes that the Docker daemon is in a stopped state.
Caution: If you have already run the Docker daemon on your Docker hostand have images you want to keep,
pushthem Docker Hub or your privateDocker Trusted Registry before attempting this procedure.
-
If it is running, stop the Docker
daemon. -
Verify your kernel version and that the overlay kernel module is loaded.
$ uname -r 3.19.0-21-generic $ lsmod | grep overlay overlay -
Start the Docker daemon with the
overlaystorage driver.$ docker daemon --storage-driver=overlay & [1] 29403 root@ip-10-0-0-174:/home/ubuntu# INFO[0000] Listening for HTTP on unix (/var/run/docker.sock) INFO[0000] Option DefaultDriver: bridge INFO[0000] Option DefaultNetwork: bridge <output truncated>Alternatively, you can force the Docker daemon to automatically start withthe
overlaydriver by editing the Docker config file and adding the--storage-driver=overlayflag to theDOCKER_OPTSline. Once this optionis set you can start the daemon using normal startup scripts without havingto manually pass in the--storage-driverflag. -
Verify that the daemon is using the
overlaystorage driver$ docker info Containers: 0 Images: 0 Storage Driver: overlay Backing Filesystem: extfs <output truncated>Notice that the Backing filesystem in the output above is showing as
extfs. Multiple backing filesystems are supported butextfs(ext4) isrecommended for production use cases.
Your Docker host is now using the overlay storage driver. If you run themount command, you’ll find Docker has automatically created the overlaymount with the required “lowerdir”, “upperdir”, “merged” and “workdir”constructs.
OverlayFS and Docker Performance
As a general rule, the overlay driver should be fast. Almost certainly faster than aufs and devicemapper. In certain circumstances it may also be faster than btrfs. That said, there are a few things to be aware of relative to the performance of Docker using the overlay storage driver.
-
Page Caching. OverlayFS supports page cache sharing. This means multiplecontainers accessing the same file can share a single page cache entry (orentries). This makes the
overlaydriver efficient with memory and a goodoption for PaaS and other high density use cases. -
copy_up. As with AUFS, OverlayFS has to perform copy-up operations anytime a container writes to a file for the first time. This can insert latencyinto the write operation — especially if the file being copied up islarge. However, once the file has been copied up, all subsequent writes to thatfile occur without the need for further copy-up operations.
The OverlayFS copy_up operation should be faster than the same operationwith AUFS. This is because AUFS supports more layers than OverlayFS and it ispossible to incur far larger latencies if searching through many AUFS layers.
-
RPMs and Yum. OverlayFS only implements a subset of the POSIX standards.This can result in certain OverlayFS operations breaking POSIX standards. Onesuch operation is the copy-up operation. Therefore, using
yuminside of acontainer on a Docker host using theoverlaystorage driver is unlikely towork without implementing workarounds. -
Inode limits. Use of the
overlaystorage driver can cause excessiveinode consumption. This is especially so as the number of images and containerson the Docker host grows. A Docker host with a large number of images and lotsof started and stopped containers can quickly run out of inodes.
Unfortunately you can only specify the number of inodes in a filesystem at thetime of creation. For this reason, you may wish to consider putting/var/lib/docker on a separate device with its own filesystem, or manuallyspecifying the number of inodes when creating the filesystem.
The following generic performance best practices also apply to OverlayFS.
-
Solid State Devices (SSD). For best performance it is always a good ideato use fast storage media such as solid state devices (SSD).
-
Use Data Volumes. Data volumes provide the best and most predictableperformance. This is because they bypass the storage driver and do not incurany of the potential overheads introduced by thin provisioning andcopy-on-write. For this reason, you should place heavy write workloads on datavolumes.
/var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间
转：
/var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间
今天收到一个磁盘告警，告警的原因是一台 Jenkins 机器上某个磁盘空间满了。
马上使用 df -h 命令看下使用情况
上图是我优化后的截图，告警的时候磁盘使用量已经接近 100%。
上图中看到的 overlay 分区是 Docker 的虚拟文件系统，其真实的文件系统是 /dev/vda1。所以我们要找到是什么原因大量占据了 /dev/vda1。
一般有两种情况。
无用的镜像和容器太多
我们可以使用以下命令大致看下情况
docker system df -v
# 用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及无tag的镜像。
docker system prune
# 可以将没有容器使用 Docker 镜像都删掉。注意，这两个命令会把你暂时关闭的容器，以及暂时没有用到的Docker镜像都删掉了
docker system prune -a
日志、大文件占用了 /dev/vda1 分区
还有一种情况就是 一些日志文件，大文件占用了 /dev/vda1 分区。这个分区一般是挂载在 “/” 下面。
所以我们可以重点关注下面几个目录：
- /var/tmp
- /var/log
- /root
转：
/var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间
--Posted from Rpc
/var/lib/docker/overlay2 占用很大，清理Docker占用的磁盘空间，迁移 /var/lib/docker 目录
0 du -hs /var/lib/docker/ 命令查看磁盘使用情况。
linlf@dacent:~$ sudo du -hs /var/lib/docker/
237G /var/lib/docker/
1 docker system df命令，类似于Linux上的df命令，用于查看Docker的磁盘使用情况:
linlf@dacent:~$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 7 2 122.2GB 79.07GB (64%)
Containers 2 2 61.96GB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
2 docker system prune命令可以用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像(即无tag的镜像)。
linlf@dacent:~$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all build cache
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
3 docker system prune -a命令清理得更加彻底，可以将没有容器使用Docker镜像都删掉。注意，这两个命令会把你暂时关闭的容器，以及暂时没有用到的Docker镜像都删掉了…所以使用之前一定要想清楚.。我没用过，因为会清理 没有开启的 Docker 镜像。
4 迁移 /var/lib/docker 目录。
4.1 停止docker服务。
systemctl stop docker
4.2 创建新的docker目录，执行命令df -h,找一个大的磁盘。 我在 /home目录下面建了 /home/docker/lib目录，执行的命令是：
mkdir -p /home/docker/lib
4.3 迁移/var/lib/docker目录下面的文件到 /home/docker/lib：
rsync -avz /var/lib/docker /home/docker/lib/
4.4 配置 /etc/systemd/system/docker.service.d/devicemapper.conf。查看 devicemapper.conf 是否存在。如果不存在，就新建。
sudo mkdir -p /etc/systemd/system/docker.service.d/
sudo vi /etc/systemd/system/docker.service.d/devicemapper.conf
4.5 然后在 devicemapper.conf 写入：（同步的时候把父文件夹一并同步过来，实际上的目录应在 /home/docker/lib/docker ）
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd --graph=/home/docker/lib/docker
4.6 重新加载 docker
systemctl daemon-reload
systemctl restart docker
systemctl enable docker
4.7 为了确认一切顺利，运行
# docker info
命令检查Docker 的根目录.它将被更改为 /home/docker/lib/docker
...
Docker Root Dir: /home/docker/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
...
4.8 启动成功后，再确认之前的镜像还在：
linlf@dacent:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
AAA/AAA v2 7331b8651bcc 27 hours ago 3.85GB
BBB/BBB v1 da4a80dd8424 28 hours ago 3.47GB
4.9 确定容器没问题后删除/var/lib/docker/目录中的文件。
https://blog.csdn.net/qq_37674858/article/details/79976751
https://blog.csdn.net/cmrsautomation/article/details/52857791
Android：PlaybackOverlayFragment无效
我正在开发Android TV应用程序,当我开始处理项目代码时,它会为PlaybackOverlayFragment抛出一个错误,说明它无法解析符号PlaybackOverlayFragment
public class PlaybackOverlayFragment extends android.support.v17.leanback.app.PlaybackOverlayFragment
目前在我的gradle文件中它显示：
compile 'com.android.support:leanback-v17:27.1.1'
原始项目是在编译sdk版本26并且我将它升级到27,这是因为它抛出错误吗？
解决方法:
PlaybackOverlayFragment在不久前被弃用,然后在v27中完全删除.
您应该尽快远离弃用的API,因为它们可能会在将来的任何时候被删除.
该文档说您应该使用PlaybackFragment而不是在27.1.0中弃用…所以现在你应该使用PlaybackSupportFragment
资料来源：https://developer.android.com/reference/android/support/v17/leanback/app/PlaybackFragment
CentOS 7.x docker使用overlay2存储方式
编辑/etc/docker/daemon.json添加以下内容：
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
安装依赖：
yum install yum-plugin-ovl -y
否则会报以下错误：
May 05 18:20:45 node1 dockerd[49605]: Error starting daemon: error initializing graphdriver: /var/lib/docker contains several valid graphdrivers: overlay2, overlay; Please cleanup or explicitly choose storage driver (-s )
最后重启docker即可
systemctl restart docker
补充知识：centos7 编译加载toa模块
1.安装kernel-devel包，需要与当前kernel版本一致
yum install kernel-devel
yum update kernel
2.由于update内核后，需要重启系统使其生效
3.获取toa源码
cd /usr/local/src/ git clone https://github.com/huaweicloud/elb-toa.git cd elb-toa/src make
4.正常的话应该会生成toa.ko，加载测试下
insmod toa.ko
lsmod |grep toa
部署个nginx测试下
添加开机自加载
cd /lib/modules/uname -r/kernel/net/
cp /usr/local/src/elb-toa/src/toa.ko .
把下面这句加入rc.local
insmod /lib/modules/3.10.0-957.21.3.el7.x86_64/kernel/net/toa.ko
确保/etc/rc.d/rc.local 有执行权限，否则rc.local不生效
以上这篇CentOS 7.x docker使用overlay2存储方式就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持。
- Docker Overlay2磁盘空间占用过大清理的方法实现
- 解决docker磁盘空间不足问题
- 如何清理 Docker 占用的磁盘空间的方法
- 关于docker清理Overlay2占用磁盘空间的问题(亲测有效)
我们今天的关于Docker and OverlayFS in practice的分享就到这里，谢谢您的阅读，如果想了解更多关于/var/lib/docker/overlay2 占用很大，清理 Docker 占用的磁盘空间、/var/lib/docker/overlay2 占用很大，清理Docker占用的磁盘空间，迁移 /var/lib/docker 目录、Android：PlaybackOverlayFragment无效、CentOS 7.x docker使用overlay2存储方式的相关信息，可以在本站进行搜索。
本文标签：
