Closed GongT closed 3 years ago
Did I missed something about "empty layers" in the doc?
@GongT sorry for the late reply and I'm just catching up after being away for a few days. After a quick scan it looks like you're doing podman build
and then 'buildah budand are finding differences in size between the two resulting images? The difference is probably due to the way that the
--layersoption is defaulted to between the projects. For Podman
--layers` is set to True by default, for Buildah, it is set to False by default. Does that explain the difference in your mind?
I did not use buildah bud
or podman build
, so there isn't a --layers
option.
I'm doing buildah bud --layers
and "manually create base filesystem by buildah commit
".
I have tried the BUILDAH_LAYERS=true
environment variable, no effect.
I found there is a "empty_layer" in history when I set --layers
, how can I do the same thing when I use buildah config
+ buildah commit
?
{
"created": "2020-09-09T04:06:23.064359109Z",
"created_by": "/bin/sh -c #(nop) ENV test=2",
"empty_layer": true // <<--
}
@GongT sorry, I obviously skimmed this issue way too quickly in the first pass. I'm not sure why you're seeing the results that you are. I would expect them to have a portion of the first image size added to each successive image. In fact, that's what I see using Buildah 1.15.1 and Podman 2.0.
# ./run_tom.sh
0+1 records in
0+1 records out
116 bytes copied, 0.000715178 s, 162 kB/s
loop: 1, size: 3054
loop: 2, size: 5544
loop: 3, size: 8034
loop: 4, size: 9500
loop: 5, size: 10966
loop: 6, size: 12432
loop: 7, size: 13897
loop: 8, size: 15364
loop: 9, size: 16830
loop: 10, size: 18296
final: 19762
# podman version
Version: 2.0.4
API Version: 1
Go Version: go1.13.14
Built: Wed Dec 31 19:00:00 1969
OS/Arch: linux/amd64
# buildah version
Version: 1.15.1
Go Version: go1.13.14
Image Spec: 1.0.1-dev
Runtime Spec: 1.0.2-dev
CNI Spec: 0.4.0
libcni Version:
image Version: 5.5.1
Git Commit:
Built: Wed Dec 31 19:00:00 1969
OS/Arch: linux/amd64
# cat /etc/*release
Fedora release 31 (Thirty One)
Regardless, what I think you might be looking for is the --squash
option on the commit command. If I change your commit line in the script to:
LAST_IMG=$( buildah commit --squash --rm "$CONTAINER" my-test:$i 2>/dev/null)
I see:
# ./run_tom.sh
0+1 records in
0+1 records out
116 bytes copied, 0.000663092 s, 175 kB/s
loop: 1, size: 3054
loop: 2, size: 3050
loop: 3, size: 3054
loop: 4, size: 3054
loop: 5, size: 3054
loop: 6, size: 3054
loop: 7, size: 3054
loop: 8, size: 3054
loop: 9, size: 3052
loop: 10, size: 3054
final: 3054
Does that fix things for you?
I tried --squash
, but it did not fit my requirement.
I want my image to have 2 layers:
base
, unchanged for half a yearSo I can save a lot bandwidth
podman build --squash
is exactly what i want, but it not supported by buildah commit
(nor buildah bud
).
buildah commit
's --squash
option works like podman build --squash-all
I want to use buildah at first time is because this tutorial
dnf install --installroot $scratchmnt --releasever 30 bash coreutils --setopt install_weak_deps=false -y
This feature is really great. And this is why I must use buildah commit
.
OMG. I tried to switch to podman build
, but I found this issue again. ðŸ˜
I build a test image with:
FROM fedora
RUN touch /a
And I get:
localhost/test latest f28d523f70dc 32 seconds ago 378 MB
registry.fedoraproject.org/fedora latest 00ff39a8bf19 2 months ago 189 MB
Dump it podman save --format=oci-dir --output=. test
:
total 361M
-rw-r--r--. 1 root root 181M Sep 10 13:14 82f4e266783e1953cc68ccced7c00bf23afe6f18684869115eee3bbe37827330
-rw-r--r--. 1 root root 181M Sep 10 13:14 a344333fd60e49df1a8bc922844c68562422199e225ad450172f4781b12e34f6
-rw-r--r--. 1 root root 1.2K Sep 10 13:14 f28d523f70dc0e619e3a16c11a81987a198c9f56ceb6193f746279412c3b78c9
-rw-r--r--. 1 root root 501 Sep 10 13:14 manifest.json
-rw-r--r--. 1 root root 33 Sep 10 13:13 version
Finally, after I switch from "overlay" to "btrfs" (+ mkfs.btrfs & mount), this issue disappear...
Description I'm using buildah to create some images, but these images always two times larger than my expect.
Eg, a python project with tensorflow, it should about 1.6GB large,
podman run xxx du -xhs /
show it only contains≈1.6GB
file, but the image size is 4GB.Everytime I update and push it, it really upload 4GB data on network.
Steps to reproduce the issue:
A small test script:
It create a test base image, with only one 1mb file.
then
from
andcommit
10 times.Describe the results you received:
Describe the results you expected:
podman images
should list 11 (10 test + 1 base) image with≈1MB
Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:*Output of `cat /etc/release`:**
Output of
uname -a
:Output of
cat /etc/containers/storage.conf
: