Replies: 5 comments 10 replies
-
|
Do you care about the size or are you just looking to remove functionality? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I'll give this a shot. Thanks for the feedback. |
Beta Was this translation helpful? Give feedback.
-
|
You might find this script helpful, to see which modules are biggest: https://github.com/afbjorklund/build-size
|
Beta Was this translation helpful? Give feedback.
-
|
That looks quite useful. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think that adding build tags will help shrink binary sizes much. In a way, all roads lead to Rome. Even if we'd remove So removing commands won't do much unless we change the backend. BUT: Maintaining conditional compilation is extremely painful, so I am extremely reluctant to it. In fact, it's an entire research topic (google "linux ifdef hell") that I've been working on a for a number of years. I'd much prefer to invest into slimming down "vanilla" Podman as much as possible for the benefit of all users. @rganesan, do you have a target binary size in mind? We have upstream scripts (see https://github.com/containers/podman/tree/main/dependencies/analyses) to analyze dependency bloat. |
Beta Was this translation helpful? Give feedback.
-
|
I remember that the podman-machine ISO (100M) ended up twice as big as the docker-machine ISO (50M), for the boot2podman project. It was a bit disappointing at the time, but mostly since I didn't bother with the kernel modules and because I included buildah and skopeo... Now when the OS installation is more like 1G or 10G, it seems like it doesn't matter... Not even sure what a "podman-full.tar.gz" looks like now, after the demise of Nix ? |
Beta Was this translation helpful? Give feedback.
-
|
Making a podman-run command would be interesting. |
Beta Was this translation helpful? Give feedback.
-
|
On Mon, Nov 14, 2022 at 2:53 PM Valentin Rothberg ***@***.***> wrote:
I don't think that adding build tags will help shrink binary sizes much.
In a way, all roads lead to Rome. Even if we'd remove podman pull, for
instance, there are more than a handful of other commands who may call the
pull backend (including run).
In addition to binary size, we're also concerned about the attack surface.
We don't want to allow a "podman build" or a "podman pull" from a random
registry.
So removing commands won't do much unless we change the backend. BUT:
Maintaining conditional compilation is extremely painful, so I am extremely
reluctant to it. In fact, it's an entire research topic (google "linux
ifdef hell") that I've been working on a for a number of years
<https://scholar.google.com/citations?user=awzkEU4AAAAJ&hl=fr>.
Having wrestled with autoconf and automake for years building for multiple
Unix like OS targets, I understand and sympathize with your concern.
However, as podman keeps gathering features, I think it would be good to
brainstorm how to split a base vs full-featured version (for example
vim-tiny vs vim). The base version could be potentially installed by
default in a distro.
I'd much prefer to invest into slimming down "vanilla" Podman as much as
possible for the benefit of all users.
@rganesan <https://github.com/rganesan>, do you have a target binary size
in mind?
Our basis for comparison was docker 17 which we used to bundle in the image
before docker became simply too bloated. Even containerd installed size
currently runs into 120+MB. In comparison, podman's current installed size
(including dependencies) is already much smaller at ~55MB. It would be nice
to get this under 25MB which I know is a tall ask.
We have upstream scripts (see
https://github.com/containers/podman/tree/main/dependencies/analyses) to
analyze dependency bloat.
Thanks, I'll take a look.
Ganesan
… —
Reply to this email directly, view it on GitHub
<#16493 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABRNVRKR6CBAW3EH5LH7JALWIIAJBANCNFSM6AAAAAAR6HJPBQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Ganesan Rajagopal
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for elaborating, @rganesan!
Blocking random/untrusted registries can be achieved via configurations. I am sure we can find a way without a special flavor/variant of Podman.
Glad you noticed the difference in binary bloat. We've invested quite some time in slimming down Podman. Our tests will fail, for instance, if a PR increases the binary size too much.
We'll do our best. Good news is that we share the goal of further trimming down Podman. How far we can push it, I don't know. |
Beta Was this translation helpful? Give feedback.
-
|
Could you break down the dependancies on the 55 MB? On Fedora I see, but I am not sure all of these are required. gvproxy is not if you are not using machine, if you only use --network=host and --network=none, you can drop the network tools. |
Beta Was this translation helpful? Give feedback.
-
|
Adding security should be achieved via other means like configuration of containers.conf and registries.conf. |
Beta Was this translation helpful? Give feedback.
-
|
The sizes are based on "dnf into" reported sizes for podman and
dependencies on CentOS 9 Stream.
podman (version 4.1.1): 45MB
netavark: 8.1MB
crun + deps: 2MB
libgpg_error: 800K
+ bunch of other smaller dependencies totalling up to 45-46MB.
Ganesan
…On Tue, Nov 15, 2022 at 2:59 AM Daniel J Walsh ***@***.***> wrote:
Could you break down the dependancies on the 55 MB?
On Fedora I see, but I am not sure all of these are required. gvproxy is
not if you are not using machine, if you only use --network=host and
--network=none, you can drop the network tools.
du -sm /usr/bin/podman /usr/bin/crun /usr/bin/conmon /usr/libexec/podman/*
38 /usr/bin/podman
1 /usr/bin/crun
1 /usr/bin/conmon
4 /usr/libexec/podman/aardvark-dns
0 /usr/libexec/podman/catatonit
12 /usr/libexec/podman/gvproxy
9 /usr/libexec/podman/netavark
4 /usr/libexec/podman/rootlessport
—
Reply to this email directly, view it on GitHub
<#16493 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABRNVRMFD6YXT27PSKZ3RJDWIKVMXANCNFSM6AAAAAAR6HJPBQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Ganesan Rajagopal
|
Beta Was this translation helpful? Give feedback.
-
|
On Tue, Nov 15, 2022 at 3:01 AM Daniel J Walsh ***@***.***> wrote:
Adding security should be achieved via other means like configuration of
containers.conf and registries.conf.
Thanks, we'll follow this approach.
Ganesan
… —
Reply to this email directly, view it on GitHub
<#16493 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABRNVROACFVCTWCYEKLIGDLWIKVTHANCNFSM6AAAAAAR6HJPBQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Ganesan Rajagopal
|
Beta Was this translation helpful? Give feedback.
-
We'd like to ship podman with embedded devices that support running containers but with restricted user interaction. We would like to slim down the footprint for size considerations. For example we don't need commands like "build", "machine" or even "pull"/"push" etc or remote connections (network access is restricted, so images have to be loaded from an uploaded tarball).
One option we considered is to write our own layer on top of runc/crun but customers want a podman/docker familiar CLI to run and monitor the containers.
Seeking some guidance if this makes any sense at all and if it does how to go about this. Would be acceptable to introduce to some build tags (say "minimal" for example)?
Beta Was this translation helpful? Give feedback.
All reactions