Using standard configuration management tools instead of bash scripts can improve reliability for this project.
I suggest slowly moving from this collection of bash scripts to an Ansible system.
It doesn't have to be a traditional Ansible system where it configures multiple servers at the same time. Ansible can configure the system that it's running on (localhost).
The question is, what should be the strategy to move towards the system and make it for your existing users of compass?
I suggest making it such that an initial script is run which runs an installation of uv, which is a Python virtual environment manager.
Then, uv is used to run Ansible, where we actually lock the version of Ansible used and any other Python dependencies if required.
And then we slowly replace many of our scripts and configs with Ansible playbooks that run against localhost.
Ansible has lots of built-in features that allow us to rely on that for interacting with operating systems, configurations, and templating configurations.
Ansible also allows us to implement something called idempotency. It also has testing.
The new deployment can work like this:
- Initial bash script that installs uv
- The project will then have a uv.lock file as well as a Python project definition with defined dependencies such as ansible.
- The script will then run Ansible from within uv using uv run.
- Ansible will then configure the server based on a better yaml definition for the server
- If a transition is required from env to YAML, we can write a small Python script that can take care of that.
For a step-by-step transition, we can migrate each component and replace the bash script with a call to uv run ansible name-of-playbook.yaml
Using standard configuration management tools instead of bash scripts can improve reliability for this project.
I suggest slowly moving from this collection of bash scripts to an Ansible system.
It doesn't have to be a traditional Ansible system where it configures multiple servers at the same time. Ansible can configure the system that it's running on (localhost).
The question is, what should be the strategy to move towards the system and make it for your existing users of compass?
I suggest making it such that an initial script is run which runs an installation of uv, which is a Python virtual environment manager.
Then, uv is used to run Ansible, where we actually lock the version of Ansible used and any other Python dependencies if required.
And then we slowly replace many of our scripts and configs with Ansible playbooks that run against localhost.
Ansible has lots of built-in features that allow us to rely on that for interacting with operating systems, configurations, and templating configurations.
Ansible also allows us to implement something called idempotency. It also has testing.
The new deployment can work like this:
For a step-by-step transition, we can migrate each component and replace the bash script with a call to
uv run ansible name-of-playbook.yaml