[mikepurvis]

The ansible-in-containers thing is very much an unsolved problem. Basically right now you have three choices:

- install ansible in-band and run it against localhost (sucks because your playbook is in a final image layer; you might not want Python at all in the container)

- use packer with ansible as your provisioner and a docker container export, see: https://alex.dzyoba.com/blog/packer-for-docker/

- copy a previous stage's root into a subdirectory and then run ansible on that as a chroot, afterward copy the result back to a scratch container's root.

All of these options fall down when you're doing anything long-running though, because they can't work incrementally. As soon as you call ansible (or any other tool), then from Docker's point of view it's now a single step. This is really unfortunate because a Dockerfile is basically just shell invocations, and ansible gives a more structured and declarative-ish way to do shell type things.

I have wondered if a system like Dagger might be able to do a better job with this, basically break up the playbook programmatically into single task sub-playbooks and call each one in its own Dagger task/layer. This would allow ansible to retain most of its benefits while not being as hamstrung by the semantics of the caller. And it would be particularly nice for the case where the container is ultimately being exported to a machine image because then if you've defined everything in ansible you have a built-in story for freshening that deployed system later as the playbook evolves.

[westurner]

With multi-stage Dockerfiles, you only copy the final, built application artifacts from the earlier stage(s). Then, building a package as one signed file to copy is justified and easier anyway.

There's always:

  RUN dnf remove -y ansible && dnf clean all 

I thought there was a native way to build container images with ansible that don't have ansible installed in the image though?

ansible/ansible-builder: https://github.com/ansible/ansible-builder

"How to Use ansible-builder to Create Execution Environments" https://oneuptime.com/blog/post/2026-02-21-how-to-use-ansibl... :

> The Build Process Explained: When you run ansible-builder build, it goes through these steps:

> Reads your `execution-environment.yml` definition, Resolves collection dependencies (including transitive dependencies), Generates a `Containerfile` in a `context/` directory, Copies dependency files into the build context, Runs the container build using Podman or Docker

How to Use Ansible to Build Podman Images > Building with Build Arguments, Multi-Stage Builds, Building with Buildah: https://oneuptime.com/#building-with-buildah :

It's possible to build images using build a commands in an ansible playbook:

  buildah from
  buildah copy
  buildah run
  buildah config
  buildah commit

.

The CLI way to traverse an ansible playbook graph, for e.g. dagger:

  ansible-playbook --list-tags 
  ansible-playbook --tags {tagname}

But where can it parallelize?

It probably shouldn't (?) parallelize because that wouldn't be a deterministic build; installing A then B is not the same as installing B then A. (Is not the same thing as installing A in one container image layer, B in another container image layer, and then trying to merge the package databases.) A given package B could conditionally install or configure according to whether or not A is already installed, and so for example package install tasks are not commutative.

.

Bootc (osbuild) builds VM and native machine images from Containerfiles:

  bootc-image-builder
  bootc upgrade 

/? bootc ansible [Debian] https://www.google.com/search?q=bootc+ansible https://www.google.com/search?q=bootc+ansible+debian

"Demonstrate a debian or arch base image" bootc-dev/bootc#865 https://github.com/bootc-dev/bootc/issues/865

Is packer necessary with bootc?

To require signatures for containers and also for native containers with bootc:

  cat /etc/containers/policy.json | grep sigstoreSigned

  podman image trust show --raw

Here's this on ansible, dagger, bootc: "Public link: Dagger for Programmable CI/CD" https://gemini.google.com/share/3965633a3ff8