Wdrażanie i konserwacja PostgreSQL z Ansible

Ansible jest jednym z najbardziej znanych i powszechnie stosowanych narzędzi do automatyzacji IT, pomaga nam w automatyzacji zadań operacyjnych IT, takich jak...

Bootstraping hosta (maszyna wirtualna lub bare-metal) od zera
Konfigurowanie hostów i usług
Zarządzanie wdrożeniami i aktualizacjami oprogramowania
Ansible obsługuje również orkiestrację infrastruktury chmury, na przykład tworzenie wielu instancji EC2 i RDS dla aplikacji w chmurach publicznych (AWS, GCP, Azure). Więcej o udostępnianiu w chmurze można znaleźć tutaj

Ponieważ ten blog dotyczy głównie zarządzania PostgreSQL za pomocą Ansible, nie będziemy wchodzić w szczegóły użycia Ansible, jednak omówimy niektóre podstawy Ansible. Polecam przejść przez link do dokumentu Ansible, jeśli chcesz dowiedzieć się więcej na ten temat.

Podstawy Ansible

Ansible to projekt open-source napisany w Pythonie, którego kod źródłowy jest dostępny na GitHub. Ponieważ jest to pakiet Pythona, możemy łatwo zainstalować Ansible za pomocą pip.

Ansible musi być zainstalowany tylko na jednym hoście, z którego będziemy koordynować nasze zadania operacyjne za pomocą poleceń Ansible (Ansible, Ansible-playbook). Ten host orkiestracji nazywamy węzłem kontrolnym.

Polecenia Ansible używają bibliotek OpenSSH do logowania się do hostów docelowych w celu wykonywania zadań operacyjnych, które nazywamy węzłem zarządzanym hostów docelowych. Nazwa hosta lub adres IP węzła zarządzanego są wymienione w pliku o nazwie Inventory, a ta nazwa pliku ekwipunku jest następnie określana jako dane wejściowe do poleceń Ansible.

W pliku inwentarza możemy wymienić wiele hostów w jednej grupie, co pozwoli uniknąć wielokrotnego powtarzania tych samych zadań dla różnych hostów. Więcej szczegółów na temat wykorzystania plików inwentarza można znaleźć tutaj.

Ponieważ polecenie Ansible używa SSH do logowania, nie ma potrzeby instalowania Ansible na wszystkich hostach, wystarczy zainstalować go na węźle kontrolnym. Jednak wszystkie węzły kontrolne i zarządzane powinny mieć zainstalowane Pythona i wszelkie niezbędne biblioteki Pythona. Więcej na temat instalacji Ansible można znaleźć tutaj.

W przypadku wersji demonstracyjnej będę używać laptopa jako węzła kontrolnego i maszyny wirtualnej gościa CentOS-7 jako węzła zarządzanego. Maszyna wirtualna CentOS-7 została udostępniona przy użyciu Vagrant na dostawcy VirtualBox.

Instalowanie Ansible na węźle kontrolnym

Zainstalujemy Ansible za pomocą pip, jak wspomniano na stronie dokumentu Ansible. Następujące polecenia zostały wykonane jako użytkownik „Ansible”.

$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ python get-pip.py --user

Użycie opcji --user powoduje, że polecenia pip i Ansible zostaną zainstalowane w katalogu HOME i musimy dodać ścieżkę bin do naszej zmiennej środowiskowej PATH.

$ echo 'export PATH=$HOME/Library/Python/2.7/bin:$PATH' >> ~/.bash_profile
$ source ~/.bash_profile

Następujące polecenie pip zainstalowało Ansible w wersji 2.8.0 (która jest najnowszą stabilną wersją w momencie pisania tego bloga).

$ pip install --user ansible 
$ which ansible
/Users/Ansible/Library/Python/2.7/bin/Ansible
$ ansible --version
Ansible 2.8.0
...
...

Kontrola wstępna węzła kontrolnego i węzła zarządzanego

Upewnij się, że masz prawidłowe połączenie sieciowe między węzłem kontrolnym a węzłem zarządzanym.

Sprawdź zaporę sieciową pod kątem reguł, które mogą blokować połączenia przychodzące i wychodzące na porcie SSH, jeśli tak, otwórz port SSH, aby zapewnić dostęp zarówno do węzłów kontrolnych, jak i zarządzanych.

