Proposal: Use prepare.yml instead of rendering Dockerfiles with the Docker driver #1642
Comments
|
Sounds like a better approach as the bash file could easily grow insane. PS. I cannot believe someone usedcurcly braches inside foldernames... |
|
Since this is an architectural change, who is in charge now to tell me if this is worth investing the time to write a PR for? @webknjaz merged a lot of PRs and committed quite a bit recently - are you responsible for architecture too? |
|
@MarkusTeufelberger I've volunteered to help with Molecule after its acquisition, it's nowhere near my actual areas of responsibilities (which is Ansible Core Engine). And yes, I like the idea of using Ansible to pre-populate container envs. Since Molecule is tightly coupled with Ansible and targets it unconditionally it's a way to go. P.S. @ssbarnea curly braces are coming from cookiecutter project which uses jinja2 to render project templates. I cannot blame them though, it's a quite common tool for sharing project templates nowadays and I can see why they did it. P.P.S. @MarkusTeufelberger while I give it a green light as of now there's no "official" roadmap on how we think it should look later, just keep that in mind. cc @gundalow |
|
Please reopen, @webknjaz |
|
I've added this to ansible/community#427 (comment) we will have out first meeting on Wednesday 23rd at 1900UTC, calendar invite is in the agenda ansible/community#427 |
PR ansible#1649 Fedora Rawhide dropped the python2-dnf package and now has only python3-dnf one. By using a wildcard we avoid the installation failure as it will install all found versions. Signed-off-by: Sorin Sbarnea <ssbarnea@redhat.com> Closes ansible#1642
|
Let's also ping @TomasTomecek ^ |
|
Hello! Please let me know if you need any help. |
|
I'd rather use ansible native tools than require buildah on the molecule host to be honest... but ansible-bender looks like a nice project! |
|
Not sure what you mean by ansible-native tools. I don't think you need to use anything from bender directly: I'm glad to consult with you if you have any questions. Most of the relevant code is over here, I'm assuming that molecule has something very similar (and more advanced) as well. (yes, bender support only buildah now, but I'm planning to add support for docker and podman in future) |
|
I mean using a docker container as target host and using Ansible modules (e.g. |
|
To clarify: The desired output of a molecule run is either a deleted container (if it was successful) or a running container (if something went wrong or if only Currently molecule tends to clutter the local docker cache with containers it built itself. This is different than e.g. the Vagrant mode, where it will fetch an upstream "image" (called "box" in Vagrant terms), but uses this image unmodified to deploy an initialization playbook in there (to install python etc.). I'd like molecule to act similarly in Docker mode, so it never actually builds an image by itself. As far as I understand |
That's correct.
Got it, thanks for the explanation. |
|
Just to pitch in, whatever way we improve this, we'd have to cover the use case of #1810. I think users are looking for ways to customise what packages are installed without 'ejecting' and adding to the generated
Ah, that's interesting. Taking a look at it, yes, Molecule always builds an image: if you specify a |
|
I would rip out the whole If someone wants to customize something before the playbook is executed, they can customize this |
|
I would personally prefer to avoid using cookiecutter templating and use a non templated version that does the job. |
|
As long as it can be overwritten/extended, I'm totally fine with that. The more it looks like the |
|
I will close this because current behavior is to user embedded prepare.yml and internal Dockerfile template, which is good for most cases. User can still customize it needed. |
|
I obviously disagree (hence this feature request), but fair enough if you don't want to go that route. Maybe it would still be be worth documenting how to actually customize this (don't run |
|
Based on the changes being made to docker modules and ansible, I suspect it would be a nightmare to maintain prepare.yml files scattered on tens if not hundreads of repos. At the same time I kinda find hard to make molecule keep-up being a wrapper for calling these. I am open to suggestions in this tricky area. |
|
The Maybe I should just open a PR to make it a bit clearer, but I wanted to ask first if this is even desired or if docker/podman are expected and designed to be special cases in molecule with integrated templates, build steps on creation time and whatnot compared to e.g. vagrant or lxc/lxd. |
|
I plan to attempt to combine the docker and podman into a single driver that can use any of the two backends, right afater the 3.0 release. This should allow users to switch from one to another without having to touch their scenarios. Still, I am not sure if I will succeed. For arch-linux, why you are not maeing few PRs to add it to the implicit set of supported platforms? One first step would be to add it to https://github.com/pycontribs/pys and later to molecule. |
|
Molecule support for Arch docker containers in the Dockerfile was added, then removed, then re-added and then removed again in the past few years already, I found it more sustainable to maintain my own files instead of relying on built-ins. The repository you're referring to installs too many things in containers that are not related to Ansible and that might actually mask errors in roles (e.g. no task to install This change would allow me (and others) to choose an upstream base image in the |
Issue Type
Desired Behavior
Similar to Vagrant it might be beneficial to let Ansible itself install Python/Bash/Sudo/??? to various containers in a (pre-rendered)
prepare.ymlplaybook and instead using the images listed in "platforms" unmodified. The current approach (render https://github.com/ansible/molecule/blob/master/molecule/cookiecutter/scenario/driver/docker/%7B%7Bcookiecutter.molecule_directory%7D%7D/%7B%7Bcookiecutter.scenario_name%7D%7D/Dockerfile.j2 and build a custom image from that) seems a bit out of place, after all Vagrant boxes for example are also used unmodified instead of rendering out a Packer config and building the VM from scratch.The text was updated successfully, but these errors were encountered: