Pierwsze kroki z PostgreSQL 11 na Ubuntu 18.04

PostgreSQL, choć jest nowoczesnym i wszechstronnym systemem zarządzania bazą danych (RDBMS), nie należy do najłatwiejszych do skonfigurowania i rozpoczęcia pracy podczas tworzenia aplikacji. Czytaj dalej, aby dowiedzieć się, jak rozpocząć korzystanie z najnowszej wersji PostgreSQL w wersji LTS Ubuntu.

Instalacja

Ubuntu 18.04 jest dostarczany z PostgreSQL 10, ale zamiast tego możemy użyć repozytorium APT hostowanego przez zespół PostgreSQL, aby zainstalować najnowszą wersję, PostgreSQL 11.

Możesz skonfigurować repozytorium za pomocą tych poleceń:

# add the repository
sudo tee /etc/apt/sources.list.d/pgdg.list <<END
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
END

# get the signing key and import it
wget https://www.postgresql.org/media/keys/ACCC4CF8.asc
sudo apt-key add ACCC4CF8.asc

# fetch the metadata from the new repo
sudo apt-get update

A następnie zainstaluj samo oprogramowanie, używając:

sudo apt-get install postgresql-11

Instalacja robi kilka rzeczy:

• Instaluje serwer PostgreSQL, narzędzia i klienta wiersza poleceń o nazwie psql .
• Tworzy użytkownika systemu Linux o nazwie postgres . Wszystkie pliki danych są własnością tego użytkownika, a wszystkie procesy działają jako ten użytkownik.
• Tworzy jedną bazę danych, zwaną także postgresem .
• Tworzy jednego użytkownika PostgreSQL (nie użytkownik systemu Linux), zwany także postgresem .

Widać, że zaczyna to być zagmatwane!

Klastry baz danych

Twój nowo zainstalowany serwer PostgreSQL składa się z zestawu procesów, które zarządzają tak zwanym „klasterem baz danych”. Tutaj możesz zobaczyć procesy:

alice@devbox:~$ ps axfww | grep postgres
 4737 ?        S      0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
 4749 ?        Ss     0:00  \_ postgres: 11/main: checkpointer
 4750 ?        Ss     0:00  \_ postgres: 11/main: background writer
 4751 ?        Ss     0:00  \_ postgres: 11/main: walwriter
 4752 ?        Ss     0:00  \_ postgres: 11/main: autovacuum launcher
 4753 ?        Ss     0:00  \_ postgres: 11/main: stats collector
 4754 ?        Ss     0:00  \_ postgres: 11/main: logical replication launcher  

Proces główny (tutaj z PID 4737) jest głównym procesem, który dalej tworzy procesy potomne – jest to konwencjonalnie nazywane procesem „postmaster”.

Użycie przez PostgreSQL terminu „klaster” wyprzedza współczesny fantazyjny żargon rozproszonego klastra – tutaj oznacza to po prostu zestaw baz danych zarządzanych na jednej maszynie przez jednego postmastera. Przeczytaj więcej o klastrach tutaj.

Klaster zawiera m.in. bazy danych (na razie mamy tylko jednego, „postgresa”) oraz użytkowników PostgreSQL (ponownie jeden na razie, zwany też „postgresem”). Pamiętaj, że klaster jest powiązany z całą masą plików danych, z których wszystkie znajdują się w jednym katalogu – w tym przypadku pod /var/lib/postgresql/11/main . Czy zauważyłeś tę ścieżkę w powyższym wierszu poleceń postmastera?

Kiedy Twoja aplikacja lub psql łączy się z Postgresem, musi to zrobić w kontekście użytkownika PostgreSQL. Jest zawsze użytkownik PostgreSQL powiązany z połączeniem. Ale, jak można się domyślić, użytkownik PostgreSQL może, ale nie musi, odpowiadać użytkownikowi systemowemu.

Użytkownicy systemu i użytkownicy PostgreSQL

Użytkowników PostgreSQL można tworzyć za pomocą poleceń SQL, takich jak CREATE ROLE lub dołączonych narzędzi, takich jak createdb.

