Ansible ist eines der bekanntesten und am weitesten verbreiteten IT-Automatisierungstools. Es hilft uns bei der Automatisierung von IT-Betriebsaufgaben wie ...
- Bootstrapping des Hosts (VM oder Bare-Metal-Maschine) von Grund auf neu
- Konfigurieren von Hosts und Diensten
- Verwalten von Softwarebereitstellungen und Upgrades
- Ansible bietet auch Unterstützung für die Orchestrierung der Cloud-Infrastruktur, z. B. das Erstellen einer Reihe von EC2- und RDS-Instanzen für Ihre Anwendungen in öffentlichen Clouds (AWS, GCP, Azure). Mehr zur Cloud-Bereitstellung finden Sie hier
Da es in diesem Blog hauptsächlich um die Verwaltung von PostgreSQL mit Ansible geht, gehen wir nicht näher auf die Verwendung von Ansible ein, sondern gehen auf einige Grundlagen von Ansible ein. Ich empfehle, den Link zum Ansible-Dokument durchzugehen, wenn Sie mehr darüber erfahren möchten.
Ansible-Grundlagen
Ansible ist ein in Python geschriebenes Open-Source-Projekt, dessen Quellcode auf GitHub verfügbar ist. Da es sich um ein Python-Paket handelt, können wir Ansible einfach mit pip installieren.
Ansible muss auf nur einem Host installiert werden, von dem aus wir unsere operativen Aufgaben mit Ansible-Befehlen (Ansible, Ansible-playbook) orchestrieren. Wir nennen diesen Orchestrierungshost den Kontrollknoten.
Ansible-Befehle verwenden OpenSSH-Bibliotheken, um sich bei den Zielhosts anzumelden, um operative Aufgaben auszuführen, wir nennen diese Zielhosts Managed Node. Der Hostname oder die IP des verwalteten Knotens werden in einer Datei namens Inventory erwähnt, dieser Inventardateiname wird dann als Eingabe für die Ansible-Befehle angegeben.
In der Bestandsdatei können wir mehrere Hosts unter einer einzigen Gruppe auflisten, wodurch vermieden wird, dass dieselben Aufgaben mehrmals für verschiedene Hosts wiederholt werden. Weitere Einzelheiten zur Verwendung der Inventardatei finden Sie hier.
Da der Ansible-Befehl SSH für die Anmeldung verwendet, muss Ansible nicht auf allen Hosts installiert werden, sondern nur auf dem Steuerknoten. Auf allen Kontrollknoten und verwalteten Knoten sollten jedoch Python und alle erforderlichen Python-Bibliotheken installiert sein. Mehr zur Ansible-Installation finden Sie hier.
Für die Demo verwende ich einen Laptop als Kontrollknoten und eine CentOS-7-Gast-VM als verwalteten Knoten. Die CentOS-7-VM wurde mit Vagrant auf dem Anbieter VirtualBox bereitgestellt.
Ansible auf dem Kontrollknoten installieren
Wir werden Ansible mit pip installieren, wie auf der Ansible-Dokumentseite angegeben. Die folgenden Befehle wurden als „Ansible“-Benutzer ausgeführt.
$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ python get-pip.py --userMit der Option --user werden pip- und Ansible-Befehle im HOME-Verzeichnis installiert, und wir müssen den bin-Pfad zu unserer PATH-Umgebungsvariable hinzufügen.
$ echo 'export PATH=$HOME/Library/Python/2.7/bin:$PATH' >> ~/.bash_profile
$ source ~/.bash_profileDer folgende pip-Befehl hat Ansible Version 2.8.0 installiert (das ist die neueste stabile Version zum Zeitpunkt des Schreibens dieses Blogs.)
$ pip install --user ansible
$ which ansible
/Users/Ansible/Library/Python/2.7/bin/Ansible
$ ansible --version
Ansible 2.8.0
...
... Kontrollknoten- und verwaltete Knoten-Vorabprüfungen
Stellen Sie sicher, dass zwischen dem Kontrollknoten und dem verwalteten Knoten eine ordnungsgemäße Netzwerkverbindung besteht.
Überprüfen Sie Ihre Firewall auf Regeln, die möglicherweise eingehende und ausgehende Verbindungen am SSH-Port blockieren. Wenn dies der Fall ist, öffnen Sie den SSH-Port, um Zugriff sowohl auf die Kontrollknoten als auch auf die verwalteten Knoten zu gewähren.
Versuchen Sie zunächst, sich über SSH mit dem verwalteten Knoten zu verbinden. Sie sollten sich vom Kontrollknoten aus beim verwalteten Knoten anmelden können.
Sie können den kennwortlosen SSH-Zugriff auf die verwalteten Knoten gemäß den Sicherheitsrichtlinien Ihrer Organisation einrichten. Für diese Demo habe ich passwortlos für SSH zu meinem verwalteten Knoten „pg01“ (CentOS-7) für den Benutzer „vagrant“ konfiguriert. Dadurch hat der verwaltete Knoten die Sudo-Berechtigung, die meisten Installations- und Hostkonfigurationsaufgaben werden als „vagrant“-Benutzer mit „sudo“ ausgeführt.
Auf dem Kontrollknoten haben wir die Konfigurationsdatei ansible.cfg, die von den Ansible-Befehlen verwendet wird. Nachfolgend sind einige Konfigurationsoptionen aufgeführt, die in der Konfigurationsdatei definiert sind. Um mehr über die anderen verfügbaren Konfigurationsoptionen zu erfahren, sehen Sie sich die Beispielkonfigurationsdatei an.
- remote_port – Wenn der SSH-Server auf dem verwalteten Knoten auf einem anderen Port als dem Standardport 22 läuft, können wir ihn ändern
- remote_user – Der Login-Benutzername, der von Ansible zum Verbinden des verwalteten Knotens zum Ausführen der Aufgaben verwendet wird
- private_key_file – privater SSH-Schlüssel, der für die Anmeldung bei Ansible verwendet wird
Da die oben genannte Konfiguration global für alle verwalteten Knoten gilt, können wir, wenn wir eine andere Konfiguration für einen bestimmten Host oder eine bestimmte Hostgruppe haben möchten, diese in der Bestandsdatei angeben. Ein Beispiel dafür sehen Sie unten in der Inventardatei „development.yaml“.
Durchführen eines Ansible-Trockenlaufs
Erstellen Sie eine Bestandsdatei „development.yaml“ wie unten gezeigt.
$ pwd
/Users/Ansible/postgres-setup
$ cat development.yaml
all:
hosts:
children:
postgres_clusters:
hosts:
pg01:
vars:
ansible_port: 22
ansible_user: "vagrant"
ansible_private_key_file: "/Users/Ansible/postgres-setup/private_key"In der obigen Inventardatei ist Host pg01 eines der Mitglieder der Hostgruppe postgres_clusters. Die Variablen ansible_port, ansible_user und ansible_private_key_file gelten nur für die Hosts unter der Gruppe postgres_clusters.
Wir werden nun prüfen, ob Ansible die Aufgaben auf dem verwalteten Knoten ausführen kann. Im Beispiel unten führt der ansible-Befehl den Modul-Ping auf dem verwalteten Knoten pg01 aus. Wenn Ansible den Modul-Ping ausführen konnte, sollten Sie SUCCESS als Antwort sehen.
$ ansible -i development.yaml -m ping pg01
pg01 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}Wenn Ansible auf dem verwalteten Knoten als erste Aufgabe ausgeführt wird, sammelt es Informationen wie Hostname, IP-Adresse und Speicher des verwalteten Knotens. Um diese zu überprüfen, können wir das Modul setup aufrufen, das ein großes JSON zurückgeben würde. Wir können all diese in unserem Ansible-Playbook verwenden.
$ ansible -i development.yaml -m setup pg01
pg01 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.100.4",
"10.0.2.15"
],
"ansible_all_ipv6_addresses": [
"fe80::a00:27ff:fe29:ac89",
"fe80::5054:ff:fe26:1060"
],Ansible-Rolle
Ansible Role ist eine Möglichkeit, einen bestimmten Satz verwandter Aufgaben und Konfigurationseinstellungen in einer einzigen Einheit zu bündeln, indem Sie einfach einem bestimmten Host oder einer bestimmten Hostgruppe eine Rolle zuweisen. Ansible wendet alle zugehörigen Konfigurationen und Aufgaben an. Dadurch wird vermieden, dass die Aufgaben für jeden Host oder jede Hostgruppe mehrmals wiederholt werden.
Jede Rolle wird als Verzeichnis dargestellt und innerhalb des Rollenverzeichnisses gibt es Unterverzeichnisse wie Standarddateien, Handler, Meta, Aufgaben, Vorlagen, Tests, Vars. Den Zweck dieser Verzeichnisse finden Sie hier.
Ansible-Befehle durchsuchen standardmäßig das Rollenverzeichnis unter den in DEFAULT_ROLES_PATH.
genannten Pfaden$ ansible-config list | grep -A2 '^DEFAULT_ROLES_PATH'
DEFAULT_ROLES_PATH:
default: ~/.Ansible/roles:/usr/share/Ansible/roles:/etc/Ansible/roles
description: Colon separated paths in which Ansible will search for Roles.Ansible-Galaxie
Ansible Galaxy ist ein Portal, auf dem die Community-Leute das GitHub-Repository ihrer Ansible-Rollen teilen. Wir können das Galaxy-Portal nach den erforderlichen Ansible-Rollen durchsuchen. Mit dem Befehl ansible-galaxy konnten wir die Rolle herunterladen und wiederverwenden. Bevor Sie eine Rolle verwenden, gehen Sie alle Ansible YAML-Dateien in den Verzeichnissen defaults, vars, task, templates, handlers im Detail durch und machen Sie sich bewusst, wie die Rolle funktioniert.
Für unsere Bereitstellung von PostgreSQL verwenden wir die vom Autor ANXS und GitHub Repo entwickelte Rolle „postgresql“.
Installieren der Ansible-Rolle „anxs.postgresql“
$ ansible-galaxy install anxs.postgresql
- downloading role 'postgresql', owned by anxs
- downloading role from https://github.com/ANXS/postgresql/archive/v1.10.1.tar.gz
- extracting anxs.postgresql to /Users/ansible/.Ansible/roles/anxs.postgresql
- anxs.postgresql (v1.10.1) was installed successfullyDer obige Befehl installiert das Rollenverzeichnis „anxs.postgresql“ unter dem Verzeichnis „/Users/ansible/.Ansible/roles“, dies ist eines der Verzeichnisse im DEFAULT_ROLES_PATH und der ansible-Befehl durchsucht dieses Verzeichnis nach Rollen. P>
Ansible-Playbook
Ein Ansible Playbook ist eine YAML-Datei, in der wir die Aufgaben oder Rollen auflisten, die auf einem bestimmten Host oder der Hostgruppe ausgeführt werden müssen. Hier können Sie mehr über die Entwicklung von Playbooks lesen und die Definition von Tags wie Hosts, Aufgaben, Rollen und Variablen lernen.
Standardmäßig werden alle Aufgaben von dem eingeloggten Ansible-Benutzer ausgeführt. Um bestimmte Aufgaben mit einem anderen Benutzer (oder mit „Root“-Privilegien) auszuführen, können wir uns bedienen. Wie Sie diesen Befehl verwenden, erfahren Sie hier.
Im Playbook unten (postgres-play.yaml) habe ich die Rolle „anxs.postgresql“ unter der Hostgruppe „postgres_clusters“ aufgelistet, sodass alle Aufgaben in der Rolle anxs.postgresql für alle Hosts unter der Gruppe ausgeführt werden „postgres_clusters“.
$ cat postgres-play.yaml
---
- hosts: postgres_clusters
become: yes
roles:
- role: anxs.postgresqlBeere:Yes in YAML definiert, dass diese Rolle mit höheren Rechten ausgeführt wird, indem die DEFAULT_BECOME_METHOD „sudo“
verwendet wird$ ansible-config list | grep -A2 '^DEFAULT_BECOME_METHOD'
DEFAULT_BECOME_METHOD:
default: sudo
description: Privilege escalation method to use when `become` is enabled.Wir führen dieses Playbook als Benutzer „vagrant“ aus und der Benutzer wurde bereits mit sudo-Macht ausgestattet.
[[email protected] ~]$ sudo cat /etc/sudoers.d/vagrant
%vagrant ALL=(ALL) NOPASSWD: ALLBereitstellen von PostgreSQL mit Ansible
Wir werden nun das Playbook „postgres-play.yaml“ ausführen, das alle PostgreSQL-bezogenen Pakete installiert und es mit den Standardeinstellungen konfiguriert.
Für dieses Beispiel installiert Ansible PostgreSQL 9.6 auf Port 5432, wobei postgres max_connections auf 100 gesetzt ist. Alle Standardeinstellungen finden Sie in der Datei /Users/ansible/.Ansible/roles/anxs.postgresql/defaults/main.yml .
$ grep -E '^postgresql_(version|port|max_connections):' ~/.Ansible/roles/anxs.postgresql/defaults/main.yml
postgresql_version: 9.6
postgresql_port: 5432
postgresql_max_connections: 100Playbook ausführen
$ ansible-playbook -i development.yaml postgres-play.yaml
PLAY [postgres_clusters] ***************************************************************************************************************************************************************************************
TASK [Gathering Facts] *****************************************************************************************************************************************************************************************
ok: [pg01]
...
...
PLAY RECAP *****************************************************************************************************************************************************************************************************
pg01 : ok=21 changed=14 unreachable=0 failed=0 skipped=32 rescued=0 ignored=0 Sobald Ansible alle Aufgaben ausgeführt hat, wird unter PLAY RECAP.
eine Zusammenfassung der Aufgabenausführungen angezeigt- ok=21, 21 Aufgaben ohne Änderungen ausgeführt.
- changed=14, 14 Tasks hat Änderungen am Host vorgenommen, wie das Installieren von Postgres, das Erstellen von Verzeichnissen, Dateien, das Starten von Postgres.
- skipped=32, 32 Aufgaben wurden übersprungen, möglicherweise weil einige Funktionen nicht aktiviert wurden. Da wir auf entOS installieren, wurden Ubuntu-bezogene Aufgaben übersprungen.
Überprüfen Sie den Status und die Konfiguration des PostgreSQL-Dienstes.
[[email protected] ~]$ systemctl status postgresql-9.6
● postgresql-9.6.service - PostgreSQL 9.6 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.6.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/postgresql-9.6.service.d
└─custom.conf
Active: active (running) since Wed 2019-05-29 07:15:25 UTC; 24min ago
Docs: https://www.postgresql.org/docs/9.6/static/
Process: 7559 ExecStartPre=/usr/pgsql-9.6/bin/postgresql96-check-db-dir /var/lib/pgsql/9.6/data (code=exited, status=0/SUCCESS)
Main PID: 7564 (postmaster)
CGroup: /system.slice/postgresql-9.6.service
├─7564 /usr/pgsql-9.6/bin/postmaster -D /etc/postgresql/9.6/data
├─7567 postgres: checkpointer process
├─7568 postgres: writer process
├─7569 postgres: wal writer process
├─7570 postgres: autovacuum launcher process
└─7571 postgres: stats collector process
[[email protected] ~]$ psql -U postgres
psql (9.6.13)
Type "help" for help.
postgres=# show max_connections ;
max_connections
-----------------
100
(1 row)
postgres=# show statement_timeout ;
statement_timeout
-------------------
(1 row)
postgres=# show log_min_duration_statement ;
log_min_duration_statement
----------------------------
-1
(1 row)Wir haben jetzt PostgreSQL auf dem verwalteten Host „pg01“ mit der Standardkonfiguration installiert.
Ändern der PostgreSQL-Konfiguration
Jetzt werden wir die PostgreSQL-Instanz mit unseren benutzerdefinierten Einstellungen neu konfigurieren.
Ich habe eine custom.yaml-Datei erstellt (wie unten gezeigt), die die Liste der Variablen enthält, die definiert sind, um PostgreSQL-Einstellungen wie listen_addresses, max_connections, wal_level, hot_standby, statement_timeout, log_checkpoint, log_lock_waits, log_destination, log_min_duration_statement.
zu ändern$ pwd
/Users/ansible/postgres-setup
$ cat custom.yaml
postgresql_listen_addresses: "*"
postgresql_max_connections: 300
postgresql_wal_level: "hot_standby"
postgresql_hot_standby: "on"
postgresql_statement_timeout: 60000
postgresql_log_lock_waits: "on"
postgresql_log_destination: "csvlog"
postgresql_log_min_duration_statement: 0Wir werden jetzt unser Playbook postgres-play.yaml ändern, um diese custom.yaml zu verwenden.
$ cat postgres-play.yaml
---
- hosts: postgres_clusters
become: yes
vars_files:
- ./custom.yaml
roles:
- role: anxs.postgresqlMithilfe von vars_files-Tags habe ich die benutzerdefinierte Konfigurationsdatei custom.yaml angegeben, die die in der Rolle anxs.postgresql angegebene Standardkonfiguration überschreibt. Weitere Details zur Variablenpriorität finden Sie hier.
Wir könnten jetzt denselben Ansible-Playbook-Befehl erneut ausführen, den wir zuvor ausgeführt hatten, aber dies wird alle Aufgaben wie das Installieren von PostgreSQL, das Konfigurieren, das Erstellen von Benutzern und Datenbanken ausführen. Dazu sollten wir Ansible darauf beschränken, nur die Aufgaben im Zusammenhang mit der PostgreSQL-Konfiguration auszuführen, indem wir die Option --tags
Um die Liste der unterstützten Tags zu erfahren, könnten wir den Befehl mit --list-tags.
ausführen$ ansible-playbook -i development.yaml postgres-play.yaml --list-tags
playbook: postgres-play.yaml
play #1 (postgres_clusters): postgres_clusters TAGS: []
TASK TAGS: [always, postgresql, postgresql-configure, postgresql-databases, postgresql-extensions, postgresql-install, postgresql-monit, postgresql-users]Von den obigen Tags geben wir nur das postgresql-configure-Tag an, um die postgresql-Einstellungen zu ändern.
$ ansible-playbook -i development.yaml postgres-play.yaml --tags postgresql-configure
PLAY [postgres_clusters] ***************************************************************************************************************************************************************************************
TASK [Gathering Facts] *****************************************************************************************************************************************************************************************
ok: [pg01]
...
...
TASK [anxs.postgresql : PostgreSQL | Update configuration - pt. 2 (postgresql.conf)] ***************************************************************************************************************************
changed: [pg01]
...
...
TASK [anxs.postgresql : PostgreSQL | Reload all conf files] ****************************************************************************************************************************************************
changed: [pg01]
PLAY RECAP *****************************************************************************************************************************************************************************************************
pg01 : ok=13 changed=2 unreachable=0 failed=0 skipped=6 rescued=0 ignored=0Wie Sie in der PLAY RECAP sehen, wurden nur 2 Änderungen an den verwalteten Knoten pg01 weitergegeben. Der erste aktualisiert die Konfiguration und der zweite lädt die Konfigurationen neu.
Vergewissern Sie sich, dass die Konfigurationsänderungen auf dem verwalteten Knoten wirksam wurden.
postgres=# show listen_addresses ;
listen_addresses
------------------
localhost
(1 row)
postgres=# show max_connections ;
max_connections
-----------------
100
(1 row)
postgres=# show wal_level ;
wal_level
-----------
minimal
(1 row)
postgres=# show hot_standby ;
hot_standby
-------------
off
(1 row)
postgres=# show statement_timeout;
statement_timeout
-------------------
1min
(1 row)
postgres=# show log_lock_waits ;
log_lock_waits
----------------
on
(1 row)
postgres=# show log_destination ;
log_destination
-----------------
csvlog
(1 row)
postgres=# show log_min_duration_statement;
log_min_duration_statement
----------------------------
(1 row)Wie Sie sehen können, sind einige Konfigurationsänderungen wie listen_addresses, max_connections, wal_level, hot_standby noch nicht in Kraft getreten. Diese Konfigurationsänderungen erfordern einen PostgreSQL-Neustart und die Rolle anxs.postgresql hat nur den Dienst selbst neu geladen.
Um einen abrupten Neustart von PostgreSQL während der Produktionszeit zu vermeiden, hat der ursprüngliche Autor die Neustartaufgabe möglicherweise nicht zur Rolle hinzugefügt. Wir können den postgresql-Dienst während der geplanten Ausfallzeit manuell neu starten.
[[email protected] ~]$ sudo systemctl restart postgresql-9.6
[[email protected] ~]$ psql -U postgres
psql (9.6.13)
postgres=# show listen_addresses ;
listen_addresses
------------------
(1 row)
postgres=# show max_connections ;
max_connections
-----------------
300
(1 row)
postgres=# show wal_level;
wal_level
-----------
replica
(1 row)
postgres=# show hot_standby;
hot_standby
-------------
on
(1 row)PostgreSQL-Benutzer und -Datenbanken erstellen
Wir werden nun die Benutzer „app1“ und „app2“ und die Datenbanken „app1_db“ und „app2_db“ erstellen, die den Benutzern „app1“ bzw. „app2“ gehören.
Ich habe zwei neue Variablen, postgresql_users und postgresql_database, zu custom.yaml hinzugefügt, die die Liste der Benutzer und Datenbanken enthält, die erstellt werden müssen. Die Rolle anxs.postgresql verwendet die Ansible-Module postgresql_users und postgresql_db zum Erstellen des Benutzers und der Datenbank. Sie können sich auf diese Dokumente beziehen, um die Variablen hinzuzufügen.
$ cat custom.yaml
...
...
postgresql_users:
- name: app1
pass: md5bb0592c05941d14c231da96950c71b60
encrypted: yes
- name: app2
pass: md5bbb1e4d09b64ca54a237727af46cba7c
encrypted: yes
postgresql_databases:
- name: app1_db
owner: app1
- name: app2_db
owner: app2 Wir werden jetzt nur die Aufgaben ausführen, die mit den Tags postgresql-users und postgresql-databases verknüpft sind.
$ ansible-playbook -i development.yaml postgres-play.yaml --tags postgresql-users,postgresql-databases
PLAY [postgres_clusters] ***************************************************************************************************************************************************************************************
...
...
TASK [anxs.postgresql : PostgreSQL | Make sure the PostgreSQL users are present] *******************************************************************************************************************************
changed: [pg01] => (item=None)
changed: [pg01] => (item=None)
changed: [pg01]
...
...
TASK [anxs.postgresql : PostgreSQL | Make sure the PostgreSQL databases are present] ***************************************************************************************************************************
changed: [pg01] => (item={u'owner': u'app1', u'name': u'app1_db'})
changed: [pg01] => (item={u'owner': u'app2', u'name': u'app2_db'})
...
...
PLAY RECAP *****************************************************************************************************************************************************************************************************
pg01 : ok=6 changed=2 unreachable=0 failed=0 skipped=9 rescued=0 ignored=0Überprüfen Sie, ob die Benutzer und Datenbanken auf dem verwalteten Host erstellt wurden.
postgres=# \du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
app1 | | {}
app2 | | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
app1_db | app1 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
app2_db | app2 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
(5 rows)Externen Hosts erlauben, sich mit dem PostgreSQL-Server zu verbinden
Wir erlauben nun den externen Hosts, sich mit dem PostgreSQL-Dienst zu verbinden, indem wir die Variable postgresql_pg_hba_custom zu custom.yaml hinzufügen
$ cat custom.yaml
...
...
postgresql_pg_hba_custom:
- {type: "host", database: "all", user: "all", address: "0.0.0.0/0", method: "md5" }Ausführen der mit postgresql-configure gekennzeichneten Aufgaben, um die Konfiguration anzuwenden.
$ ansible-playbook -i development.yaml postgres-play.yaml --tags postgresql-configureÜberprüfen, ob ich von meinem Kontrollknoten aus eine Verbindung zum PostgreSQL-Server herstellen kann.
$ PGPASSWORD=password psql -h pg01 -U app1 -d app1_db -c 'Select true'
bool
------
(1 row)Schlussfolgerung
Dieser Blog sollte Ihnen die Grundlagen vermitteln, die Sie wissen müssen, um Ansible für die Bereitstellung und Verwaltung von PostgreSQL zu verwenden. Wir haben jedoch nur einige Verwaltungsaufgaben von PostgreSQL behandelt. Abhängig von der Infrastruktur Ihrer Organisation müssen Sie möglicherweise einige der Standardkonfigurationen überschreiben und der Ansible-Rolle sogar noch mehr Aufgaben hinzufügen.
