提交后Docker映像大小与容器大小不匹配
最近，我从运行jboss的centos基本映像创建了一个docker容器。最初，我安装了jdk（并已提交），该容器使容器体积庞大（约850M）。后来，我卸载了jdk并安装了jre。从容器内部
du -xsh /
仅显示440M。但是将更改提交到映像后，它仍然显示711M。图像尺寸是否应与容器的 du
不匹配（或接近）？还是在提交时，码头工人会继续添加旧版本（例如SCM）吗？
谢谢
问题答案：
回答我自己的问题。似乎无论何时有人提交给镜像，docker都会继续在基础镜像上添加层。但是，让您的容器将其提交到基础的工作很少，只会在现有图像之上添加一个新层，而该层总是会膨胀该图像。这种方法的问题是，当您进行修改并提交到基本映像时，最终将不必要的图层带到了产品中。我看不到任何正式的方法来合并图层。但是此链接中似乎有一些解决方法。但是，我只是从基础重新创建了所有内容，只提交了一次，这使得图像大小非常接近容器大小。
-
我正在尝试从构建镜像。构建后，命令报告的镜像虚拟大小为1.917 GB。我登录检查大小（），它是573 MB。我很确定这个巨大的大小通常是不可能的。这是怎么回事？如何获得正确的图像大小？更重要的是，当我推送这个存储库时，大小是1.9 GB而不是573 MB。 输出
-
我正在尝试构建一个安装了plv8扩展的PostgreSql 9.6 docker映像。下面是我的Dockerfile。 生成的图像大小为3.45 GB，而Docker hub的原始图像大小为235 MB。你知道为什么产生的图像尺寸这么大吗？如何缩小其尺寸？我试图使用此链接减小其大小，但不幸的是，docker导入/导出丢失了元数据。 更新： 我试图将所有RUN语句合并为一个语句。 新的大小是3.11
-
这是一个关于camera-x的ImageAnalysis用例的一般性问题，但我将使用这个codelab的稍微修改版本作为示例来说明我看到的问题。我发现图像尺寸（image.height*image.width）和相关的ByteBuffer大小（通过其限制和/或容量测量）之间不匹配。我希望它们是相同的，并将图像的一个像素映射到ByteBuffer中的单个值。情况似乎并非如此。希望有人能澄清这是否是一
-
https://docs.oracle.com/javase/8/docs/api/java/util/Spliterator.html SIZED特征值表示在遍历或拆分之前从估计大小（）返回的值表示有限大小，在没有结构源修改的情况下，表示完整遍历将遇到的元素数量的精确计数。 SUBSIZE Character 值表示 trySplit（） 生成的所有拆分器都将同时具有 SIZE 和 SUBSIZ
-
我用两个容器运行docker的环境。我注意到Overly2文件夹太大了。当docker关闭（docker compose down）时，Overly2文件夹的大小为2.3GB。当容器运行时，Overly2文件夹将增加到4.0GB，并且随着时间的推移而增加。这正常吗？ 命令停止容器： 命令，容器运行： 编辑 命令
-
问题内容： 我通过Fedora的Dockerfile创建了一个简单的映像（最初为320 MB）。 添加了Nano（这个1MB大小的微型编辑器），图像的大小已增加到530 MB。我在此基础上添加了Git（30-ish MB），然后将图像大小的火箭提高到830 MB。 那不是疯了吗？ 我试图导出和导入容器以删除历史记录/中间图像。这项工作最多可节省25 MB，现在我的图像大小为804 MB。我也尝试过