...
...
TODO: need to figure out how we can roll out the ansible playbooks, for something like buildroot , like
- Do we want it specified in the manifest (BOM) of the app
- or do we want to have predefined playbooks for the control node and we just pass in arguments depending on the system
- Ex use case: if a package needs updating, we just give an installer and some arguments like a filepath, and ansible will automatically handle that. A passive system if you will (it'll modify whenever changes are detected)
- Ansible (control nodes) in containers - Ansible ecosystem documentation
Image Added - There is built-in support for ansible in containers which is good for our build system so we can run on the ad-build cluster like everything else
How to make execution environment Introduction to Execution Environments - Ansible ecosystem documentation
- Then you would have to use ansible-navigator to actually run any playbooks against the execution environment. Think of it like this: one main controller/container that has ansible-navigator, which creates jobs that runs playbooks to other ansible runners (containers that run once and are killed once completed).
- Potential problem: seems like this is only useful if you have the redhat automation controller 15. Execution Environments — Automation Controller User Guide v4.5 (ansible.com). And we are moving to rocky linux so may be an issue
- Potential solution: There is an open source automation controller Ansible AWX | Ansible Collaborative, which theoretically achieves the same goal as redhat automation controller, but its backed by the community rather than redhat
- This provides web UI, REST API (for our backend to communicate/cli with), and task engine (to manage jobs/playbooks)
- We may or may not need a fancy automation controller, if we did we'd use the open-source AWX
- What we will have is any change to configuration (Deployment database) through the CLI, would send a push event to the ansible controller, then that could start the playbooks.
- And can have a slow loop that checks if the configuration actually matches whats deployed out there.
- SLAC IT for example has an ansible configuration setup, they have all their playbooks in one repo, and a bunch of configuration files. Then they run it when they need to.
- TODO: to get started - create basic playbook with placeholders for like cvs stuff or anything that you dont want affected on servers.
- This playbook will be used to deploy IOCs on dev or production. so like all the steps you do manually should be on a script, and into a playbook.
- This should start from the CLI with 'bs run deployment <arg> <arg>' like specifying dev/prod and/or ioc name