Add Ansible Tasks to Configured Server

[JoelProminic]

From @JustinProminic

-- a new button for an already running/created server to download a GitHub repository and execute its custom ansible task. The goal of this is to within 2-3 MINUTES of effort merge the changes from each developer's unique responsibility for the overall project. It should not involve creating a fresh Domino server each time. To accomplish this, two things need to happen:
a) Mark needs to create a custom ansible runner and make it part of the "core" demo-tasks

b) Piotr needs to add a button and logic to request the URL (and maybe even save recently used ones so the user doesn't need to keep pasting it each time?) ... not sure how GitHub authentication can be handled for private repos, so Adrian will need to chime in on that and make that part easy

So, for example, the recent Nomad link update development might have looked like this:

1. Super.Human.Portal would be already setup with Ansible tasks to install the development version. This could include compilation to avoid miscommunications on the build process
2. Piotr makes the initial changes in a branch and reports the CORS errors to me
3. I link the reposiotry to a new or existing server and switch to the branch. I would then run vagrant provision to install the update
4. I experiment with changes to the CORS headers until I have something that I want Piotr to test
5. I update the ansible script so that it will apply my settings in haproxy.cfg and commit my changes
6. Piotr pulls my changes and runs vagrant provision to apply the changes
7. The back and forth continues until we are satisfied
8. We ask another user to test
9. That user links the repository/branch to a SHI server and runs vagrant provision to get to apply the update.

Some potential problems:

• Developers will need some familiarity with Ansible. Hopefully most of the cases could be handled with copied snippets, but in a complex case the Ansible scripts could take longer to write than the code change itself.
• The additional tasks will need to be carefully designed so that they don't interfere with other provisioners working against the same files (like haproxy.cfg). Again, hopefully we can rely on some good snippets for this
• The core Ansible tasks will need to be designed to not reinstall applications (i.e. Domino) if not needed. This should already be the case, but we may find problems as we do more provisioning.

@MarkProminic, we could use some help getting started with this when you have some time:

• Demonstrating how to modify the configuration files on the host to include external ansible roles
• Helping build up some snippets for common actions. We can also review the existing provisioners and Ansible examples for this, but some help getting started would be appreciated.

@piotrzarzycki21, you can work on the UI for this once we have a plan of how to handle this on the Ansible side.

[JoelProminic]

The MXHX project would be a good example to start with on this. The haproxy changes are described in this issue, but I can help organize this if needed.

[JoelProminic]

Here is how I envision the process from the Super.Human.Installer UI, based on today's discussion:

1. Find the desired VM in SHI
2. Click a button like "Custom Provisioners"
3. Display a list of the current custom provisioners for the VM
4. Click Add
5. Allow the user to specify the custom provisioner:
   1. Clone from Git
   2. Select local directory (which may already be a Git clone)
6. Save the new custom provisioner
7. Select one or more custom provisioners and click "Run"
8. Run a command to execute only the selected provisioners. We'll need to work out the details with @MarkProminic.

[MarkProminic]

For the most part yea that looks right, here is more what I would expect for us internally to share projects

$NAMESPACE = custom
git clone https://github.com/Moonshine-IDE/moonshine-vagrant-mxhx-demo
mkdir provisioners/ansible/ansible_collections/$NAMESPACE
cp -r roles $INSTANCE/provisioners/ansible/ansible_collections/$NAMESPACE/moonshine-vagrant-mxhx-demo/roles
cp galaxy.yml $INSTANCE/provisioners/ansible/ansible_collections/$NAMESPACE/moonshine-vagrant-mxhx-demo/
nano Hosts.yml
insert into roles:
- name: $NAMESPACE.moonshine-vagrant-mxhx-demo.mxhx
vars: any vars here
vagrant rsync
vagrant provision

[JustinProminic]

Mark wrote:

To run an Ansible playbook locally, follow these concise steps:

Install Ansible on your local machine.

Create a simple inventory file (e.g., hosts) with:
localhost ansible_connection=local

Run the playbook with:
ansible-playbook -i hosts your_playbook.yml

This executes the playbook on your local machine without SSH, using the local connection type.

[JustinProminic]

Mark said all S.H.I. VMs already have Ansible installed, so you can ignore the "Install Ansible on your local machine." line above.

[JustinProminic]

Mark clarified these commands need to happen INSIDE the S.H.I. VM so SSH into it first:

Create a simple inventory file (e.g., hosts) with:
localhost ansible_connection=local

Run the playbook with:
ansible-playbook -i hosts your_playbook.yml

[JustinProminic]

The "hosts" file referenced above you can really think of as more like "ansible_hosts" and is NOT related to /etc/hosts in the S.H.I. VM.

[JoelProminic]

The example command above didn't work without creating an inventory (-i hosts expected an inventory file or directory at hosts). I also found that using localhost from an inventory required authentication, which required setting up private key authentication. This is not hard, but Mark and I found this trick to run a script locally without an inventory:

Create playbook.yml with these contents. Note that hosts is set to localhost:

- name: My first play
  hosts: all
  tasks:
   - name: Ping my hosts
     ansible.builtin.ping:

   - name: Print message
     ansible.builtin.debug:
      msg: Hello world

Then run:

ansible-playbook playbook.yml

Note that this gives a warning about localhost. We may be able to fix it with this setting.

Note that this does not reuse anything from the SHI provisioners.