Add a local Ansible provisioner or option

[kevcenteno]

Vagrant has an option to run an Ansible playbook locally / run Ansible within the guest VM. This requires a default share (maybe we set this to /lxdock).

Does this sound like something we'd be interested in for this project? If so, would we want this to be a separate Provisioner class, or set it as a side option like the Shell provisioner?

[shuhaowu]

Yes. I want to do this for a while now. It seems wrong to copy your pubkey into the container and also introduce some unnecessary dependencies (a pubkey specifically at ~/.ssh/id_rsa

[shuhaowu]

That said, ansible local requires ansible to be installed in the container, which has its own disadvantages.

[kevcenteno]

Another potential issue is how do we go about monitoring the guest-side Ansible output.

[robvdl]

Running commands inside containers and getting the output isn't the nicest currently, I'm trying to fix issue #129 as well which runs commands inside the container using lxdock shell -c command. Basically a shell script is created and put onto the container and then run, I'm not sure if this is absolutely necessary but this is how that is currently working.

But yeah this means getting Ansible onto the container and I am not entirely sure if this should be core behaviour, but I am open to developing some kind of plugin system maybe.

Otherwise you could have a shell provisioner and have a small shell script that installs Ansible and invoke playbooks inside the container.

The first thing I want to see fixed is not run Ansible as root anymore, that is a bit of an issue as well because that is not how Vagrant executes Ansible by default (sometimes I like to share playbooks between Vagrantfile and lxdock.yml in a project and having one use root by default is not great). Doing Ansible as root by default is quite bad really.

[shuhaowu]

I mean ansible itself is not really that core as it is a part of the lxdock/provisioners. The ansible_local provisioner can do the same.

The reason we should probably include this as a part of lxdock is that it would simplify setting up a dev environment as other developers no longer need to install ansible in their host setup. In fact I've used this exact functionality via vagrant.

What would be interesting is being able to load this kind of stuff via python's entry_point mechanism so then other people can create packages like lxdock-saltstack or whatever and lxdock can dynamically load it in. I can brainstorm the plugin system in another issue, tho.

[kevcenteno]

Ah, I agree that getting output from the guest is a high priority, regardless if it's from the Shell or some other provisioner. Currently, it's a bit of a mystery to see if a Shell provision executed correctly or not.

[kevcenteno]

With that said, does it make sense to have a default share set up, like how vagrant does with /vagrant?

[robvdl]

Could that tie into having a default user lxdock as well if no users are defined.

Another thing that vagrant does is setup passswordless sudo for the vagrant user, which I currently do with Ansible.

[kevcenteno]

I think the tie-in with a default lxdock user makes sense... but I think this user should be set regardless if a user or users are defined by the user. This gives us a reliable non-root user to run provision tasks.

[robvdl]

mm yeah that is where I wanted something slightly different, I wanted my app user to be the default user instead of lxdock. My initial suggestion how to handle this was to have default: yes on one of the users (which is optional) if you wanted to override the default and only then it wouldn't create one called lxdock but @shuhaowu convinced me to use the first user in the list instead.

[kevcenteno]

A default: yes user option makes the most sense to me, especially because I alpha-sort my users; "first user is default" breaks this.

[robvdl]

Yeah it really does sound like the best option to me to be able to say which user is the default user for each container. If they have a bunch of users defined in the lxdock.yml and none of them are default, then it's going to end up creating the lxdock user.

I'm not sure yet about automatically creating a share though, I guess one way we could maybe do this is only setup a /lxdock share if there are no shares defined, but if the user has their own shares defined then don't do this. You can always setup this share yourself though, it's only 2-3 lines in the lxdock.yml.

[kevcenteno]

Is there a particular reason not to automatically set up a default share? Vagrant does this by default, and the user has to explicitly unset this default share: https://www.vagrantup.com/docs/synced-folders/

One advantage of this is that it's less setup for a local Provisioner, since it assumes it's running out of the default /vagrant share.

[robvdl]

I was thinking if you don't want your source to be mounted there, I have mine as /src/appname.

That is why I was thinking maybe if a share to "." already exists it won't create a second one, or maybe it should, I don't know.

I suppose I can get used to using the location /lxdock if needed.

[robvdl]

It would keep things simpler if I just changed my workflow and start using /lxdock.

I haven't actually tried to mount "." in two places, it would probably work fine.

[kevcenteno]

That's fair. I prefer working out of the home directory of the vagrant user. I wonder if mounting in two places would break things?

[shuhaowu]

The home directory/default user seems to be another issue. Can we track that in another issue instead?

[robvdl]

Moved default user discussion to issue #133

[kevcenteno]

I would say that this blocked by #133