Feature Request: GO:Embed about go-ansible HOT 12 CLOSED

@apenella how i achieve my goals currently. I embed a folder that contains all scaffolding for Ansible. When binary is actually used by a customer the files in the binary are then placed on to disk AND THEN go-ansible is initiated. I would prefer that i need not copy to disk but just use from the embed.FS.

Thanks

from go-ansible.

The idea is to reduce the visibility and files that a potential customer can see and work with.

from go-ansible.

I like this idea as well

from go-ansible.

@renepardon I have been thinking about it and you don't need to write a custom executor, indeed. I wrote an example that uses an embed fs, you can take a look at #119

I'm not sure if the example is similar to what @jessequinn implemented. If you compile the example's code, you can execute it from somewhere else and it will work as expected.

That is the output of one execution:

❯ /tmp/ansibleplaybook-simple-embedfs
Copying file from the embeded filesystem 'embedfs/inventory.ini' to '/tmp/ansibleplaybook-simple-embedfs-3664130936/inventory.ini'
Copying file from the embeded filesystem 'embedfs/site.yml' to '/tmp/ansibleplaybook-simple-embedfs-3664130936/site.yml'
Copying file from the embeded filesystem 'embedfs/site2.yml' to '/tmp/ansibleplaybook-simple-embedfs-3664130936/site2.yml'

PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [127.0.0.1]

TASK [ansibleplaybook-simple] **************************************************
ok: [127.0.0.1] => {
    "msg": "Your are running 'ansibleplaybook-simple-embedfs' example"
}

PLAY RECAP *********************************************************************
127.0.0.1                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0


PLAY [all] *********************************************************************

TASK [ansibleplaybook-simple] **************************************************
ok: [127.0.0.1] => {
    "msg": "Your are running 'ansibleplaybook-simple-embedfs' example on site2.yml"
}

PLAY RECAP *********************************************************************
127.0.0.1                  : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

I like that idea because embedding the ansible code into the binary would allow anyone to create more portable solutions. However, I see that feature as a responsibility of the application side, not the library. The library should focus on providing generic functionality that can be used across different applications, while application-specific features should be implemented in the application code itself.

What are your thoughts?

from go-ansible.

Hi @jessequinn
I hope to start working soon on new features for go-ansible. Amongst those features, I would like to write a container executor, but I guess that it wouldn't solve the scenario you have in mind, am I right? However, I keep your suggestion and I will think about how it would fit in the library.
Thanks!

from go-ansible.

Can you give a hint where to start or how you would do this @apenella ? Maybe I could work on a pull request for that one..

from go-ansible.

Hi @renepardon
Thank you very much for your interest.

I'm not entirely convinced about this feature yet. I haven't used the embed.FS package before, but my understanding is that it requires you to define the files or folders you want to load directly in the source code. This would mean creating a fixed folder for all scaffolding files for Ansible, which could create unnecessary coupling with the library. I'd prefer to avoid this if possible.

However, the go-ansible library does offer a possible solution: it allows you to define a custom Executor. One approach to solving this issue could be to define a custom Executor in your application that uses go-ansible, and include the embed.FS package within it. This would provide a way to load the necessary files without coupling your application to the library.
I guess that you can create a custom Executor from the default Executor.

As I mentioned earlier, my lack of experience with embed.FS may have resulted in an incomplete or inaccurate response. If you have any suggestions or alternative solutions, I would be glad to discuss them further. Thank you for bringing this to my attention.

from go-ansible.

Hi @apenella

I just started with Go at all ;) So I might not be the correct person to explain everything in detail already but the embed.FS is pretty nice because the files are included into the final binary. I could imagine the playbook files to be embed so a third party can not read those playbooks (or other files)

I also used it already to embed Javascript/HTML files or SQLite3 migration files.

So creating a custom executor which reads and executes the playbooks from embed would work?

from go-ansible.

Thank you very much for the example @apenella
So there is no way around and the files - even if embedded - needs to be copied to the file system?

from go-ansible.

Since Ansible requires the playbook and inventory files (the inventory just when you specify the inventory in a file), you need to make those files accessible to it when it is being executed. I found the solution of copying the files into a tmp directory pretty straightforward.

I have not explored how feasible could be other options such as creating anonymous files in memory with the memfd_create or even using the ExtraFiles attribute (defined in the os.exec Cmd struct) to provide those files. Nevertheless, those solutions also would require copying the files from embed fs to memory or somewhere else.

That's another reason why I am not convinced to include that feature in the library because each application may have different requirements and preferences on how to use the embedded FS.

from go-ansible.

Hi @apenella

ok, makes sense. I will have a look at the anonymous files then.
I mean, doing a memory dump will also be possible but the level of required experience is way higher already than it is for opening a file and read it.
If I can not get it to work with anonymous files I might consider using Ansible Vault for more than just secrets.
ExtraFiles is not supported on Windows. My use case is to support all three main OS’es.

from go-ansible.

Hi! @jessequinn @renepardon
Unfortunately, I will discard this proposal. The reason is that the go:embed package requires a static definition of files or directories and I want to avoid that. IMHO, and as I previously said, it is preferable to define the embedded filesystem on the caller end, who knows more about the application requirements.

On the other hand, I am about to start to work on a new feature to add vaulted variables as extra-vars #121, It would help you if you needed to deal with vaulted variables.

I am glad to know that the go-ansible library helped you.
Thank you very much for your proposal!

from go-ansible.