Gdy jakakolwiek aplikacja próbuje połączyć się z Postgresem, musi podać nazwę użytkownika PostgreSQL. Zobaczmy, co się stanie, gdy uruchomisz klienta PostgreSQL, takiego jak psql:

alice@devbox:~$ psql
psql: FATAL:  role "alice" does not exist

Tutaj „alice” to nazwa użytkownika systemu Linux. psql przyjmuje tę nazwę i używa jej jako nazwy użytkownika Postgres. Rola (role to ogólna nazwa sortowania dla „użytkownika” lub „grupy”, BTW) o tej nazwie nie istnieje, na co narzeka Postgres.

Wiemy, że istnieje rola o nazwie „postgres”, więc spróbujmy tego. Do określenia nazwy użytkownika możemy użyć parametru „-U” psql:

alice@devbox:~$ psql -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"

OK, jesteśmy coraz bliżej – rola/użytkownik „postgres” istnieje, ale „peerauthentication” nie powiodły się. Co to jest „uwierzytelnianie równorzędne”?

Uwierzytelnianie równorzędne i hasło

Klienci PostgreSQL, tacy jak psql lub Twoja aplikacja, mogą łączyć się z serwerem PostgreSQL za pomocą jednego z tych mechanizmów IPC:

• Gniazda domeny uniksowej
• Gniazda TCP

W przeciwieństwie do gniazd TCP, gniazda domeny Unix oferują możliwość weryfikacji identyfikatora użytkownika systemowego połączenia klienta. Serwer Postgres może zbadać połączenie przychodzące przez gniazdo domeny uniksowej i określić identyfikator użytkownika systemu klienta, a następnie zdecydować, czy przyznać mu dostęp, czy nie.

Domyślnie twój serwer nasłuchuje tylko połączeń przez gniazda domeny unix, a nie TCP/IP.

Zobaczmy, co się stanie, jeśli spróbujemy uruchomić psql jako użytkownik systemu postgres:

alice@devbox:~$ sudo -u postgres psql
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
Type "help" for help.

postgres=#

To się udało! (Użyj „\q”, „\quit” lub ^D aby wyjść z psql, BTW.)

W uwierzytelnianiu równorzędnym, jeśli połączenie klienta jest nawiązywane przy użyciu gniazda domeny Unix, a proces klienta ma taką samą nazwę użytkownika systemowego jak użytkownik PostgreSQL, z którym próbuje się połączyć, wówczas uwierzytelnianie jest uważane za zakończone powodzeniem.

Użytkownikom PostgreSQL można również opcjonalnie przypisać hasło i można poprosić PostgreSQL o walidację połączeń przychodzących za pomocą hasła. Ale jak? To kolejny element układanki.

pg_hba.conf

Nadszedł czas, aby otworzyć (nie)sławny plik konfiguracyjny pg_hba.conf, znajdujący się pod adresem/etc/postgresql/11/main/pg_hba.conf :

sudo vim /etc/postgresql/11/main/pg_hba.conf

HBA oznacza uwierzytelnianie oparte na hoście. Zasadniczo ten plik służy do kontrolowania sposobu uwierzytelniania użytkowników PostgreSQL. Ten plik jest prawdopodobnie najbardziej nieintuicyjną częścią krzywej uczenia się PostgreSQL. Dokumentacja referencyjna jest tutaj, należy ją przeczytać później.

Pierwsza linia (bez komentarza) to:

local all postgres peer

który mówi Postgresowi, aby akceptował połączenia „lokalne” (domena unix) do „wszystkich” baz danych, uwierzytelniając się jako użytkownik „postgres” przy użyciu uwierzytelniania „peer”. Dlatego łączenie jako użytkownik systemu „postgres” działa po wyjęciu z pudełka.

Kolejność wierszy w tym pliku jest ważna, wygrywa pierwszy pasujący wiersz. Zobaczmy inny wiersz:

host all all 127.0.0.1/32 md5

Ta linia umożliwia „wszystkim” użytkownikom logowanie się przy użyciu protokołu TCP/IP („host”) z lokalnego hosta („127.0.0.1/32”) do „wszystkich” baz danych, jeśli uda im się uwierzytelnić hasłem przy użyciu metody „md5”.

