galaxyproject.postgresql

PostgreSQL

Rola Ansible do instalacji i zarządzania serwerami PostgreSQL. Ta rola działa zarówno na systemach opartych na Debianie, jak i RedHat, oraz zapewnia skrypty do tworzenia kopii zapasowych dla ciągłej archiwizacji PostgreSQL i odzyskiwania w punkcie czasowym. Nie tworzy ani nie zarządza użytkownikami PostgreSQL, rolami, grupami, bazami danych itd. W tym celu zobacz galaxyproject.postgresql_objects.

Na platformach opartych na RedHat będą zainstalowane pakiety Globalnej Grupy Rozwoju PostgreSQL (PGDG). Na platformach opartych na Debianie można wybrać pakiety z repozytoriów dystrybucji (z APT) lub pakiety PGDG.

Zmiany, które wymagają restartu, nie będą zastosowane, chyba że ręcznie zrestartujesz PostgreSQL. Ta rola przeładował serwer w przypadku tych zmian konfiguracyjnych, które można zaktualizować tylko przez przeładowanie, ponieważ przeładowanie jest operacją nieinwazyjną, ale opcje, które wymagają pełnego restartu, nie spowodują automatycznego ponownego uruchomienia serwera.

Wymagania

Ta rola wymaga Ansible w wersji 2.4 lub wyższej.

Zmienne roli

Wszystkie zmienne są opcjonalne

postgresql_user_name: Nazwa użytkownika systemowego używana dla PostgreSQL (domyślnie: postgres).
postgresql_version: Wersja PostgreSQL do zainstalowania. Na platformach opartych na Debianie domyślnie jest to wersja wskazywana przez metapakiet postgresql. Na platformach opartych na RedHat domyślnie jest to 10.
postgresql_flavor: Na platformach opartych na Debianie określa, czy chcesz używać pakietów PostgreSQL z pgdg, czy z repozytoriów apt dystrybucji. Możliwe wartości: apt, pgdg (domyślnie: apt).
postgresql_conf: Lista haseł (słowników) opcji postgresql.conf (kluczów) i wartości. Te opcje nie są dodawane bezpośrednio do postgresql.conf - rola dodaje podkatalog conf.d w katalogu konfiguracyjnym oraz polecenie include dla tego katalogu do postgresql.conf. Opcje ustawione w postgresql_conf są następnie ustawiane w conf.d/25ansible_postgresql.conf. Z powodów dziedziczenia, może to być także pojedynczy hash, ale składnia listy jest preferowana, ponieważ zachowuje porządek.

Ze względu na analizę YAML, musisz być ostrożny przy definiowaniu wartości w postgresql_conf, aby upewnić się, że są one poprawnie zapisane w pliku konfiguracyjnym. Na przykład:
```
postgresql_conf:
  - max_connections: 250
  - archive_mode: "off"
  - work_mem: "'8MB'"
```
Staje się to następującym w 25ansible_postgresql.conf:
```
max_connections = 250
archive_mode = off
work_mem: '8MB'
```
postgresql_pg_hba_conf: Lista linii do dodania do pg_hba.conf.
postgresql_pg_hba_local_postgres_user: Jeśli ustawione na false, usunie wpis użytkownika postgres z pg_hba.conf, który jest wstępnie skonfigurowany w instalacjach PostgreSQL opartych na Debianie. Prawdopodobnie nie chcesz tego robić, chyba że wiesz, co robisz.
postgresql_pg_hba_local_socket: Jeśli ustawione na false, usunie wpis local z pg_hba.conf, który jest wstępnie skonfigurowany przez pakiet PostgreSQL.
postgresql_pg_hba_local_ipv4: Jeśli ustawione na false, usunie wpis host ... 127.0.0.1/32 z pg_hba.conf, który jest wstępnie skonfigurowany przez pakiet PostgreSQL.
postgresql_pg_hba_local_ipv6: Jeśli ustawione na false, usunie wpis host ... ::1/128 z pg_hba.conf, który jest wstępnie skonfigurowany przez pakiet PostgreSQL.
postgresql_pgdata: Ustaw to tylko, jeśli zmieniłeś katalog $PGDATA z domyślnej wartości pakietu. Zauważ, że to nie konfiguruje PostgreSQL do używania innego katalogu, musisz zrobić to samodzielnie, to tylko pozwala na poprawne zlokalizowanie katalogu przez rolę.
postgresql_conf_dir: Jak w przypadku postgresql_pgdata, z wyjątkiem katalogu konfiguracyjnego.
postgresql_install_psycopg2: Próba zainstalowania odpowiedniego pakietu dostarczającego psycopg2 do interpretera Pythona, którego Ansible używa po stronie zdalnej. Umożliwia to korzystanie z modułów Ansible postgresql_* (może przez galaxyproject.postgresql_objects), które zależą od psycopg2. Domyślnie ustawione na true.

