-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
epic: no python in the target image #49
Comments
@ipbabble hi, I opened this issue to track the work on the |
@TomasTomecek I'd like to review the ansible-bender work and see where we can make modifications to allow for from scratch. Yes a call would be useful in helping me zero in on the appropriate code. |
Stumbled across this - I have this sort-of-working, insofar as using I'm using this with a base image that I create by using |
Update: tried hacking the buildah builder to always aver that |
@jordemort thanks for the update, that's really interesting! I agree that we should make bender work with the scratch image - people should still be able to run Edit: doesn't make sense to create a new one, my original post has it all. @jordemort thank you for your effort! Please let me know if there is anything I can help with. |
Having a
into Ansible much easier. I would rather not have to use a tarball to create scratch containers when DNF can install the packages I need on the fly. |
I was expecting to see in the output the environment var passed in through @TomasTomecek I'm asking this to see if it's currently possible what you suggest as an easy solution to build containers from scratch.
|
That sounds like a bug, could you please open a new issue for that?
That's really just an idea, honestly. You'd need to prepare the |
Meanwhile, would it be possible to provide an option to run a startup command when we start the container? This way I am able to install python. |
Could you please describe the use case in more detail in a separate issue? I recall that doing such a thing in |
I am very interested by this. I can't use the layer mechanism right now as I raw install/uninstall python. My builds take 5 minutes to run and it is too long for my Twitch viewers :) |
Hi, I'd like to understand potential workarounds, I didn't fully understand the proposals above. The only thing that works for me (up to now) is to use a simple Dockerfile to build a local image with python3 on top - and use that as baseline for ansible-bender. That's somehow a bit ugly? Something like --init-playbook or raw pretask sound cleaner (besides they still would install python3 into the container, but hey..)
Hopeing there is cleaner, managable approach that i oversaw. Thanks! |
@Trashmee how exactly are you feeding that locally created docker into ansible-bender? Can you share the command line? |
There is a demand to be build container images with bender without the need of python in the base image.
There are multiple ways of doing this:
ansible-container mounts the interpreter inside the target environment (prone to errors, kinda hacky)
Barak Korren suggested to use the raw module to install python beforehand and uninstall it once the build is done (waste of resources, had to be only a single layer)
support builds from scratch (
buildah from scratch
) and then utilize the chroot connection plugin or a similar workflow, where we would use python on the host and populate a certain path (might require changes in playbooks, dunno if this is possible now)Edit: adding more details
For the
from scratch
part, we should likely start with a research how feasible it is.If we want to utilize chroot connection, we need python interpreter inside the container. The interpreter can be bind-mounted from the host system, but that's pretty nasty.
If we want to do local connection, the playbook needs to look in a certain way: e.g. we want to do
dnf install --instalroot /path/to/the/container
where ansible-bender would likely provided the/path/to/the/container
variable. Then we might even need a second playbook which would be executed inside the just-provisioned environment (using connection buildah or local). Now that I just wrote it, I kinda like the approach. We could keep the current interface and just add a new option which would be a path to playbook to do thefrom scratch
work. Example:With this command, ab would ran the init.yaml playbook using connection local and provisioned the scratch container:
And then we would continue as we do now: we would use the playbook.yaml and using the buildah connection we would run against the
{{ container_root }}
. Hm, but that still requires python inside the container.The easiest short-term solution I can think of is to provide a variable with the scratch mount and let people structure their playbooks around it. So instead of doing:
do
and bender would provide execute the playbook like this:
scratch is not a real image, it's a "keyword" for buildah:
The text was updated successfully, but these errors were encountered: