Skip to main content

Better support for adhoc ansible runs

Feature Requests

As an infrastructure owner, I would like to be able to execute arbitrary ansible playbooks using an existing ansible stack.

Spacelift currently locks each stack to a single playbook, which makes it difficult to make use of ansible’s full capabilities for managing the operating systems and applications on our EC2 infrastructure.

Workaround
Problem
Status: 🔭 Discovery3 comments

Log in to comment and vote

Comments3

  • Sapphire Pinwheel

    •

    Apr 21

    This is a similar feature we would love to see get more attention. This is akin to “day 2” actions that we are trying to develop for this such a purpose. Having the ability to run tasks on a given EC2 in an adhoc fashion would be greatly beneficial.

  • Green Rice

    •

    Feb 25

    Coworker of Sofia here. Tasks may be a suitable alternative. When running an Ansible playbook in a stack task, it doesn’t provide the same benefits as running in a tracked run. When running an Ansible playbook from a task, the stack’s resources are not updated. For example, if I ran Ansible playbook as a task against a new host in Ansible inventory, that host would not appear as a resource. Additionally, if I execute a playbook as a task against an existing host in resources, the execution history (and configuration management view) are not updated for that host.

    In our use case, we have the Spacelift stack act as the Ansible execution environment for a single application environment. The stack would be aware of all of the Ansible executions (including tasks) from the resource/host configuration view. If stack owners are running ad-hoc playbooks in tasks that don’t appear in the resource view, then it become difficult to know what playbooks have run for individual hosts (which is valuable to us).

  • Black Breeze

    •

    Feb 24

    Thanks for taking the time to write this up Sofia! I’m wondering if you had a chance to look into the Tasks functionality in Spacelift? This is our mechanism specifically designed to run ad-hoc operations safely. It was initially implemented mainly for Terraform state management but in principle I can’t see why it couldn’t be extended to your Ansible use case.

    Unless there’s something that I’m missing, for which I apologize - it’s been a while since I did Ansible in anger. Not sure if you’re planning to attend the dinner with us later this week - if so, we can discuss directly.