Istnieje więcej metod uwierzytelniania haseł (md5, scram-sha-256, gss, ldap, …), niż możemy omówić, więc wróćmy do prostszych przykładów.

Ale najpierw musimy upewnić się, że PostgreSQL również akceptuje połączenia TCP/IP. W tym celu musimy edytować główny plik konfiguracyjny.

postgresql.conf

Plik /etc/postgresql/11/main/postgresql.conf jest głównym plikiem konfiguracyjnym dla twojego klastra PostgreSQL. Ten plik zawiera dużo ustawień i zrozumienie, co to wszystko oznacza, wcale nie jest łatwym zadaniem. Na razie spójrzmy na pierwsze ustawienie:

#listen_addresses = 'localhost'

Ta linia jest domyślnie komentowana, odkomentujmy ją, aby była odczytana:

listen_addresses = 'localhost'

Pozwoli to PostgreSQL na nasłuchiwanie przychodzących połączeń TCP/IP na hoście lokalnym, porcie 5432 (domyślny). Zapisz zmiany (musisz być „rootem”, aby to zrobić) i zrestartuj serwer Postgres, aby zmiany zaczęły obowiązywać:

sudo systemctl restart postgresql

(Pamiętaj, że w przypadku większości zmian ustawień wystarczy „załadować ponownie”, a nie „zrestartować”, ale wymaga to „restartu”).

Teraz widzimy, że Postgres nasłuchuje na porcie 5432, powiązanym z 127.0.0.1:

alice@devbox:~$ sudo netstat -tnlp | grep 5432
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      8408/postgres

Teraz skonfigurujmy nowego użytkownika i bazę danych do użytku przez aplikację.

Konfiguracja aplikacji

Połączmy się jako superużytkownik „postgres”, aby wprowadzić zmiany:

alice@devbox:~$ sudo -u postgres psql
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
Type "help" for help.

postgres=# create user myapp_user password 's3cr3t';
CREATE ROLE
postgres=# create database myapp owner myapp_user;
CREATE DATABASE
postgres=#

Stworzyliśmy teraz bazę danych o nazwie myapp i użytkownika o nazwie myapp_user ,z hasłem s3cr3t . Baza danych jest pusta i będzie własnością użytkownikamyapp_user , co oznacza, że ​​łącząc się jako myapp_user klient będzie mógł wykonać większość poleceń DDL/DML.

Połączmy się teraz z bazą danych aplikacji jako ten użytkownik aplikacji:

alice@devbox:~$ psql -h 127.0.0.1 -d myapp -U myapp_user
Password for user myapp_user:
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

myapp=>

Zadziałało! Jesteś teraz połączony z „myapp” (patrz monit), używając połączenia SSL przez aTCP/IP do 127.0.0.1. Zauważ, że podaliśmy nazwę bazy danych również w wierszu poleceń dla psql. Ze względów historycznych, jeśli zostanie to pominięte, zakłada się, że nazwa bazy danych jest taka sama jak nazwa użytkownika systemu (tutaj „alicja”), a nie o to nam chodzi. Podana jest również nazwa użytkownika PostgreSQL („-U myapp_user”).

Jeśli chcesz połączyć się z innych komputerów, musisz edytować pg_hba.conf aby dodać wiersze w ten sposób:

# existing entry, allows connections from localhost
host all   all        127.0.0.1/32 md5

# new entry to allow connections from 10.1.2.0/24 subnet,
# only to myapp database for myapp_user
host myapp myapp_user 10.1.2.0/24  md5

i przeładuj PostgreSQL („sudo systemctl reload postgresql”), aby wprowadzić zmiany.

Mając to na miejscu, możesz teraz używać w swoich aplikacjach parametrów połączenia z bazą danych, takich jak te:

# URL format
postgresql://myapp_user:[email protected]/myapp

# connection string format
host=127.0.0.1 user=myapp_user dbname=myapp password=s3cr3t

Gotowe!

Powinno to zapewnić konfigurację dedykowanej bazy danych i użytkownika dla Twojej aplikacji. Twoja platforma do tworzenia aplikacji (taka jak Django, Drupal itp.) powinna być w stanie tworzyć obiekty (takie jak tabele, widoki) i zarządzać danymi w tej bazie danych.