Najpierw spróbuj połączyć się przez SSH z zarządzanym węzłem. Powinieneś być w stanie zalogować się do węzła zarządzanego z węzła kontrolnego.

Możesz skonfigurować dostęp SSH bez hasła do węzłów zarządzanych zgodnie z zasadami bezpieczeństwa Twojej organizacji. W tym demo mam skonfigurowane bez hasła dla SSH do mojego zarządzanego węzła „pg01” (CentOS-7) dla użytkownika „włóczęga”. To sprawia, że zarządzany węzeł ma moc sudo, większość zadań związanych z instalacją i konfiguracją hosta będzie wykonywana jako użytkownik „wędrujący” z „sudo”.

W węźle kontrolnym mamy plik konfiguracyjny ansible.cfg, który będzie używany przez polecenia Ansible. Poniżej znajduje się kilka opcji konfiguracyjnych, które są zdefiniowane w pliku konfiguracyjnym. Aby dowiedzieć się więcej o innych dostępnych opcjach konfiguracji, sprawdź przykładowy plik konfiguracyjny.

remote_port - Jeśli serwer SSH na zarządzanym węźle działa na innym porcie niż domyślny 22, możemy to zmienić
zdalny_użytkownik — nazwa użytkownika, która będzie używana przez Ansible do połączenia z zarządzanym węzłem, do uruchamiania zadań
private_key_file - prywatny klucz SSH, który będzie używany do logowania w Ansible

Ponieważ powyższa konfiguracja obowiązuje globalnie dla wszystkich zarządzanych węzłów, jeśli chcemy mieć inną konfigurację dla konkretnego hosta lub grupy hostów, możemy określić je w pliku inwentarza. Przykład tego można zobaczyć poniżej w pliku inwentarzowym „development.yaml”.

Wykonywanie próbnego biegu Ansible

Utwórz plik inwentarza „development.yaml”, jak pokazano poniżej.

$ 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"

W powyższym pliku inwentarzowym host pg01 jest jednym z członków grupy hostów postgres_clusters. Zmienne ansible_port, ansible_user i ansible_private_key_file dotyczą tylko hostów w grupie postgres_clusters.

Sprawdzimy teraz, czy Ansible może uruchamiać zadania na zarządzanym węźle. W poniższym przykładzie polecenie ansible wykonuje moduł ping na zarządzanym węźle pg01, jeśli Ansible był w stanie uruchomić moduł ping, jako odpowiedź powinna pojawić się SUCCESS.

$ ansible -i development.yaml -m ping pg01
pg01 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    }, 
    "changed": false, 
    "ping": "pong"
}

Uruchamiając Ansible na zarządzanym węźle jako pierwsze zadanie, zbiera informacje, takie jak nazwa hosta, adres IP, pamięć zarządzanego węzła. Aby to sprawdzić, możemy wywołać konfigurację modułu, która zwróci duży JSON. Możemy skorzystać z każdego z nich w naszym poradniku Ansible.

$ 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"
        ],

Rola odpowiedzi

Ansible Role to sposób na połączenie pewnego zestawu powiązanych zadań i ustawień konfiguracyjnych w jedną jednostkę poprzez przypisanie roli do konkretnego hosta lub grupy hostów. Ansible zastosuje wszystkie powiązane konfiguracje i zadania. Pozwala to uniknąć wielokrotnego powtarzania zadań dla każdego hosta lub grupy hostów.

Każda rola jest reprezentowana jako katalog, aw katalogu ról znajdują się podkatalogi, takie jak pliki domyślne, programy obsługi, meta, zadania, szablony, testy, vars. Przeznaczenie tych katalogów można znaleźć tutaj.

Komendy Ansible domyślnie przeszukują katalog ról pod ścieżkami wymienionymi w DEFAULT_ROLES_PATH.

$ 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.

Galaktyka Ansible

Ansible Galaxy to portal, w którym członkowie społeczności udostępniają repozytorium GitHub swoich ról Ansible. Możemy przeglądać portal galaktyk w poszukiwaniu wymaganych ról Ansible. Korzystając z polecenia ansible-galaxy, mogliśmy pobrać i ponownie wykorzystać rolę. Przed użyciem roli przejrzyj szczegółowo wszystkie pliki Ansible YAML w katalogach domyślnych, zmiennych, zadań, szablonów, programów obsługi i pamiętaj o tym, jak działa rola.

