I am trying to automate the creation of postgresql services on a shared postgres Server as my target.
we create an .env file for each service on the target with contains the portnumber used for that particular instance. Based on that I detect the largest currently reserved postgres port.
I can detect that number by this command on that host (not knowing whether this is the most scientific way to do this, but it works).
It is worth mentioning that port scannic with i.e. netstat can not be utilized because it is possible a service may not be running at the time of play which might return a false result.
Now I want to create a vairable pg_service_port for my playbook with the next larger number detected (if the above returns 5433 the new value 5434 (5433 +1) shall be applied for the current run.
can somebody kindly point me to the right approach for such an endeavour? I could imagine debug may play a role in this but don't really have much of a clue with it.
Instead of fragile grepping for port numbers in files that someone (you?) put somewhere and then incrementing those - why not just configure this yourself in the playbook?
You then have a single source of truth.
Thanks Vladimir ... that looks pretty sophisticated (almost out of sight-ish) ... but could be a nice challenge to even understand what is going on
so far I detected one challenge. Maybe my initial question has not been sufficientely explicit with this.
I run this against a single host that has a couple of paralles postgres services running.
The pg-somename.env files, defining the port for each instance which I want to use to detext the next free port are located in the same folder and the only thing I can tell about the filenames is that they follow a pg*.env naming pattern.
as far as my experiments with fetch go it is not able to interpret such a pattern in the way regular bash (find, cat, less, ..) does. So the TASK below does not localize the files I am looking for.
- name: fetch all .env files to fetched
ansible.builtin.fetch:
src: /opt/db/postgres/bin/.pg*env
dest: fetched/
flat: true
become: yes
is there a trick to make this work? A colleague mentioned using the find module in order to creating a list for a loop precedding a fetch might be possible. But that seems to be pretty hairy as well.
this is how I manged this in the end. probably the solution suggested by @Vladimit Botka is more scientific but I could not indorporate the find operation required with the rest of the suggestion