ansible-builder 3.0 feature branch

[nitzmahone]

A 3.0 evolution of ansible-builder to address a number of pain points with current ansible-builder:

• Allows use of vanilla RHEL-ish container images instead specially-crafted images- check out demo/v3_demo/execution-environment.yml for a working sample tested with Fedora, CentOS Stream 8/9, UBI9...
• Allows injection of custom before/after build steps at every build stage.
• Allows copying arbitrary files from the builder host into the generated container build context (which can then be copied into intermediate/final container images as needed with custom build steps).
• Allows declarative bootstrapping of Python, Ansible Core, and Ansible Runner (in addition to roles/collections, of course).
• Allows inline definition of EE Python/bindep/role/collection requirements.
• Allows customization of ENTRYPOINT and CMD.

[Akasurde]

Since we are here, can we think about -

1. Adding custom scripts specified by users to perform actions which can be before/after galaxy command, before/after specific workflow like start/end of the build - feature request: ability to execute commands BEFORE ansible-galaxy run #293
2. Possibility of specifying Custom CA certificates (required for private galaxy/automation hub) either by copying or mounting volume mounts - need to support custom CA certificates and proxy settings #195

[cidrblock]

3 questions while I think of them,

Can the build def be left in the EE?
Can we produce a 2nd EE with dev tools?
Can the results of a deep introspection of the EE be left in the EE post build (docstrings, python packages, system packages)?

Here is how navigator introspects the image today: https://github.com/ansible/ansible-navigator/blob/main/share/ansible_navigator/utils/image_introspect.py

Collection/plugin are "cached" but here is how they are cataloged, note ansible-doc wasn't used here due to the need to show shadowed collections: https://github.com/ansible/ansible-navigator/blob/main/share/ansible_navigator/utils/catalog_collections.py

[nitzmahone]

@cidrblock

Can the build def be left in the EE?

eg the source execution-environment.yml that builder consumed? Sure, should be pretty easy. I assume no problem there if an EE is used as the base for another EE, that the resultant build def in the final EE would be "last writer wins"- that's technically accurate anyway I guess, since that's what you'd use to re-create that EE... 😆

Need to figure out where to dump it (and the related deep introspection below, assuming we do it). Something like /etc/ansible/ee-def.yml?

Can we produce a 2nd EE with dev tools?

Technically yes, but it seems like a slippery slope. include_devtools: yes turns into "I want to install a custom build of the devtools from $private_git_repo that I need to auth to", and generating two copies of the build context, accepting two copies of the tags for build and munging them appropriately- I just have trouble seeing how the UX doesn't go south in a big hurry. Also, not sure which all tools you're looking to include, but if navigator is one of them, it's likely going to need to be isolated (eg, installed in a venv or something) to avoid trashing Python deps...

Can the results of a deep introspection of the EE be left in the EE post build (docstrings, python packages, system packages)?

Yes, I think that would be a reasonable thing, though we'd need to talk through how we'd version that format and where the thing that creates it will live...

[nitzmahone]

@Akasurde

Adding custom scripts specified by users to perform actions which can be before/after galaxy command, before/after specific workflow like start/end of the build - #293

Yes, I've been assuming we'd add pre/post hook steps for the Galaxy and Build stages (and maybe more)- I'd probably just do arbitrary steps to replace the existing additional_build_steps, but a related need there is to be able to add arbitrary files to the context... eg, awx-ee already does something that I can't see how it possibly works: https://github.com/ansible/awx-ee/blob/devel/execution-environment.yml#L14-L15 - run.sh is in the root of the project, so builder has no idea it needs to copy that file to the context- it's not parsing the steps (nor should it). Maybe it works because runner already put /run.sh there? Dunno, but having a way to get runner to add files to the context and then specify arbitrary pre/post steps for the different build stages would allow for scripts, commands, even private stages if someone was clever enough (or builder forced the issue by explicitly switching back to the previous stage after executing those hooks).

Possibility of specifying Custom CA certificates (required for private galaxy/automation hub) either by copying or mounting volume mounts - #195

I think this could also be accommodated for build-time stuff with the pre/post Galaxy steps I mentioned above- the implementation would likely be highly dependent on knowing where the base OS image hangs its certs, so we probably don't want to provide a high-level interface for doing so, but having the ability to inject extra steps and files into the context should cover that need.

[ffirg]

The biggest user experience pain point challenge we get is using builder tooling in a disconnected environment. Can we consider this in the architect up front? We'll need options to be able to NOT pull from the internet for deps etc.

I'd also like to get any container builds resulting from this put through the RH deptopia mill as this is or is becoming the SoT for container imaging introspection and is currently presenting a gap challenge for productization @Spredzy FYI

[ryanmerolle]

I'm happy to test this when ready in a working state.

[Akasurde]

Suggested change

	# NOTE(pabelanger): Ensure all the direcotry we use exists regardless
	# NOTE(pabelanger): Ensure all the directory we use exists regardless

[AlanCoding]

How is this going? It's likely that in the next 1-2 months we'll have to add some hacks to the awx-ee in order to start moving new features into the community that require new Ansible / runner, and @shanemcd has approaches that would work, but we would prefer to work this into it instead.

[ryanmerolle]

I hope this will allow the usage of overriding the default yum repos. The assemble function overwrites all my internal yum proxy details which would likely be an issue for those with air gaped environments.

[nitzmahone]

@ryanmerolle yes, it will be possible (and much easier) to do so with explicit pre/post stage tasks for each build stage, but we probably won't add an explicit first-class feature for declarative repo management (starts to duplicate a lot of Ansible itself there 😆 )

[ryanmerolle]

Well I know you guys have been hard at work. I appreciate the update!