Do naszego wdrożenia PostgreSQL użyjemy roli „postgresql” opracowanej przez autora ANXS i repozytorium GitHub.

Instalowanie roli Ansible „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 successfully

Powyższe polecenie instaluje katalog ról „anxs.postgresql” w katalogu „/Users/ansible/.Ansible/roles”, jest to jeden z katalogów w DEFAULT_ROLES_PATH, a polecenie ansible przeszuka ten katalog w poszukiwaniu dowolnych ról.

Poradnik Ansible

Ansible Playbook to plik YAML, w którym wymienimy zadania lub role, które muszą zostać wykonane na określonym hoście lub grupie hostów. Możesz przeczytać więcej o tworzeniu poradników, a także poznać definicje tagów, takich jak hosty, zadania, role, vars tutaj.

Domyślnie wszystkie zadania wykonywane są jako użytkownik ansible, który się zalogował. W celu wykonania poszczególnych zadań z innym użytkownikiem (lub z uprawnieniem „root”) możemy skorzystać z funkcji zostań. Jak korzystać z tego polecenia, można znaleźć tutaj.

W poniższym playbooku (postgres-play.yaml) wymieniłem rolę „anxs.postgresql” w grupie hostów „postgres_clusters”, więc wszystkie zadania w roli anxs.postgresql zostaną wykonane dla wszystkich hostów w grupie „postgres_clusters”.

$ cat postgres-play.yaml 
---
- hosts: postgres_clusters
  become: yes
  roles: 
    - role: anxs.postgresql

stać się:tak w YAML określa, że ta rola będzie wykonywana z wyższymi uprawnieniami za pomocą DEFAULT_BECOME_METHOD „sudo”

$ ansible-config list | grep -A2 '^DEFAULT_BECOME_METHOD'
DEFAULT_BECOME_METHOD:
  default: sudo
  description: Privilege escalation method to use when `become` is enabled.

Będziemy prowadzić ten poradnik jako użytkownik „włóczęgi”, który miał już dostęp do sudo power.

[[email protected] ~]$ sudo cat /etc/sudoers.d/vagrant
%vagrant ALL=(ALL) NOPASSWD: ALL

Manynines DevOps Przewodnik po zarządzaniu bazami danychDowiedz się, co musisz wiedzieć, aby zautomatyzować i zarządzać bazami danych typu open sourcePobierz za darmo

Wdrażanie PostgreSQL za pomocą Ansible

Uruchomimy teraz podręcznik „postgres-play.yaml”, który zainstaluje wszystkie pakiety związane z PostgreSQL i skonfiguruje go przy użyciu ustawień domyślnych.

W tym przykładzie Ansible zainstaluje PostgreSQL 9.6 na porcie 5432, z parametrem postgres max_connections ustawionym na 100. Wszystkie ustawienia domyślne można znaleźć w pliku /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: 100

Prowadzenie poradnika

$ 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

Gdy Ansible wykona wszystkie zadania, podsumowanie wykonanych zadań zostanie wyświetlone w sekcji POWTÓRKA ODTWARZANIA.

ok=21, 21 zadań wykonanych bez zmian.
zmieniono=14, 14 zadań wprowadziło zmiany na hoście, takie jak instalowanie postgresa, tworzenie katalogów, plików, uruchamianie postgresa.
skiped=32, 32 zadania zostały pominięte, może to być spowodowane niewłączeniem niektórych funkcji. Ponieważ instalujemy na entOS, zadania związane z Ubuntu zostały pominięte.

Sprawdź stan i konfigurację usługi PostgreSQL.