Kopie zapasowe

Ta rola może wdrażać i planować konfigurację i skrypty do utrzymywania kopii zapasowych PITR PostgreSQL.

Pełne kopie zapasowe będą wykonywane w skonfigurowanych odstępach czasu, natomiast segmenty logów write-ahead (WAL) pomiędzy pełnymi kopiami zapasowymi będą archiwizowane w {{ postgresql_backup_dir }}/wal_archive/ na polecenie serwera PostgreSQL. Segmenty WAL można usunąć z tego katalogu, gdy najstarsza kopia zapasowa, która się do nich odnosi, została usunięta. To odbywa się automatycznie przez skrypt kopii zapasowej, jeśli postgresql_backup_dir jest zamontowany lokalnie.

Gdy postgresql_backup_dir jest zdalną ścieżką rsync (zawierającą ":"), skrypt kopii zapasowej nadal będzie utrzymywał kopie zapasowe (w tym usuwanie starszych pełnych kopii zapasowych), ale nie może automatycznie przycinać katalogu wal_archive/. Jeśli możesz zainstalować standardowe narzędzie pg_archivecleanup z pakietu klienckiego PostgreSQL na swoim serwerze kopii zapasowej, możesz uruchomić skrypt kopii zapasowej tej roli z opcją --clean-archive bezpośrednio na serwerze kopii zapasowej.

postgresql_backup_dir: Jeśli ustawiony, włącza kopie zapasowe PITR. Ustaw to na katalog, w którym będą tworzone kopie zapasowe bazy danych (można użyć dowolnego formatu obsługiwanego przez rsync, np. user@host:/path). Najnowsza kopia zapasowa będzie w podkatalogu o nazwie current.
postgresql_backup_local_dir: Ścieżka w systemie plików na serwerze PostgreSQL, gdzie umieszczone będą skrypty kopii zapasowych.
postgresql_backup_[hour|minute]: Kontroluje, o której godzinie zadanie cron będzie uruchamiane, aby wykonać pełną kopię zapasową. Domyślnie o 1:00 w nocy.
postgresql_backup_[day|month|weekday]: Dodatkowe kontrole cron, kiedy wykonywana jest pełna kopia zapasowa (domyślnie: *).
postgresql_backup_post_command: Dowolne polecenie do uruchomienia po pomyślnym zakończeniu zaplanowanej kopii zapasowej.

Dodatkowe opcje związane z kopiami zapasowymi można znaleźć w pliku domyślnym.

Zależności

Funkcja kopii zapasowych wymaga Pythona w wersji 2.7 lub 3.5+, psycopg2 i rsync. Zauważ, że jeśli instalujesz wersje PGDG PostgreSQL na Enterprise Linux, odpowiednie pakiety psycopg2 są dostępne w repozytoriach yum PGDG.

Przykładowy Playbook

Standardowa instalacja: Domyślne postgresql.conf, pg_hba.conf i domyślna wersja dla systemu operacyjnego:

---

- hosts: dbservers
  roles:
    - galaxyproject.postgresql

Użyj pakietów pgdg na hoście opartym na Debianie:

---

- hosts: dbservers
  vars:
    postgresql_flavor: pgdg
  roles:
    - galaxyproject.postgresql

Użyj pakietów PostgreSQL 9.5 i ustaw kilka opcji postgresql.conf oraz wpisów pg_hba.conf:

---

- hosts: dbservers
  vars:
    postgresql_version: 9.5
    postgresql_conf:
      - listen_addresses: "''"    # wyłącz nasłuch na sieci (nasłuch na lokalnym gnieździe tylko)
      - max_connections: 50       # zmniejszenie limitu połączeń
    postgresql_pg_hba_conf:
      - host all all 10.0.0.0/8 md5
  roles:
    - galaxyproject.postgresql

Włącz kopie zapasowe do /archive:

- hosts: all
  vars:
    postgresql_backup_dir: /archive
  roles:
    - galaxyproject.postgresql

Włącz kopie zapasowe do /archive na zdalnym serwerze:

- hosts: dbservers
  vars:
    postgresql_backup_dir: backup.example.org:/archive
  roles:
    - galaxyproject.postgresql

- hosts: backupservers
  tasks:
    - name: Zainstaluj skrypty PostgreSQL
      ansible.builtin.apt:
        name: postgresql-common
    - name: Skopiuj skrypt kopii zapasowej
      ansible.builtin.copy:
        src: roles/galaxyproject.postgresql/files/backup.py
        dest: /usr/local/bin/pgbackup.py
        mode: "0755"
    - name: Zaplanuj czyszczenie WAL
      ansible.builtin.cron:
        name: Czyszczenie zarchiwizowanych WAL PostgreSQL
        hour: 22
        minute: 0
        job: /usr/local/bin/pgbackup.py --clean-archive /archive