docker镜像存储位置
⑴ 怎么修改docker images的存储目录
第一种方式更改docker的配置文件
Ubuntu/Debian: edit your /etc/default/docker file with the -g option: DOCKER_OPTS="-dns 8.8.8.8 -dns 8.8.4.4 -g /mnt"
Fedora/Centos: edit /etc/sysconfig/docker, and add the -g option in the other_args variable: ex. other_args="-g /var/lib/testdir". If there's more than one option, make sure you enclose them in " ". After a restart, (service docker restart) Docker should use the new directory.
第二种方式使用连接
1) Stop docker: service docker stop. Verify no docker process is running ps faux
2) Double check docker really isn't running. Take a look at the current docker directory: ls /var/lib/docker/
2b) Make a backup - tar -zcC /var/lib docker > /mnt/pd0/var_lib_docker-backup-$(date +%s).tar.gz
3) Move the /var/lib/docker directory to your new partition: mv /var/lib/docker /mnt/pd0/docker
4) Make a symlink: ln -s /mnt/pd0/docker /var/lib/docker
5) Take a peek at the directory structure to make sure it looks like it did before the mv: ls /var/lib/docker/ (note the trailing slash to resolve the symlink)
6) Start docker back up service docker start
7) restart your containers
⑵ 如何更改Docker默认的images存储位置
Docker的镜像以及一些数据都是在/var/lib/docker目录下,它占用的是Linux的系统分区,也就是下面的/dev/vda1,当有多个镜像时,/dev/vda1的空间可能不足,我们可以把docker的数据挂载到数据盘,例如:/dev/vdb目录下。
[root@10-10-63-106 docker]# df -lhT
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 xfs 20G 3.8G 16G 20% /
devtmpfs devtmpfs 916M 0 916M 0% /dev
tmpfs tmpfs 921M 0 921M 0% /dev/shm
tmpfs tmpfs 921M 43M 878M 5% /run
tmpfs tmpfs 921M 0 921M 0% /sys/fs/cgroup
/dev/vdb xfs 100G 11G 90G 11% /data
其中主要的步骤如下:
(1) 首先,备份fstab文件
sudo cp /etc/fstab /etc/fstab.$(date +%Y-%m-%d)
(2) 停止docker, 用rsync同步/var/lib/docker到新位置.
如果rsync没有安装,则使用yum -y intall rsync 进行安装,停止docker ,service docker stop,在数据分区中建立要挂载的目录,mkdir /data/docker 使用rsync工具同步,rsync -aXS /var/lib/docker/. /data/docker/,这可能需要花费的较长的时间,取决于/var/lib/docker的大小,
(3) 修改fstab
在该文件中把下面一行添加到fstab里,将新位置挂载到 /var/lib/docker
/data/docker /var/lib/docker none bind 0 0
文件的内如如下:
[root@10-10-63-106 docker]# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Thu Jul 31 07:50:13 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/vda1 / xfs errors=remount-ro 0 1
/swapfile none swap defaults 0 0
/dev/vdb /data xfs defaults,noatime 0 0
/data/docker /var/lib/docker none bind 0 0
(4) 重新挂载
mount –a
(5) 使用下面的命令检查一下
df /var/lib/docker/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vdb 104806400 47204 104759196 1% /var/lib/docker
(6)进入Container查看我们的空间
bash-4.1# df -lhT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 9.8G 1.4G 7.9G 15% /
tmpfs tmpfs 921M 0 921M 0% /dev
shm tmpfs 64M 0 64M 0% /dev/shm
/dev/vdb xfs 100G 2.1G 98G 3% /etc/resolv.conf
/dev/vdb xfs 100G 2.1G 98G 3% /etc/hostname
/dev/vdb xfs 100G 2.1G 98G 3% /etc/hosts
tmpfs tmpfs 921M 0 921M 0% /run/secrets
tmpfs tmpfs 921M 0 921M 0% /proc/kcore
没有更改/var/lib/docker路径之前的情况:
bash-4.1# df -lhT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 9.8G 1.4G 7.9G 15% /
tmpfs tmpfs 921M 0 921M 0% /dev
shm tmpfs 64M 0 64M 0% /dev/shm
/dev/vda1 xfs 20G 13G 6.9G 66% /etc/resolv.conf
/dev/vda1 xfs 20G 13G 6.9G 66% /etc/hostname
/dev/vda1 xfs 20G 13G 6.9G 66% /etc/hosts
tmpfs tmpfs 921M 0 921M 0% /run/secrets
tmpfs tmpfs 921M 0 921M 0% /proc/kcore
宿主机中的分区大小信息:
[root@10-10-63-106 ~]# df -lhT
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 xfs 20G 13G 6.9G 65% /
devtmpfs devtmpfs 916M 0 916M 0% /dev
tmpfs tmpfs 921M 0 921M 0% /dev/shm
tmpfs tmpfs 921M 89M 832M 10% /run
tmpfs tmpfs 921M 0 921M 0% /sys/fs/cgroup
/dev/vdb xfs 100G 33M 100G 1% /data
⑶ docker-machine 安装的docker 镜像 存储在哪
方案1, 使用参数-g 来修改 Docker 的镜像存储文件夹.
修改方法如下:
在 Ubuntu/Debian 系统下:
编辑 /etc/default/docker 文件, 添加-g 参数的设置, 如下:
DOCKER_OPTS="-dns 8.8.8.8 -dns 8.8.4.4 -g /mnt"
在 Fedora/Centos 系统下:
编辑 /etc/sysconfig/docker 文件, 添加-g 参数的设置, 如下:
other_args="-g /mnt"
重启 Docker 服务, 问题就解决了.
方案2 使用链接
1) 停止 Docker: service docker stop.
2) 做个备份 tar -zcC /var/lib/docker > /mnt/var_lib_docker-backup-$(date + %s).tar.gz
3) 迁移/var/lib/docker目录到met 目录下: mv /var/lib/docker /mnt/docker
4) 建个 symlink: ln -s /mnt/docker /var/lib/docker
5) 确认文件夹类型为symlink 类型 ls /var/lib/docker
6) 启动 docker service.
⑷ 本地镜像保存在docker宿主机的什么目录下
docker镜像存储在本地机器中的哪个位置?
-
问答
-
云+社区
-
腾讯云
https://cloud.tencent.com/developer/ask/179262
⑸ 03-Docker存储引擎
目前docker的默认存储引擎为overlay2,不同的存储引擎需要相应的文件系统支持,如需要磁盘分区的时候传递d-type稳健分层功能,即需要传递内核参数并开启格式化磁盘的时候指定的功能
Docker 存储引擎的核心思想是“层”的概念,理解了这个层,就基本可以理解它的设计思路。当我们拉取一个 Docker 镜像的时候,可以看到如下:
一个镜像被分成许多的“层”,每“层”包含了若干的文件,而一层层堆叠起来就组成了我们的一个完整的镜像。我们镜像中的文件就是所有“层”文件的并集。 我们构建 Docker 镜像一般采用 Dockerfile 的方式,而 Dockerfile 的每行命令,其实就会生成一个“层”,即使什么文件都没有添加。
文件的创建是在读写层增加文件,那修改和删除呢?
这就要提一下 Docker 设计的 -on-write (CoW) 策略。
当我们试图读取一个文件时,Docker 会从上到下一层层去找这个文件,找到的第一个就是我们的文件。所以下面层相同的文件就被“覆盖”了。而修改就是当我们找到这个文件时,将它“复制”到读写层并修改,这样读写层的文件就是我们修改后的文件,并且“覆盖”了镜像中的文件了。而删除就是创建了一个特殊的 whiteout 文件,这个 whiteout 文件覆盖的文件即表示删除了。
这样的设计有什么好处吗?
第一个好处是减少了存储空间,由于镜像被分成了多个层,而各个层是静态只读的,是可以共享的。当你从一个镜像构建另一个镜像时,只需要添加新的层,原有的层不会被复制。
我们可以用 docker history 命令查看我们创建的镜像,相同的层将共享且只保存一份。
我们可以在系统的 /var/lib/docker/<存储驱动>/ 下看到我们所有的层。
第二个好处是启动容器就变得非常轻量和快速。因为我们的容器只是添加了一个“空”的读写层,其他的都是复用的只读层,需要用时才会去搜索。
Docker 的存储引擎针对不同的文件系统,是由不同的存储驱动。
Docker 主要有一下几类存储驱动:
有条件的情况下,我们还是建议选择 overlay2 的存储驱动。
Linux 系统正常运行, 通常需要两个文件系统:
OverlayFS 是从 aufs 之上改进和简化而来的,比 aufs 和 devicemapper 有更好的性能,大部分情况下也比 btrfs 好。
OverlayFS 结构分为三个层: LowerDir 、 Upperdir 、 MergedDir
LowerDir、Upperdir、MergedDir 关系图:
特性:
获取镜像存储路径
Lower层
LowerDir 层的存储是不允许创建文件, 此时的LowerDir实际上是其他的镜像的UpperDir层,也就是说在构建镜像的时候, 如果发现构建的内容相同, 那么不会重复的构建目录,而是使用其他镜像的Upper 层来作为本镜像的Lower
Merged层
属于对外展示层,只能在运行中的容器查看,镜像是查看不了的
1)查看init层地址指向
容器在启动的过程中, Lower 会自动挂载init的一些文件
2) init层主要内容是什么?
init层是以一个uuid+-init结尾表示,放在只读层(Lowerdir)和读写层(Upperdir)之间,
作用只是存放/etc/hosts、/etc/resolv.conf 等文件。
3) 为什么需要init层?
(1) 容器在启动以后, 默认情况下lower层是不能够修改内容的, 但是用户有需求需要修改主机名与域名地址, 那么就需要添加init层中的文件(hostname, resolv.conf), 用于解决此类问题.
(2) 修改的内容只对当前的容器生效, 而在docker commit提交为镜像时候,并不会将init层提交。
(3) init 文件存放的目录为/var/lib/docker/overlay2/<init_id>/diff
4) 查看init层文件
hostname与resolv.conf 全部为空文件, 在系统启动以后由系统写入。
配置 Docker 存储驱动非常简单,只需要修改配置文件即可。
方法1
方法2
⑹ docker存储驱动
一句话,docker 存储驱动用于管理docker 镜像和容器。
在了解docker存储驱动之前,先了解下docker如何构建镜像,以及容器如何使用这些镜像。
下图为docker镜像的图形表示。
镜像为一系列只读层,当启动一个容器时,docker将读取只读镜像,并在顶部增加一个可读写层,如果正在运行的容器修改了现有文件,则该文件将从基础只读层复制到应用更改的最高读写层,读写层的版本会隐藏基础文件,但不会破坏它,它仍然处于基础层中。删除容器后,这些更改将丢失。
Docker使用存储驱动程序来管理镜像层和可写容器层的内容。
每个存储驱动程序处理实现的方式不同,但是所有驱动程序都使用可分层镜像和即写即拷(CoW)策略。
当使用docker pull拉取一个镜像时,每一层都是单独拉取的,并存储在本地/var/lib/docker/<storage-driver>中。
注意,/var/lib/docker/<storage-driver>中的目录名与层id不对应(自Docker 1.10以来一直如此)。
注意,多个容器可能共享部分或全部只读镜像数据。因此,不能只计算虚拟大小的总数。这可能过高估计了磁盘的总使用量。
如果一个文件或者目录处于只读层,而容器需要对其进行访问时,那么只使用现有文件。当容器需要修改文件时,那么文件被复制到读写层并修改,这将最小化IO和读写层的大小。
docker存储驱动分为两类,一类是overlays(覆盖),一类是Snapsshotting(快照)。
它们都使用可拔插的架构。
可以通过docker info查看当前使用的存储器驱动。
区别之处:
overlays文件系统,它们有多个目录,每层镜像都有不同的文件。
Snapsshottings包括devicemapper,btrfs和ZFS,它们在block级别上处理文件差异。
○ overlay2是当前支持的所有Linux发行版的首选存储驱动程序,不需要额外配置。
○ 当运行在内核3.13上的Ubuntu 14.04上时,aufs是Docker 18.06和更老版本的首选存储驱动程序,因为内核3.13不支持overlay2。
○ 支持devicemapper,但是在生产环境中需要直接lvm,因为环回lvm虽然是零配置,但性能非常差。devicemapper是CentOS和RHEL推荐的存储驱动程序,因为它们的内核版本不支持overlay2。但是,CentOS和RHEL的当前版本现在支持overlay2,它现在是推荐的驱动程序。
○ 如果btrfs和zfs存储驱动程序是后备文件系统(安装Docker的主机的文件系统),则使用它们。这些文件系统允许高级选项,比如创建“快照”,但是需要更多的维护和设置。这些都依赖于备份文件系统的正确配置。
○ vfs存储驱动程序用于测试目的,并用于不能使用即写即拷文件系统的情况。这个存储驱动程序的性能很差,一般不推荐用于生产。
所有这些存储驱动程序,就是Union文件系统 的变体。
对于Docker,后备文件系统就是/var/lib/docker/所在的文件系统。有些存储驱动程序只与特定的后备文件系统(宿主机的文件系统)一起工作。
○ overlay2、aufs和overlay都在文件层而不是块层操作。这样可以更有效地使用内存,但是容器的可写层可能会在写量大的工作负载中增长得相当大。
○ 块级存储驱动程序(如devicemapper、btrfs和zfs)对于写量大的工作负载性能更好(尽管不如Docker卷)。
○ 对于许多小的写操作或具有许多层的容器或深度文件系统,overlay的性能可能比overlay2好,但是消耗更多的inode,这可能导致inode耗尽。
○ btrfs和zfs需要大量内存。
○ zfs对于高密度的工作负载(如PaaS)是一个很好的选择。
关于性能、适用性和最佳实践的更多信息可以在每个存储驱动程序的文档中找到。
⑺ docker私有镜像仓库搭建和镜像删除
docker私有镜像仓库一般用来存放公司内部的镜像,比如微服务中会有很多的服务需要放到自己公司内部的镜像仓库上,发布的时候直接从私有镜像仓库拉取。比如我公司的微服务部署在k8s环境上,微服务技术依然选择熟悉的 Spring Cloud ,这样每一个服务其实就是一个 Spring Boot 项目,我们通过Maven的插件会在项目编译、打包之后推送到我们的私有镜像仓库,之后CI工具使用kubelet部署的时候会从私有镜像仓库拉取镜像,最后完成部署,可以说私有镜像仓库是非常重要的一个环节。
接下来我会主要讲述一下私有镜像仓库的搭建以及镜像的管理,包括一些自己遇到的问题。
首先要保证自己的服务器已经安装了 docker 。具体的安装教程可以看 官网 ,这里就不在赘述了。
首先我们需要创建一个自己的CA证书,
比如下图是我自己创建时输入的相关内容:
做好镜像存储目录和证书目录的挂载,运行即可
这一步需要在所有需要拉取镜像的服务器上执行。上月底我在部署正式环境时我就遇到了这个问题,k8s的节点上一直显示拉取镜像失败,后来才发现忘了在k8s服务器上配置证书。
hostname 即生成CA证书的时候最后输入的 hostname , port 镜像仓库对外暴露的端口号。
如果是在镜像仓库所在的服务器上,执行:
如果不是同一台服务器,同样需要存放创建证书目录,执行:
之后将证书上传到目标服务器,且放在证书目录下,名称为 ca.crt 。
为了测试,我拉取一个 redis 镜像,然后给它重新打一个 tag 。
推送到私有镜像仓库:
浏览器显示:
表示刚才推送到私有镜像仓库是成功的。接下来我们测试从另一台服务器拉取刚才的镜像。当然这台服务器一定要按照之前的描述配置好CA证书,还要修改服务器 hosts 文件,配置好 ip 和 hostname 。
拉取镜像:
拉取镜像如下图所示:
根据显示可以看出拉取镜像是成功的。
到这里镜像仓库的搭建、推送和拉取都讲完了,接下来就看看怎么删除镜像。
这里说的删除镜像是指从仓库中删除,即从服务器上删除。在构建仓库的时候我们将镜像的仓库容器内的目录挂载到了服务器的目录。镜像仓库内其实是没有镜像文件,都在服务器对应的目录下。在开发的时候我就遇到过这样一个问题,因为是开发环境项目编译、打包、镜像构建和推送都非常频繁,虽然新的镜像会覆盖老的镜像,但是原有的镜像文件本身并没有被覆盖,这样的结果就是虽然镜像仓库上看镜像只有一个,但是本地服务上存储的是很多个镜像文件(而且基本是没啥用的),最终导致了服务磁盘空间不足的情况。
我们依然以 Redis 举例,我将多不同版本的 Redis 多次像私有仓库推送,不管是 Redis 4.0、5.0、6.0,最终我向仓库推送的版本号都是 redis:v4 (过程省略),最终我们在镜像仓库目录( /home/registry/ )下可以看到有多个 sha256 的值,详细目录:
/home/registry/docker/registry/v2/repositories/redis/_manifests/revisions/sha256
如下图:
如果要删除镜像首先需要修改配置文件,进入到docker容器内:
保存之后退出容器。
我们进入到存放镜像的目录下,删除一个镜像的 sha256 的值
上面只是删除了镜像的 sha256 值,并没有删除镜像本身,我们需要调用垃圾回收的命令:
这时候会看到一些输出,比如:
这时候我们在查看下对应目录的磁盘使用情况:
但是变化不明显,那就在删除一个试试。
除了手动删除之外还可以通过API来删除,这个方法我没有测试,感兴趣的小伙伴可以测试一下。在实际过程中我也是使用上述方法删除的,因为我一般都是磁盘使用率到一定比例才进行批量删除的,另外网上也有人通过脚本,感兴趣的小伙伴都可以尝试一下。
删除可以使用使用官方API删除:
查询镜像的 sha256 的值:
今天关于docker私有镜像仓库的内容就讲到这里,如果对上面内容有什么疑问欢迎大家交流探讨,也欢迎大家多多点赞、分享、转发,谢谢大家~~~
⑻ docker image是什么,存储在什么位置
image是镜像,位置在/var/lib/docker,里面有镜像,容器和分层,都存储在这里
⑼ docker windows 拉下来镜像在什么位置
docker的镜像默认存放位置是 / var / lib / docker 下,要把这个挂到数据盘下本身不是什么难事,不过要平滑移动就麻烦了。于是先去分区,挂载。我把数据盘挂载到了 / data 下,然后开始研究......
# df -lhT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 29G 2.0G 26G 8% /
none tmpfs 4.0K 0 4.0K 0% /sys/fs/cgroup
udev devtmpfs 834M 12K 834M 1% /dev
tmpfs tmpfs 168M 428K 168M 1% /run
none tmpfs 5.0M 0 5.0M 0% /run/lock
none tmpfs 839M 0 839M 0% /run/shm
none tmpfs 100M 0 100M 0% /run/user
none tmpfs 64K 0 64K 0% /etc/network/interfaces.dynamic.d
/dev/sdb1 ext4 69G 52M 66G 1% /mnt
/dev/sdc1 ext4 1007G 156M 956G 1% /data
备份&文件同步
首先,备份 fstab 文件,文件位于 / etc / fstab
Shell