On Wed, 19 Feb 2025 at 20:24:20 +0800, Sean Whitton wrote:
> However, there are no instructions about maintaining the container image
> and the image store.
I'm not sure that autopkgtest-{build,virt}-podman(1) is really the ideal
place for a podman tutorial, any more than -{build,virt}-schroot is the
place for a schroot tutorial: nothing here is specific to autopkgtest.
If autopkgtest is the only use of podman by a particular uid, then
everything it works with is essentially a disposable cache anyway,
so it's OK to clean up anything that is not in active use
(`podman container prune`, `podman image prune`). However, if the same
user is using podman for other things, they might have usage patterns
where that cleanup would be undesired (like if they are keeping a stateful
"pet" container around for interactive use with podman-toolbox,
in which case `podman container prune` would result in losing that state),
so it's difficult to give a one-size-fits-all recommendation.
> 1. How does one rebuild the image, say in a weekly cronjob? Do you just
> run the same command again, and the new image will take precedence?
Yes, that should work. The tags created by a-b-podman will be changed
to point to the newer image, and the old image will hang around in the
content-addressed storage with no name (addressable only by its hash)
until it is pruned.
If a podman image is like a git commit, then you can think of podman
tags as being like git refs (they can be used like either git tags or
git branches), and I think what you are looking for in your next question
is the equivalent of `git gc`?
> 2. How do you prune ~/.local/share/containers/ to avoid it just building
> up forever?
> I found both 'podman image prune' and 'podman container prune'.
> It would be great if a recommendation could be documented.
`podman image prune` prunes unused images, which I believe means images
that have no tags pointing to them and also no container instances
running with them as the base (but I could be wrong about this, I am
not an expert on podman). If a container instance is like a schroot
session, then an image is like a stored schroot tarball: you can't enter
it directly, but you can create new container instances that have it as
their starting point. In my git-commit analogy, this is like `git gc`.
List images with `podman image list`. The ones that are listed with
repository and tag "<none>" are the ones that `podman image prune` will
try to delete.
`podman container prune` prunes container instances that exist but are
no longer running. A container instance is like a schroot session: it
has some on-disk resources, and maybe some running processes. List them
with `podman container list -a`. To continue my git commit analogy above,
you could think of a container instance as being like a git worktree with
a detached HEAD (including the checked-out source code, any uncommitted
edits, and any temporary build artifacts that might be in the tree), and
`podman container prune` is like removing all the worktrees that you're
no longer using.
When using autopkgtest-virt-podman, this command should rarely
(never?) do anything in practice, because a-v-podman runs
`podman stop $container_id` and `podman rm -f $container_id`
during cleanup. `podman stop` kills the container's processes, and
`podman rm -f` cleans up its on-disk resources, similar to `schroot
--end-session`. However, there could be stale container instances if
a-v-podman was terminated uncleanly (a crash or an unexpected system
reboot or similar).
When using podman interactively, by default the container instance will
continue to hang around after you have exited from the interactive shell
or similar, until you explicitly remove it with `podman rm`. This can be
done automatically on container exit by creating the container instance
with `podman run --rm`. I'm actually not sure why a-v-podman doesn't
use `--rm` to make its cleanup more automatic.
A typical interactive podman invocation might be something like this:
podman run --rm -it -v $HOME/tmp/exchange:/tmp/exchange:rw \
localhost/autopkgtest/amd64/debian:sid
in order to avoid the container instance being kept indefinitely.
(This also demonstrates how to use -v/--volume to have a way to copy
artifacts in and out of the container.)
On Wed, 19 Feb 2025 at 13:04:04 +0000, Ian Jackson wrote:
> To be completely clear, we would want a way to do this that will work
> correctly even if there are concurrent uses of the (old) image. Those
> concurrent uses should not be disturbed.
I believe `podman image prune` will avoid deleting images that are
currently in use as the base for a container, even if there is no longer
any tag pointing to the image. Certainly that seems to be true from a
brief experiment. Continuing the git commit analogy, this is like the way
`git gc` won't garbage-collect a commit that is checked out as a detached
HEAD in a worktree, even if it's no longer reachable from a branch or tag.
The tags that you use on the a-v-podman command-line are only aliases
(like a git branch or tag), and the "real" content of the image is in
content-addressed storage (like a git commit). I don't think the podman
CLI will let you delete it while it's still in use (certainly not without
applying some --force).
> Likewise, the cleanup operation ought not to disturb in-progress uses,
> but that'll be easier since hopefully there's an operation that will
> only want to delete "old and unused" things.
I believe the operation you want is exactly `podman image prune`, perhaps
combined with `podman container prune` if there might have been container
instances that were shut down uncleanly and are no longer wanted.
smcv