[[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)

Zainstalowaliśmy PostgreSQL na zarządzanym hoście „pg01” przy użyciu domyślnej konfiguracji.

Zmiana konfiguracji PostgreSQL

Teraz ponownie skonfigurujemy instancję PostgreSQL, używając naszych niestandardowych ustawień.

Stworzyłem plik custom.yaml (jak pokazano poniżej), który zawiera listę zmiennych zdefiniowanych do modyfikacji ustawień PostgreSQL, takich jak listen_addresses, max_connections, wal_level, hot_standby, statement_timeout, log_checkpoint, log_lock_waits, log_destination, log_min_duration_statement.

$ 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: 0

Zmienimy teraz nasz poradnik postgres-play.yaml, aby używał tego custom.yaml.

$ cat postgres-play.yaml  
---
- hosts: postgres_clusters
  become: yes
  vars_files:
    - ./custom.yaml
  roles: 
    - role: anxs.postgresql

Używając tagów vars_files określiłem niestandardowy plik konfiguracyjny custom.yaml, który zastąpi domyślną konfigurację określoną w roli anxs.postgresql. Więcej szczegółów na temat pierwszeństwa zmiennych można znaleźć tutaj.

Mogliśmy teraz ponownie uruchomić to samo polecenie ansible-playbook, które wykonaliśmy wcześniej, ale to wykona wszystkie zadania, takie jak instalowanie PostgreSQL, konfigurowanie, tworzenie użytkowników i baz danych. W tym celu powinniśmy ograniczyć Ansible do wykonywania tylko zadań związanych z konfiguracją PostgreSQL za pomocą opcji --tags .

Aby poznać listę obsługiwanych tagów, możemy uruchomić polecenie z --list-tags.

$ 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]

Z powyższych tagów określimy tylko tag postgresql-configure, aby zmodyfikować ustawienia postgresql.

$ 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=0

Jak widać w PODSUMIENIU ODTWARZANIA, tylko 2 zmiany zostały wprowadzone do zarządzanego węzła pg01. Pierwszy to aktualizacja konfiguracji, a drugi to ponowne wczytanie konfiguracji.

Sprawdź, czy zmiany konfiguracji weszły w życie w zarządzanym węźle.

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)

Jak widać, niektóre konfiguracje się zmieniły, takie jak adresy_słuchowe, max_połączenia, wal_level, hot_standby, jeszcze nie weszły w życie. Te zmiany konfiguracji wymagają ponownego uruchomienia PostgreSQL, a rola anxs.postgresql spowodowała ponowne załadowanie samej usługi.

Aby uniknąć nagłego restartu PostgreSQL w godzinach produkcji, pierwotny autor mógł nie dodać zadania restartu do roli. Możemy ręcznie ponownie uruchomić usługę postgresql podczas zaplanowanego przestoju.

[[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)

Tworzenie użytkowników i baz danych PostgreSQL

Utworzymy teraz użytkowników „app1” i „app2” oraz bazy danych „app1_db” i „app2_db” należące odpowiednio do użytkowników „app1” i „app2”.

Dodałem dwie nowe zmienne postgresql_users i postgresql_database do pliku custom.yaml, który zawiera listę użytkowników i baz danych do stworzenia. Rola anxs.postgresql wykorzystuje moduł Ansible postgresql_users i postgresql_db do tworzenia użytkownika i bazy danych. Możesz odwołać się do tych dokumentów, aby dodać zmienne.

$ 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

Będziemy teraz uruchamiać tylko zadania związane z tagami postgresql-users i postgresql-databases.

$ 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

Sprawdź, czy użytkownicy i bazy danych są utworzone na zarządzanym hoście.

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)

Zezwalanie zewnętrznym hostom na łączenie się z serwerem PostgreSQL

Teraz umożliwimy zewnętrznym hostom łączenie się z usługą PostgreSQL, dodając zmienną postgresql_pg_hba_custom do custom.yaml

$ cat custom.yaml
...
...
postgresql_pg_hba_custom:
  - {type: "host", database: "all", user: "all", address: "0.0.0.0/0", method: "md5" }

Uruchamianie zadań oznaczonych postgresql-configure, aby zastosować konfigurację.

$ ansible-playbook -i development.yaml postgres-play.yaml --tags postgresql-configure

Sprawdzam, czy mogę połączyć się z serwerem PostgreSQL z mojego węzła kontrolnego.

$ PGPASSWORD=password psql -h pg01 -U app1 -d app1_db -c 'Select true'
 bool
------
 
(1 row)

Wniosek

Ten blog powinien dać ci podstawy, które musisz znać, aby używać Ansible do wdrażania i zarządzania PostgreSQL. Omówiliśmy jednak tylko kilka zadań administracyjnych PostgreSQL. W zależności od infrastruktury Twojej organizacji może być konieczne zastąpienie kilku domyślnych konfiguracji i dodanie jeszcze większej liczby zadań do roli Ansible.