Ansible w pigułce: jeden węzeł sterujący wypycha konfigurację na wiele serwerów naraz, a na tych serwerach nie instalujesz żadnego dodatkowego oprogramowania.

Wyobraź sobie, że masz postawić dziesięć identycznych serwerów WWW. Logujesz się przez SSH na pierwszy, instalujesz nginx, wgrywasz konfigurację, zakładasz konto, uruchamiasz usługę. Potem to samo na drugim. I na trzecim. Po piątym mylisz się w jednym poleceniu i nagle serwery przestają być identyczne. Właśnie ten problem rozwiązuje Ansible.

W tym artykule wyjaśnimy od zera, czym Ansible jest i jak działa. Nie na slajdach, tylko na działającym labie: postawiliśmy węzeł sterujący i cztery serwery, a wszystkie zrzuty poniżej to prawdziwe wyjścia poleceń z tego środowiska. Zobaczysz playbook w akcji, zrozumiesz idempotencję i dowiesz się, dlaczego model bez agenta zrobił z Ansible ulubione narzędzie administratorów.

Z tego artykułu dowiesz się

• Czym jest Ansible i jaki problem rozwiązuje
• Dlaczego działa bez agenta i czym różni się od Puppet i Chef
• Jak wygląda inventory i polecenia ad-hoc
• Czym jest playbook i jak jednym plikiem konfigurujesz wiele serwerów
• Co to jest idempotencja i czemu jest tak ważna
• Fakty, szablony Jinja2, role i szyfrowanie sekretów (Vault)

Czym jest Ansible

Ansible to narzędzie do automatyzacji konfiguracji serwerów i wdrożeń. Zamiast ręcznie klikać i wpisywać polecenia na każdej maszynie z osobna, opisujesz stan docelowy w czytelnym pliku tekstowym, a Ansible sam doprowadza do niego wszystkie wskazane serwery. Powiesz mu: „na tych dziesięciu hostach ma być zainstalowany nginx, ma działać i ma mieć taką konfigurację”, a on wykona to na wszystkich naraz.

Ansible powstał w 2012 roku, dziś rozwija go Red Hat i jest jednym z najpopularniejszych narzędzi w świecie DevOps. Jego siła bierze się z prostoty: konfigurację zapisujesz w formacie YAML, który czyta się niemal jak zwykłą listę kroków po polsku, a do działania nie potrzebujesz niczego poza SSH i Pythonem.

Cały Ansible opiera się na kilku prostych pojęciach. Przejdziemy przez nie po kolei, pokazując każde na żywym przykładzie.

Problem, który rozwiązuje

Ręczna administracja nie skaluje się. Trzy serwery jeszcze ogarniesz, ale przy trzydziestu pojawiają się dwa problemy. Po pierwsze czas: ta sama czynność powtórzona trzydzieści razy to godziny pracy. Po drugie rozjazd konfiguracji: prędzej czy później któryś serwer dostanie inną wersję pakietu albo inny wpis w konfiguracji, i zaczyna zachowywać się inaczej niż reszta. Ansible zamyka opis serwera w pliku, który trzymasz w repozytorium razem z kodem - dzięki temu konfiguracja jest powtarzalna, wersjonowana i taka sama na każdej maszynie. Skoro konfiguracja żyje w repozytorium, warto znać podstawy kontroli wersji - jeśli dopiero zaczynasz, zajrzyj do przewodnika czym jest Git i jak z niego korzystać. Ansible często łączy się też z narzędziami do zarządzania infrastrukturą jako kodem, takimi jak Terraform, i z podejściem GitOps - pokazaliśmy taki tandem w artykule o agencie AI, który stawia maszyny Terraformem i pilnuje GitOps.

Agentless, czyli bez agenta na serwerach

Najważniejsza cecha Ansible kryje się w słowie agentless (bez agenta). Na zarządzanych serwerach nie instalujesz żadnego oprogramowania Ansible - żadnej usługi, żadnego demona działającego w tle. Ansible siedzi tylko na jednej maszynie, tak zwanym węźle sterującym (może nim być Twój laptop), i łączy się z serwerami przez zwykłe SSH. Wykorzystuje to, co i tak jest na każdym Linuksie: połączenie SSH i interpreter Pythona.

Ansible wypycha konfigurację z węzła sterującego (model push). Starsze narzędzia, jak Puppet i Chef, wymagają agenta na każdym hoście, który sam odpytuje serwer centralny (model pull).

To ogromne uproszczenie. W modelu z agentem (jak w starszych Puppet czy Chef) na każdym serwerze musisz zainstalować i utrzymywać program, który cyklicznie pyta serwer centralny o konfigurację. To kolejna rzecz do zainstalowania, zabezpieczenia i naprawiania, gdy się zepsuje. Ansible tego nie potrzebuje: model push oznacza, że to węzeł sterujący sam wypycha zmiany na serwery wtedy, kiedy Ty o to poprosisz. Start jest banalny - o czym za chwilę.

Pierwszy kontakt: instalacja, inventory i polecenia ad-hoc

Instalacja sprowadza się do jednego polecenia. Ansible to paczka Pythona, więc instalujemy go menedżerem pakietów pip:

python3 -m pip install ansible
ansible --version

Po instalacji sprawdzamy wersję. To całe przygotowanie węzła sterującego - reszta to już praca.

Inventory - lista serwerów

Ansible musi wiedzieć, czym ma zarządzać. Tę listę nazywamy inventory. To zwykły plik tekstowy, w którym grupujemy serwery - na przykład osobno serwery WWW, osobno bazy danych. Grupy pozwalają potem powiedzieć „zrób to tylko na serwerach WWW”:

# inventory.ini - lista zarzadzanych hostow
[web]
web1
web2
web3

[db]
db1

[serwery:children]
web
db

Polecenie ansible-inventory --graph pokazuje inventory jako drzewo grup. Widać grupę serwery z podgrupami web (web1, web2, web3) i db (db1).

Polecenia ad-hoc - szybkie zadania bez pliku

Zanim napiszemy pełny scenariusz, możemy odpalać pojedyncze zadania jednym poleceniem. Nazywamy je ad-hoc (doraźnymi). Klasyczny pierwszy kontakt to ping - sprawdzenie, czy Ansible dogada się ze wszystkimi hostami:

ansible serwery -m ping

Każdy host odpowiada zielonym SUCCESS i „pong”. To potwierdza, że węzeł sterujący ma połączenie SSH i Pythona na wszystkich serwerach.

Tak samo uruchomimy dowolne polecenie systemowe na całej grupie naraz. Tu pytamy serwery WWW o czas działania, a przy okazji sprawdzamy, że nginx jeszcze nie jest zainstalowany - zaraz to zmienimy playbookiem:

ansible web -m command -a "uptime"

Polecenia ad-hoc wykonują się na wszystkich serwerach WWW jednocześnie. Widać, że nginx jeszcze nie istnieje (błąd na czerwono) - to nasz punkt wyjścia.

Polecenia ad-hoc i inventory to dopiero rozgrzewka. Jeśli chcesz nauczyć się pisać kompletne playbooki, składać z nich role wielokrotnego użytku i wdrażać całe środowiska od zera, pokażemy Ci to na praktycznych warsztatach. Szkolenie Ansible: automatyzacja zadań w praktyce ma terminy gwarantowane.

Playbook - serce Ansible

Polecenia ad-hoc są wygodne do drobiazgów, ale prawdziwa moc Ansible to playbook: plik YAML, w którym opisujemy cały scenariusz konfiguracji. Playbook to lista zadań (tasks), wykonywanych po kolei na wskazanych hostach. Każde zadanie używa jakiegoś modułu - gotowego klocka, który wie, jak coś zrobić. Modułowi mówisz, jaki ma być efekt („nginx ma być zainstalowany”), a on martwi się, jak to osiągnąć na danym systemie.

Oto kompletny playbook, który stawia serwer WWW na wszystkich hostach z grupy web - instaluje nginx, zakłada konto, wgrywa stronę z szablonu, poprawia wpis w konfiguracji, uruchamia usługę i sprawdza, czy odpowiada:

---
# site.yml - postaw serwer WWW nginx na wszystkich hostach z grupy [web]
- name: Konfiguracja serwerow WWW
  hosts: web
  gather_facts: true
  vars:
    powitanie: "Ta strona zostala postawiona przez Ansible"
    admin_user: deploy

  tasks:
    - name: Zainstaluj serwer nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Zaloz konto administracyjne
      ansible.builtin.user:
        name: "{{ admin_user }}"
        groups: sudo
        shell: /bin/bash
        state: present

    - name: Wgraj strone startowa z szablonu Jinja2
      ansible.builtin.template:
        src: templates/index.html.j2
        dest: /var/www/html/index.html
        owner: www-data
        mode: "0644"

    - name: Ustaw liczbe procesow roboczych nginx
      ansible.builtin.lineinfile:
        path: /etc/nginx/nginx.conf
        regexp: "^worker_processes"
        line: "worker_processes auto;"

    - name: Uruchom serwer nginx
      ansible.builtin.command: nginx
      args:
        creates: /run/nginx.pid

    - name: Sprawdz odpowiedz serwera WWW
      ansible.builtin.uri:
        url: http://localhost
        return_content: false
      register: odpowiedz

    - name: Pokaz kod odpowiedzi HTTP
      ansible.builtin.debug:
        msg: "Serwer {{ inventory_hostname }} odpowiada kodem HTTP {{ odpowiedz.status }}"

Zwróć uwagę, jak czyta się ten plik: to niemal lista kroków po ludzku. hosts: web mówi „rób to na serwerach WWW”, a każdy - name: to jeden opisany krok. Uruchamiamy całość jednym poleceniem:

ansible-playbook site.yml

Playbook w akcji. Ansible wykonuje zadania na trzech serwerach jednocześnie. Na żółto zadania, które coś zmieniły (changed), na zielono te, które już były w porządku (ok). Na dole PLAY RECAP: changed=4 na każdym hoście.

W kolorach kryje się cała logika Ansible. Żółte „changed” to zadania, które faktycznie coś zmieniły na serwerze. Zielone „ok” oznacza, że stan już się zgadzał i nie trzeba było nic robić. Podsumowanie PLAY RECAP na dole zbiera statystyki z każdego hosta - ile zadań się wykonało i ile z nich coś zmieniło.

Efekt jest namacalny. Zadanie z modułem template wygenerowało stronę startową, podstawiając do szablonu prawdziwe dane każdego serwera (nazwę hosta, wersję systemu, adres IP). Podejrzyjmy gotowy plik prosto na serwerze web1 poleceniem cat:

Gotowy plik index.html na serwerze web1, podejrzany poleceniem cat. Nazwa hosta, system i adres IP nie są wpisane na sztywno - szablon Jinja2 podstawił je automatycznie z faktów o serwerze.

Widziałeś, jak jeden plik konfiguruje całą flotę serwerów naraz - to codzienność administratora pracującego z Ansible. Chcesz opanować playbooki, zmienne i szablony na tyle, by automatyzować własną infrastrukturę bez zaglądania do dokumentacji co chwilę? Szkolenie Ansible: automatyzacja infrastruktury dla administratorów ma terminy gwarantowane.

Idempotencja - uruchom raz albo sto razy

Dochodzimy do pojęcia, które odróżnia Ansible od zwykłego skryptu. Idempotencja oznacza, że wielokrotne uruchomienie tego samego playbooka daje ten sam efekt co jedno uruchomienie. Ansible najpierw sprawdza stan serwera i zmienia tylko to, co odbiega od opisanego celu. Jeśli wszystko już się zgadza - nie robi nic.

Ta sama konfiguracja, dwa uruchomienia. Za pierwszym razem Ansible doprowadza serwer do stanu docelowego (changed=4). Za drugim nie ma już nic do zrobienia (changed=0).

Zobaczmy to na żywo. Uruchamiamy dokładnie to samo polecenie drugi raz, bez żadnych zmian:

ansible-playbook site.yml     # to samo, drugi raz

Drugie uruchomienie: wszystkie zadania na zielono (ok), PLAY RECAP pokazuje changed=0. Nginx jest już zainstalowany, strona wgrana, usługa działa - Ansible niczego nie rusza.

To potężna właściwość w praktyce. Playbook możesz odpalać bez obaw ile razy chcesz - jako sposób na sprawdzenie, czy serwery nadal są w prawidłowym stanie, albo po dodaniu jednego nowego zadania. Ansible dołoży tylko brakującą różnicę i nie zepsuje tego, co już działa. Zwykły skrypt shellowy tak nie potrafi - próba drugiej instalacji czy dopisania tej samej linijki zwykle kończy się błędem albo duplikatem.

Co dzieje się przy jednym uruchomieniu: Ansible bierze inventory i playbook, moduły łączą się przez SSH z serwerami, doprowadzają je do stanu docelowego i zwracają raport zmian.

Fakty, szablony, role i sekrety

Powyższe wystarczy, żeby zrozumieć, czym jest Ansible. Warto jednak poznać jeszcze cztery pojęcia, które spotkasz od razu przy realnej pracy.

Fakty (facts) - Ansible sam bada serwer

Zanim wykona zadania, Ansible zbiera fakty o każdym serwerze: system operacyjny, adresy IP, ilość pamięci, zamontowane dyski i setki innych informacji. Możesz się do nich odwoływać w playbookach - na przykład zainstalować inny pakiet na Debianie, a inny na systemie z rodziny Red Hat. Podejrzyjmy fakty o dystrybucji jednego z serwerów:

ansible web1 -m setup -a "filter=ansible_distribution*"

Fakty o serwerze web1. Ansible sam wykrył, że to Debian 12. Tych danych używamy potem w playbookach i szablonach, żeby jedna konfiguracja działała na różnych systemach.

Szablony Jinja2 - jedna konfiguracja, wiele serwerów

Widziałeś już moduł template w playbooku. Korzysta on z Jinja2 - systemu szablonów, w którym w plik konfiguracyjny wstawiasz miejsca do wypełnienia w podwójnych nawiasach klamrowych. Ansible podstawia tam wartości zmiennych i faktów osobno dla każdego serwera. Dzięki temu jeden szablon obsługuje całą flotę, a każdy host dostaje swoją, właściwą wersję pliku - jak strona z poprzedniego przykładu, gdzie nazwa hosta i adres IP były podstawione automatycznie.

Tak dokładnie wygląda szablon index.html.j2, który wgrywaliśmy w playbooku. Wszystko, co stoi w podwójnych nawiasach klamrowych (podświetlone), to miejsce do wypełnienia - Ansible wstawi tam realną wartość osobno dla każdego serwera:

<!DOCTYPE html>
<html lang="pl">
<head><meta charset="utf-8"><title>{{ inventory_hostname }}</title></head>
<body>
  <h1>{{ powitanie }}</h1>
  <p>Host: {{ inventory_hostname }}</p>
  <p>System: {{ ansible_distribution }} {{ ansible_distribution_version }}</p>
  <p>Adres IP: {{ ansible_default_ipv4.address | default('n/d') }}</p>
</body>
</html>

Widać to od razu, gdy zestawimy szablon z wynikiem z poprzedniej sekcji: {{ inventory_hostname }} zamieniło się w web1, a {{ ansible_default_ipv4.address }} w konkretny adres IP tego serwera. Najlepszy dowód, że dzieje się to osobno dla każdego hosta, to pobrać gotową stronę wprost z innego serwera. Odpytajmy przez HTTP maszynę web2:

Ta sama konfiguracja, inny serwer. Strona pobrana przez HTTP z web2 ma w treści web2 i jego własny adres IP (172.19.0.2) - a powstała z dokładnie tego samego szablonu Jinja2 co strona web1. To właśnie znaczy „jedna konfiguracja, wiele serwerów”.

Role i Ansible Galaxy - porządek w większych projektach

Gdy playbooków i zadań przybywa, jeden wielki plik YAML robi się nieczytelny. Wtedy dzielimy konfigurację na role. Rola to samodzielny, gotowy do wielokrotnego użytku kawałek automatyzacji - na przykład „postaw serwer WWW” albo „skonfiguruj bazę danych” - w którym zadania, szablony, pliki i zmienne leżą w z góry ustalonych katalogach. Dzięki tej stałej strukturze Ansible sam wie, gdzie czego szukać, a Ty raz napisaną rolę wpinasz potem do dowolnego playbooka jednym wpisem.

Roli nie musisz pisać od zera. Służy do tego osobne narzędzie ansible-galaxy, a stoi za nim Ansible Galaxy - publiczny katalog ról i kolekcji współdzielonych przez społeczność. Tym samym poleceniem pobierzesz gotową rolę z internetu (ansible-galaxy role install autor.nazwa_roli) albo wygenerujesz pusty szkielet własnej:

ansible-galaxy role init webserver

To polecenie niczego nie pobiera z sieci - tworzy lokalnie kompletny szkielet katalogów nowej roli o nazwie webserver, z pustymi plikami main.yml w każdym miejscu, którego Ansible się spodziewa. Zamiast ręcznie zakładać kilkanaście folderów, dostajesz je od razu gotowe do wypełnienia:

Polecenie ansible-galaxy role init tworzy gotowy szkielet roli webserver - komplet standardowych katalogów, każdy z pustym plikiem main.yml do wypełnienia.

Każdy katalog w tym szkielecie ma z góry przypisane zadanie:

• tasks/main.yml - główna lista zadań roli, ta sama, którą wcześniej wpisywaliśmy wprost w playbooku (tu trafiłyby zadania instalujące i konfigurujące nginx).
• handlers/main.yml - procedury (handlers) uruchamiane tylko wtedy, gdy coś faktycznie się zmieniło, na przykład „przeładuj nginx po zmianie konfiguracji”.
• templates/ - szablony Jinja2 (pliki .j2), dokładnie takie jak nasz index.html.j2.
• files/ - gotowe pliki statyczne kopiowane na serwery bez żadnych zmian.
• defaults/main.yml oraz vars/main.yml - zmienne roli. W defaults trzymasz wartości domyślne, łatwe do nadpisania, a w vars te ważniejsze, o wyższym priorytecie.
• meta/main.yml - metadane roli i lista innych ról, od których ona zależy.
• tests/ oraz README.md - przykładowy playbook testowy z własnym inventory i miejsce na dokumentację roli.

Gotową rolę wpinasz do playbooka jednym wpisem roles:, a Ansible sam sięgnie po jej tasks/main.yml:

---
# site.yml - ten sam efekt co wczesniej, ale zadania siedza w roli
- name: Konfiguracja serwerow WWW
  hosts: web
  roles:
    - webserver

Odwrotny scenariusz jest jeszcze wygodniejszy: zamiast pisać rolę samodzielnie, pobierasz gotową i sprawdzoną z Ansible Galaxy. Weźmy popularną rolę geerlingguy.nginx, która potrafi postawić i skonfigurować nginx za nas. Pobieramy ją jednym poleceniem:

ansible-galaxy role install geerlingguy.nginx

Ansible Galaxy pobiera rolę geerlingguy.nginx wprost z GitHuba i rozpakowuje ją lokalnie do ~/.ansible/roles. Od tej chwili możesz jej używać w swoich playbookach.

Teraz wystarczy krótki playbook, który stosuje pobraną rolę - bez pisania własnych zadań instalujących nginx:

---
# nginx-galaxy.yml - uzyj gotowej roli pobranej z Ansible Galaxy
- name: Postaw serwer WWW rola z Galaxy
  hosts: web2
  become: true
  roles:
    - geerlingguy.nginx

Uruchamiamy go dokładnie tak samo jak każdy inny playbook:

ansible-playbook nginx-galaxy.yml

Rola z Galaxy robi całą robotę: instaluje nginx, wgrywa konfigurację i uruchamia usługę. Część jej zadań dotyczy innych systemów niż Debian, więc Ansible je pomija - stąd liczba w polu skipped w podsumowaniu.

Ansible Vault - sekrety w repozytorium

Playbooki i pliki ze zmiennymi trzymasz w repozytorium Git razem z resztą kodu - i słusznie, bo masz wtedy pełną historię zmian. Kłopot w tym, że część danych to sekrety: hasła do baz, klucze API, tokeny. Gdyby leżały w repozytorium otwartym tekstem, zobaczyłby je każdy, kto ma do niego dostęp, a po wycieku repozytorium - praktycznie każdy. Ansible Vault rozwiązuje to, szyfrując sekrety algorytmem AES256 hasłem, które znasz tylko Ty (i Twój serwer automatyzacji). Zaszyfrowane dane spokojnie commitujesz, a Ansible odszyfruje je w pamięci dopiero w chwili uruchomienia playbooka. Przejdźmy przez to krok po kroku.

Krok 1: zaszyfruj pojedynczą wartość

Najczęstszy przypadek to jeden sekret, na przykład hasło do bazy. Zamieniasz go w zaszyfrowany blok poleceniem encrypt_string:

ansible-vault encrypt_string --stdin-name db_password

Co oznaczają poszczególne części polecenia:

• encrypt_string - tryb szyfrowania pojedynczej wartości, a nie całego pliku.
• --stdin-name db_password - nazwa zmiennej, pod jaką zapiszesz sekret. Samą wartość sekretu Ansible czyta ze standardowego wejścia - wpisujesz ją w terminalu i kończysz skrótem Ctrl+D.

Po uruchomieniu Ansible poprosi najpierw o hasło Vaulta (dwa razy, drugi raz dla potwierdzenia), potem o samą wartość sekretu, a na końcu wypisze gotowy blok:

Ansible pyta dwa razy o hasło Vaulta (drugi raz dla potwierdzenia), prosi o wartość sekretu, a potem wypisuje blok !vault. Wklejasz go wprost do pliku ze zmiennymi jako wartość zmiennej db_password i spokojnie commitujesz - bez hasła Vaulta to bezużyteczny ciąg znaków.

Krok 2: albo zaszyfruj cały plik

Gdy sekretów jest więcej, wygodniej trzymać je w jednym pliku i zaszyfrować go w całości. Tworzysz zwykły plik YAML (na przykład sekrety.yml z kluczami db_password i api_key), a potem uruchamiasz:

ansible-vault encrypt sekrety.yml

Polecenie encrypt <plik> szyfruje plik w miejscu - po podaniu hasła cała czytelna treść zamienia się w nagłówek $ANSIBLE_VAULT;1.1;AES256 i blok szesnastkowy. Żeby zajrzeć do środka bez odszyfrowywania pliku na dysk, używasz ansible-vault view:

U góry zaszyfrowany plik sekrety.yml (nieczytelny blok), a pod spodem podgląd poleceniem ansible-vault view - odszyfrowana treść pojawia się dopiero po podaniu hasła i tylko na ekranie.

Krok 3: podglądaj, edytuj i zmieniaj hasło

Na zaszyfrowanym pliku pracujesz kilkoma poleceniami, bez ręcznego odszyfrowywania go na dysk:

• ansible-vault view sekrety.yml - pokazuje odszyfrowaną treść na ekranie (po podaniu hasła), nigdzie jej nie zapisując.
• ansible-vault edit sekrety.yml - otwiera plik w edytorze już odszyfrowany, a po zapisaniu automatycznie szyfruje go z powrotem.
• ansible-vault rekey sekrety.yml - zmienia hasło Vaulta, przydaje się przy rotacji haseł w zespole.
• ansible-vault decrypt sekrety.yml - trwale odszyfrowuje plik. Używaj wyjątkowo, bo zdejmuje ochronę.

Krok 4: użyj sekretu przy uruchomieniu playbooka

To najważniejszy krok, bo sam zaszyfrowany plik nic nie robi, dopóki nie sięgniesz po niego w playbooku. Sekret podpinasz jak każdą inną zmienną - na przykład wpisem vars_files: [sekrety.yml] - i odwołujesz się do niego jako {{ db_password }}. Jedyna różnica jest przy uruchamianiu: musisz podać hasło Vaulta. Interaktywnie robisz to tak:

ansible-playbook use-secret.yml --ask-vault-pass

A w automatyzacji (CI/CD) podajesz hasło z pliku, który trzymasz poza repozytorium:

ansible-playbook use-secret.yml --vault-password-file ~/.vault_pass

Znaczenie parametrów:

• --ask-vault-pass - Ansible zapyta o hasło interaktywnie, wygodne przy pracy z konsoli.
• --vault-password-file <plik> - hasło czytane z pliku, na potrzeby potoków CI/CD. Ten plik NIGDY nie trafia do repozytorium (trzymasz go w sekretach pipeline'u albo lokalnie, poza projektem).

Jeśli uruchomisz playbook bez hasła, Ansible w ogóle nie wystartuje i zgłosi błąd. Dopiero z hasłem sekret zostaje odszyfrowany w pamięci na czas działania i nigdzie nie jest zapisywany:

Pierwsze uruchomienie bez hasła kończy się błędem „Attempting to decrypt but no vault secrets found”. Drugie, z parametrem --vault-password-file, odszyfrowuje sekret w pamięci i playbook wykonuje się poprawnie (PLAY RECAP: ok=1, failed=0).

Tak domyka się bezpieczny obieg sekretu: zaszyfrowany leży w repozytorium, a odszyfrowuje się wyłącznie w pamięci i wyłącznie w chwili, gdy jest naprawdę potrzebny.

Podsumowanie

Ansible to narzędzie, które zamienia ręczną, powtarzalną administrację w jeden opisany plik. Zapamiętaj kilka rzeczy:

• Opisujesz stan docelowy, nie kolejne komendy - a Ansible sam doprowadza do niego serwery.
• Agentless - na serwerach nie instalujesz niczego, wystarczy SSH i Python.
• Playbook w YAML czyta się jak listę kroków i trzymasz go w repozytorium razem z kodem.
• Idempotencja pozwala uruchamiać playbook bez obaw, ile razy chcesz - zmienia się tylko to, co trzeba.
• Role, szablony i Vault dają porządek i bezpieczeństwo, gdy projekt rośnie.

Dobry sposób na naukę to zrobić dokładnie to, co my w tym artykule: postawić kilka maszyn (choćby w kontenerach) i napisać własny, pierwszy playbook. Ansible odwdzięcza się szybko - już pierwszy scenariusz, który konfiguruje kilka serwerów naraz, pokazuje, ile czasu oszczędza.

Szkolenie Ansible -->

Jeśli chcesz przejść od pierwszego playbooka do biegłej automatyzacji całej infrastruktury - ról, Vault, dynamicznego inventory i wdrożeń - nasze szkolenie Automatyzacja zadań z Ansible prowadzi przez to krok po kroku, na praktycznych warsztatach. Kurs ma terminy gwarantowane.

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• Czym jest DevOps i jakich narzędzi używa (i do czego)
• Kubernetes vs Docker - czym się różnią i kiedy co wybrać
• AI dla DevOpsów: agent stawia maszyny Terraformem i pilnuje GitOps
• Czym jest Git i jak z niego korzystać? Przewodnik krok po kroku
• Co to jest Prometheus? Kompletny przewodnik dla początkujących
• Czym jest SRE (Site Reliability Engineering) i jakich narzędzi używa

✕

Claude Code (Anthropic) i Codex (OpenAI) - dwaj najpopularniejsi agenci AI do kodowania w terminalu. Postawiliśmy przed nimi dokładnie to samo zadanie i nagraliśmy realny przebieg.

Jeszcze dwa lata temu asystent AI podpowiadał pojedyncze linie kodu w edytorze. Dziś pracujemy z agentami - programami, które samodzielnie czytają projekt, planują zmiany, edytują pliki, uruchamiają testy i poprawiają błędy, a my tylko opisujemy cel w zwykłym języku. Dwa najczęściej wybierane to Claude Code od Anthropic i Codex od OpenAI. W tym artykule porównamy je uczciwie: nie z folderu reklamowego, tylko na realnym zadaniu, które uruchomiliśmy w obu narzędziach.

Słowo wyjaśnienia na start. Agent to model AI, któremu dano narzędzia (może czytać i zapisywać pliki, uruchamiać polecenia) oraz pętlę działania: dostaje cel, wykonuje krok, sprawdza wynik i powtarza, aż zadanie będzie gotowe. CLI (interfejs wiersza poleceń) to praca w czarnym oknie terminala, bez klikania. Oba narzędzia, które porównujemy, to właśnie agenci uruchamiani z terminala.

Porównujemy oba narzędzia pod każdym względem, który realnie waży przy wyborze: sposób pracy z kodem, modele AI pod spodem, bezpieczeństwo (uprawnienia i piaskownica), ekosystem (wtyczki do edytorów, tryb chmurowy, standard MCP, praca zespołowa agentów, otwartość kodu) oraz koszty i plany. Najważniejsze: to porównanie robimy na żywo, a nie w teorii - każdy wniosek opieramy na realnym przebiegu w terminalu i na prawdziwych zrzutach ekranu z obu narzędzi, a nie na tabelkach z materiałów producenta.

Z tego artykułu dowiesz się

• Czym różni się Claude Code od Codeksa i skąd je wziąć
• Jak oba narzędzia poradziły sobie z tym samym zadaniem (krok po kroku, z realnymi zrzutami)
• Na jakich modelach działają i jak wybrać mocniejszy albo tańszy
• Jak pilnują bezpieczeństwa - uprawnienia i piaskownica
• Pełna tabela funkcji: IDE, chmura, MCP, open source, praca zespołowa agentów
• Ile to kosztuje i który plan wybrać
• Które narzędzie do czego lepiej pasuje

Czym są Claude Code i Codex

Oba narzędzia działają tak samo od strony użytkownika: instalujesz jedno polecenie, wchodzisz do katalogu z projektem, uruchamiasz i piszesz po ludzku, co ma się stać. Reszta to już praca agenta. Różnice zaczynają się głębiej: kto je robi, na jakich modelach działają i na jakich zasadach.

Claude Code

• Tworzone przez Anthropic (twórcy modeli Claude).
• Działa na rodzinie modeli Claude - od najszybszego po najmocniejszy do trudnych zadań.
• Wliczone w plany Pro i Max (a także zespołowe), rozliczane z limitu subskrypcji.
• Kod jest widoczny na GitHubie, ale narzędzie jest zamknięte licencyjnie (nie wolno go dowolnie kopiować ani hostować u siebie).

Codex

• Tworzone przez OpenAI (twórcy modeli GPT).
• Działa na rodzinie modeli GPT nastawionych na kodowanie.
• Wliczone w plany Plus, Pro i Business, rozliczane z limitu subskrypcji.
• Otwarty kod (open source) na licencji Apache 2.0 - można go audytować, rozwijać i uruchamiać po swojemu.

Każde z nich warto poznać osobno: podstawy Codeksa tłumaczymy w osobnym przewodniku dla początkujących, a całą pracę z Claude Code rozkładamy krok po kroku w bezpłatnym kursie Claude Code.

Tak wyglądają po uruchomieniu. Najpierw Claude Code z informacją o modelu i planie, pod spodem Codex z nazwą modelu i katalogiem roboczym. Oba czekają teraz na nasze polecenie.

Claude Code po uruchomieniu: u góry model i plan konta, na dole pole, w które wpisujemy zadanie zwykłym językiem.

Codex po uruchomieniu w tym samym katalogu: nazwa narzędzia, aktywny model i podpowiedź, że możemy poprosić o cokolwiek.

Instalacja przez npm

Najprostsza droga to menedżer pakietów npm - jest on częścią środowiska Node.js (platformy do uruchamiania programów w języku JavaScript). Jeśli nie masz go jeszcze na komputerze, najpierw zainstaluj Node.js - npm dołączy się do niego automatycznie. Sprawdź w terminalu, czy już je masz:

Kopiuj

node -v
npm -v

Jeśli w odpowiedzi zobaczysz numery wersji - masz wszystko, czego trzeba, przejdź od razu do instalacji niżej. Jeśli terminal odpowie, że nie zna takiego polecenia, zainstaluj Node.js w sposób pasujący do Twojego systemu:

• Windows i macOS - pobierz instalator z oficjalnej strony nodejs.org (wybierz wersję oznaczoną jako LTS, czyli stabilną i zalecaną) i przejdź przez kreator „dalej, dalej, zakończ". npm zainstaluje się razem z Node.js.
• macOS z Homebrew - wystarczy jedno polecenie: brew install node.
• Linux (Debian, Ubuntu) - sudo apt install nodejs npm.

Po instalacji zamknij i otwórz terminal na nowo (żeby zobaczył nowe polecenia), a potem zainstaluj oba narzędzia - każde jednym poleceniem:

Kopiuj Kopiuj

# Claude Code (Anthropic)
npm install -g @anthropic-ai/claude-code

# Codex (OpenAI)
npm install -g @openai/codex

Logowanie i konto - w obu potrzebne płatne konto

Po instalacji zostaje logowanie, i tu ważna rzecz: oba narzędzia wymagają płatnego konta. Darmowe plany (zwykły Claude.ai oraz darmowy ChatGPT) nie dają dostępu do agenta w terminalu. Wejściowy plan zaczyna się w obu przypadkach od około 20 USD miesięcznie - to Claude Pro oraz ChatGPT Plus; wyższe plany dają większe limity (szczegóły w sekcji o kosztach niżej).

Samo logowanie jest proste - uruchamiasz narzędzie w katalogu projektu, a ono otwiera przeglądarkę:

Kopiuj

# Claude Code - uruchom i zaloguj sie przez przegladarke (konto Pro/Max)
claude

# Codex - uruchom i wybierz "Sign in with ChatGPT" (konto Plus/Pro/Business)
codex

Claude Code przy pierwszym uruchomieniu prosi o wybór sposobu logowania. Wybieramy pierwszą pozycję - Claude account with subscription (konto z subskrypcją Pro, Max, Team lub Enterprise), a nie rozliczenie po API.

Claude Code, wybór sposobu logowania: pierwsza opcja to konto z subskrypcją (Pro/Max), druga to rozliczenie po API.

Zaraz potem Claude Code otwiera przeglądarkę na stronie logowania Anthropic. Jeśli okno nie otworzy się samo, w terminalu pojawia się pełny adres do skopiowania i wklejenia ręcznie. Po zalogowaniu w przeglądarce wracamy do terminala - narzędzie jest gotowe.

Gdy przeglądarka nie otworzy się sama, Claude Code wyświetla pełny adres logowania do skopiowania.

Codex po starcie pokazuje własny ekran wyboru logowania. Wybieramy Sign in with ChatGPT - to logowanie kontem OpenAI (Plus, Pro lub Business). Dwie pozostałe opcje to logowanie kodem urządzenia oraz własny klucz API.

Codex, wybór logowania: „Sign in with ChatGPT" korzysta z Twojego planu (Plus/Pro/Business), bez osobnej opłaty za API.

Dalej jest tak samo jak w Claude Code: Codex otwiera przeglądarkę, a gdy tego nie zrobi - podaje adres do wklejenia. Logujemy się kontem ChatGPT i wracamy do terminala.

Codex kończy logowanie w przeglądarce; na maszynie bez okna graficznego można przełączyć się na logowanie kodem urządzenia.

Od tej pory w obu narzędziach pracujesz w ramach limitów swojego planu, bez osobnych opłat za samo narzędzie.

Test praktyczny: to samo zadanie w obu narzędziach

Żeby porównanie miało sens, przygotowaliśmy mały, czysty projekt w Pythonie - prosty koszyk sklepu z listą kursów i metodą liczącą sumę. Możesz pobrać go i powtórzyć ten sam test u siebie:

Pobierz projekt demo (ZIP)

Do obu narzędzi wpisaliśmy identyczne polecenie:

Kopiuj

Dodaj do klasy Koszyk metodę zastosuj_kod(kod): dla kodu RABAT10 obniża
sumę o 10 procent, a inne kody zgłaszają ValueError. Napisz testy w pytest
w pliku test_sklep.py i uruchom je.

Projekt zawierał też plik z instrukcjami dla asystenta (o tym pliku za chwilę). Oba narzędzia działały na dokładnie tym samym stanie kodu - między jednym a drugim testem cofaliśmy projekt do punktu wyjścia. Zobaczmy, co się stało.

Claude Code - najpierw pyta o zgodę

Claude Code przeczytał plik, zaplanował zmianę i pokazał nam gotową różnicę (diff) - to znaczy podgląd tego, co chce dopisać, z zielonym oznaczeniem nowych linii. Zanim jednak cokolwiek zapisał na dysku, zatrzymał się i zapytał o zgodę.

Claude Code pokazuje planowaną zmianę (zielone linie) i pyta: czy zapisać tę edycję w pliku? Nic nie dzieje się bez naszej akceptacji.

Po akceptacji dopisał metodę, stworzył plik z testami, uruchomił pytest i sam sprawdził wynik. Na koniec streścił po polsku, co zrobił.

Efekt Claude Code: cztery napisane testy, wszystkie przechodzą, a niżej czytelne podsumowanie tego, co powstało. Zwróćmy uwagę - metoda liczy rabat "w locie", bez zmiany stanu koszyka.

Codex - planuje i tłumaczy swoje decyzje

Codex podszedł do tego samego zadania inaczej. Najpierw krótko opisał plan ("sprawdzę implementację i testy, potem dodam metodę zgodnie ze stylem"), zajrzał do kodu i wyjaśnił swoją decyzję projektową. Następnie zrobił zmianę, uruchomił testy i sprawdził stan repozytorium.

Codex podczas pracy: tłumaczy, że doda do koszyka pole z rabatem i przerobi metodę liczącą sumę. Widać różnicę kodu i uruchomiony test.

Efekt Codeksa: przerobione dwa pliki, testy przechodzą, podsumowanie po polsku. Tu rozwiązanie jest inne - Codex dodał do koszyka pole rabat_procent i przebudował metodę sumy.

I to jest najciekawsze w całym teście. Oba narzędzia wykonały zadanie poprawnie, ale zupełnie inaczej. Claude Code dodał osobną metodę, która liczy rabat bez ruszania stanu koszyka, i obudował ją czterema testami. Codex wolał zapisać rabat jako pole obiektu i przebudować metodę liczącą sumę, dodając dwa testy. Żadne z podejść nie jest "błędne" - to dwie różne, sensowne decyzje projektowe, dokładnie tak, jak zrobiliby to dwaj różni programiści.

Wspólny mianownik jest ważniejszy niż różnice. Oba narzędzia: przeczytały nasz plik z instrukcjami, pokazały kolorową różnicę przed zapisem, same uruchomiły testy i potwierdziły, że przechodzą. To jest właśnie pętla agenta w akcji:

Pętla agenta w akcji: cel, plan, edycja plików, uruchomienie testów i poprawki - a potem od nowa, aż wszystko przechodzi. Dokładnie tak pracują Claude Code i Codex.

Na jakich modelach działają

Siła każdego agenta to model pod spodem. Oba narzędzia pozwalają przełączać model w trakcie pracy - mocniejszy do trudnych zadań, tańszy i szybszy do prostych. W Claude Code robi to komenda wyboru modelu:

Wybór modelu w Claude Code. Domyślny jest model do codziennej, złożonej pracy; osobno mamy najmocniejszy do najtrudniejszych zadań, wydajny do rutyny i najszybszy do prostych pytań.

Podobnie u Codeksa - lista modeli od najmocniejszego po tanie i szybkie warianty, plus starsze wersje dostępne na żądanie.

Wybór modelu w Codeksie: wariant flagowy do najcięższej pracy, zbalansowany do codziennych zadań i najtańszy do prostych. Starsze modele wciąż są dostępne.

Rodzina Claude (Claude Code)

• Opus - domyślny, do codziennej i złożonej pracy, z ogromnym oknem kontekstu.
• Fable - najmocniejszy, do najtrudniejszych i najdłuższych zadań.
• Sonnet - wydajny, do rutynowych zmian.
• Haiku - najszybszy, do prostych odpowiedzi.

Rodzina GPT (Codex)

• Sol - wariant flagowy, do najcięższego kodowania i pracy agentowej.
• Terra - zbalansowany, do codziennych zadań.
• Luna - najszybszy i najtańszy, do prostych zmian.
• plus starsze modele dostępne na żądanie.

Kontekst to ilość tekstu (kodu, dokumentacji, historii rozmowy), którą model widzi naraz - im większy, tym większe fragmenty projektu agent może ogarnąć bez gubienia wątku. Claude Code udostępnia w praktyce bardzo duże okno kontekstu; Codex w wersji terminalowej pracuje na nieco mniejszym wycinku, mimo że sam model potrafi więcej. Przy ogromnych repozytoriach to realna różnica.

Bezpieczeństwo: uprawnienia i piaskownica

Agent, który sam uruchamia polecenia w Twoim systemie, brzmi groźniej niż jest - oba narzędzia mają mocne hamulce. Widzieliśmy je już wyżej: Claude Code zapytał o zgodę przed zapisem pliku. To domyślne zachowanie - każda edycja i każde polecenie wymaga akceptacji, chyba że świadomie włączymy tryb bardziej samodzielny.

Codex trzyma to samo od innej strony: pracuje w piaskownicy (po angielsku sandbox - odizolowane środowisko, w którym agent ma dostęp tylko do tego, na co pozwolisz) i pyta o zgodę przy wyjściu poza wyznaczony obszar. W panelu stanu widać aktualny tryb uprawnień. Panel otwieramy komendą /status wpisaną w oknie agenta - działa tak samo w Codeksie i w Claude Code.

Panel stanu Codeksa: aktywny model, tryb uprawnień "pytaj o zgodę", odczytany plik z instrukcjami oraz zużycie limitów - pięciogodzinnego i tygodniowego. Adres konta zamaskowaliśmy.

Oba narzędzia mają kilka poziomów swobody - od "tylko do odczytu", przez "może pisać w katalogu projektu za zgodą", po pełną samodzielność dla tych, którzy wiedzą, co robią. Pod spodem korzystają z mechanizmów izolacji wbudowanych w system operacyjny, więc agent nie wychodzi tam, gdzie nie powinien.

Claude Code

• Domyślnie pyta o zgodę przed edycją i uruchomieniem polecenia.
• Tryby: zwykły, automatyczna akceptacja edycji, tryb planowania, pełna samodzielność.
• Izolacja poleceń powłoki na poziomie systemu.

Codex

• Praca w piaskownicy: tylko odczyt, zapis w katalogu projektu albo pełny dostęp.
• Pyta o zgodę przy wyjściu poza obszar roboczy.
• Izolacja na poziomie systemu, a w chmurze - w osobnych kontenerach.

Pełne porównanie funkcji

Poza samym kodowaniem oba narzędzia dorobiły się sporego ekosystemu: wtyczek do edytorów, trybu chmurowego, współpracy wielu agentów naraz i standardu MCP. Zebraliśmy to w jednej tabeli.

MCP (Model Context Protocol) to otwarty standard, dzięki któremu agent może podłączyć się do zewnętrznych narzędzi i źródeł danych - bazy danych, systemu zgłoszeń, dokumentacji firmy - i korzystać z nich w trakcie pracy. Oba narzędzia go obsługują. W panelu stanu Claude Code widać, że ma podłączone serwery MCP:

Panel stanu Claude Code: sposób logowania, model i podłączone serwery MCP. Adres konta zamaskowaliśmy.

Warto zatrzymać się przy dwóch wierszach. Pierwszy to plik z instrukcjami. Oba narzędzia czytają na starcie specjalny plik w katalogu projektu - CLAUDE.md u jednego, AGENTS.md u drugiego - w którym opisujemy zasady: styl kodu, czego używać, czego unikać. W naszym teście oba faktycznie zastosowały się do tych zasad. Drugi wiersz to open source. Codex można pobrać, przejrzeć jego kod i uruchomić po swojemu - to ważne dla firm, które muszą audytować narzędzia. Claude Code ma kod widoczny na GitHubie, ale zamkniętą licencję.

Ile to kosztuje

Najważniejsza wiadomość: w obu przypadkach narzędzie w terminalu jest wliczone w subskrypcję czatu, którą być może już masz. Nie płaci się osobno za sam program. Płaci się za zużycie, które rozlicza się z limitów planu. Widać to na panelach stanu - jest limit odnawiany co kilka godzin i limit tygodniowy.

A jednostką, w której mierzy się to zużycie - i za którą naliczana jest opłata przy rozliczeniu za faktyczne użycie - jest token. To od liczby tokenów zależy, jak szybko topnieją limity planu i ile zapłacisz przy rozliczeniu przez klucz API.

Co to jest token? Token to najmniejszy kawałek tekstu, którym operuje model - zwykle fragment słowa. W języku polskim jeden token to mniej więcej dwa do czterech znaków: krótkie „kod" to jeden token, a dłuższa „refaktoryzacja" rozpada się na kilka. Liczą się tokeny w obie strony - to, co wysyłasz (Twoje polecenie plus pliki, które agent czyta), oraz to, co model generuje w odpowiedzi (kod, testy, wyjaśnienia). Im większy kontekst wrzucasz i im dłuższą odpowiedź dostajesz, tym więcej tokenów zużywasz.

Ile tokenów dostajesz w danym planie? Tu jest niespodzianka: plany subskrypcyjne nie dają stałej puli tokenów na miesiąc. Rozliczają zużycie w oknach czasowych - jest limit odnawiany co kilka godzin oraz limit tygodniowy - a wyższy plan po prostu podnosi te limity (u Anthropic plan Max to 5x lub 20x tego, co Pro; u OpenAI podobnie Pro względem Plus). Ile dokładnie się w nich zmieści, zależy od modelu, długości rozmowy i liczby plików, które agent czyta - dlatego żaden z dostawców nie podaje jednej stałej liczby „tokenów na miesiąc". Codex liczy zużycie okna wprost w tokenach (cięższe zadania wyczerpują je szybciej), a Claude Code pokazuje to raczej jako liczbę zapytań i czas pracy modelu. Ile zostało w bieżącym oknie, sprawdzisz w panelu stanu komendą /status.

Claude Code (Anthropic)

Codex (OpenAI)

Jedyny tryb, w którym płacisz dosłownie za każdy token, to klucz API (rozliczenie za zużycie). Cennik podaje wtedy stawkę za milion tokenów - osobno, taniej, za tokeny wejściowe i drożej za wyjściowe. Nie ma tu limitu z góry ani okna czasowego: masz pełną kontrolę nad kosztem, ale płacisz od faktycznego zużycia, a nie ryczałtem jak w subskrypcji. To rozwiązanie raczej dla automatyzacji i zespołów niż dla codziennej pracy przy jednym komputerze.

Ceny podajemy orientacyjnie - to rynek, który zmienia cenniki co kilka tygodni, a oba narzędzia potrafią dostać nowe modele i limity z miesiąca na miesiąc. Przed decyzją sprawdź aktualny cennik u źródła: cennik Anthropic oraz cennik OpenAI. Sama mechanika jest jednak stabilna: wejściowy plan za około 20 USD u obu, wyższe plany dla intensywnej pracy oraz opcja rozliczenia za tokeny przez klucz API, gdy potrzebujesz pełnej kontroli nad kosztem.

Praktyczny wniosek: jeśli masz już subskrypcję jednego z tych ekosystemów, zacznij od narzędzia, które w niej dostajesz - nie dopłacasz nic więcej. Dopiero przy naprawdę intensywnej, codziennej pracy warto rozważyć wyższe plany albo rozliczenie za tokeny.

Które wybrać?

Po tym teście nie ogłosimy jednego zwycięzcy, bo go nie ma. Oba narzędzia są dojrzałe i oba zrobiły zadanie poprawnie. A wielu doświadczonych programistów po prostu używa obu naprzemiennie - w zależności od zadania.

Claude Code sprawdzi się, gdy:

• Duże, powiązane refaktory, gdzie liczy się ogarnięcie całego projektu naraz (bardzo duże okno kontekstu).
• Praca zespołu agentów ze wspólną listą zadań.
• Jesteś już w ekosystemie Anthropic albo cenisz mocne domyślne hamulce bezpieczeństwa.

Codex sprawdzi się, gdy:

• Potrzebujesz otwartego kodu - do audytu, własnych zmian albo uruchomienia u siebie.
• Wiele niezależnych zadań uruchamianych równolegle w piaskownicach.
• Jesteś już w ekosystemie OpenAI albo zależy Ci na oszczędnym zużyciu tokenów.

Najlepsza rada jest banalna, ale prawdziwa: spróbuj obu na własnym, realnym zadaniu. Oba instalujesz jednym poleceniem, oba dostajesz w ramach subskrypcji za około 20 USD, a różnice w podejściu - takie jak te, które pokazaliśmy wyżej - najlepiej poczujesz na swoim kodzie, nie na cudzym przykładzie.

Podsumowanie

Claude Code i Codex to dwie bardzo dobre odpowiedzi na to samo pytanie: jak oddać agentowi AI nudną, powtarzalną część programowania, zachowując kontrolę nad tym, co dzieje się z kodem. Oba czytają projekt, planują, edytują pliki za naszą zgodą i same uruchamiają testy. Różnią się filozofią (zamknięte kontra otwarte), rodziną modeli, wielkością kontekstu i drobnymi decyzjami, które widać dopiero w praktyce. Wybór sprowadza się do tego, w którym ekosystemie już jesteś, czy potrzebujesz otwartego kodu i jak wyglądają Twoje zadania. A najrozsądniej - miej pod ręką oba i wybieraj w zależności od zadania.

Jeśli chcesz wejść w agentowe kodowanie na poważnie i nauczyć się wyciskać z tych narzędzi maksimum - od uprawnień i plików instrukcji, przez MCP, po pracę zespołu agentów - prowadzimy praktyczne szkolenia z obu:

Szkolenie Claude Code - od zera do zespołu agentów AI -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR - nawet do 100% kosztów.

★★★★★ Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Codex - od zera do zespołu agentów AI -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR - nawet do 100% kosztów.

★★★★★ Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs Claude Code: Claude na produkcji
• ›Kurs Claude Code: UX aplikacji z Claude
• ›Kurs Claude Code: automatyzacja CI/CD
• ›Kurs Claude Code: jak zacząć i co potrafić w 2026
• ›Kurs Claude Code: prompt engineering dla Claude
• ›Kurs Claude Code: umiejętności i możliwości Claude

Tak w skrócie pracuje Codex: od Twojego polecenia zapisanego zwykłym językiem, przez czytanie kodu i propozycję zmian, po uruchomienie i prośbę o zatwierdzenie. Poniżej rozkładamy każdy z tych kroków na czynniki pierwsze - na prawdziwych zrzutach z naszej sesji.

Coraz częściej słyszysz, że „AI samo pisze kod", a obok nazwy ChatGPT pojawia się słowo Codex. Jeśli dopiero zaczynasz, łatwo się w tym pogubić: czy to osobny program, model, wtyczka, a może wszystko naraz? W tym przewodniku wyjaśnimy prosto i bez żargonu, czym jest Codex, jak działa i jak zrobić z nim pierwszy realny krok. Żeby nie zostać na poziomie teorii, uruchomiliśmy Codeksa na czystej maszynie i przeszliśmy całą drogę sami - wszystkie zrzuty terminala poniżej pochodzą z tej właśnie sesji.

Codex to agent kodujący (po angielsku coding agent) stworzony przez OpenAI - firmę, która robi też ChatGPT. „Agent" to kluczowe słowo, do którego jeszcze wrócimy: chodzi o program, który nie tylko doradza, ale sam wykonuje pracę w Twoim projekcie. Jeśli chcesz najpierw zrozumieć samo pojęcie agenta w szerszym kontekście, zacznij od naszego wpisu Co to jest agent AI - przewodnik dla firm; tutaj skupiamy się na jednym, konkretnym agencie dla programistów.

Z tego artykułu dowiesz się

• Czym właściwie jest Codex i czym różni się od zwykłego czatu z AI
• Gdzie Codex działa: w terminalu, w edytorze kodu i w chmurze
• Jak go zainstalować i zalogować się przez konto ChatGPT oraz którego planu (i za ile) potrzebujesz
• Jak wygląda pierwsze zadanie krok po kroku - na prawdziwym przykładzie
• Jak działa piaskownica i zatwierdzanie, czyli jak zachować kontrolę nad agentem
• Jak uruchomić Codeksa bez pytań w skrypcie i automatyzacji
• Kiedy Codex się przydaje i na co warto uważać na starcie

Czym właściwie jest Codex (i czym różni się od czatu)

Najprościej: Codex to sztuczna inteligencja, która pracuje w Twoim kodzie tak, jak zrobiłby to programista siedzący obok Ciebie. Nie ogranicza się do rozmowy w oknie czatu. Codex potrafi otworzyć pliki Twojego projektu, przeczytać je, samodzielnie wprowadzić zmiany w wielu miejscach naraz, uruchomić polecenia (na przykład testy) i pokazać Ci efekt do akceptacji.

To właśnie oznacza słowo agent. Zwykły asystent w czacie odpowiada tekstem: podpowiada linijkę, którą musisz sam skopiować i wkleić, a poza tym, co mu wkleisz, nie wie nic o Twoim projekcie. Agent działa inaczej - dostaje dostęp do Twojego kodu i sam wykonuje w nim zadanie. Różnicę najlepiej widać na jednym obrazku.

Zwykły asystent doradza w oknie czatu; agent Codex wykonuje pracę bezpośrednio w projekcie i pokazuje efekt do zatwierdzenia. To ta różnica sprawia, że mówimy o „agencie", a nie o zwykłym podpowiadaczu.

Dwa pojęcia, które będą się przewijać w całym artykule, warto od razu wyjaśnić po polsku:

• Repozytorium - to po prostu katalog z Twoim projektem, zwykle prowadzony pod kontrolą systemu Git (jeśli nie wiesz, czym jest Git, mamy osobny przewodnik po Git krok po kroku). Codex czyta ten katalog i to w nim wprowadza zmiany.
• Piaskownica (po angielsku sandbox) - odizolowane, „ogrodzone" środowisko, w którym Codex uruchamia polecenia tak, żeby nie mógł przypadkiem namieszać w reszcie komputera. Do piaskownicy wrócimy w części o bezpieczeństwie.

Ważne, żeby nie mylić Codeksa z samym modelem językowym. Model to „mózg", który generuje tekst i kod; wyjaśnialiśmy to w artykule Jak działa LLM. Codex to warstwa wyżej - to całe narzędzie zbudowane wokół takiego modelu, które potrafi realnie działać na plikach i uruchamiać polecenia. Model odpowiada; agent wykonuje.

Gdzie działa Codex: terminal, edytor i chmura

Codex to nie jeden program, lecz rodzina powierzchni - kilka sposobów korzystania z tego samego agenta. Wszystkie łączy jedno konto ChatGPT i ten sam model, więc możesz zacząć w jednym miejscu, a dokończyć w innym bez utraty kontekstu.

Ten sam agent w czterech odsłonach. Dla początkującego najprostszym punktem wejścia jest wiersz poleceń (CLI) - i na nim skupimy się w tym przewodniku.

Codex CLI - agent w terminalu

To wersja konsolowa: instalujesz jedno polecenie, wpisujesz codex w terminalu i rozmawiasz z agentem wprost w oknie tekstowym. Nie wymaga żadnego dodatkowego programu, dlatego jest najlepszym startem, gdy chcesz zrozumieć, jak Codex myśli i działa. Właśnie tę wersję pokazujemy na kolejnych zrzutach.

Rozszerzenie do edytora (IDE)

Jeśli pracujesz w edytorze kodu takim jak Visual Studio Code, Cursor czy Windsurf, możesz dodać Codeksa jako panel obok kodu. Rozszerzenie jest darmowe i oficjalne - wydawcą jest OpenAI.

Rozszerzenie Codeksa do Visual Studio Code w oficjalnym sklepie. Instalujesz je jak każdą inną wtyczkę do edytora, a logujesz się tym samym kontem ChatGPT co w terminalu.

Codex w ChatGPT (chmura)

Możesz też zlecić zadanie w przeglądarce, a agent wykona je w tle na Twoim repozytorium - nawet gdy nie ma Cię przy komputerze. Ta wersja przydaje się do dłuższych zadań i pracy zespołowej, ale wymaga podłączenia repozytorium z serwisu GitHub, dlatego dla pierwszych kroków zostawiamy ją na później.

Panel startowy Codeksa w chmurze. Widać w nim wszystkie drogi wejścia oraz przycisk podłączenia repozytorium z GitHub, potrzebny do zadań uruchamianych w tle.

Jest jeszcze osobna aplikacja na komputer, która pozwala prowadzić kilku agentów naraz. Cokolwiek wybierzesz, płacisz raz - Codex korzysta z Twojego planu ChatGPT, o czym za chwilę.

Instalacja i logowanie: Sign in with ChatGPT

Cała droga od zera do pierwszego zadania sprowadza się do trzech kroków: instalacja, logowanie i pierwsze polecenie. Zajmuje to kilka minut.

Trzy kroki startu. Poniżej rozpisujemy każdy z nich, z prawdziwymi zrzutami z terminala.

Krok 1. Instalacja

Najprostsza droga to menedżer pakietów o nazwie npm. Jest on częścią środowiska Node.js (popularnej platformy do uruchamiania programów napisanych w języku JavaScript), więc jeśli nie masz go jeszcze na komputerze, najpierw zainstaluj Node.js - npm dołączany jest do niego automatycznie. Możesz sprawdzić, czy już go masz, wpisując w terminalu:

Kopiuj

node -v
npm -v

Jeśli w odpowiedzi zobaczysz numery wersji, masz wszystko, czego trzeba - przejdź od razu do polecenia instalującego Codeksa niżej. Jeśli terminal odpowie, że nie zna takiego polecenia, zainstaluj Node.js w sposób pasujący do Twojego systemu:

• Windows i macOS - pobierz instalator z oficjalnej strony nodejs.org (wybierz wersję oznaczoną jako LTS, czyli stabilną i zalecaną) i przejdź przez kreator „dalej, dalej, zakończ". npm zainstaluje się razem z Node.js.
• macOS z menedżerem Homebrew - wystarczy jedno polecenie: brew install node.
• Linux (Debian, Ubuntu) - sudo apt install nodejs npm.

Po instalacji zamknij i otwórz terminal na nowo, a potem sprawdź wersje jeszcze raz - powinny się już pokazać. Gdy masz gotowe Node.js, instalacja samego Codeksa to jedno polecenie:

Kopiuj

npm install -g @openai/codex

Jeśli wolisz w ogóle pominąć instalację Node.js, Codex ma też instalator dla systemu macOS (przez menedżer Homebrew) oraz gotowe skrypty instalacyjne, które nie wymagają npm:

Kopiuj

# macOS (Homebrew)
brew install --cask codex

# Linux / macOS - skrypt instalacyjny
curl -fsSL https://chatgpt.com/codex/install.sh | sh

Kopiuj

Po instalacji możemy sprawdzić, czy wszystko się udało, prostym poleceniem z wersją:

Instalacja zakończona sukcesem. Polecenie z flagą wersji potwierdza, że Codex jest gotowy do pracy.

Krok 2. Logowanie kontem ChatGPT

Codeksa uruchamiasz poleceniem codex. Przy pierwszym starcie wybierasz opcję Sign in with ChatGPT („zaloguj się przez ChatGPT"). To wygodne dla początkujących: nie musisz zakładać osobnego konta dla programistów ani generować klucza API - logujesz się swoim zwykłym kontem ChatGPT, a Codex korzysta z limitów Twojego planu. O tym, czy plan musi być płatny i ile to kosztuje, piszemy zaraz niżej.

Zanim Codex zacznie pracę w danym katalogu, zapyta, czy ufasz jego zawartości. To celowy bezpiecznik: agent będzie czytał pliki z tego folderu, a w nieznanym kodzie mogłyby się kryć ukryte instrukcje próbujące nim pokierować - dlatego Codex upewnia się, że świadomie otwierasz właśnie ten katalog.

Zanim ruszy do pracy, Codex pyta o zaufanie do katalogu. To pierwszy z kilku momentów, w których to Ty masz ostatnie słowo.

Po potwierdzeniu zobaczysz ekran startowy: nazwę i wersję narzędzia, wybrany model, katalog roboczy oraz pole, w które wpisujesz polecenie. Od tej chwili możesz „rozmawiać" z agentem po polsku.

Ekran startowy Codeksa. W dole widać pole „Ask Codex to do anything" - czyli miejsce, w którym zlecasz zadanie.

Czy potrzebujesz płatnego konta ChatGPT (i ile to kosztuje)

Tak - Codex działa z płatnym planem ChatGPT; darmowe konto nie wystarczy. Dobra wiadomość jest taka, że nie płacisz osobno za samego Codeksa - korzystasz z limitów planu, który już masz albo dopiero wykupisz. Do wyboru jest kilka planów (ceny podajemy orientacyjnie, bo bywają aktualizowane - najświeższe znajdziesz na oficjalnej stronie z cennikiem):

• Plus - plan dla osób prywatnych, orientacyjnie około 23 € miesięcznie. To najczęstszy wybór na start i w zupełności wystarcza, żeby poznać Codeksa.
• Pro - większe limity dla osób, które pracują z AI codziennie i intensywnie, orientacyjnie od około 103 € miesięcznie.
• Business - plan dla zespołów (od dwóch stanowisk, rozliczany rocznie), orientacyjnie około 21 € za użytkownika miesięcznie, z panelem administratora i wspólnym kontem firmowym.

Codex działa też z planami Edu oraz Enterprise. Jeśli dopiero zaczynasz, wybierz Plus - w każdej chwili możesz zmienić plan na wyższy.

Jak założyć konto i włączyć plan:

1. Wejdź na stronę chatgpt.com i załóż konto - adresem e-mail albo przez logowanie kontem Google.
2. W ustawieniach konta kliknij „Ulepsz plan" (po angielsku Upgrade) i wykup Plus. Na tym etapie podajesz dane karty płatniczej.
3. Gotowe. Tym samym kontem logujesz się w Codeksie przez „Sign in with ChatGPT" - nie musisz nic dodatkowo konfigurować.

A jak wygląda samo logowanie krok po kroku? Zajmuje kilkanaście sekund. W terminalu wpisujesz codex i wybierasz „Sign in with ChatGPT" - Codex uruchamia logowanie i podaje adres, który otwiera się w przeglądarce.

Logowanie startuje jednym poleceniem. Codex sam otwiera przeglądarkę (a jeśli tego nie zrobi, podaje adres do wklejenia) i na końcu potwierdza „Successfully logged in".

W przeglądarce wybierasz konto ChatGPT, którego chcesz użyć:

Krok 1 w przeglądarce: wybór konta ChatGPT. Dane konta zasłoniliśmy.

Następnie potwierdzasz dostęp dla Codeksa. Jeśli Twoje konto ma kilka obszarów roboczych (na przykład firmowy i prywatny), tutaj wskazujesz właściwy:

Krok 2: potwierdzenie dostępu przyciskiem „Kontynuuj". Adres e-mail konta zasłoniliśmy.

Gotowe - pojawia się potwierdzenie, a w terminalu Codex jest już zalogowany:

Krok 3: „Signed in to Codex". Zamykasz kartę i wracasz do terminala - od tej chwili możesz zlecać zadania.

Jest jeszcze druga droga, raczej dla zaawansowanych: zamiast planu ChatGPT można zalogować Codeksa kluczem API z platformy dla programistów OpenAI i płacić za faktyczne zużycie. Bywa taniej przy sporadycznym korzystaniu, ale wymaga osobnego konta rozliczeniowego - dla początkującego prostszy jest zwykły plan ChatGPT.

Twoje pierwsze zadanie krok po kroku

Teoria za nami - czas na praktykę. Przygotowaliśmy maleńki projekt: skrypt w Pythonie, który liczy statystyki sprzedaży z pliku CSV, ale ma celowo wprowadzony błąd (średnią liczy przez złą liczbę elementów). Możesz pobrać dokładnie ten sam projekt i przejść całe ćwiczenie razem z nami:

Pobierz projekt demo (ZIP)

W środku znajdziesz skrypt stats.py, plik sprzedaz.csv z przykładowymi danymi oraz krótki opis. Poprosimy teraz Codeksa, żeby ten błąd znalazł, poprawił i sprawdził wynik. Polecenie wpisujemy zwykłym językiem, po polsku:

Kopiuj Popraw błąd w obliczaniu średniej w pliku stats.py (trzeba dzielić przez liczbę elementów). Potem uruchom skrypt i pokaż wynik.

Zauważ, że nie musimy używać żadnych specjalnych komend - piszemy po ludzku, co ma się stać. Wpisane polecenie wygląda w oknie Codeksa tak:

Polecenie zapisane zwykłym językiem. Tak samo napisalibyśmy je do kolegi z zespołu.

Po zatwierdzeniu Codex najpierw przygląda się projektowi: streszcza, co zamierza zrobić, i otwiera plik, żeby zrozumieć kod. Widać to na pasku „Explored" z zapisem odczytania pliku. Agent nie zgaduje - czyta źródło, zanim cokolwiek zmieni.

Codex zapowiada plan i czyta plik, zanim wprowadzi zmianę. To dobry nawyk, którego oczekiwalibyśmy od człowieka.

Najciekawsze dzieje się w kolejnym kroku. Codex proponuje konkretną zmianę i od razu pokazuje różnicę - po angielsku nazywa się to diff: linia usuwana jest oznaczona na czerwono, a wstawiana na zielono. Następnie sam uruchamia skrypt i pokazuje jego wynik, a na końcu krótko podsumowuje, co zrobił.

Pełny cykl w jednym miejscu: różnica (diff) z poprawką, uruchomienie skryptu i poprawny wynik - średnia 162,00 zł zamiast błędnej wartości. To jest ta „magia", o którą chodzi w agentach: od polecenia do sprawdzonej zmiany.

W kilkanaście sekund agent zrobił to, co człowiek: zrozumiał kod, znalazł błąd, poprawił go w jednym miejscu i potwierdził uruchomieniem, że wynik jest już prawidłowy. I - co istotne - cały czas widzieliśmy, co robi.

Piaskownica i zatwierdzanie: jak zachować kontrolę

Skoro agent może zmieniać pliki i uruchamiać polecenia, naturalne pytanie brzmi: co go powstrzymuje przed narobieniem szkód? Codex ma na to dwie niezależne dźwignie, którymi to Ty ustawiasz poziom swobody agenta: piaskownicę (co agent może w ogóle dotknąć) oraz zatwierdzanie (kiedy pyta Cię o zgodę).

Piaskownica i zatwierdzanie to dwie osobne dźwignie. Ustawiasz je zależnie od tego, jak bardzo ufasz zadaniu i środowisku.

W praktyce, gdy uruchamiasz Codeksa domyślnie, pracuje on w trybie zapisu w katalogu roboczym z pytaniem o zgodę przy ważniejszych krokach. Możesz to sprawdzić w każdej chwili poleceniem /status, które pokazuje między innymi wybrany model, uprawnienia oraz zużycie planu (limit na kilka godzin i tygodniowy).

Panel /status. Wiersz „Permissions" pokazuje aktualny tryb (tu: zapis w projekcie z pytaniem o zgodę), a niżej widać zużycie limitów planu. Adres e-mail konta zasłoniliśmy.

Tryby możesz zmieniać wprost w trakcie sesji - służą do tego wbudowane komendy. Komenda /permissions otwiera wybór trybu pracy: od pytania o zgodę, przez automatyczne zatwierdzanie, po pełny dostęp.

Komenda /permissions pozwala przełączyć tryb pracy bez wychodzenia z sesji. Trzy gotowe zestawy odpowiadają dźwigniom z grafiki wyżej; dłuższe opisy po prawej stronie skraca szerokość okna terminala.

Z kolei komenda /model przełącza model i poziom „wysiłku", z jakim agent podchodzi do zadania:

Komenda /model przełącza model używany w sesji. Aktualnie wybrany jest oznaczony jako „current".

Te same ustawienia możesz zapisać z góry w pliku konfiguracyjnym ~/.codex/config.toml. Prosty przykład:

Kopiuj

# ~/.codex/config.toml
approval_policy = "on-request"      # pytaj o zgodę przy ważnych krokach
sandbox_mode = "workspace-write"   # pozwól zapisywać w katalogu projektu

Kopiuj

Zasada dla początkującego jest prosta: zaczynaj od trybów ostrożnych. Tryb tylko do odczytu jest świetny do poznawania cudzego kodu, a zapis w projekcie z pytaniem o zgodę wystarcza do większości codziennych zadań. Pełny dostęp (bez pytań, także poza projektem) zostaw na później i tylko dla zaufanych, odizolowanych środowisk.

Codex w skrypcie: tryb bez pytań

Interaktywne okno to nie jedyny sposób pracy. Codex ma też tryb nieinteraktywny, uruchamiany jednym poleceniem codex exec. Agent wykonuje wtedy zadanie od razu, bez pełnego interfejsu i bez zatrzymywania się na pytania - idealnie do skryptów, potoków ciągłej integracji (po angielsku CI, czyli automatycznego budowania i testowania kodu) oraz powtarzalnych czynności.

Kopiuj

codex exec -s read-only "Wyjaśnij w dwóch zdaniach, co robi skrypt stats.py."

Ten sam agent uruchomiony jednym poleceniem, bez interfejsu. Odpowiedź trafia prosto na wyjście - można ją zapisać do pliku albo przekazać dalej w skrypcie.

W tym przykładzie użyliśmy flagi trybu tylko do odczytu, więc mamy pewność, że Codex niczego nie zmieni - jedynie przeczyta kod i odpowie. To wygodny, bezpieczny sposób, żeby na przykład automatycznie streszczać zmiany albo generować krótkie opisy do zgłoszeń.

To jednak dopiero połowa obrazka. Jeśli nadasz trybowi wyższe uprawnienia - na przykład zapis w projekcie - możesz zlecić Codeksowi realną zmianę i od razu zapisanie jej w repozytorium Gita. Jednym poleceniem agent wprowadzi poprawkę, utworzy commit i wypchnie go (polecenie git push) na wskazaną gałąź:

Kopiuj

codex exec -s workspace-write "Popraw literówki w pliku README, zrób commit i wypchnij zmianę na gałąź main."

Właśnie tak buduje się drobne automatyzacje, w których agent samodzielnie realizuje zadanie i zapisuje wynik - na przykład w potoku CI, który po każdej zmianie porządkuje kod albo aktualizuje dokumentację. Pamiętaj tylko, że w trybie exec Codex nie zatrzymuje się, żeby zapytać o zgodę, więc takie polecenia uruchamiaj świadomie i w zaufanym, odizolowanym środowisku.

Kiedy Codex się przydaje (i na co uważać)

Codex nie zastępuje programisty - jest narzędziem, które oszczędza mu kilka godzin dziennie na powtarzalnej robocie. Sprawdza się szczególnie tam, gdzie trzeba zrozumieć kod i wprowadzić w nim konkretne, weryfikowalne zmiany:

• Poprawianie błędów - opisujesz objaw, agent znajduje przyczynę i proponuje poprawkę (dokładnie jak w naszym przykładzie).
• Dodawanie funkcji i refaktoryzacja - drobne przebudowy kodu w wielu plikach naraz, z podglądem różnic przed zapisem.
• Pisanie testów - agent potrafi dopisać testy i od razu je uruchomić.
• Poznawanie nowego projektu - w trybie tylko do odczytu wypytujesz o to, jak działa nieznana baza kodu.

Są też rzeczy, o których na starcie warto pamiętać. Zawsze przeglądaj różnice, zanim je zatwierdzisz - agent bywa pewny siebie, a to Ty odpowiadasz za kod. Trzymaj się trybów ostrożnych, dopóki nie nabierzesz zaufania, i nie uruchamiaj pełnego dostępu na produkcyjnym środowisku „w ciemno". I nie traktuj wyniku jak wyroczni: Codex, jak każde narzędzie AI, potrafi się pomylić, dlatego uruchomienie kodu i testy są tu najlepszym sprawdzianem. Więcej o tym, jak zmienia się rola programisty w czasach takich narzędzi, piszemy w artykule Doświadczony programista w czasach AI.

Od czego zacząć

Codex to agent kodujący od OpenAI, który realnie pracuje w Twoim projekcie - czyta pliki, proponuje zmiany, uruchamia je w piaskownicy i pyta Cię o zgodę. Dostępny jest w terminalu, w edytorze i w chmurze, a płacisz za niego swoim planem ChatGPT. Jeśli chcesz go dziś wypróbować, wystarczą trzy ruchy: zainstaluj narzędzie poleceniem npm install -g @openai/codex, uruchom codex i zaloguj się przez ChatGPT, a potem daj mu małe, konkretne zadanie w istniejącym projekcie i przejrzyj proponowane różnice. Zacznij od trybu tylko do odczytu albo zapisu z pytaniem o zgodę - tak najszybciej i najbezpieczniej złapiesz, jak Codex myśli.

Jeśli interesuje Cię pokrewne narzędzie tej klasy, mamy też obszerny, bezpłatny kurs Claude Code dla programistów. A gdy zechcesz przejść od pierwszych kroków do świadomej, zespołowej pracy z Codeksem - od trybów i integracji po budowanie współpracujących agentów - najszybszą drogą jest przejście przez to z trenerem na naszym szkoleniu.

Szkolenie Codex - od zera do zespołu agentów AI -->

To szkolenie ma terminy gwarantowane.

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• Co to jest agent AI w 2026 - kompletny przewodnik
• Bezpłatny kurs Claude Code - przewodnik dla programistów
• Czym jest Git i jak z niego korzystać? Przewodnik krok po kroku
• AI dla DevOpsów: agent stawia maszyny i pilnuje GitOps
• MCP - czym jest Model Context Protocol i dlaczego zmienia AI w firmach

Tak w praktyce wygląda praca w Snowflake: piszemy zwykłe zapytanie SQL, klikamy uruchom i po chwili mamy wynik. Tutaj policzyliśmy roczne przychody wg segmentu rynku na zbiorze około 1,5 miliona zamówień. Wynik, 35 wierszy, pojawił się w 1,6 sekundy. To prawdziwy zrzut z konta, które założyliśmy na potrzeby tego artykułu.

Snowflake to jedno z tych pojęć, które w ogłoszeniach o pracę i na konferencjach pojawia się coraz częściej, a mimo to wiele osób nie potrafi krótko powiedzieć, czym właściwie jest. Baza danych? Hurtownia? Kolejna chmura? W tym przewodniku wyjaśnimy to po kolei, bez żargonu i na prawdziwych przykładach. Wszystkie zrzuty pochodzą z żywego konta Snowflake, na którym naprawdę uruchamialiśmy zapytania, więc widzisz autentyczne wyniki.

Z tego artykułu dowiesz się:

• Czym jest Snowflake i dlaczego mówi się o nim „hurtownia danych w chmurze jako usługa"
• Jak zbudowana jest jego architektura z trzech rozdzielonych warstw i co to praktycznie daje
• Czym są wirtualne magazyny i na czym polega rozdzielenie mocy obliczeniowej od składowania danych
• Dlaczego zapytania w Snowflake są szybkie, mimo że nie zakładamy żadnych indeksów
• Jak działają Time Travel, współdzielenie danych i model rozliczeń w kredytach
• Kiedy Snowflake ma sens, a kiedy lepiej sięgnąć po coś innego

Czym właściwie jest Snowflake

Snowflake to hurtownia danych działająca w chmurze i dostarczana jako usługa (ang. Software as a Service, w skrócie SaaS, czyli gotowe oprogramowanie, z którego korzystasz przez przeglądarkę, bez instalowania i utrzymywania go u siebie). Mówiąc prościej: to miejsce, w którym firma trzyma duże ilości danych i zadaje im pytania językiem SQL, a całą maszynerię pod spodem, czyli serwery, dyski, aktualizacje i kopie zapasowe, utrzymuje dostawca. Ty logujesz się do przeglądarki i pracujesz z danymi.

Hurtownia danych (ang. data warehouse) to wyspecjalizowana baza, w której gromadzi się dane z wielu systemów firmy po to, żeby je analizować: liczyć raporty, budować pulpity, szukać wzorców. Różni się od zwykłej bazy aplikacyjnej tym, że jest zoptymalizowana pod ciężkie zapytania analityczne przechodzące przez miliony wierszy, a nie pod pojedyncze, szybkie operacje typu „dodaj zamówienie". Snowflake jest właśnie taką hurtownią, tyle że w całości w chmurze.

Warto od razu rozwiać trzy nieporozumienia. Snowflake nie jest programem, który się instaluje na własnym serwerze, bo działa wyłącznie w chmurze. Snowflake nie jest przywiązany do jednej chmury: to samo konto możesz założyć na infrastrukturze Amazona (AWS), Microsoftu (Azure) albo Google (GCP), a sposób pracy jest identyczny. I wreszcie Snowflake nie jest kolejnym silnikiem, który trzeba stroić ręcznie: nie zakładasz w nim indeksów, nie planujesz partycji, nie dobierasz parametrów serwera. Większość tej pracy platforma bierze na siebie, a Ty skupiasz się na danych i na pytaniach, które chcesz im zadać.

Darmowe konto próbne z zapasem kredytów założysz w kilka minut na signup.snowflake.com, bez podawania karty płatniczej. Pierwsze, co widzimy po zalogowaniu, to Snowsight, czyli przeglądarkowy interfejs Snowflake. To z niego pisze się zapytania, przegląda dane, buduje pulpity i zarządza kontem. Poniżej jego strona główna zaraz po założeniu darmowego konta próbnego:

Strona główna Snowsight, czyli przeglądarkowego interfejsu Snowflake, na świeżo założonym koncie próbnym. Po lewej menu (praca z danymi, katalog, zarządzanie), na środku szybkie akcje, a w rogu licznik darmowych kredytów. Cała praca odbywa się tutaj, bez instalowania czegokolwiek.

Skąd w ogóle wziął się Snowflake? Powstał z prostego spostrzeżenia: klasyczne hurtownie danych łączyły na sztywno moc obliczeniową z dyskami. Jeśli chciałeś liczyć szybciej, musiałeś dokupić większy serwer razem z dyskami, nawet jeśli danych wcale nie przybyło. A gdy dwa zespoły odpytywały hurtownię naraz, wchodziły sobie w drogę i czekały w kolejce. Snowflake rozwiązał to, rozdzielając te dwie rzeczy od siebie. To jest sedno całej platformy i właśnie od architektury zaczniemy.

Architektura: trzy rozdzielone warstwy

Snowflake jest zbudowany z trzech niezależnych warstw. To nie jest szczegół dla inżynierów, tylko klucz do zrozumienia, dlaczego platforma działa tak, jak działa. Każda warstwa skaluje się osobno i odpowiada za inną część pracy.

Trzy warstwy Snowflake. Warstwa usług koordynuje pracę (to mózg), warstwa obliczeniowa liczy zapytania (mięśnie), a warstwa składowania trzyma dane (magazyn). Kluczowe jest to, że każda z nich skaluje się niezależnie od pozostałych.

Warstwa składowania danych

Na samym dole są dane. Snowflake trzyma je w chmurze obiektowej, czyli w usłudze do przechowywania plików w chmurze (na przykład Amazon S3), i sam zajmuje się ich organizacją. Zapisuje je w formacie kolumnowym, mocno je kompresuje i dzieli na małe fragmenty zwane micro-partycjami, o których opowiemy dokładniej przy okazji wydajności. Ważne jest jedno: tych danych nie widzisz jako plików i nie musisz nimi zarządzać. Dla Ciebie to po prostu tabele, do których piszesz SQL.

Warstwa obliczeniowa

Nad danymi jest moc obliczeniowa (ang. compute), która wykonuje zapytania. W Snowflake dostarczają jej wirtualne magazyny (ang. warehouses), czyli klastry serwerów uruchamiane na żądanie. To one czytają dane, łączą tabele, liczą sumy i zwracają wynik. Magazynów może działać wiele naraz i, co najważniejsze, są od siebie niezależne. Za chwilę poświęcimy im osobną sekcję, bo to najczęściej mylona część Snowflake.

Warstwa usług chmurowych

Na górze jest warstwa, która spina całość. To ona przyjmuje Twoje logowanie, pilnuje uprawnień, przechowuje informacje o tym, jakie masz tabele i co w nich jest (tak zwane metadane, czyli dane o danych), planuje i optymalizuje zapytania oraz dba o spójność transakcji. Nazywamy ją mózgiem, bo sama nic nie liczy, ale steruje tym, co robią pozostałe warstwy. Działa w tle i zwykle w ogóle o niej nie myślisz, a to dobrze, bo to znak, że robi swoje.

Dlaczego ten podział jest tak istotny? Bo pozwala skalować każdą warstwę osobno. Masz dużo danych, ale liczysz rzadko? Płacisz głównie za składowanie, a moc włączasz na chwilę. Masz mało danych, ale liczysz je intensywnie i przez wielu użytkowników naraz? Dokładasz mocy obliczeniowej, nie ruszając składowania. W klasycznej hurtowni jedno ciągnęło drugie. Tutaj są rozłączone.

Wirtualne magazyny: moc obliczeniowa na żądanie

Do czego służą: wirtualne magazyny to moc obliczeniowa Snowflake. Każdy magazyn to osobny klaster, który wykonuje Twoje zapytania. Włączasz go, gdy potrzebujesz liczyć, powiększasz, gdy pracy jest dużo, i wyłączasz, gdy skończysz. Płacisz tylko za czas, w którym pracował.

To jest pojęcie, które najłatwiej zrozumieć na przykładzie, więc spójrzmy na listę magazynów na naszym koncie. Widać na niej trzy magazyny w rozmiarze X-Small. Jeden ma status Started, bo przed chwilą liczyliśmy na nim zapytanie z początku artykułu, a dwa pozostałe są Suspended, czyli uśpione, i nie generują żadnego kosztu.

Lista wirtualnych magazynów. Każdy to osobna moc obliczeniowa o zadanym rozmiarze (tutaj X-Small). Magazyn COMPUTE_WH jest uruchomiony, bo przed chwilą na nim liczyliśmy, a dwa pozostałe są uśpione i nic nie kosztują. Uśpienie i wybudzanie dzieje się automatycznie.

Rozmiar magazynu decyduje o jego mocy. Zaczyna się od X-Small, a kolejne rozmiary, Small, Medium, Large i dalej, to za każdym razem mniej więcej podwojenie mocy obliczeniowej. Zmiana rozmiaru to jedno kliknięcie, bez przenoszenia danych i bez przerwy w pracy:

Tworzenie magazynu i wybór rozmiaru. Od X-Small po 4X-Large (i dalej), a każdy krok w górę to około dwa razy więcej mocy. Ciężkie zapytanie na większym magazynie policzy się szybciej, ale zużyje w tym czasie więcej kredytów.

Najciekawsze jest to, jak magazyny się włączają i wyłączają. Możesz ustawić, żeby magazyn sam się usypiał po chwili bezczynności (auto-suspend) i sam wybudzał przy pierwszym zapytaniu (auto-resume). Dzięki temu nie płacisz za moc, której nikt nie używa. Poniższa animacja pokazuje ten cykl: powiększamy magazyn na czas ciężkiej pracy, a gdy nikt nie odpytuje, magazyn gaśnie i koszt obliczeń spada do zera.

Elastyczna moc obliczeniowa w Snowflake. Magazyn powiększamy na czas ciężkich zapytań, a gdy praca się kończy, sam się usypia i przestaje generować koszt. To jest istota modelu „płacisz za użycie".

Definicję magazynu zapisuje się zwykłym poleceniem SQL, więc całą tę logikę możesz mieć opisaną w kodzie i wersjonowaną razem z projektem:

-- Magazyn, ktory sam sie usypia po minucie bezczynnosci
CREATE WAREHOUSE analityka
  WAREHOUSE_SIZE = 'X-SMALL'
  AUTO_SUSPEND  = 60     -- uspij po 60 sekundach ciszy
  AUTO_RESUME   = TRUE;  -- wznow sam przy pierwszym zapytaniu

Jedna kopia danych, wiele zespołów naraz

Skoro moc obliczeniowa jest oddzielona od danych, wynika z tego coś bardzo praktycznego: kilka zespołów może pracować na tych samych danych jednocześnie, każdy na własnym magazynie, nie wchodząc sobie w drogę. W klasycznej hurtowni ciężki raport potrafił spowolnić pracę wszystkich, bo wszyscy dzielili tę samą moc. W Snowflake każdy zespół dostaje osobne mięśnie, a dane pozostają jedną, wspólną kopią.

Rozdzielenie obliczeń i danych w praktyce. Zespół ładujący dane, analitycy raportujący i zespół uczenia maszynowego korzystają z jednej kopii danych, ale każdy na własnym magazynie. Nikt nie czeka w kolejce za cudzym zapytaniem.

To rozwiązuje jeden z najstarszych bólów hurtowni danych: konflikt między tymi, którzy dane ładują, a tymi, którzy je analizują. Nocny proces ładowania może działać na swoim magazynie, analitycy na swoim, a zespół uczenia maszynowego na jeszcze innym. Jeśli któryś z magazynów okaże się za mały, powiększasz tylko jego, nie ruszając reszty. Dane cały czas są jedne i te same, więc nie ma mowy o rozjeżdżających się kopiach.

Jak wygląda codzienna praca w Snowflake

Od strony użytkownika Snowflake to przede wszystkim pisanie SQL w przeglądarce. Zapytanie z początku artykułu policzyło roczne przychody wg segmentu rynku na zbiorze przykładowym, który Snowflake udostępnia każdemu nowemu kontu. Oto dokładnie to zapytanie, gotowe do skopiowania:

-- Roczne przychody wg segmentu rynku (dane przykladowe TPC-H, ~1,5 mln zamowien)
SELECT YEAR(o_orderdate)                    AS rok,
       c_mktsegment                         AS segment,
       ROUND(SUM(o_totalprice)/1000000, 1)  AS przychod_mln_usd,
       COUNT(*)                             AS liczba_zamowien
FROM snowflake_sample_data.tpch_sf1.orders o
JOIN snowflake_sample_data.tpch_sf1.customer c
     ON c.c_custkey = o.o_custkey
GROUP BY rok, segment
ORDER BY rok, segment;

Zwróć uwagę, że to zwykły, standardowy SQL. Nie ma tu niczego specyficznego dla Snowflake poza nazwą zbioru danych. Ktokolwiek zna SQL z innej bazy, odnajdzie się tu od pierwszej minuty, i to jedna z głównych przyczyn popularności platformy.

Jeśli chcesz przejść od pierwszych zapytań do sprawnego przetwarzania danych w Snowflake, Szkolenie Snowflake ma terminy gwarantowane.

Wynik nie musi zostać suchą tabelą. W Snowsight ten sam rezultat jednym kliknięciem zamieniamy na wykres, bez eksportowania danych do innego narzędzia. Poniżej ten sam zestaw przychodów pokazany jako wykres słupkowy wg segmentu:

Ten sam wynik co w tabeli, pokazany jako wykres. W panelu po lewej wybieramy typ wykresu oraz to, co ma trafić na osie. Prosta wizualizacja powstaje bez opuszczania Snowflake i bez eksportu danych na zewnątrz.

Dane w Snowflake są zorganizowane w bazy i schematy, czyli foldery na tabele. Wbudowany eksplorator pokazuje tę strukturę i pozwala przeglądać zawartość konta. Na naszym zrzucie widać rozwinięty zbiór przykładowy z kilkoma schematami w różnych rozmiarach:

Eksplorator baz danych. Po lewej drzewo baz i schematów, po prawej szczegóły. Zbiór przykładowy nie jest tu skopiowany, tylko udostępniony przez Snowflake (widoczne pole „Shared by"), o czym więcej przy okazji współdzielenia danych.

Dlaczego zapytania są szybkie: micro-partycje i wgląd w wykonanie

Wróćmy do pytania, które zadaje sobie każdy, kto przesiada się na Snowflake z klasycznej bazy: skoro nie zakładam indeksów ani nie planuję partycji, to skąd bierze się szybkość? Odpowiedzią są micro-partycje.

Snowflake sam, bez Twojego udziału, dzieli każdą tabelę na wiele małych, skompresowanych fragmentów zwanych micro-partycjami. Dla każdego z nich zapamiętuje, jakie wartości się w nim znajdują, na przykład najmniejszą i największą datę czy kwotę. Dzięki temu, gdy pytasz o konkretny zakres, silnik od razu wie, które fragmenty w ogóle mogą zawierać wynik, a resztę pomija. Zamiast czytać całą tabelę, czyta jej ułamek.

Micro-partycje w akcji. Zapytanie o lata 2024 i nowsze każe silnikowi sięgnąć tylko po pasujące fragmenty danych, a te ze starszymi latami całkowicie pominąć. Mniej odczytanych danych to krótszy czas i mniejszy koszt, a wszystko dzieje się automatycznie.

To dlatego w Snowflake zwykle nie zakłada się indeksów. Ten mechanizm działa z automatu na każdej tabeli i w większości przypadków wystarcza. Efekt widać na liczbach. Nasze zapytanie łączące półtora miliona zamówień z bazą klientów policzyło się poniżej dwóch sekund, a gdy zajrzymy w jego szczegóły, zobaczymy dokładnie, ile trwało i na jakim magazynie:

Szczegóły wykonanego zapytania. Snowflake zapisuje o każdym zapytaniu komplet informacji: status, czas trwania (tutaj 1,6 sekundy), rozmiar użytego magazynu i znaczniki czasu. To punkt wyjścia, gdy chcemy zrozumieć, co zadecydowało o czasie wykonania zapytania.

Jeśli zapytanie działa wolno, Snowflake pokazuje jego profil wykonania, czyli rozbicie na kolejne kroki (odczyt tabel, łączenie, grupowanie) wraz z udziałem każdego z nich w czasie. To pierwsze miejsce, do którego zagląda się przy optymalizacji:

Profil wykonania zapytania. Snowflake rozkłada zapytanie na kroki i pokazuje, który z nich zajął najwięcej czasu. Tutaj najdroższy jest odczyt tabel, a całość policzyła się w niecałą sekundę czystego przetwarzania. Taki obraz zastępuje zgadywanie konkretną wiedzą, co poprawić.

Wszystkie zapytania, które kiedykolwiek uruchomiono na koncie, trafiają do historii. Można je filtrować, przeszukiwać i wracać do nich później, co jest bezcenne przy rozliczaniu kosztów i szukaniu tego jednego zapytania, które zamula system:

Historia zapytań. Każde uruchomione zapytanie zostaje zapisane wraz z czasem, statusem i tym, kto je uruchomił. To wbudowany dziennik pracy całego konta, przydatny zarówno do rozliczeń, jak i do diagnozy.

Funkcje, które lubią zespoły danych

Poza samym liczeniem SQL Snowflake ma kilka funkcji, które w codziennej pracy robią dużą różnicę. Nie sposób omówić tu wszystkich, więc wybraliśmy te, o które najczęściej pytają uczestnicy naszego szkolenia z Snowflake.

Time Travel, czyli podróż w czasie po danych

Snowflake przez zadany czas pamięta wcześniejsze wersje danych. Możesz odpytać tabelę taką, jaka była godzinę czy dzień temu, a nawet przywrócić tabelę skasowaną przez pomyłkę. Pomyłkowy UPDATE albo DROP przestaje być katastrofą, bo do stanu sprzed błędu wracasz jednym zapytaniem.

Time Travel pozwala patrzeć na dane wstecz. Odpytasz tabelę sprzed godziny, porównasz ją z obecną albo cofniesz przypadkowe skasowanie. Jak długo sięga pamięć wstecz, zależy od wybranej wersji Snowflake.

W praktyce wygląda to tak jak niżej. Pierwsze zapytanie pokazuje dane sprzed godziny, drugie przywraca właśnie usuniętą tabelę:

-- Tabela taka, jaka byla godzine temu
SELECT * FROM zamowienia AT(OFFSET => -3600);

-- Ups, skasowalismy tabele. Przywracamy ja jednym poleceniem
UNDROP TABLE zamowienia;

Współdzielenie danych bez kopiowania

Snowflake pozwala udostępnić dane innej firmie lub innemu kontu bez wysyłania plików i bez robienia kopii. Odbiorca widzi u siebie zawsze aktualne dane, a Ty zachowujesz nad nimi kontrolę. Dokładnie tak działa zbiór przykładowy, który odpytywaliśmy: nie został skopiowany na nasze konto, tylko udostępniony przez Snowflake, co widać w jego szczegółach jako pole „Shared by" na jednym z wcześniejszych zrzutów. Wokół tego mechanizmu wyrósł Snowflake Marketplace, czyli miejsce, gdzie firmy wymieniają się gotowymi zbiorami danych.

Dane półstrukturalne i język Python

Snowflake radzi sobie nie tylko z klasycznymi tabelami. Dane półstrukturalne, na przykład w formacie JSON (popularny sposób zapisu danych, w którym wartości opisane są nazwami), można wczytać do specjalnej kolumny i odpytywać SQL-em bez wcześniejszego rozkładania ich na kolumny:

-- 'dane' to kolumna typu VARIANT, w ktorej siedzi cale JSON
SELECT dane:klient.miasto::string AS miasto,
       dane:kwota::number        AS kwota
FROM zdarzenia;

Kto woli programować, może pracować z danymi w Pythonie przy pomocy biblioteki Snowpark, w której zapytania pisze się w kodzie, a wykonują się po stronie Snowflake, blisko danych. Do tego dochodzi warstwa funkcji sztucznej inteligencji (Snowflake Cortex), która pozwala wołać gotowe modeli językowe wprost z SQL. To już temat na osobny artykuł, ale warto wiedzieć, że platforma daleko wyszła poza samo raportowanie.

Za co się płaci: model kredytów

Rozliczenia w Snowflake bywają źródłem nieporozumień, więc uprośćmy je do dwóch niezależnych osi. Płacisz osobno za moc obliczeniową i osobno za składowanie danych.

Dwie niezależne osie rozliczeń. Za obliczenia płacisz w kredytach naliczanych co sekundę pracy magazynu (uśpiony magazyn nie kosztuje nic), a za składowanie osobno, ryczałtem za terabajt miesięcznie. To dlatego można trzymać dużo danych tanio, a dopłacać dopiero za realne liczenie.

Moc obliczeniową rozlicza się w kredytach. Magazyn zużywa je tylko wtedy, gdy pracuje, a naliczanie idzie co sekundę. Większy magazyn zużywa więcej kredytów na godzinę, ale ciężkie zapytanie kończy na nim szybciej, więc bywa, że większy rozmiar wychodzi podobnie kosztowo, za to daje wynik wcześniej. Kluczowe jest to, że uśpiony magazyn nie kosztuje nic, dlatego auto-suspend jest tak ważny.

Składowanie danych to zupełnie osobna opłata, liczona ryczałtem za terabajt miesięcznie, podobnie jak za dysk w chmurze. Ponieważ Snowflake mocno kompresuje dane, w praktyce zajmują one mniej miejsca niż w zwykłej bazie. Dzięki rozdzieleniu tych dwóch osi możesz trzymać ogromne ilości danych stosunkowo tanio i płacić więcej tylko wtedy, gdy naprawdę je przeliczasz.

O czym warto pamiętać: elastyczność bywa mieczem obosiecznym. Skoro powiększenie magazynu to jedno kliknięcie, równie łatwo zostawić włączoną dużą moc albo puścić nieoptymalne zapytanie po całej tabeli. Dlatego w Snowflake tak ważne są nawyki: auto-suspend, świadome dobieranie rozmiaru magazynu i zaglądanie w historię oraz profil zapytań. Tego właśnie uczymy na szkoleniu.

Kiedy Snowflake ma sens, a kiedy niekoniecznie

Snowflake nie jest odpowiedzią na każdy problem z danymi, więc warto wiedzieć, do czego pasuje, a do czego lepiej wziąć coś innego.

Sprawdzi się, gdy masz dużo danych z wielu systemów i chcesz je wspólnie analizować, gdy zależy Ci na tym, by nie utrzymywać serwerów samodzielnie, gdy wiele zespołów potrzebuje pracować na tych samych danych naraz, oraz gdy obciążenie jest nierówne, raz spokojnie, raz skokowo, bo wtedy model płatności za użycie naprawdę się opłaca.

Będzie gorszym wyborem jako baza pod aplikację obsługującą tysiące drobnych, pojedynczych zapytań na sekundę, bo do tego służą bazy operacyjne takie jak PostgreSQL. Nie jest też darmowy, więc przy małych, prostych zbiorach danych zwykła baza często wystarczy taniej. I choć upraszcza bardzo wiele, nie zwalnia z myślenia o kosztach, bo łatwość skalowania działa w obie strony.

Jak zacząć z Snowflake

Najlepszą wiadomością jest to, że próg wejścia jest niski. Snowflake udostępnia bezpłatne konto próbne z zapasem kredytów, a wszystkie zrzuty w tym artykule powstały właśnie na takim koncie. Zakładasz je w kilka minut, dostajesz gotowy zbiór przykładowy i możesz od razu pisać zapytania w przeglądarce, bez instalowania czegokolwiek.

Sensowna kolejność nauki wygląda tak. Najpierw dobrze opanuj SQL, bo to fundament pracy w Snowflake. Potem zrozum architekturę trzech warstw i wirtualne magazyny, bo bez tego trudno panować nad wydajnością i kosztami. Następnie naucz się ładować własne dane i modelować je w tabele. Na koniec zajmij się rzeczami, które odróżniają Snowflake od zwykłej bazy: Time Travel, współdzieleniem, danymi półstrukturalnymi i bezpieczeństwem. Najszybciej przechodzi się tę drogę na żywym koncie, pod okiem kogoś, kto pokaże także pułapki, których na własnej skórze wolałbyś uniknąć.

Podsumowanie

Snowflake to hurtownia danych w chmurze dostarczana jako usługa, której siła bierze się z jednego pomysłu: rozdzielenia mocy obliczeniowej od składowania danych. Dane leżą w jednej, wspólnej warstwie, a liczą je niezależne wirtualne magazyny, które włączasz, powiększasz i usypiasz zależnie od potrzeb, płacąc tylko za czas realnej pracy. Nad tym wszystkim czuwa warstwa usług, która planuje zapytania, pilnuje uprawnień i spójności. Zapytania są szybkie dzięki automatycznym micro-partycjom, a nie ręcznemu strojeniu, a funkcje takie jak Time Travel czy współdzielenie danych rozwiązują problemy, z którymi klasyczne hurtownie radziły sobie z trudem. Dla firmy oznacza to mniej utrzymania infrastruktury i elastyczne koszty, a dla osoby pracującej z danymi znajomy SQL w przeglądarce i platformę, która skaluje się razem z ambicjami. To właśnie jest Snowflake i do tego służy.

Przetwarzanie danych z użyciem Snowflake - szkolenie z praktykiem Od architektury i wirtualnych magazynów, przez ładowanie i modelowanie danych, po wydajność, Time Travel i rozliczenia. Wszystko na żywym koncie Snowflake, dokładnie na tych mechanizmach, które pokazaliśmy w artykule. Szkolenie ma terminy gwarantowane. Przyjdź na szkolenie Snowflake -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Power Query krok po kroku: import, czyszczenie i łączenie danych w Excelu i Power
• ›SQL vs. NoSQL - wielkie porównanie baz danych
• ›Co to jest KNIME? Tutorial krok po kroku
• ›Współczesne rozwiązania Big Data 2026
• ›Czym jest Power BI, Power Query i DAX?
• ›Kurs administracji PostgreSQL

Trzy plany ChatGPT, między którymi realnie wybiera firma: Plus dla jednej osoby, Business dla zespołu oraz Enterprise dla dużej organizacji. Ten artykuł rozkłada każdy z nich na czynniki - z cenami i prawdziwymi zrzutami z konta Business.

Decyzja o wprowadzeniu ChatGPT w firmie sprowadza się zwykle do dwóch pytań: który plan kupić i ile to kosztuje. Odpowiedź nie jest oczywista, bo OpenAI ma dziś kilka poziomów licencji, a nazwy potrafią mylić. W tym artykule porównamy trzy plany, które w praktyce bierze pod uwagę firma - Plus, Business i Enterprise - pokażemy ich realne ceny i wytłumaczymy, do kogo pasuje który. Żeby nie zostać na poziomie teorii, uruchomiliśmy prawdziwy plan ChatGPT Business i część zrzutów poniżej pochodzi wprost z jego panelu administratora.

Na start jedna uwaga porządkowa dla szukających planu ChatGPT Team: OpenAI zmieniło jego nazwę na ChatGPT Business. To ten sam poziom „dla zespołu", tylko dziś nazywa się Business i ma dwa typy stanowisk, o czym za chwilę.

Ten artykuł skupia się na wyborze planu i kosztach. Jeśli szukasz samego wdrożenia krok po kroku - konfiguracji panelu administratora, bezpieczeństwa danych i RODO, gotowego regulaminu korzystania z AI oraz budowania firmowych agentów - mamy o tym osobny, praktyczny przewodnik: ChatGPT Business - wdrożenie w firmie. Świetnie uzupełnia to, o czym piszemy poniżej.

Z tego artykułu dowiesz się

• Jakie poziomy licencji ma ChatGPT - od konta darmowego po Enterprise
• Ile realnie kosztują plany Plus, Business i Enterprise
• Kiedy wystarczy ChatGPT Plus i dlaczego to jeszcze nie jest rozwiązanie firmowe
• Co daje ChatGPT Business - prawdziwy panel administratora krok po kroku
• Kiedy firma dojrzewa do Enterprise i za co się wtedy płaci
• Który plan wybrać - prosta decyzja w trzech krokach
• Jak wygląda bezpieczeństwo danych i RODO w planach firmowych

Cztery poziomy: od konta prywatnego do Enterprise

ChatGPT sprzedawany jest w dwóch światach. Pierwszy to plany indywidualne, kupowane przez jedną osobę na własną kartę: darmowy, tani plan Go, popularny Plus i wydajny Pro. Drugi to plany firmowe, które tworzą wspólną, zarządzaną przestrzeń dla całego zespołu: Business i Enterprise. Poniżej realny cennik planów indywidualnych - to punkt odniesienia, zanim przejdziemy do wersji dla firm.

Cztery plany indywidualne ChatGPT: darmowy Free, tani Go, najczęściej wybierany Plus (23 euro) oraz wydajny Pro (od 103 euro). Wszystkie to licencje dla jednej osoby, bez panelu firmy.

A tak wygląda część firmowa cennika - plany Business i Enterprise:

Część firmowa cennika ChatGPT. Business ma dwa typy stanowisk - Standard (21 euro miesięcznie przy rozliczeniu rocznym) i Premium z pięciokrotnie wyższymi limitami. Enterprise wyceniany jest indywidualnie w rozmowie z działem handlowym OpenAI.

Dla firmy kluczowa jest jedna granica. Plany indywidualne kupuje pracownik dla siebie i nikt tego nie kontroluje - ani dział IT, ani dział prawny. Plany firmowe odwracają tę sytuację: powstaje jedna przestrzeń robocza (po angielsku „workspace"), do której zapraszasz ludzi na adresy służbowe, a nad całością czuwa administrator. W dalszej części porównujemy więc trzy plany: Plus jako punkt odniesienia dla pojedynczej osoby oraz dwa plany firmowe - Business i Enterprise.

Ile to kosztuje: realne ceny planów

Zacznijmy od liczb, bo to zwykle one przesądzają. Ceny podajemy w euro, zgodnie z oficjalnym cennikiem ChatGPT (stan na 2026 rok - warto je zweryfikować u źródła przed zakupem, bo dostawca je aktualizuje).

W części firmowej najważniejsza nowość względem starego planu Team to dwa typy stanowisk w planie Business (widać je na firmowym cenniku wyżej):

• Stanowisko Standard - 21 euro miesięcznie przy rozliczeniu rocznym (26 euro przy rozliczeniu miesięcznym). To wariant do codziennej pracy biurowej.
• Stanowisko Premium - 105 euro miesięcznie przy rozliczeniu rocznym (130 euro przy miesięcznym). Ma pięciokrotnie wyższe limity i zdejmuje część ograniczeń intensywnego użycia.

Wygodne jest to, że oba typy stanowisk mogą istnieć w jednej firmie obok siebie. Większość zespołu dostaje Standard, a osoby, które pracują z AI naprawdę intensywnie, dostają Premium. Tak wygląda nasze prawdziwe rozliczenie w planie Business - dwa stanowiska Standard, płatność miesięczna.

Prawdziwy panel rozliczeń naszego konta ChatGPT Business. Dwa stanowiska Standard po 26 euro dają 52 euro miesięcznie. Widać też przełącznik na rozliczenie roczne (tańsze o 19 procent) oraz domyślny typ stanowiska ustawiony na Standard.

Plus na tym tle kosztuje 23 euro miesięcznie za jedno konto, a Enterprise nie ma sztywnej ceny - jest wyceniany indywidualnie, bo dochodzą do niego negocjowane limity, wsparcie i warunki umowy. Całość różnic najłatwiej ogarnąć w jednej tabeli.

Plus, Business i Enterprise w jednej tabeli. Kolumna Business jest wyróżniona, bo to plan, do którego dojrzewa większość firm wdrażających ChatGPT u wszystkich pracowników.

ChatGPT Plus - dla jednej osoby

ChatGPT Plus to plan dla pojedynczego użytkownika. Za 23 euro miesięcznie dostajesz dostęp do zaawansowanych modeli i trybów myślenia, wyższe limity niż w wersji darmowej oraz komplet funkcji do codziennej pracy: analizę plików, generowanie obrazów, tworzenie edytowalnych dokumentów, przeszukiwanie internetu, a także agenta do kodu Codex (w niższych limitach niż w planach firmowych). Sam Codex jest zresztą dostępny w każdym planie ChatGPT, od Free po Enterprise - plany różnią się nie tym, czy go mają, tylko limitami jego użycia. Dla freelancera albo jednej osoby w firmie, która chce po prostu przyspieszyć swoją pracę, to często w zupełności wystarcza.

Problem zaczyna się wtedy, gdy z narzędzia korzysta cały zespół. Na kontach Plus każdy pracownik ma osobne, prywatne konto: firma nie wie, kto z narzędzia korzysta, jakie dane do niego trafiają ani co się z nimi dzieje, gdy pracownik odchodzi. Nie ma panelu administratora, nie ma firmowej umowy powierzenia danych, nie ma wspólnych agentów. Innymi słowy, Plus świetnie sprawdza się jako narzędzie osobiste, ale nie jako firmowe wdrożenie. Jeśli dopiero poznajesz możliwości narzędzia na koncie prywatnym, dobrym punktem wyjścia jest nasz przewodnik jak wycisnąć 100% z ChatGPT, gdzie pokazujemy tryby, projekty i budowanie własnych agentów.

ChatGPT Business - firmowe środowisko z panelem administratora

ChatGPT Business to moment, w którym korzystanie z AI przenosi się z szarej strefy prywatnych kont do środowiska, które da się rozliczyć, skonfigurować i objąć polityką bezpieczeństwa. Powstaje jedna firmowa przestrzeń robocza, do której zapraszasz pracowników, a najważniejsza różnica dotyczy danych: w planie firmowym rozmowy domyślnie nie są wykorzystywane do trenowania modeli. Sercem tego planu jest panel administratora (konsola zarządzania organizacją). Poniżej jego prawdziwy widok w naszej przestrzeni.

Panel administratora ChatGPT Business, zakładka Ogólne. Po lewej cała mapa zarządzania firmowym wdrożeniem AI. Identyfikatory organizacji i przestrzeni roboczej zamazaliśmy.

To, co widzisz po lewej stronie, w świecie kont prywatnych po prostu nie istnieje. Przejdźmy przez najważniejsze sekcje. Pierwsza to członkowie - tu administrator zaprasza i usuwa użytkowników, więc dostęp do narzędzia gaśnie razem z odejściem pracownika. Widać też, ile stanowisk jest wykupionych, ile przypisanych i kto ma jaką rolę.

Zarządzanie członkami. Widać przypisane stanowiska, role (właściciel i członek), typ stanowiska oraz zakładki oczekujących zaproszeń i próśb o dołączenie. Dane osób zamazaliśmy.

Druga sekcja to uprawnienia i role. Da się je kontrolować bardzo drobiazgowo - w naszej przestrzeni panel wylicza kilkadziesiąt przełączników: od tego, czy pracownicy mogą tworzyć osobiste tokeny dostępowe, przez lokalny dostęp do narzędzi programistycznych, po nagrywanie i transkrypcję spotkań. To jest różnica między rolą (kim jesteś w organizacji) a uprawnieniem (co konkretnie wolno Ci zrobić).

Uprawnienia i role - kilkadziesiąt przełączników. Tu administrator decyduje między innymi o tokenach dostępowych i o lokalnym dostępie do narzędzi programistycznych.

Trzecia rzecz, o którą zawsze pyta dział bezpieczeństwa, to tożsamość i dostęp. W tej sekcji firma weryfikuje własne domeny, konfiguruje logowanie jednokrotne (po angielsku „SSO" - jedno firmowe logowanie do wielu narzędzi) i decyduje o automatycznym zakładaniu kont dla osób z zaufanej domeny. To domena działu IT, ale warto wiedzieć, że w planie Business takie mechanizmy w ogóle są.

Tożsamość i dostęp: zweryfikowane domeny, logowanie jednokrotne (SSO) oraz automatyczne tworzenie kont dla osób z firmowej domeny. Tego na kontach prywatnych po prostu nie ma.

Całe firmowe wdrożenie ChatGPT - od panelu administratora, przez dobór modeli, po własne agenty - przechodzimy krok po kroku na warsztacie Szkolenie ChatGPT Business - wdrożenie w firmie.

Business daje też coś, czego indywidualny użytkownik nie ma: administrator ustala domyślny model i wysiłek myślenia dla całej organizacji, osobno dla zwykłego czatu i osobno dla trybu pracy z kodem. Dzięki temu pracownicy nie muszą się zastanawiać, a firma pilnuje rozsądnego balansu między jakością a kosztem.

Panel Modele. Administrator ustawia domyślny model, wysiłek myślenia i szybkość - osobno dla zwykłego czatu i osobno dla trybu pracy z kodem.

Wreszcie konektory (wtyczki łączące ChatGPT z systemami firmy). To one odblokowują prawdziwą wartość, bo asystent sięga po dokumenty i sprawy tam, gdzie one naprawdę żyją. Coraz częściej odbywa się to przez MCP (Model Context Protocol - wspólny standard łączenia AI z danymi i narzędziami), który rozłożyliśmy na części w artykule o tym, czym jest protokół MCP i dlaczego zmieni AI w firmach.

Konektory w panelu administratora: Gmail, GitHub, Google Drive, Google Calendar, Slack, Notion, Outlook, Canva. Każdy z osobnym statusem i regułą instalacji, którą ustawia administrator.

Jeśli chcesz zobaczyć te wszystkie elementy w kontekście pełnego wdrożenia - z regulaminem AI, Custom GPT i budowaniem agentów dla działów - opisaliśmy to osobno w tekście ChatGPT Business - wdrożenie w firmie. Tu chodzi nam przede wszystkim o to, żebyś wiedział, za co konkretnie płacisz, wybierając Business.

ChatGPT Enterprise - dla dużej organizacji

ChatGPT Enterprise to plan dla dużych organizacji, w których dochodzą wymagania niemieszczące się już w Business. Zawiera wszystko, co Business, i dokłada do tego przede wszystkim skalę oraz kontrolę: najwyższe limity użycia, rozbudowane logowanie firmowe wraz z automatyczną aprowizacją i usuwaniem kont, dłuższe i konfigurowalne zasady przechowywania danych, dedykowane wsparcie oraz umowę o gwarantowanym poziomie usługi (po angielsku „SLA").

Enterprise nie ma sztywnej ceny widocznej w cenniku - kupuje się go w rozmowie z działem handlowym OpenAI, a wycena zależy od liczby stanowisk i negocjowanych warunków. W praktyce to plan dla organizacji, które mają osobny dział IT i compliance oraz twarde wymagania bezpieczeństwa. Dla znakomitej większości firm, które chcą po prostu bezpiecznie dać ChatGPT wszystkim pracownikom, plan Business jest w zupełności wystarczający - i wielokrotnie tańszy w uruchomieniu.

Który plan wybrać

Decyzję można sprowadzić do jednego pytania na starcie: ile osób będzie korzystać i jak wrażliwe dane będą wchodzić w grę? Reszta układa się niemal sama.

Prosta decyzja w trzech krokach. Jedna osoba i dane niewrażliwe to Plus. Zespół i dane firmowe to Business. Duża organizacja z działem IT i compliance to Enterprise.

• Jedna osoba, prywatna produktywność, brak potrzeby kontroli firmy - wybierz Plus.
• Zespół albo cała firma, wspólne dane, potrzeba panelu administratora i zgodności z RODO, a do tego chęć tworzenia własnych agentów (Custom GPT) i udostępniania ich całej organizacji - wybierz Business. To najczęstszy wybór i punkt, do którego dojrzewa większość firm.
• Duża organizacja z osobnym działem IT, wymaganiami compliance i potrzebą najwyższych limitów - rozważ Enterprise.

Najczęstszy błąd to nie wybór złego planu, tylko kupienie licencji bez pomysłu na konkretne zastosowania i bez zasad, jakie dane wolno wprowadzać. Zanim więc zdecydujesz o planie, warto mieć listę realnych zadań dla AI w firmie - pomysłami dzielimy się w przeglądzie 10 zastosowań agentów AI w polskich firmach, gdzie przy każdym z dziesięciu zastosowań linkujemy do osobnego tutoriala krok po kroku, jak zbudować takiego agenta.

Bezpieczeństwo danych i RODO w skrócie

Zanim firma wpuści swoje dane do ChatGPT, pojawia się pytanie: czy to, co wpiszemy, posłuży do trenowania modelu i gdzie te dane trafiają. W planach firmowych (Business i Enterprise) odpowiedź jest korzystna i opiera się na kilku filarach, które warto znać przed rozmową z działem prawnym.

Pięć filarów ochrony danych firmowych w planach ChatGPT dla firm. Część gwarantuje dostawca, część konfiguruje administrator po stronie firmy.

W skrócie: dane z ChatGPT Business i Enterprise domyślnie nie trenują modeli, OpenAI udostępnia umowę powierzenia przetwarzania danych oraz standardowe klauzule umowne, a dla klientów z Europejskiego Obszaru Gospodarczego stroną umowy jest OpenAI Ireland. Dane są szyfrowane, a infrastruktura ma uznane certyfikaty bezpieczeństwa. Ostatni filar, kontrola dostępu, dzieje się już w panelu administratora, który pokazaliśmy wyżej.

Od czego zacząć

Sensowna kolejność jest taka: najpierw ustal, do czego w ogóle chcecie używać AI, potem policz, ile osób będzie z niej korzystać (i czy któraś potrzebuje stanowiska Premium), a na końcu wybierz plan. Dla większości firm będzie to Business ze stanowiskami Standard, z pojedynczymi stanowiskami Premium dla osób pracujących z AI najintensywniej. Zacznij od pilotażu na małej grupie i jednego realnego zastosowania, a dopiero potem skaluj licencję na całą organizację.

Dobrze poprowadzone wdrożenie zamienia rozproszone eksperymenty pojedynczych osób w spójne, bezpieczne narzędzie, z którego korzysta cała firma i które oszczędza pracownikom sporo czasu każdego dnia. Jeśli chcesz przejść tę drogę z przewodnikiem, zapraszamy na nasze szkolenie.

Szkolenie ChatGPT Business - wdrożenie w firmie -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ChatGPT Business - wdrożenie w firmie: panel administratora, RODO i agenci AI
• Jak wycisnąć 100% z ChatGPT - tryby, projekty, własne GPT i agenci AI
• Czy warto wdrażać Microsoft Copilot - najczęstsze wątpliwości managementu
• MCP (Model Context Protocol) - czym jest i dlaczego zmieni AI w firmach
• 10 zastosowań agentów AI w polskich firmach
• Jak działa LLM - duży model językowy wytłumaczony po ludzku

Cel tego poradnika: własny GPT, który odpowiada pracownikom na podstawie dokumentów firmy - oferty, procedur i najczęstszych pytań. Zbudujemy go od zera, bez pisania kodu.

W każdej firmie te same pytania krążą w kółko. Ile trwa realizacja zamówienia, jak wygląda procedura reklamacji, co jest w cenniku, kto odpowiada za dany temat. Odpowiedzi są w dokumentach, ale nikt nie chce ich za każdym razem przeszukiwać, więc pytania lądują na Slacku albo u jednej przeciążonej osoby. W tym poradniku pokażemy, jak w kilkanaście minut zbudować własnego GPT (konfigurowalnego asystenta na bazie ChatGPT), który zna dokumenty Twojej firmy i odpowiada na ich podstawie. Taki asystent nie tylko odpowie pracownikowi w kilka sekund - potrafi też przygotować wstępną odpowiedź na maila, który trafił do biura obsługi klienta, gotową do sprawdzenia i wysłania. Bez programowania, bez zewnętrznych narzędzi, w całości w oknie przeglądarki.

Dobra wiadomość na start: zbudujesz go zarówno w ChatGPT Plus, jak i w ChatGPT Business. Kreator jest w obu planach identyczny, więc każdy krok z tego poradnika wygląda tak samo niezależnie od tego, który masz. Różnica pojawia się dopiero przy udostępnianiu asystenta i ochronie danych - i to ona decyduje, który plan lepiej pasuje do wiedzy firmowej. Rozłożyliśmy to poniżej.

Sam kreator działa tak samo w Plusie i w Business. Business dokłada to, co ważne przy danych firmowych: brak trenowania na Twoich danych, umowę powierzenia i udostępnianie w obrębie firmy.

W tym poradniku zrzuty robimy w ChatGPT Business, ale jeśli masz Plusa, przejdziesz dokładnie te same kroki - Twój asystent będzie po prostu widoczny dla Ciebie i osób, które zaprosisz, zamiast publikowany w firmowej przestrzeni. Jeśli interesuje Cię szerszy obraz całego wdrożenia firmowego, opisaliśmy je w artykule ChatGPT Business - wdrożenie w firmie, gdzie pokazujemy prawdziwy panel administratora i zasady bezpieczeństwa. Tutaj skupiamy się na jednej rzeczy: zbudowaniu asystenta wiedzy firmowej krok po kroku.

Z tego poradnika dowiesz się

• Czym jest własny GPT i kiedy naprawdę warto go firmie zbudować
• Czy wystarczy ChatGPT Plus, czy lepszy Business oraz co przygotować przed startem
• Jak otworzyć kreator własnego GPT w oknie przeglądarki
• Jak napisać instrukcje, żeby asystent nie zmyślał i mówił „nie wiem”
• Jak wgrać wiedzę firmową i jak asystent z niej korzysta
• Jak przetestować asystenta, zanim udostępnisz go innym
• Jak udostępnić asystenta - sobie, zaproszonym osobom albo całej firmie - i o czym pamiętać

Czym jest własny GPT i po co go budować

Własny GPT to zwykły ChatGPT, któremu raz opisujesz, kim ma być i z jakiej wiedzy korzystać, a on od tej pory zachowuje się tak samo dla każdego, kto z niego korzysta. Nie jest to osobny program ani integracja wymagająca informatyka. To raczej formularz: wypełniasz kilka pól i masz gotowego asystenta. Najlepiej widać to, gdy rozłożymy go na części.

Własny GPT to sześć pól do wypełnienia. Najważniejsze z nich to instrukcje (charakter i zasady asystenta) oraz wiedza firmowa (wgrane dokumenty).

Naturalne pytanie brzmi: po co to robić, skoro można po prostu zapytać ChatGPT. Do jednorazowego pytania rzeczywiście wystarczy zwykła rozmowa. Własny GPT zaczyna się opłacać tam, gdzie te same pytania wracają, gdzie liczy się spójność odpowiedzi w zespole i gdzie asystent ma znać konkretne dokumenty Twojej firmy, a nie ogólną wiedzę z internetu. Poniższe zestawienie pokazuje tę różnicę wprost.

Kiedy warto zbudować własnego GPT. Do jednorazowego pytania wystarczy czat, ale gdy pytania wracają i liczy się wiedza z Twoich dokumentów, wygrywa dedykowany asystent.

Jeśli chcesz najpierw dobrze opanować sam ChatGPT i jego tryby pracy, zebraliśmy to w artykule Jak wycisnąć 100% z ChatGPT. Tutaj zakładamy, że podstawy masz już za sobą, i przechodzimy prosto do budowy asystenta. Cały proces sprowadza się do pięciu kroków, które przejdziemy po kolei.

Pięć kroków od pomysłu do gotowego asystenta. Cały proces przechodzisz w oknie przeglądarki, bez pisania kodu.

Zanim zaczniesz: konto i materiały

Do zbudowania własnego GPT wystarczy konto ChatGPT Plus albo Business - w obu kreator jest dokładnie taki sam. Jeśli robisz asystenta na własny użytek albo dla nauki, Plus w zupełności wystarczy. Jeśli natomiast wgrywasz realne dokumenty firmy i chcesz udostępnić asystenta zespołowi, wybierz Business: dane z rozmów domyślnie nie trenują tam modelu, jest umowa powierzenia danych, a administrator decyduje, kto może publikować asystentów i komu są widoczne. Prościej mówiąc, wrażliwą wiedzę firmową bezpieczniej trzymać na koncie firmowym niż na prywatnym.

Druga rzecz to materiały, czyli wiedza, na której asystent ma się opierać. Najlepiej sprawdzają się dokumenty, które i tak już masz: oferta i cennik, procedury obsługi, najczęstsze pytania klientów, standardy komunikacji, regulaminy. Nie muszą być idealne. Wystarczy, że są aktualne i zawierają odpowiedzi, których oczekujesz od asystenta.

Na potrzeby tego poradnika zbudujemy asystenta obsługi klienta dla przykładowej firmy Ziarnovia - fikcyjnego dostawcy kawy, ekspresów i serwisu do biur. Przygotowaliśmy dla niej cztery krótkie dokumenty. Możesz je pobrać i przejść całe demo dokładnie tak, jak my, albo podmienić na własne pliki.

• Pobierz PDFZiarnovia - oferta i cennik (ekspresy, kawa, serwis)
• Pobierz PDFZiarnovia - procedury obsługi klienta (dostawa, serwis, reklamacje)
• Pobierz PDFZiarnovia - najczęstsze pytania klientów
• Pobierz PDFZiarnovia - standardy komunikacji z klientem

Dobra praktyka: zanim wgrasz dokumenty, przejrzyj je pod kątem danych, których asystent nie powinien znać (na przykład dane osobowe czy wewnętrzne notatki). Asystent potraktuje wszystko, co wgrasz, jako wiarygodne źródło - dlatego wiedza powinna być czysta i aktualna.

Krok 1. Otwórz kreator własnego GPT

W bocznym menu ChatGPT otwieramy pozycję Modele GPT - to tu zbierają się wszystkie własne asystenty. Na stronie „Moje modele GPT” klikamy Utwórz model GPT. To jedno kliknięcie otwiera cały kreator, nie trzeba niczego instalować.

Wejście do kreatora: w bocznym menu otwieramy „Modele GPT”, a na stronie „Moje modele GPT” klikamy „Utwórz model GPT”.

Kreator ma dwie zakładki u góry oraz podgląd na żywo po prawej stronie.

Kreator własnego GPT tuż po otwarciu. U góry przełączasz się między zakładką Utwórz (opisujesz asystenta rozmową) a Skonfiguruj (ustawiasz wszystko ręcznie), a po prawej masz podgląd na żywo.

Zakładka Utwórz prowadzi rozmowę, w której opisujesz asystenta zwykłym językiem, a ChatGPT sam wypełnia za Ciebie pola. Zakładka Skonfiguruj pokazuje wszystkie ustawienia wprost, do ręcznej edycji. W tym poradniku pracujemy na zakładce Skonfiguruj, bo daje pełną kontrolę i dokładnie widać, co gdzie wpisujemy. Po prawej stronie przez cały czas mamy podgląd - żywe okno rozmowy, w którym można od razu przetestować asystenta.

Kreator własnego GPT, zakładka Skonfiguruj. Po lewej pola do wypełnienia (nazwa, opis, instrukcje, wiedza), po prawej podgląd na żywo. Na start wszystko jest puste.

Krok 2. Nazwa, opis i charakter asystenta

Zaczynamy od rzeczy najprostszych. Nazwa to sposób, w jaki pracownicy zobaczą asystenta na liście, więc powinna od razu mówić, do czego służy. „Asystent obsługi Ziarnovia” jest lepszy niż „Pomocnik”. Opis to jedno zdanie widoczne pod nazwą, które doprecyzowuje rolę. Te dwa pola nie wpływają na jakość odpowiedzi, ale porządkują asystentów, gdy w firmie zrobi się ich kilka.

Nazwa i opis asystenta. To pierwsze, co widzą pracownicy, dlatego warto, żeby od razu mówiły, do czego służy asystent.

Krok 3. Instrukcje - serce asystenta

To najważniejszy krok w całym procesie. Instrukcje to opis zachowania asystenta zwykłym językiem - jego charakter, zasady i granice. To tu decydujesz, na jakiej podstawie ma odpowiadać, czego mu nie wolno i jakim tonem ma mówić. Dobre instrukcje zamieniają ogólny model w konkretnego, przewidywalnego pracownika. Oto instrukcje, których użyliśmy dla asystenta Ziarnovia. Możesz je skopiować i dopasować do własnej firmy.

Kopiuj Jesteś asystentem obsługi klienta przykładowej firmy Ziarnovia, która dostarcza kawę, ekspresy i serwis do biur. Odpowiadasz wyłącznie na podstawie wgranych dokumentów: oferty i cennika, procedur obsługi, najczęstszych pytań oraz standardów komunikacji. Zasady:

1. Podawaj tylko ceny, terminy i warunki, które znajdziesz w dokumentach. Nie zmyślaj i nie podawaj cen spoza cennika.
2. Jeśli w materiałach nie ma odpowiedzi, powiedz to wprost i skieruj rozmówcę do biura obsługi, zamiast zgadywać.
3. Odpowiadaj po polsku, krótko, rzeczowo i uprzejmie, zwracając się do rozmówcy per Państwo.
4. Gdy pytanie jest niejasne, dopytaj o szczegóły, zanim odpowiesz.

Zwróć uwagę na dwie rzeczy, które są kluczowe dla firmowego zastosowania. Po pierwsze, wyraźne ograniczenie odpowiedzi do wgranych dokumentów, dzięki czemu asystent nie wymyśla informacji. Po drugie, jawne pozwolenie na powiedzenie „nie wiem”. W obsłudze klienta pewna, ale błędna odpowiedź bywa groźniejsza niż uczciwe odesłanie do człowieka. Te dwa zdania w instrukcji robią większą różnicę niż cała reszta konfiguracji.

Instrukcje wklejone w kreatorze. To one nadają asystentowi charakter: na czym się opiera, czego mu nie wolno i jak ma się zwracać do rozmówcy.

Nad samą treścią instrukcji naprawdę warto się pochylić, bo to od niej zależy jakość asystenta. Jeśli chcesz nauczyć się formułować takie polecenia skuteczniej, zebraliśmy techniki w artykule prompt engineering krok po kroku.

Chcesz opanować pisanie skutecznych poleceń i instrukcji dla ChatGPT w praktyce? Szkolenie Mistrz promptów - intensywne warsztaty z ChatGPT ma terminy gwarantowane.

Krok 4. Wgraj wiedzę firmową

Instrukcje mówią asystentowi, jak ma się zachowywać. Teraz damy mu to, na czym ma pracować. W sekcji Wiedza dołączamy pliki, które asystent będzie traktował jako źródło prawdy. Wgrywamy tu nasze cztery dokumenty firmy Ziarnovia. Obsługiwane są typowe formaty biurowe, między innymi PDF, dokumenty tekstowe i arkusze, więc zwykle nie trzeba niczego konwertować.

Cztery dokumenty firmy wgrane do sekcji Wiedza. Od tej chwili asystent odpowiada, sięgając do ich treści.

Warto rozumieć, co dzieje się pod spodem, bo to tłumaczy zarówno siłę, jak i granice takiego asystenta. Gdy pracownik zadaje pytanie, asystent najpierw przeszukuje wgrane dokumenty w poszukiwaniu pasujących fragmentów, a dopiero potem układa z nich odpowiedź. Nie „uczy się” dokumentów na pamięć - za każdym razem do nich zagląda. Dzięki temu odpowiada konkretem z Twoich materiałów, a nie ogólną wiedzą modelu.

Od pytania do odpowiedzi. Asystent przeszukuje wgrane dokumenty i odpowiada zgodnie z ich treścią. Gdy odpowiedzi nie ma w materiałach, dobrze poinstruowany asystent mówi o tym wprost.

To podejście - odpowiadanie na podstawie własnych dokumentów, a nie samej wiedzy modelu - ma swoją nazwę i swoje głębsze, techniczne warianty. Jeśli chcesz zobaczyć, jak to samo można zbudować na większą skalę, opisaliśmy kilka dróg w artykule własny asystent AI z wiedzą firmy bez kodowania.

Krok 5. Funkcje i rozpoczęcia rozmowy

Zostały dwa ustawienia, które dopracowują asystenta. Sekcja Funkcje to przełączniki dodatkowych możliwości: wyszukiwania w sieci, generowania obrazów oraz interpretera kodu i analizy danych. Dla asystenta wiedzy firmowej zwykle chcemy, żeby trzymał się wgranych dokumentów, więc te funkcje wyłączamy - inaczej asystent mógłby mieszać firmowe procedury z przypadkowymi treściami z sieci. Wyszukiwanie w sieci włączamy świadomie tylko wtedy, gdy asystent naprawdę potrzebuje aktualnych danych z zewnątrz.

Rozpoczęcia konwersacji to gotowe przykłady pytań, które pojawiają się pod oknem czatu jako klikalne podpowiedzi. Dobrze dobrane, od razu pokazują pracownikowi, do czego asystent służy i jak z nim rozmawiać. Wpisaliśmy tu cztery typowe pytania klienta firmy Ziarnovia.

Sekcja Funkcje z wyłączonymi przełącznikami (asystent trzyma się dokumentów), a po prawej podgląd z czterema rozpoczęciami konwersacji jako klikalnymi kartami.

Krok 6. Przetestuj asystenta

Zanim udostępnimy asystenta komukolwiek, sprawdzamy go w podglądzie po prawej stronie kreatora. To najważniejszy moment kontroli jakości. Zadajemy pytanie, na które odpowiedź jest w dokumentach - i patrzymy, czy asystent podaje właściwy konkret. Pytamy o cenę jednorazowego przeglądu ekspresu, która w cenniku Ziarnovia wynosi 180 zł netto.

Test odpowiedzi z wiedzy. Na pytanie o koszt przeglądu asystent podaje 180 zł netto - dokładnie tę wartość, która jest w cenniku. To znak, że korzysta z dokumentów, a nie zgaduje.

Równie ważny jest test odwrotny. Zadajemy pytanie, na które celowo nie ma odpowiedzi w dokumentach - na przykład o produkt, którego firma nie ma w ofercie. Dobrze poinstruowany asystent nie powinien niczego wymyślać. Zamiast tego przyznaje, że nie ma takiej informacji, i kieruje do biura obsługi. To właśnie działanie zasady „nie wiem” z instrukcji.

Test granicy wiedzy. Pytanie o produkt spoza oferty - asystent nie zmyśla, tylko mówi wprost, że nie ma takiej informacji, i odsyła do biura obsługi. Dokładnie tego chcemy.

Jeśli w którymś teście asystent zmyśla albo pomija oczywistą informację z dokumentów, wracamy do instrukcji i je doprecyzowujemy, po czym testujemy ponownie. Ta pętla - popraw instrukcję, sprawdź w podglądzie - to normalna część budowy. Zwykle wystarczą dwie, trzy rundy, żeby asystent zachowywał się dokładnie tak, jak chcemy.

Chcesz, żeby Twój zespół samodzielnie budował takich asystentów i agentów AI? Szkolenie Tworzenie agentów AI - Twoi wirtualni asystenci ma terminy gwarantowane.

Krok 7. Udostępnij asystenta

Asystent działa, więc czas dać go innym. Zapisujemy go przyciskiem Utwórz w prawym górnym rogu, a w oknie Udostępnianie modelu GPT ustawiamy, kto ma dostęp. Jedyny możliwy zakres to Tylko zaproszeni - publiczne udostępnianie GPT zostało wyłączone w całym ChatGPT, więc asystent nie trafia do internetu, tylko do wskazanych przez Ciebie osób. To akurat zaleta: wiedza firmowa zostaje w firmie.

Zapraszanie jest proste. W polu Dodaj osoby ze swojego obszaru roboczego u góry okna wpisujesz imię lub adres e-mail współpracownika, wybierasz go z podpowiedzi i potwierdzasz. Od tej chwili widzi on asystenta na swojej liście modeli GPT i może z niego korzystać. Kolejne osoby dodajesz tak samo, a dostęp w każdej chwili odbierzesz, usuwając kogoś z listy.

Okno udostępniania. Zakres to „Tylko zaproszeni”, a osoby dodajesz w polu u góry, wpisując imię lub adres e-mail. Dane osoby udostępniającej zasłoniliśmy.

Zasady udostępniania zależą od planu. W Business nad całością czuwa administrator - w panelu firmowym decyduje, kto może publikować własne GPT i komu wolno je udostępniać, dzięki czemu z pomysłu jednej osoby robi się kontrolowane narzędzie całej firmy. Na koncie Plus nie ma administratora ani firmowej przestrzeni, więc o dostępie decydujesz samodzielnie, zapraszając pojedyncze osoby.

Po zapisaniu asystent jest gotowy do pracy - otwiera się z własnym ekranem powitalnym, opisem i podpowiadanymi pytaniami.

Gotowy asystent - z nazwą, opisem i podpowiadanymi pytaniami. Otwierasz go jednym kliknięciem i pytasz jak zwykłego kolegę z działu, a w firmie robi to każda zaproszona osoba. Dane autora zasłoniliśmy.

O czym pamiętać: granice i dobre praktyki

Własny GPT jest szybki i tani w budowie, ale ma swoje granice. Warto je znać, żeby nie budować oczekiwań, których nie spełni. Zebraliśmy cztery zasady, które oddzielają dobrą praktykę od rozczarowania.

Cztery rzeczy, o których warto pamiętać. Najczęstsze rozczarowanie bierze się z traktowania wgranej wiedzy jak połączenia z systemem firmy na żywo.

Najważniejsza z nich dotyczy aktualności. Wgrana wiedza jest statyczna - to zdjęcie dokumentów z chwili wgrania. Gdy zmienisz cennik albo procedurę, musisz podmienić plik w bazie wiedzy, bo asystent nie zaktualizuje się sam. Jeśli potrzebujesz połączenia z systemami firmy na żywo, to już zadanie dla konektorów i protokołu MCP (wspólnego standardu łączenia AI z danymi firmy), o którym piszemy w artykule czym jest Model Context Protocol. Własny GPT z wgranymi plikami to inne, prostsze narzędzie - i do wielu zastosowań w zupełności wystarczające.

Podsumowanie: asystent w kilkanaście minut

Zbudowanie własnego GPT nie wymaga programisty ani budżetu na wdrożenie. Wystarczy konto Plus lub firmowe, kilka dokumentów i kilkanaście minut. Przeszliśmy całą drogę: od nazwy i instrukcji, przez wgranie wiedzy firmowej, po test i udostępnienie gotowego asystenta. Efektem jest asystent, który odpowiada na podstawie dokumentów Twojej firmy i uczciwie przyznaje, gdy czegoś nie wie.

Najlepszy pierwszy asystent to ten, który rozwiązuje jedno konkretne, powtarzalne zadanie w jednym dziale - odpowiadanie na typowe pytania obsługi, przygotowanie oferty według firmowych standardów czy tłumaczenie regulaminów pracownikom. Gdy zobaczysz, ile czasu oszczędza, kolejne asystenty dla innych działów zbudujesz już w kwadrans. A jeśli chcesz przejść tę drogę pod okiem praktyków i z gotowymi wzorcami dla różnych działów, zapraszamy na nasze warsztaty.

Szkolenie Tworzenie agentów AI - Twoi wirtualni asystenci →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ChatGPT Business w firmie: panel administratora, RODO i agenci AI
• Jak wycisnąć 100% z ChatGPT - tryby, projekty, własne GPT i agenci AI
• Własny RAG bez kodowania - asystent AI z wiedzą firmy
• MCP (Model Context Protocol) - czym jest i dlaczego zmieni AI w firmach
• Jak stworzyć agenta AI - 10 przykładów dla firm z tutorialami krok po kroku

Efekt kilkunastu linii kodu w pandas: przychód według kategorii i miesięczny trend sprzedaży. Do tego dojdziemy w tym artykule, pracując na jednym pliku CSV.

Pandas to najpopularniejsza biblioteka Pythona do pracy z danymi w formie tabel. Wczytuje pliki CSV, Excela czy dane z bazy, pozwala je filtrować, grupować i liczyć, a na końcu narysować wykres - wszystko w kilku czytelnych liniach. W tym artykule zainstalujemy pandas od zera, a potem na prawdziwym zbiorze sprzedaży sklepu internetowego przejdziemy przez całą ścieżkę: od wczytania danych, przez filtrowanie i grupowanie, aż po gotowy wykres do raportu. Ten sam plik i ten sam kod odtworzysz u siebie w kilka minut - dane są do pobrania niżej.

Jeśli Pythona dopiero zaczynasz, warto najpierw zajrzeć do naszego bezpłatnego kursu Python od podstaw, a potem wrócić tutaj. Do przejścia przez ten artykuł wystarczy jednak podstawowa znajomość języka.

Z tego artykułu dowiesz się:

• jak zainstalować pandas przez pip i sprawdzić, że działa
• czym jest DataFrame i jak wczytać dane z pliku CSV
• jak filtrować, grupować i liczyć na prawdziwych danych sprzedaży
• jak zamienić wynik w wykres, który trafi do raportu
• czym jest Anaconda i kiedy wybrać ją zamiast pip

Pobierz dane do ćwiczeńPlik sprzedaz_sklep_internetowy.csv - 4300 zamówień sklepu z lat 2024-2025 (kategoria, produkt, miasto, ilość, cena). Dokładnie ten sam plik widzisz na wszystkich zrzutach poniżej. Zapisz go w folderze, z którego będziesz uruchamiać Pythona.

Pobierz plik CSV

Czym jest pandas i najważniejsze pojęcie: DataFrame

Pandas dodaje do Pythona jeden kluczowy obiekt: DataFrame, czyli dwuwymiarową tabelę z nazwanymi kolumnami i ponumerowanymi wierszami - tak jak arkusz w Excelu, tylko sterowany kodem. Pojedyncza kolumna DataFrame to obiekt Series. Każda kolumna ma swój typ danych, po angielsku dtype (skrót od data type): liczby całkowite, liczby z przecinkiem, tekst albo daty. Ten typ decyduje o tym, co można z kolumną zrobić - na liczbach policzysz średnią, a z daty wyciągniesz miesiąc.

Anatomia DataFrame: kolumny mają nazwy i typy (dtype), wiersze mają indeks (etykiety 0, 1, 2...). Jedna kolumna to obiekt Series.

Cała reszta pandas sprowadza się do operacji na tym obiekcie: wybierz kolumny, odfiltruj wiersze, pogrupuj, policz, narysuj. Zobaczmy to na żywym przykładzie, ale najpierw zainstalujmy bibliotekę.

Instalacja pandas przez pip

Zakładamy, że masz zainstalowanego Pythona w wersji 3.9 lub nowszej. Jeśli jeszcze nie, przeprowadzi Cię przez to nasz wpis Instalacja Pythona i PyCharma. Mając Pythona, pandas instalujesz jednym poleceniem w terminalu (w Windowsie to Wiersz polecenia lub PowerShell, na macOS i Linuksie - Terminal):

Kopiuj

pip install pandas

Instalacja pandas przez pip. Menedżer pakietów sam dociąga zależności (m.in. numpy) i kończy komunikatem Successfully installed.

Na macOS i Linuksie polecenie brzmi często pip3 install pandas, bo samo pip może wskazywać na starego Pythona 2. Dobrym nawykiem jest tworzenie osobnego środowiska wirtualnego (po angielsku virtual environment) dla każdego projektu. To odizolowany katalog z własnym kompletem bibliotek, dzięki któremu projekty nie mieszają sobie wersji pakietów:

Kopiuj

python -m venv .venv
# Windows:
.venv\Scripts\activate
# macOS / Linux:
source .venv/bin/activate
pip install pandas

Kopiuj

Po instalacji warto sprawdzić, czy wszystko działa. Uruchamiamy Pythona i importujemy pandas. Przyjęło się skracać nazwę do pd - zobaczysz ten zapis w każdym przykładzie w sieci:

Kopiuj

python -c "import pandas as pd; print(pd.__version__)"

Sprawdzenie, że pandas działa: import biblioteki i odczyt numeru wersji. Jeśli nie widzisz błędu, możemy zaczynać analizę.

Wczytanie danych - pierwszy DataFrame

Pracujemy na pliku sprzedaz_sklep_internetowy.csv (jeśli jeszcze go nie masz, pobierz go tutaj). To 4300 zamówień fikcyjnego sklepu z elektroniką: data zamówienia, kategoria, produkt, miasto, kanał sprzedaży, ilość i cena jednostkowa. Wczytujemy plik funkcją read_csv i od razu oglądamy pierwsze wiersze metodą head. Parametr parse_dates mówi pandas, żeby kolumnę z datą potraktował jako datę, a nie zwykły tekst:

Kopiuj

import pandas as pd

df = pd.read_csv("sprzedaz_sklep_internetowy.csv", parse_dates=["data"])
df.head()

Kopiuj

Metoda head() pokazuje pierwsze pięć wierszy. Widać wszystkie kolumny i pierwsze zamówienia - dane wczytały się poprawnie.

Kod uruchamiamy w notatniku Jupyter, dlatego ostatnia linia komórki od razu wyświetla ładnie sformatowaną tabelę. W zwykłym skrypcie dopisałbyś print(df.head()). O Jupyterze więcej w części o Anacondzie.

Ile w ogóle mamy danych? Atrybut shape zwraca liczbę wierszy i kolumn:

Kopiuj

df.shape

shape zwraca parę liczb: 4300 wierszy i 8 kolumn. Pierwsza liczba to zawsze liczba wierszy.

Zanim cokolwiek policzymy, warto poznać strukturę tabeli. Metoda info wypisuje listę kolumn, liczbę niepustych wartości i typ danych każdej kolumny:

Kopiuj

df.info()

info() to pierwszy raport o danych: nazwy kolumn, brak braków (4300 wartości wszędzie) oraz typy - liczby, tekst (str) i data (datetime64).

Zwróć uwagę na typy danych: data jest typu datetime64 (dzięki parse_dates), ceny to float64 (liczby z przecinkiem), a nazwy to str (tekst). Gdyby data była zwykłym tekstem, nie moglibyśmy wyciągnąć z niej miesiąca ani zrobić wykresu w czasie.

Szybkie podsumowanie liczb metodą describe

Jedno polecenie daje komplet statystyk dla wszystkich kolumn liczbowych: średnią, odchylenie standardowe, wartości minimalną i maksymalną oraz kwartyle. Metoda round zaokrągla wynik dla czytelności:

Kopiuj

df.describe().round(2)

describe() liczy statystyki jednym poleceniem. Widać między innymi średnią cenę jednostkową i najdroższe zamówienie w całym zbiorze.

To bezcenne przy pierwszym kontakcie z danymi. Od razu widać zakres cen, typową ilość w zamówieniu i to, czy nie ma podejrzanych wartości, na przykład ujemnych. Wiersz 50% to mediana, czyli wartość środkowa - odporniejsza na pojedyncze bardzo drogie zamówienia niż zwykła średnia.

Wybieranie kolumn i filtrowanie wierszy

Pojedynczą kolumnę wybierasz przez df["nazwa"], a kilka kolumn naraz przez listę nazw w podwójnych nawiasach kwadratowych:

Kopiuj

df[["produkt", "cena_jedn"]].head()

Wybranie dwóch kolumn: produkt i cena jednostkowa. Podwójne nawiasy kwadratowe oznaczają listę kolumn do pokazania.

Najczęstsza operacja to jednak filtrowanie wierszy po warunku. Zapis w środku nawiasu (df["cena_jedn"] > 5000) tworzy tak zwaną maskę logiczną, czyli kolumnę wartości prawda albo fałsz dla każdego wiersza. Pandas zwraca tylko te wiersze, dla których warunek jest prawdziwy:

Kopiuj

df[df["cena_jedn"] > 5000].head()

Filtr po warunku: tylko zamówienia droższe niż 5000 zł za sztukę. To najczęściej używana operacja w codziennej analizie danych.

Warunki można łączyć operatorami & (i) oraz | (lub), pamiętając o nawiasach wokół każdego z nich, na przykład df[(df["kategoria"] == "Laptopy") & (df["ilosc"] > 1)]. Do precyzyjnego wskazywania wierszy i kolumn służą też df.loc (po etykietach) oraz df.iloc (po numerach pozycji).

Tworzenie nowej kolumny - przychód

W danych mamy ilość i cenę jednostkową, ale nie ma przychodu. Policzmy go. W pandas nie potrzeba do tego pętli - mnożymy dwie kolumny naraz, a wynik trafia do nowej kolumny. To tak zwana wektoryzacja: operacja wykonuje się od razu na całej kolumnie, dzięki czemu zapis jest krótki, a obliczenie bardzo szybkie. Do podglądu wybieramy zamówienia z ilością większą niż 1, żeby od razu było widać efekt mnożenia:

Kopiuj

df["przychod"] = df["ilosc"] * df["cena_jedn"]
df[df["ilosc"] > 1][["produkt", "ilosc", "cena_jedn", "przychod"]].head()

Nowa kolumna przychód powstaje z pomnożenia dwóch istniejących kolumn. Na zamówieniach z ilością większą niż 1 wyraźnie widać, że przychód to ilość razy cena jednostkowa.

Sortowanie i największe zamówienia

Które zamówienia były największe? Metoda nlargest zwraca wiersze o najwyższej wartości wskazanej kolumny, tutaj dziesięć zamówień o najwyższym przychodzie. Na końcu wybieramy kilka kolumn, żeby wynik był czytelny:

Kopiuj

df.nlargest(10, "przychod")[["data", "produkt", "ilosc", "cena_jedn", "przychod"]]

Dziesięć największych zamówień według przychodu. Na szczycie drogie laptopy kupowane po dwie sztuki. Ogólne sortowanie robi metoda sort_values.

Grupowanie - serce analizy (groupby)

Najciekawsze pytania dotyczą grup: która kategoria zarabia najwięcej, które miasto kupuje najchętniej. Służy do tego groupby, które działa według schematu podziel, policz, połącz (po angielsku split-apply-combine): pandas dzieli dane na grupy według wskazanej kolumny, w każdej grupie wykonuje obliczenie (tu sumę przychodu), a potem składa wyniki w jedną tabelę. Na koniec sortujemy malejąco:

Kopiuj

przychod_kat = df.groupby("kategoria")["przychod"].sum().sort_values(ascending=False)
przychod_kat

groupby sumuje przychód w każdej kategorii. Widać od razu, że Laptopy i Smartfony odpowiadają za większą część obrotu.

Liczby robią wrażenie, ale wykres przekonuje szybciej. Pandas ma wbudowane rysowanie - metoda plot na naszym wyniku tworzy gotowy wykres słupkowy. Parametr kind="barh" to słupki poziome, a color ustawia ich kolor:

Pierwszy wykres wprost z danych

Kopiuj

przychod_kat.sort_values().plot(kind="barh", color="#E02D33",
                                title="Przychód wg kategorii", xlabel="przychód [zł]");

Ten sam wynik jako wykres słupkowy - kilka słów w wywołaniu plot() i mamy gotowy obraz do raportu. Laptopy na czele.

Średnik na końcu linii to drobiazg z notatnika Jupyter - ukrywa techniczny komunikat o obiekcie wykresu. W zwykłym skrypcie dopisz na górze import matplotlib.pyplot as plt, a na dole plt.show(), żeby okno z wykresem się pojawiło. Pandas rysuje przy pomocy biblioteki matplotlib, którą instaluje się tak samo prosto: pip install matplotlib.

Chcesz przejść od pojedynczych analiz do sprawnej, codziennej pracy z danymi w Pythonie pod okiem praktyka? Szkolenie Analiza danych w języku Python ma terminy gwarantowane.

Ile zamówień w każdej kategorii - value_counts

Uwaga na pułapkę: największy przychód nie znaczy najwięcej zamówień. Metoda value_counts zlicza, ile razy występuje każda wartość w kolumnie:

Kopiuj

df["kategoria"].value_counts()

value_counts liczy zamówienia w kategoriach. Akcesoria mają ich najwięcej, choć w przychodzie były na ostatnim miejscu.

To jest właśnie ten moment, dla którego robi się analizę danych. Akcesoria to najczęstsze zamówienia, ale najniższy przychód - dużo tanich transakcji. Z laptopami jest odwrotnie: mało zamówień, ale każde wysokie. Bez zestawienia tych dwóch liczb łatwo o złą decyzję, na przykład o promowaniu nie tej kategorii, co trzeba.

Tabela przestawna - pivot_table

Jeśli znasz tabele przestawne z Excela, poczujesz się jak w domu. pivot_table rozkłada jedną wartość na dwa wymiary. Sprawdźmy przychód w układzie kategoria (wiersze) wobec kanału sprzedaży (kolumny). Parametr margins=True dodaje wiersz i kolumnę z sumami:

Kopiuj

pd.pivot_table(df, values="przychod", index="kategoria",
               columns="kanal", aggfunc="sum", margins=True).round(0)

Tabela przestawna: kategoria wobec kanału sprzedaży. Kolumna All to suma dla każdej kategorii, a wiersz All - dla każdego kanału.

Analiza w czasie - trend miesięczny (resample)

Skoro kolumna z datą ma typ daty, możemy łatwo agregować po czasie. Ustawiamy datę jako indeks, a metoda resample grupuje dane w równe przedziały czasu. Tutaj "ME" oznacza końce kolejnych miesięcy (od angielskiego month end). Sumujemy przychód i od razu rysujemy:

Kopiuj

miesiecznie = df.set_index("data").resample("ME")["przychod"].sum()
miesiecznie.plot(marker="o", color="#E02D33",
                 title="Miesięczny przychód", xlabel="", ylabel="przychód [zł]");

Miesięczny przychód na wykresie liniowym. Najwyższe słupki wypadają na przełomie roku (Black Friday i sezon świąteczny), a zaraz po nich, w styczniu i lutym, przychód gwałtownie spada.

Jednym spojrzeniem widać sezonowość: pod koniec roku sprzedaż wystrzeliwuje w górę - najwyższy słupek na całym wykresie to grudzień, a zaraz po nim, w styczniu i lutym, przychód gwałtownie spada. Taka informacja jest warta realnych pieniędzy - podpowiada, kiedy zwiększyć zapasy i budżet reklamowy. A wyciągnęliśmy ją z surowego pliku CSV w kilku liniach kodu.

Anaconda - gdy chcesz wszystko w jednym pakiecie

Do tej pory instalowaliśmy pandas przez pip. Jest jednak druga popularna droga: Anaconda. To gotowa dystrybucja Pythona przeznaczona do analizy danych i pracy naukowej. W jednym instalatorze dostajesz Pythona oraz komplet bibliotek - pandas, numpy, matplotlib - a także notatnik Jupyter i własny menedżer pakietów o nazwie conda. Nie musisz nic dobierać ręcznie.

pip i Anaconda prowadzą do tego samego pandas. pip jest lżejszy i standardowy, Anaconda daje komplet narzędzi od razu.

Różnica w praktyce sprowadza się do menedżera pakietów. Zamiast pip install używasz conda install, a osobne środowiska tworzysz poleceniem conda create. Conda potrafi sprawnie rozwiązać trudne zależności bibliotek kompilowanych, co bywa kłopotliwe przy czystym pip na Windowsie. Tak wygląda założenie nowego środowiska z pandas i Jupyterem oraz sprawdzenie wersji:

Kopiuj

conda create -n analiza_danych python=3.12 pandas jupyter
conda activate analiza_danych
conda list pandas

conda create zakłada izolowane środowisko i sam dobiera zgodne wersje pakietów. conda list pokazuje, że pandas jest gotowy do pracy.

Z Anacondą dostajesz też Jupyter Notebook - interaktywne środowisko, w którym kod pisze się w komórkach uruchamianych po kolei, a wynik (tabela albo wykres) pojawia się od razu pod komórką. To dlatego wszystkie zrzuty w tym artykule wyglądają tak, a nie jak wydruk z terminala. Jupyter uruchomisz z poziomu Anaconda Navigator (graficznego menu dystrybucji) albo poleceniem jupyter notebook:

Notatnik Jupyter w akcji: po lewej kod, pod nim od razu wynik. Każdą komórkę uruchamiasz osobno, budując analizę krok po kroku.

Które podejście wybrać? Jeśli dopiero zaczynasz i chcesz tylko pobawić się danymi, pip install pandas w zupełności wystarczy. Jeśli planujesz poważniej wejść w analizę danych i uczenie maszynowe, Anaconda oszczędzi Ci sporo instalowania i konfiguracji. Jednej zasady warto pilnować: w obrębie jednego środowiska nie mieszaj pip i conda, bo łatwo wtedy o konflikt wersji.

Co dalej

Masz już komplet podstaw: instalacja, wczytywanie danych, filtrowanie, grupowanie, tabele przestawne i wykresy. To fundament, na którym stoi cała analiza danych i uczenie maszynowe w Pythonie. Kolejne naturalne kroki to numpy (obliczenia na tablicach liczb), ładniejsze wykresy w matplotlib i seaborn, a potem scikit-learn - biblioteka do budowania modeli uczenia maszynowego, która dane wejściowe przyjmuje właśnie jako DataFrame z pandas. Gdy dane przestaną mieścić się na jednym komputerze, w grę wchodzą współczesne rozwiązania big data, w których składnia pandas wraca w narzędziach rozproszonych.

Najlepszy sposób na naukę to własne ćwiczenia. Pobierz plik z danymi, otwórz notatnik i spróbuj odpowiedzieć na własne pytania: które miasto kupuje najdrożej, jak wypada sprzedaż w poszczególnych kanałach, który produkt ma największy udział w swojej kategorii. Każda z tych odpowiedzi to jedno albo dwa polecenia, które już znasz.

Chcesz przejść od pandas do uczenia maszynowego z trenerem

Jeśli wolisz uczyć się w uporządkowany sposób i pracować na realnych projektach, prowadzimy szkolenie, które przechodzi całą tę ścieżkę: od podstaw Pythona, przez analizę danych w pandas, aż po pierwsze modele uczenia maszynowego. Kurs ma terminy gwarantowane, więc masz pewność, że grupa się odbędzie.

Szkolenie Python od podstaw do machine learning -->

NEWSLETTER

Nowe artykuły o Pythonie i danych prosto na maila

Co tydzień wysyłamy świeże poradniki z bloga JSystems. Bez spamu, wypisujesz się jednym kliknięciem.

Zapisz się do newslettera -->

Powiązane artykuły

• Bezpłatny kurs Python od podstaw
• Instalacja Pythona i PyCharma - konfiguracja środowiska krok po kroku
• LangChain RAG tutorial w Pythonie - krok po kroku
• Współczesne rozwiązania Big Data 2026 - Spark, lakehouse i streaming
• SQL vs. NoSQL - wielkie porównanie baz danych
• Czy AI zastąpi programistów? Oddzielamy dane od marketingu

Chcesz pogłębić temat na żywym szkoleniu z trenerem? Zobacz kurs Python from zero do Machine Learning w JSystems — termin gwarantowany.

Więcej zrzutów ekranu i przykładów: blog.jsystems.pl

To samo zadanie w obu narzędziach: gotowy plan biznesowy w tabeli. Po lewej ChatGPT Business, po prawej Microsoft 365 Copilot. Wszystkie zrzuty w tym artykule pochodzą z naszych firmowych licencji obu narzędzi.

Coraz więcej firm zadaje to samo pytanie: skoro wprowadzamy AI dla całego zespołu, to które narzędzie wybrać - ChatGPT Business czy Microsoft 365 Copilot. Odpowiedź „to zależy" jest prawdziwa, ale bezużyteczna. Dlatego zamiast powtarzać hasła marketingowe, wykupiliśmy obie licencje firmowe i puściliśmy przez nie te same, typowo biurowe zadania. W tym artykule pokazujemy na realnych zrzutach z obu narzędzi, jak wygląda codzienna praca, praca na dokumentach i danych, sięganie po firmowe pliki, budowanie własnych agentów oraz administracja. Na końcu podpowiadamy, w jakiej firmie który wybór ma więcej sensu.

Jeśli dopiero zaczynasz i chcesz najpierw zrozumieć samo narzędzie od strony firmowej, warto zajrzeć do artykułu jak wdrożyć ChatGPT Business w firmie oraz do zestawienia najczęstszych obaw przy wdrożeniu Microsoft Copilot z perspektywy managementu. Tutaj skupiamy się na jednym: bezpośrednim porównaniu obu narzędzi obok siebie.

Z tego artykułu dowiesz się

• Czym różnią się oba narzędzia u samych podstaw i dla kogo są zaprojektowane
• Jak wygląda codzienna rozmowa z AI w trybie firmowym po obu stronach
• Jak każde z narzędzi tworzy dokument i gdzie ten dokument powstaje
• Jak radzą sobie z arkuszami, Outlookiem i resztą pakietu Office
• Jak sięgają po dane Twojej firmy i czym różnią się te dwa modele
• Jak zbudować własnego agenta AI w każdym z narzędzi
• Jak wygląda administracja, bezpieczeństwo i zgodność z RODO
• Ile to kosztuje i dlaczego model rozliczenia jest ważniejszy od samej kwoty
• Co wybrać do swojej firmy w trzech typowych scenariuszach

Dwa różne podejścia do AI w firmie

Najważniejsze, co trzeba zrozumieć przed jakimkolwiek porównaniem funkcji: to nie są dwa warianty tego samego produktu. To dwie różne filozofie. ChatGPT Business to uniwersalny asystent AI, który działa w przeglądarce i aplikacji, niezależnie od tego, z jakich programów korzysta Twoja firma. Microsoft 365 Copilot to z kolei asystent wbudowany w pakiet Microsoft 365, czyli w Worda, Excela, Outlooka, Teams i PowerPointa, i to właśnie w środku tych aplikacji jest najsilniejszy.

Z tej jednej różnicy wynika prawie wszystko inne: sposób sięgania po firmowe dane, model licencji, a nawet to, gdzie w ogóle uruchamiasz AI. Dlatego zamiast pytać „które jest lepsze", lepiej pytać „które pasuje do sposobu, w jaki pracuje mój zespół".

Dwa różne podejścia: uniwersalny asystent działający wszędzie kontra AI wbudowany w pakiet Microsoft 365.

Zanim wejdziemy w szczegóły, poniższa tabela zbiera najważniejsze różnice w jednym miejscu. Do każdego z tych punktów wrócimy dalej z konkretnym zrzutem z działania.

Najważniejsze różnice ChatGPT Business i Microsoft 365 Copilot w jednej tabeli. Oba plany domyślnie nie wykorzystują firmowych rozmów do trenowania modeli.

Codzienna rozmowa: gotowy materiał z jednego polecenia

Najczęstszy sposób korzystania z AI w firmie to zwykła rozmowa: wpisujesz polecenie, dostajesz gotowy materiał. Oba narzędzia pokazujemy w wersji firmowej - ChatGPT Business oraz licencjonowany Microsoft 365 Copilot - w której rozmowy są objęte firmowymi zasadami i domyślnie nie służą do trenowania modeli. Na razie zostajemy przy zwykłym poleceniu, które nie sięga jeszcze po żadne firmowe pliki.

Postawiliśmy przed jednym i drugim narzędziem to samo zadanie: przygotuj gotowy plan wdrożenia dla zespołu handlowego, w formie tabeli, z etapami, osobami odpowiedzialnymi i ryzykami. Efekt jest w obu przypadkach bardzo podobny - czytelna tabela, którą można od razu wkleić do dokumentu.

ChatGPT Business

ChatGPT Business: gotowy, wieloetapowy plan wdrożenia w tabeli, z osobą odpowiedzialną i ryzykiem przy każdym etapie.

Microsoft 365 Copilot

Microsoft 365 Copilot: to samo zadanie i bardzo zbliżony efekt - plan podzielony na etapy z celem i osobą odpowiedzialną.

Jeśli chcesz odtworzyć ten przykład u siebie, to jest dokładne polecenie, które wpisaliśmy w obu narzędziach:

Kopiuj Jesteś asystentem menedżera sprzedaży. Przygotuj plan wdrożenia nowego systemu CRM w 6-osobowym zespole handlowym: podziel na 5 etapów, dla każdego podaj cel, osobę odpowiedzialną, czas trwania i główne ryzyko. Ujmij to w przejrzystą tabelę, a pod tabelą dodaj 3 rekomendacje na start.

Dla tak ogólnego polecenia różnica między narzędziami jest niewielka - oba dają dobry, gotowy materiał. Prawdziwe różnice zaczynają się dopiero wtedy, gdy przestajesz pisać „z głowy", a zaczynasz pracować na konkretnych dokumentach, danych i firmowych plikach. I właśnie od tego zaczynamy w kolejnych sekcjach.

Praca nad dokumentem

Tu zaczyna się pierwsza wyraźna różnica. Oba narzędzia potrafią napisać gotowy dokument, ale robią to w innym miejscu. W ChatGPT Business dokument powstaje w edytowalnym bloku tekstowym wewnątrz rozmowy - piszesz polecenie, a obok pojawia się sformatowany tekst, który możesz dalej dopracowywać.

ChatGPT Business: gotowy regulamin powstaje w edytowalnym bloku obok rozmowy, gotowy do dalszej edycji.

Microsoft 365 Copilot idzie inną drogą. Ten sam dokument powstaje od razu w Wordzie, czyli w programie, w którym i tak trafiłby do obiegu w firmie. W praktyce sprowadza się to do jednego pytania: gdzie ten tekst i tak wyląduje. Jeśli finalny dokument będzie w Wordzie, Copilot oszczędza kopiowania i wklejania. Jeśli treść dopiero powstaje albo trafi w wiele różnych miejsc, elastyczny edytor ChatGPT sprawdza się równie dobrze.

Arkusze, poczta i reszta pakietu Office

To jest obszar, w którym najmocniej widać, na czym polega przewaga Copilota. Ponieważ jest wbudowany w cały pakiet Microsoft 365, ta sama pomoc AI jest dostępna nie tylko w czacie, ale wprost w Excelu, Outlooku czy PowerPoincie, czyli tam, gdzie zespół i tak pracuje.

Zacznijmy od danych. W arkuszu Copilot policzy wskaźniki, wskaże największe wzrosty albo anomalie i zwróci gotową tabelę z wnioskami, pracując bezpośrednio na danych w Excelu. ChatGPT Business zrobi dokładnie to samo, ale dane trzeba mu najpierw dostarczyć - wgrać plik albo wkleić tabelę do rozmowy. Tu jest sedno różnicy. Copilot ma przewagę, gdy dane już siedzą w firmowym Excelu, a ChatGPT sprawdza się, gdy leżą w różnych formatach i miejscach, bo jest w tym bardzo elastyczny.

Podobnie jest z pocztą. Copilot napisze gotową wiadomość follow-up po spotkaniu, od razu w kilku wariantach tonu do wyboru. Tę samą pomoc masz też bezpośrednio przy pisaniu maila w Outlooku, a przy budowaniu slajdów w PowerPoincie.

Copilot pisze gotową wiadomość follow-up po spotkaniu, od razu w dwóch wariantach tonu do wyboru.

ChatGPT Business też napisze maila i przygotuje strukturę prezentacji - i zrobi to bardzo dobrze - ale wynik dostajesz w oknie rozmowy i musisz go przenieść do Outlooka czy PowerPointa. Różnica nie jest w jakości tekstu, tylko w liczbie kroków. Jeśli Twój zespół cały dzień pracuje w pakiecie Office, oszczędność tych kroków w skali miesiąca robi się odczuwalna.

Jeśli chcesz, żeby zespół realnie wyciskał z tego pakietu maksimum, sprawdź nasze Szkolenie Copilot w Office 365: praca z AI w Wordzie, Excelu, Outlooku i Teams. Ma terminy gwarantowane.

Sięganie po dane Twojej firmy

Sama rozmowa z AI to jedno, ale prawdziwą wartość w firmie daje dopiero odpowiadanie na podstawie firmowych dokumentów, a nie ogólnej wiedzy z internetu. Chodzi o podpięcie asystenta pod realne źródła firmy: pliki, pocztę, systemy (po angielsku nazywa się to grounding). I tu oba narzędzia idą zupełnie inną drogą.

Microsoft 365 Copilot ma tę przewagę, że firmowe dane już w nim są. Ten tryb pracy nazywa się w Copilocie Work IQ. Gdy jest włączony, asystent sięga po firmowe pliki, pocztę i spotkania z Microsoft 365 obok wiedzy z sieci. Gdy jest wyłączony, odpowiada wyłącznie na podstawie internetu. Skoro dokumenty leżą na SharePoincie i OneDrive, a rozmowy w Teams i w poczcie, Copilot z włączonym Work IQ po prostu po nie sięga, z zachowaniem uprawnień danego pracownika. W praktyce wpisujesz w rozmowie znak ukośnika i wybierasz konkretne źródło: plik, spotkanie, osobę.

W Copilocie wpisanie ukośnika otwiera firmowe źródła: pliki, kontakty, spotkania, pocztę czy witryny. Asystent widzi tylko to, do czego dany pracownik ma dostęp.

ChatGPT Business dochodzi do tego samego inną drogą. Nie zakłada, że firma siedzi w jednym ekosystemie, więc źródła podpinasz przez konektory, czyli gotowe wtyczki do popularnych systemów (dysków, poczty, CRM), a bardziej zaawansowane integracje przez wspólny standard łączenia AI z danymi. Administrator decyduje, które konektory są włączone. Dzięki temu ChatGPT sprawdza się także w firmach, które nie stoją na Microsofcie. Więcej o samym mechanizmie łączenia AI z firmowymi systemami piszemy w artykule o tym, czym jest protokół MCP i dlaczego zmienia AI w firmach.

Dwa modele docierania do firmowych dokumentów: Copilot idzie przez pakiet Microsoft 365 i uprawnienia, ChatGPT przez konektory włączane przez administratora.

Własne agenty AI

Oba narzędzia pozwalają zbudować własnego agenta AI, czyli asystenta o wąskiej specjalizacji: takiego, który zna procedury firmy, trzyma się ustalonego tonu i odpowiada tylko na podstawie wgranych materiałów. W ChatGPT Business robisz to jako Custom GPT: nadajesz nazwę, opis, instrukcje i wgrywasz wiedzę, a potem publikujesz go dla całej organizacji. Cały ten proces krok po kroku, bez pisania kodu, rozkładamy na części w osobnym artykule o budowie własnego GPT jako asystenta wiedzy firmowej.

ChatGPT Business

ChatGPT Business: własny asystent (Custom GPT) składasz z instrukcji i firmowej wiedzy, bez pisania kodu, i publikujesz dla zespołu.

Microsoft 365 Copilot

Microsoft 365 Copilot: agentów tworzysz i uruchamiasz w ramach pakietu, obok gotowych agentów Microsoftu, blisko firmowych danych i Teams.

Różnica jest znów w tym, gdzie ten agent potem żyje. Custom GPT działa wszędzie tam, gdzie ChatGPT, czyli w przeglądarce, niezależnie od reszty narzędzi. Agent zbudowany po stronie Microsoftu naturalnie wpina się w Teams i w firmowe dane w pakiecie 365. Jeśli chcesz zrozumieć, ile taki asystent realnie zmienia w codziennej pracy, zebraliśmy konkretne zastosowania agentów AI w polskich firmach. Do każdego rodzaju agenta prowadzi tam osobny tutorial krok po kroku, od pomysłu do wdrożenia.

Custom GPT kontra Copilot Studio: dwie drogi do własnego agenta. Główna różnica to miejsce, w którym agent potem działa.

Jeśli chcesz nauczyć zespół budować takich asystentów samodzielnie, poprowadzi Was przez to nasze Szkolenie Tworzenie agentów AI: Twoi wirtualni asystenci. Ma terminy gwarantowane.

Administracja, bezpieczeństwo i RODO

Dla firmy to często najważniejsza część, bo decyduje o tym, czy w ogóle wolno wpuścić narzędzie do organizacji. Dobra wiadomość jest taka, że w planach firmowych obu narzędzi obowiązuje ta sama, kluczowa zasada: rozmowy firmowe domyślnie nie służą do trenowania modeli. To fundamentalna różnica względem darmowych, prywatnych kont.

Po stronie ChatGPT Business dostajesz osobny panel administratora: zarządzasz członkami, rolami, dostępem i widzisz analitykę korzystania. To jedno miejsce, w którym firma ustala, kto i na jakich zasadach korzysta z AI.

ChatGPT Business

ChatGPT Business: panel administratora z rolami i uprawnieniami. Firma sama decyduje, kto ma dostęp do których funkcji.

Microsoft 365 Copilot

Microsoft 365 Copilot: dostępem firma zarządza w centrum administracyjnym Microsoft 365 - tu widać przypisane licencje Copilota obok reszty pakietu Office.

Największa różnica dotyczy tego, skąd bierze się zgodność i bezpieczeństwo. Copilot dziedziczy zabezpieczenia i ustawienia zgodności całego środowiska Microsoft 365, które firma zwykle ma już wdrożone. ChatGPT Business wnosi własną umowę powierzenia danych i własne ustawienia prywatności, niezależne od pakietu Office. Obie drogi prowadzą do celu, ale w pierwszej opierasz się na tym, co już masz, a w drugiej dokładasz osobny, samodzielny element.

Wspólne gwarancje obu narzędzi i kluczowa różnica: Copilot dziedziczy zgodność z pakietu Microsoft 365, ChatGPT Business wnosi własną.

Ile to kosztuje i za co płacisz

Przy kosztach najważniejsza jest nie sama kwota, tylko model rozliczenia. ChatGPT Business to samodzielna licencja, którą kupujesz za stanowisko, od dwóch stanowisk w górę, i która nie wymaga żadnej innej subskrypcji. Microsoft 365 Copilot jest natomiast dodatkiem, czyli dopłatą doliczaną za stanowisko do licencji Microsoft 365, którą firma już musi mieć.

W praktyce oznacza to jedno: żeby uczciwie porównać koszty, po stronie Copilota trzeba doliczyć to, co i tak płacisz za pakiet Office. Jeśli firma już od lat siedzi na Microsoft 365, ta baza jest kosztem, który i tak ponosisz, więc realna różnica robi się mniejsza. Jeśli nie korzystasz z pakietu Microsoftu, ChatGPT Business bywa prostszym i tańszym wejściem, bo nie ciągnie za sobą całej subskrypcji.

Samodzielna licencja kontra dodatek do pakietu. Ceny podajemy orientacyjnie - zawsze warto sprawdzić aktualny cennik u producenta.

Co wybrać do swojej firmy

Po przejściu przez wszystkie te obszary odpowiedź robi się dużo konkretniejsza niż „to zależy". Najprostsze pytanie, od którego warto zacząć, brzmi: czy cały zespół pracuje na co dzień w Microsoft 365. Jeśli tak, Copilot ma naturalną przewagę, bo wchodzi tam, gdzie ludzie już są. Jeśli nie, ChatGPT Business daje większą swobodę i mniej zależności.

Trzy typowe scenariusze i to, który wybór ma w nich najwięcej sensu. Coraz częściej najlepszą odpowiedzią okazuje się rozsądna mieszanka obu.

Warto też pamiętać, że to nie musi być wybór „albo-albo". Wiele firm decyduje się na oba narzędzia naraz i dzieli je według potrzeb działów: Copilot do codziennej produktywności w pakiecie Office, a ChatGPT do specjalistycznej pracy, researchu i budowania agentów. Jeśli budżet na to pozwala, taka mieszanka często daje najwięcej, bo gra mocnymi stronami każdego z narzędzi zamiast na siłę wciskać wszystko w jedno.

Niezależnie od tego, które narzędzie wybierzesz, największą różnicę i tak robi nie sama licencja, tylko to, czy ludzie potrafią z niej korzystać. Dobrze poprowadzone szkolenie zwraca się tu szybciej niż jakakolwiek dopłata do planu, bo zamienia „mamy AI w firmie" w realną oszczędność kilku godzin dziennie na osobę.

Szkolenie Copilot w Office 365 -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Tworzenie agentów AI -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ChatGPT Business w firmie: wdrożenie, panel administratora i agenci AI
• Czy warto wdrażać Microsoft Copilot - najczęstsze wątpliwości managementu
• Jak wycisnąć 100% z ChatGPT - tryby, projekty, własne GPT i agenci
• 10 zastosowań agentów AI w polskich firmach
• MCP (Model Context Protocol) - czym jest i dlaczego zmienia AI w firmach
• Własny RAG bez kodowania - asystent AI z wiedzą Twojej firmy

Chcesz pogłębić temat na żywym szkoleniu z trenerem? Zobacz kurs Sztuczna inteligencja w codziennej pracy w JSystems — termin gwarantowany.

Więcej zrzutów ekranu i przykładów: blog.jsystems.pl

obraz zbudowany raz

Laptop programisty to samo działa

Serwer / produkcja to samo działa

Chmura to samo działa

Zbuduj raz, uruchom wszędzie: ten sam obraz działa identycznie na każdym środowisku.

Sedno Dockera w jednym obrazku. Aplikację pakujemy w jeden obraz, a potem uruchamiamy go bez zmian na laptopie, na serwerze i w chmurze. Koniec z tłumaczeniem, że „u mnie działało".

Docker to jedno z tych pojęć, które pada na każdej rozmowie o nowoczesnym wytwarzaniu oprogramowania, a mimo to wielu osobom trudno powiedzieć wprost, czym właściwie jest. W tym przewodniku wyjaśnimy to od podstaw: czym jest konteneryzacja, czym kontener różni się od maszyny wirtualnej, a potem krok po kroku uruchomimy pierwszy kontener, zbudujemy własny obraz i połączymy kilka usług w jedną aplikację. Wszystkie przykłady uruchomiliśmy naprawdę, więc na zrzutach widzisz autentyczne wyniki z terminala i z przeglądarki, a nie rysunki poglądowe.

Z tego artykułu dowiesz się:

• Czym jest Docker i konteneryzacja oraz jaki problem realnie rozwiązują
• Czym kontener różni się od maszyny wirtualnej i dlaczego jest tak lekki
• Co znaczą słowa obraz, kontener, rejestr, Dockerfile i wolumen
• Jak uruchomić pierwszy kontener i gotową aplikację jedną komendą
• Jak zbudować własny obraz z pliku Dockerfile i połączyć usługi przez Docker Compose
• Jakie polecenia wystarczą na co dzień i jakich błędów początkujących unikać

Czym właściwie jest Docker

Docker to narzędzie do konteneryzacji, czyli pakowania aplikacji razem ze wszystkim, czego potrzebuje do działania (kodem, bibliotekami, ustawieniami), w jeden przenośny obraz, który uruchamia się identycznie na każdym komputerze. Taki zapakowany, działający pakiet nazywamy kontenerem (ang. container). Zamiast instalować aplikację i ręcznie doinstalowywać dziesiątki zależności na każdym serwerze, budujemy obraz raz i uruchamiamy go wszędzie tak samo.

Najprostsza analogia to kontener transportowy. Zanim upowszechniły się stalowe kontenery, każdy towar pakowano i przeładowywano inaczej, a połowa pracy w porcie polegała na kombinowaniu, jak to wszystko poukładać. Znormalizowany kontener zmienił zasady: nie ma znaczenia, co jest w środku, bo z zewnątrz każdy wygląda tak samo i pasuje na każdy statek, ciężarówkę i dźwig. Docker robi dokładnie to samo z oprogramowaniem. Twoja aplikacja może być w Pythonie, Javie czy Node.js, ale opakowana w kontener wygląda z zewnątrz identycznie i uruchamia się tak samo na laptopie, na serwerze i w chmurze.

Żeby zrozumieć, dlaczego to takie przełomowe, trzeba zobaczyć, czym kontener różni się od maszyny wirtualnej (ang. virtual machine), bo to z nią najczęściej się go myli.

Maszyna wirtualna

App Abiblioteki

App Bbiblioteki

App Cbiblioteki

System gościa

System gościa

System gościa

Hypervisor

System gospodarza

Sprzęt (serwer)

Każda aplikacja niesie własny, pełny system operacyjny. Stąd gigabajty miejsca i start liczony w minutach.

Kontenery (Docker)

App Abiblioteki

App Bbiblioteki

App Cbiblioteki

Docker Engine (silnik)

Jedno wspólne jądro systemu gospodarza

Sprzęt (serwer)

Kontenery współdzielą jądro gospodarza i niosą tylko aplikację z zależnościami. Stąd megabajty miejsca i start w sekundy.

Maszyna wirtualna emuluje cały komputer, więc każda z nich dźwiga własny system operacyjny. Kontenery współdzielą jądro (ang. kernel, rdzeń systemu) gospodarza, dlatego są znacznie lżejsze i szybsze. To jedna z głównych przyczyn popularności Dockera.

Różnica jest fundamentalna. Maszyna wirtualna udaje cały, osobny komputer razem z własnym systemem operacyjnym, więc typowo waży kilka gigabajtów i uruchamia się w minuty. Kontener nie udaje komputera. Współdzieli jądro systemu gospodarza i dokłada tylko to, co odróżnia jedną aplikację od drugiej, dlatego waży zwykle megabajty i startuje w sekundy. Za chwilę zobaczymy to na prawdziwych liczbach: uruchomione przez nas kontenery zajmowały pojedyncze dziesiątki megabajtów pamięci.

Warto od razu rozwiać jedno nieporozumienie. Docker nie jest maszyną wirtualną i nie jest wirtualizacją w klasycznym sensie. To mechanizm izolacji procesów wbudowany w system: kontener to zwykły proces działający na gospodarzu, tyle że odgrodzony od reszty tak, że widzi tylko swój własny, mały świat. Dodajmy jeszcze, że Docker to nie to samo co Kubernetes, o którym zapewne słyszałeś. Docker uruchamia pojedyncze kontenery, a Kubernetes zarządza tysiącami kontenerów na wielu serwerach naraz. Docker jest fundamentem, Kubernetes nadbudową. Naukę zaczyna się od Dockera, a różnice między nimi i moment, w którym warto sięgnąć po orkiestrację, rozwijamy w osobnym porównaniu Kubernetes vs Docker - czym się różnią i kiedy co wybrać.

Problem, który Docker rozwiązuje: koniec z „u mnie działa"

Najłatwiej docenić Dockera, przypominając sobie ból, który usuwa. Prawie każdy, kto pisał lub wdrażał oprogramowanie, zna zdanie „przecież u mnie działa". Aplikacja chodzi bez zarzutu na komputerze programisty, ale po przeniesieniu na serwer testowy albo produkcyjny nagle przestaje. Powód jest zawsze podobny: gdzieś indziej jest inna wersja języka, brakuje jakiejś biblioteki systemowej, inny jest plik konfiguracyjny albo zmienna środowiskowa. Im więcej takich drobnych różnic, tym więcej godzin schodzi na szukanie, dlaczego „to samo" zachowuje się inaczej.

Bez Dockera

Laptop: Python 3.12, wszystkie biblioteki na miejscu działa

Serwer testowy: Python 3.9, brakuje biblioteki nie startuje

Produkcja: inna konfiguracja, inna zmienna błąd na wdrożeniu

Każde środowisko trochę inne. „U mnie działa" kontra „na serwerze nie". Godziny na diagnozę.

Z Dockerem

Laptop: ten sam obraz działa

Serwer testowy: ten sam obraz działa

Produkcja: ten sam obraz działa

Środowisko podróżuje razem z aplikacją w obrazie. Wszędzie identyczne, bo to dosłownie ten sam pakiet.

Docker likwiduje różnice między środowiskami u samego źródła. Zamiast konfigurować każdy serwer osobno, zamykamy aplikację i jej otoczenie w jednym obrazie, który wszędzie zachowuje się tak samo.

Docker rozwiązuje ten problem w najprostszy możliwy sposób: skoro kłopotem są różnice w środowisku, to pakujemy środowisko razem z aplikacją. Obraz zawiera nie tylko nasz kod, ale też konkretną wersję języka, dokładnie te biblioteki, których używamy, i całą konfigurację. Kiedy uruchamiamy go na serwerze, dostajemy dokładnie to samo, co działało na laptopie. Nie „prawie to samo", tylko dosłownie ten sam pakiet.

Podstawowe pojęcia: obraz, kontener, rejestr, Dockerfile

Zanim przejdziemy do praktyki, uporządkujmy pięć słów, które będą wracać w każdej komendzie. Bez nich dokumentacja Dockera wygląda jak żargon, a z nimi wszystko układa się w logiczną całość.

Obraz (image)

Niezmienny szablon aplikacji, coś jak plik instalacyjny. Zawiera kod, biblioteki i konfigurację. Sam z siebie nic nie robi, dopóki go nie uruchomimy.

Kontener (container)

Działająca instancja obrazu, czyli obraz „ożywiony" i uruchomiony. Z jednego obrazu można odpalić wiele kontenerów, tak jak z jednego pliku instalacyjnego wiele kopii programu.

Rejestr (registry)

Magazyn gotowych obrazów w sieci. Najpopularniejszy to Docker Hub. Stamtąd pobieramy obrazy poleceniem pull i tam publikujemy własne poleceniem push.

Dockerfile

Przepis na zbudowanie obrazu, zapisany jako zwykły plik tekstowy z listą kroków. To on sprawia, że obraz jest powtarzalny: każdy zbuduje z niego dokładnie to samo.

Wolumen (volume)

Miejsce na dane, które ma przetrwać dłużej niż kontener. Kontenery są ulotne, więc wszystko, co ma zostać (baza danych, pliki), trzymamy w wolumenie.

Demon (Docker daemon)

Usługa działająca w tle, która faktycznie buduje obrazy i uruchamia kontenery. My wydajemy jej polecenia komendą docker, a ona wykonuje całą pracę.

Sześć pojęć, które wystarczą, żeby swobodnie czytać dokumentację Dockera. Cała reszta to warianty tych podstaw. Zapamiętaj zwłaszcza różnicę obraz kontra kontener, bo to najczęstsze źródło nieporozumień.

Zależność między nimi jest prosta i warto ją zapamiętać jako jedno zdanie: z Dockerfile budujemy obraz, obraz przechowujemy w rejestrze, a po uruchomieniu obrazu powstaje kontener, który swoje trwałe dane trzyma w wolumenie. Mając te pojęcia w głowie, możemy wreszcie coś uruchomić.

Instalacja i pierwszy kontener

Na komputer osobisty najprościej zainstalować Docker Desktop, dostępny na Windows, macOS i Linux. To jeden instalator, który dokłada wszystko, czego potrzeba: silnik Dockera, narzędzia wiersza poleceń i prosty panel graficzny. Na serwerze zwykle instaluje się sam silnik (ang. Docker Engine) z repozytorium systemu. Po instalacji sprawdzamy, czy wszystko gra, pytając Dockera o wersję, a potem uruchamiamy tradycyjny pierwszy kontener testowy o nazwie hello-world.

Pierwszy kontener w akcji. Ponieważ obrazu hello-world nie było jeszcze na dysku, Docker sam pobrał go z Docker Hub (linie „Pulling", „Pull complete"), utworzył z niego kontener i uruchomił. Wypisany komunikat to dowód, że cała maszyneria Dockera działa poprawnie.

To pozornie błahe polecenie pokazuje w miniaturze cały mechanizm Dockera. Napisaliśmy tylko docker run hello-world, a silnik po kolei: sprawdził, czy ma obraz lokalnie, a gdy go nie znalazł, pobrał go z rejestru, następnie utworzył z niego kontener i wykonał zaszytą w nim komendę. Dokładnie ten sam schemat zadziała za chwilę dla prawdziwego serwera WWW, tyle że zamiast wypisać tekst, kontener zacznie obsługiwać ruch sieciowy.

Zapamiętaj wzorzec: docker run <nazwa-obrazu> to najważniejsze polecenie Dockera. Jeśli obrazu nie ma lokalnie, Docker sam go pobierze. Cała reszta to dokładanie do tego opcji, na przykład numeru portu albo nazwy.

Obrazy i kontenery w praktyce

Uruchommy teraz coś użytecznego: serwer WWW nginx, jeden z najpopularniejszych obrazów na świecie. Najpierw obejrzymy, jakie obrazy mamy już na dysku, a potem uruchomimy nginx tak, żeby był dostępny w przeglądarce. Kluczowe będą dwie opcje polecenia run: -d uruchamia kontener w tle (ang. detached), a -p łączy port na naszym komputerze z portem wewnątrz kontenera.

# Uruchom nginx w tle; port 8088 na naszym komputerze -> port 80 w kontenerze
PS C:\demo> docker run -d -p 8088:80 --name web nginx:alpine

Trzy najczęściej używane polecenia w jednym miejscu. docker images pokazuje obrazy na dysku (zwróć uwagę, jak lekki jest nginx w wariancie alpine), docker run uruchamia kontener, a docker ps wypisuje to, co aktualnie działa, wraz z mapowaniem portów.

Warto zwrócić uwagę na dwie rzeczy. Po pierwsze, dopisek :alpine po nazwie obrazu to tag, czyli wskazanie konkretnego wariantu. Wariant alpine jest zbudowany na wyjątkowo lekkiej dystrybucji Linuksa i dlatego zajmuje kilkadziesiąt megabajtów zamiast kilkuset. Po drugie, docker ps pokazał kolumnę z portami w postaci 0.0.0.0:8088->80. To właśnie efekt opcji -p: cokolwiek wejdzie na port 8088 naszego komputera, trafi na port 80 wewnątrz kontenera, gdzie nasłuchuje nginx. Sprawdźmy to w przeglądarce.

Pod adresem localhost:8088 odpowiada nginx uruchomiony w kontenerze. Nie instalowaliśmy żadnego serwera WWW na swoim komputerze, nie konfigurowaliśmy niczego ręcznie. Jedno polecenie i działający serwer, który równie łatwo usuniemy, nie zostawiając po sobie śladu.

Zaglądanie do środka i sprzątanie

Skoro kontener działa, możemy zajrzeć do jego wnętrza, nie zatrzymując go. Polecenie docker logs pokazuje, co kontener wypisał, a docker exec pozwala uruchomić polecenie w środku działającego kontenera, na przykład sprawdzić wersję nginx albo podejrzeć, jaki system jest w środku. Jeśli praca w wierszu poleceń to dla Ciebie świeży temat, warto najpierw oswoić sam terminal - pokazujemy to w artykule Linux w codziennej pracy programisty - dlaczego warto znać terminal.

Zaglądamy do działającego kontenera. docker logs wyświetla jego dziennik (widać wpis z naszej wizyty w przeglądarce, kod 200), a docker exec uruchamia polecenia w jego wnętrzu. Kontener okazuje się miniaturowym Linuksem (Alpine) z jednym zadaniem: obsłużyć nginx.

Gdy skończymy, kontener zatrzymujemy poleceniem docker stop web i usuwamy przez docker rm web (albo od razu docker rm -f web). Po usunięciu nie zostaje żaden ślad: żadnych rozsianych po systemie plików, wpisów w rejestrze usług czy zależności. To jedna z najbardziej wyzwalających cech Dockera. Można próbować, psuć i zaczynać od nowa bez obawy, że zaśmiecimy sobie komputer.

Budowanie własnego obrazu z pliku Dockerfile

Uruchamianie cudzych obrazów to dopiero połowa Dockera. Prawdziwa moc pojawia się, gdy pakujemy w obraz własną aplikację. Zrobimy to na malutkiej aplikacji webowej w Pythonie (framework Flask), która wyświetla powitanie i pokazuje, w jakim kontenerze działa. Najpierw sam kod aplikacji:

import os, platform
from flask import Flask

app = Flask(__name__)

@app.route("/")
def strona_glowna():
    return f"""
      <h1>Witaj z wnetrza kontenera Docker!</h1>
      <p>Nazwa hosta (kontenera): {os.uname().nodename}</p>
      <p>Python w kontenerze: {platform.python_version()}</p>
    """

if __name__ == "__main__":
    # 0.0.0.0 - nasluchuj na wszystkich interfejsach, inaczej port
    # nie bedzie widoczny spoza kontenera
    app.run(host="0.0.0.0", port=5000)

Aplikacja korzysta tylko z frameworka Flask, więc plik requirements.txt ma dosłownie jedną linię. Przypięta wersja (==3.0.3) sprawia, że obraz za każdym razem zbuduje się identycznie:

flask==3.0.3

Teraz najważniejsze: Dockerfile, czyli przepis, według którego Docker zbuduje obraz z naszą aplikacją. Każda linia to jeden krok. Kolejność nie jest przypadkowa i za chwilę wyjaśnimy, dlaczego zależności instalujemy przed skopiowaniem kodu.

# 1. Obraz bazowy - lekki Python. Na nim budujemy nasz wlasny obraz.
FROM python:3.12-slim

# 2. Katalog roboczy wewnatrz kontenera. Kolejne kroki dzialaja wzgledem niego.
WORKDIR /app

# 3. Najpierw sama lista zaleznosci. Docker zapamieta ten krok w cache
#    i nie bedzie instalowal pakietow od nowa przy kazdej zmianie kodu.
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 4. Dopiero teraz kopiujemy kod aplikacji.
COPY app.py .

# 5. Informujemy, ze aplikacja w kontenerze nasluchuje na porcie 5000.
EXPOSE 5000

# 6. Polecenie uruchamiane przy starcie kontenera.
CMD ["python", "app.py"]

Te trzy pliki muszą leżeć obok siebie w jednym katalogu projektu (u nas nazwaliśmy go moja-apka). To dokładnie wszystko, czego Docker potrzebuje, żeby zbudować obraz:

moja-apka/

├─app.pykod aplikacji (Flask)

├─requirements.txtlista zależności (flask==3.0.3)

└─Dockerfileprzepis na obraz, nazwa pliku bez rozszerzenia

Nazwy plików muszą być dokładnie takie: Dockerfile pisany wielką literą i bez żadnego rozszerzenia, a requirements.txt to ta sama nazwa, którą podaliśmy w instrukcji COPY. Teraz w terminalu wchodzimy do katalogu moja-apka i stamtąd budujemy obraz jednym poleceniem. Kropka na końcu oznacza „buduj z bieżącego katalogu" (dlatego musimy stać wewnątrz moja-apka), a opcja -t nadaje obrazowi czytelną nazwę i wersję.

# jesteśmy w katalogu moja-apka, tym samym, w którym leży Dockerfile
PS C:\moja-apka> docker build -t moja-apka:1.0 .

Budowanie obrazu krok po kroku. Docker wykonuje kolejne instrukcje z Dockerfile (numery 1 do 5), a każdą kończy statusem DONE wraz z czasem. Efektem jest gotowy, nazwany obraz moja-apka:1.0, który możemy teraz uruchomić albo wysłać na inny serwer.

Warstwy obrazu i pamięć podręczna

Podczas budowania Docker nie tworzy jednego wielkiego pliku. Buduje obraz warstwa po warstwie, gdzie każda instrukcja z Dockerfile dokłada jedną warstwę na poprzednią. To nie szczegół techniczny, tylko powód, dla którego kolejność w Dockerfile ma znaczenie.

CMDuruchom python app.py (warstwa startowa)

COPY app.pynasz kod aplikacji, zmienia się najczęściej

RUN pip installzainstalowane biblioteki, zmieniają się rzadko

COPY requirementslista zależności

WORKDIR /appkatalog roboczy

FROM pythonobraz bazowy: system i Python

Obraz to stos warstw, budowany od dołu do góry. Docker zapamiętuje każdą warstwę i przy kolejnym budowaniu używa gotowych, jeśli nic się w nich nie zmieniło. Dlatego zależności (rzadko zmieniane) kopiujemy przed kodem (często zmienianym): dzięki temu zmiana jednej linijki kodu nie wymusza ponownej instalacji wszystkich bibliotek.

Ta pozornie drobna sztuczka z kolejnością potrafi skrócić budowanie z minut do sekund. Przy pierwszym budowaniu Docker wykonuje wszystkie kroki, ale przy kolejnych, jeśli zmieniliśmy tylko app.py, ponownie użyje zapamiętanej warstwy z bibliotekami i przebuduje jedynie ostatnie kroki. To jeden z tych detali, które odróżniają osobę „klikającą w Dockerze" od kogoś, kto rozumie, co się dzieje pod spodem.

Zbudowany obraz uruchamiamy tak samo jak wcześniej nginx, tyle że podajemy nazwę naszego obrazu. Sprawdźmy efekt najpierw w terminalu, a potem w przeglądarce.

Nasz własny obraz działa. Kontener wystartował na porcie 5000, a zapytanie poleceniem curl zwróciło stronę wygenerowaną w środku kontenera. Widać nazwę hosta (to skrócony identyfikator kontenera) oraz wersję Pythona, która pochodzi z obrazu, a nie z naszego komputera.

Ta sama aplikacja w przeglądarce. To już nie cudzy nginx, tylko nasz kod zapakowany we własny obraz. Dokładnie ten obraz moglibyśmy teraz wysłać na serwer albo do rejestru i uruchomić bez zmian, z gwarancją, że zachowa się identycznie. No dobrze, przyznajemy się bez bicia: samą stronę dodatkowo trochę ostylowaliśmy, bo w surowej wersji z powyższego kodu wyglądała naprawdę ubogo ;)

Chcesz budować własne obrazy i wdrażać je na produkcji pod okiem praktyka? Szkolenie Konteneryzacja Docker i Kubernetes ma terminy gwarantowane.

Docker Compose: wiele kontenerów jedną komendą

Prawdziwe aplikacje rzadko składają się z jednego kontenera. Zwykle jest ich kilka: serwer aplikacji, baza danych, pamięć podręczna, może kolejka. Uruchamianie każdego z osobna i ręczne łączenie ich w sieć szybko robi się męczące. Od tego jest Docker Compose: opisujemy całą aplikację w jednym pliku compose.yaml, a potem stawiamy wszystko naraz jednym poleceniem. To, na ile usług w ogóle warto podzielić aplikację, zależy od jej architektury - rozwijamy ten wątek w artykule Monolit vs Mikroserwisy - kiedy warto dzielić aplikację.

Rozbudujemy naszą aplikację o drugą usługę: bazę Redis, która policzy odwiedziny strony. Zacznijmy od kodu aplikacji. Względem poprzedniej wersji dochodzą tylko trzy rzeczy: import biblioteki redis, połączenie z bazą po nazwie usługi (czyli po prostu redis) oraz zwiększanie licznika przy każdym wejściu na stronę.

import os
import redis
from flask import Flask

app = Flask(__name__)

# "redis" to nazwa uslugi z compose.yaml - Docker sam zamienia
# ja na adres kontenera w wewnetrznej sieci Compose.
cache = redis.Redis(host="redis", port=6379)

@app.route("/")
def strona_glowna():
    licznik = cache.incr("odwiedziny")  # +1 przy kazdym wejsciu; stan trzyma Redis
    return f"""
      <h1>Witaj z kontenera Docker!</h1>
      <p>Ta strona zostala wyswietlona {licznik} raz(y).</p>
      <p>Licznik przechowuje kontener Redis, a strone serwuje
         kontener aplikacji: {os.uname().nodename}</p>
      <p>Odswiez strone - liczba rosnie, bo stan zyje w Redisie, nie w aplikacji.</p>
    """

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Aplikacja potrzebuje więc dodatkowej biblioteki, dlatego requirements.txt ma teraz dwie linie:

flask==3.0.3
redis==5.0.8

Teraz opisujemy całą aplikację w jednym pliku compose.yaml. Zwróć uwagę, że jedną usługę budujemy z naszego Dockerfile, a drugą bierzemy gotową z Docker Hub.

services:
  # Usluga 1 - nasza aplikacja, budowana z lokalnego Dockerfile
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - redis

  # Usluga 2 - gotowy Redis prosto z Docker Hub, bez wlasnego Dockerfile
  redis:
    image: redis:7-alpine

Plik compose.yaml kładziemy w tym samym katalogu projektu, obok kodu aplikacji i Dockerfile. Usługa web ma przecież build: ., więc Compose zbuduje ją z tego samego Dockerfile co wcześniej. Cały projekt wygląda teraz tak:

moja-apka/

├─app.pyaplikacja, teraz zlicza wejścia w Redisie

├─requirements.txtflask oraz redis

├─Dockerfilebez zmian, ten sam co wcześniej

└─compose.yamlnowy plik: opis obu usług naraz

W środku aplikacja odwołuje się do bazy po prostu jako redis, czyli po nazwie usługi. To jedna z najwygodniejszych rzeczy w Compose: Docker sam tworzy prywatną sieć i zamienia nazwy usług na adresy, więc kontenery znajdują się nawzajem bez ręcznego wpisywania adresów IP. Całość uruchamiamy jednym poleceniem, wywołanym z wnętrza katalogu moja-apka, w którym leży compose.yaml.

# w katalogu moja-apka; -d uruchamia w tle, --build przebudowuje obraz web
PS C:\moja-apka> docker compose up -d --build

Jedno polecenie, a Docker zbudował obraz aplikacji, utworzył wspólną sieć i wystartował obie usługi we właściwej kolejności (najpierw baza, potem aplikacja, bo tak zapisaliśmy w depends_on). docker compose ps potwierdza, że oba kontenery działają.

Efekt współpracy dwóch kontenerów. Aplikacja (kontener web) przy każdym wejściu pyta bazę (kontener redis) o licznik i go zwiększa. Po odświeżeniu liczba rośnie, bo stan żyje w Redisie. Gdyby aplikacja trzymała licznik u siebie, restart kontenera wyzerowałby go za każdym razem.

Wolumeny i sieci: dane oraz komunikacja

Wspomnieliśmy, że kontenery są ulotne. Gdy kontener usuniemy, znika razem z całą swoją zawartością. To świetne przy testach, ale fatalne dla bazy danych, której nie chcemy tracić przy każdym restarcie. Rozwiązaniem jest wolumen: wydzielone miejsce na dane, zarządzane przez Dockera, które istnieje niezależnie od kontenerów. Pokażmy to najprościej, jak się da. Zapiszemy plik w wolumenie z jednego kontenera, usuniemy ten kontener, a potem odczytamy plik z zupełnie nowego.

Wolumen w akcji. Pierwszy kontener zapisał notatkę do wolumenu i został usunięty (opcja --rm kasuje kontener po zakończeniu). Drugi, całkiem nowy kontener bez trudu odczytał tę samą notatkę. Dane przetrwały, bo mieszkają w wolumenie, a nie w kontenerze.

Druga strona medalu to sieci. Widzieliśmy już, że Compose sam tworzy sieć dla naszych usług. Docker pozwala tworzyć wiele odizolowanych sieci, dzięki czemu można na przykład odgrodzić bazę danych tak, żeby była widoczna tylko dla aplikacji, a nie z zewnątrz. W skrócie: wolumeny odpowiadają za to, gdzie mieszkają dane, a sieci za to, kto z kim może rozmawiać. To dwa filary, na których stoją poważniejsze wdrożenia.

Sieci, wolumeny i uruchamianie wielu usług to już codzienność wdrożeń produkcyjnych, którą najszybciej opanujesz na żywej infrastrukturze. Szkolenie Docker i Kubernetes: od zera do bohatera ma terminy gwarantowane.

Docker Hub: skąd biorą się obrazy

Kilka razy pobieraliśmy obrazy (nginx, redis, python), nie zastanawiając się skąd. Domyślnym źródłem jest Docker Hub, czyli publiczny rejestr z setkami tysięcy gotowych obrazów. Znajdziemy tam praktycznie każde popularne oprogramowanie: bazy danych, serwery WWW, języki programowania, gotowe aplikacje. Wystarczy docker run, a Docker sam pobierze obraz właśnie stąd.

Strona oficjalnego obrazu nginx na Docker Hub. Zwróć uwagę na etykietę „Docker Official Image" (obrazy weryfikowane i utrzymywane w zaufany sposób) oraz na skalę: same tygodniowe pobrania idą w dziesiątki milionów. Warto trzymać się obrazów oznaczonych jako oficjalne lub zweryfikowane, bo uruchamiamy w końcu cudzy kod.

Docker Hub działa w obie strony. Możemy nie tylko pobierać obrazy, ale i publikować własne poleceniem docker push, żeby zespół albo serwer produkcyjny mógł je pobrać. Firmy zwykle stawiają dodatkowo własny, prywatny rejestr na swoje wewnętrzne obrazy. Mechanizm jest ten sam, zmienia się tylko adres, spod którego obraz jest pobierany.

Najważniejsze komendy na co dzień

Docker ma dziesiątki poleceń, ale w codziennej pracy wraca ta sama garść. Poniższa ściąga to praktyczne minimum, które pozwala swobodnie uruchamiać, podglądać i sprzątać kontenery.

Dwa ostatnie polecenia dotyczą sprzątania, bo Docker z czasem potrafi zająć sporo miejsca obrazami i nieużywanymi warstwami. Poleceniem docker system df sprawdzimy, ile dokładnie, zanim cokolwiek skasujemy.

Po lewej realne zużycie zasobów: nasze kontenery zajmowały od 9 do 26 megabajtów pamięci, co dobrze pokazuje, jak lekka jest konteneryzacja w porównaniu z maszynami wirtualnymi. Po prawej docker system df podpowiada, ile miejsca da się odzyskać sprzątaniem.

Uwaga na docker system prune. To polecenie usuwa wszystkie nieużywane obrazy, kontenery i sieci naraz. Bywa bardzo pomocne, ale na komputerze, na którym trzymasz też inne projekty, potrafi skasować więcej, niż zakładasz. Zanim je uruchomisz, dodaj opcję pozwalającą zobaczyć, co zniknie, albo usuwaj konkretne zasoby po nazwie.

Konkretnie: prune nie ma trybu „na próbę", więc najpierw flagą -v podglądamy, co i ile zajmuje (polecenie wypisuje każdy obraz, kontener i wolumen z osobna wraz z kolumną „do odzyskania"), a potem zamiast masowego kasowania usuwamy po nazwie tylko to, czego naprawdę nie potrzebujemy:

# 1. Zobacz szczegolowo, co zajmuje miejsce i ile da sie odzyskac
PS C:\demo> docker system df -v

# 2. Wypisz kandydatow do usuniecia
PS C:\demo> docker ps -a      # kontenery (tez zatrzymane)
PS C:\demo> docker images     # obrazy na dysku
PS C:\demo> docker volume ls  # wolumeny

# 3. Usun po nazwie tylko to, czego juz nie potrzebujesz
PS C:\demo> docker rm web               # konkretny kontener
PS C:\demo> docker rmi moja-apka:1.0    # konkretny obraz
PS C:\demo> docker volume rm moje-dane  # konkretny wolumen

Najczęstsze błędy początkujących

Na koniec zebraliśmy pułapki, w które łatwo wpaść na starcie. Znajomość ich z góry oszczędza sporo zdziwienia. Kilka z nich napotkaliśmy zresztą sami, przygotowując przykłady do tego artykułu.

Port jest już zajęty (port is already allocated). Gdy próbujesz wystawić kontener na porcie, którego używa już inny program lub kontener, Docker odmówi startu. Rozwiązanie: wybierz inny port po lewej stronie dwukropka, na przykład -p 8088:80 zamiast -p 8080:80, albo zatrzymaj to, co zajmuje port.

Aplikacja nasłuchuje na 127.0.0.1 zamiast 0.0.0.0. To najczęstsza przyczyna sytuacji „kontener działa, ale strona się nie otwiera". Wewnątrz kontenera aplikacja musi nasłuchiwać na adresie 0.0.0.0, czyli na wszystkich interfejsach. Ustawiona na 127.0.0.1 rozmawia tylko sama ze sobą i mapowanie portu nic nie da.

Mylenie obrazu z kontenerem. Obraz to szablon na dysku, kontener to jego uruchomiona instancja. docker images pokazuje obrazy, docker ps pokazuje kontenery. Usunięcie kontenera nie kasuje obrazu i odwrotnie. To rozróżnienie porządkuje większość początkowych nieporozumień.

Utrata danych po usunięciu kontenera. Jeśli baza danych trzyma pliki wewnątrz kontenera, ich usunięcie oznacza utratę danych. Wszystko, co ma przetrwać, musi trafić do wolumenu. To nie jest opcja dla wygody, tylko podstawowa zasada pracy z danymi w Dockerze.

Kiedy Docker się opłaca, a kiedy niekoniecznie

Docker jest świetny, ale nie jest odpowiedzią na wszystko. Warto wiedzieć, gdzie daje najwięcej.

Docker sprawdza się znakomicie, gdy: chcesz mieć identyczne środowisko na laptopie i na produkcji, szybko postawić bazę danych lub inne narzędzie do testów bez śmiecenia w systemie, uruchamiać aplikację złożoną z wielu usług, albo wdrażać powtarzalnie i bez niespodzianek. To codzienność w zespołach pracujących w duchu DevOps.

Z drugiej strony nie w każdym przypadku Docker jest wart zachodu. Prosty skrypt uruchamiany raz na jakiś czas nie potrzebuje konteneryzacji. Aplikacje z ciężką grafiką albo wymagające bezpośredniego dostępu do sprzętu bywają kłopotliwe. Konteneryzacja dokłada też pewną warstwę wiedzy, którą trzeba opanować, więc dla jednorazowego, malutkiego projektu może być po prostu nadmiarowa. Jak zawsze w inżynierii, chodzi o dobranie narzędzia do zadania, a nie o używanie go wszędzie.

Podsumowanie

Docker rozwiązuje bardzo konkretny problem: różnice między środowiskami, przez które oprogramowanie „działa u mnie, a nie działa na serwerze". Robi to, pakując aplikację razem z jej otoczeniem w przenośny obraz, który wszędzie uruchamia się tak samo. Po drodze przeszliśmy całą podstawową ścieżkę: od uruchomienia pierwszego kontenera, przez pracę z gotowymi obrazami, budowanie własnego obrazu z Dockerfile, aż po składanie wielu usług w jedną aplikację przez Docker Compose. Wszystko na prawdziwych, uruchomionych przykładach.

To solidny fundament, ale też dopiero początek. Naturalny kolejny krok to orkiestracja, czyli zarządzanie wieloma kontenerami na wielu serwerach, za co odpowiada Kubernetes. Jeśli chcesz przejść tę drogę uporządkowanie i od razu na realnej infrastrukturze, zamiast składać wiedzę z rozproszonych poradników, najszybciej zrobisz to pod okiem praktyka.

Szkolenie Docker i Kubernetes: od zera do bohatera -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Kubernetes: orkiestracja kontenerów -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• Kubernetes vs Docker - czym się różnią i kiedy co wybrać
• Czym jest DevOps i jakich narzędzi używa
• Monolit vs Mikroserwisy - kiedy warto dzielić aplikację
• Linux w codziennej pracy programisty - dlaczego warto znać terminal
• Czym jest Ansible - automatyzacja serwerów bez agenta
• Czym jest Git - przewodnik krok po kroku

✕

Chcesz pogłębić temat na żywym szkoleniu z trenerem? Zobacz kurs Docker i Kubernetes od zera w JSystems — termin gwarantowany.

Więcej zrzutów ekranu i przykładów: blog.jsystems.pl

Prework - czyli przygotowanie środowiska na potrzeby kursu

Do udziału w warsztatowej części kursu będzie Ci potrzebne środowisko. Przygowaliśmy instrukcje dla trzech wariantów przygotowania środowiska, zarówno w formie video jak i tekstowej. Przedstawiamy też wady i zalety każdego z rozwiązań. Wybierz rozwiązanie najbardziej Ci odpowiadające i zrealizuj prework jeszcze przed rozpoczęciem kursu.

Wariant 1 - wykorzystanie VirtualBox

VirtualBox służy do wirtualizacji na lokalnym komputerze. Sam program jest bezpłatny, tworzenie hostów również nie wiąże się z żadnymi kosztami. Hosty wirtualne znajdują się na Twoim komputerze. Rozwiązanie dobre jeśli nie chcesz ponosić kosztów wirtualizacji w chmurze Azure, ale ma też pewne ograniczenia. Pamiętaj, że każdy host będzie wymagał odpowiedniej ilości pamięci RAM (po 2GB na każdy serwer w przypadku tego kursu), czasu procesora i paredziesiąt gigabajtów miejsca na dysku. Jeśli będziesz tworzyć jeden host - problemu raczej nie będzie. Jeśli jednak zechcesz stworzyć więcej hostów - np. na potrzeby replikacji, może się okazać że nie wystarczy Ci pamięci RAM, przestrzeni na dysku lub hosty będą działały wolno ze względu na współdzielenie procesora.

Przejdź do wariantu 1

Wariant 2 - wykorzystanie chmury Azure - plik template.json

Wykorzystanie chmury Azure daje nam większą elastyczność niż w przypadku VirtualBox, nie jesteśmy ograniczeni zasobami lokalnego komputera. Możesz więc stworzyć klaster składający się z dowolnej liczby serwerów. Z drugiej strony po wykorzystaniu bezpłatnych zasobów w ramach "Free Tier" Azure, utrzymanie hostów będzie kosztowało nawet jeśli hosty będą wyłączone. Jedna włączona maszyna wirtualna z parametrami niezbędnymi dla prawidłowego przebiegu warsztatów będzie kosztowała 14 groszy za godzinę - czyli ok 104zł miesięcznie, wyłączona 4 grosze za godzinę - czyli ok 30zł miesięcznie (stan na dzień 22.07.2024). Maszyny nie muszą być uruchomione cały czas, wystarczy że uruchomisz je na czas ćwiczeń. Aby maksymalnie ułatwić Ci zadanie, przygotowaliśmy gotowy plik konfiguracyjny dla Azure - co zmacznie ułatwi Ci stworzenie maszyny.

Przejdź do wariantu 2

Wariant 3 - wykorzystanie chmury Azure - konfiguracja ręczna

Ten wariant jest wariacją wariantu 2 z tą różnicą, że w tym przypadku proces konfiguracji wirtualnego hosta jest wykonywany całkowicie ręcznie. Daje Ci to większą kontrolę nad ustawieniami maszyny, ale wymaga więcej pracy.

Przejdź do wariantu 3

Nasza sugestia

Naszym zdaniem, najlepszym wyjściem będzie rozpoczęcie od VirtualBox i przejście na chmurę Azure w chwili gdy zechcesz stawiać wieloserwerowe klastry lub wykorzystać nabytą wiedzę produkcyjnie.

Na potrzeby kursu najlepiej przygotuj sobie dwa równoległe środowiska. Jeden na potrzeby powtarzania czynności trenera podczas kursu, drugi na potrzeby realizacji ćwiczeń. Konfiguracje będą miejscami wchodzić w konflikt, dlatego najlepiej mieć dwa osobne hosty.

W ramach Azure funkcjonuje "Free Tier" czyli bezpłatny dostęp do pewnej części zasobów Azure. W ramach tej opcji możesz uruchomić bardzo podstawowy serwer bezpłatnie na 750h w ciągu roku. Parametry tego serwera jednak nie powalają i do poważnych zastosowań na pewno nie wystaczą. Więcej na temat "Free Tier" przeczytasz tutaj. Pamiętaj też, że przed uruchomieniem pierwszych zasobów (w tym w ramach "Free Tier") będzie trzeba podać dane z karty kredytowej, a więc należy pilnować zużycia zasobów aby nie zaskoczyło Cię pobranie pięniędzy z karty gdy wykorzystasz darmowe limity.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›PostgreSQL - Najważniejsze pojęcia
• ›Upgrade klastra PostgreSQL - pg_upgrade krok po kroku
• ›PostgreSQL - Rodzaje replikacji
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Chcesz pogłębić temat na żywym szkoleniu z trenerem? Zobacz kurs Administracja bazami danych PostgreSQL z elementami HA, optymalizacji i replikacji w JSystems — termin gwarantowany.

Więcej zrzutów ekranu i przykładów: blog.jsystems.pl

Ogólny opis

VirtualBox to darmowe oprogramowanie do wirtualizacji, umożliwia tworzenie i zarządzanie wieloma maszynami wirtualnymi na jednym fizycznym komputerze, co znacząco ułatwia procesy testowania, rozwoju i wdrażania.

W niniejszym szkoleniu omówimy krok po kroku proces tworzenia i konfiguracji podstawowej infrastruktury z wykorzystaniem VirtualBox.

Wymagania

• Oprogramowanie VirtualBox
  https://www.oracle.com/pl/virtualization/technologies/vm/downloads/virtualbox-downloads.html
• Obraz Ubuntu Server LTS
  https://ubuntu.com/download/server

Tworzenie oraz konfiguracja maszyny wirtualnej w programie VirtualBox

1. W zainstalowanym programie Oracle VirtualBox utwórz nową maszynę wirtualną klikając przycisk “New”.

   

2. Uzupełnij nazwę maszyny, folder docelowy oraz wskaż pobrany obraz Ubuntu Server LTS w formacie .iso. Zaznacz opcję “Skip Unattended Installation”.

   

3. W sekcji “Hardware” pozostaw domyślne parametry. Są one wystarczające na cel przeprowadzanego szkolenia.

   

4. W zakładce “Virtual Hard disk” pozostaw domyślne ustawienia lub rozszerz dysk powyżej 25 GB - jeśli jest taka potrzeba.

   

5. W zakładce “Summary” zweryfikuj konfiguracje i zatwierdź utworzenie maszyny wirtualnej za pomocą przycisku “Finish”.

   

6. Wybierz utworzoną maszynę wirtualną oraz przejdź do panelu zarządzania, klikając przycisk “Settings”.

   

7. W sekcji “Network” upewnij się, że “Adapter 1” ma zaznaczoną opcję “Enable Network Adapter” oraz konfiguracja “Attached to” ustawiona jest jako “NAT”.

   

8. Przejdź do zakładki “Adapter 2”, włącz adapter zaznaczając opcję przy “Enable Network Adapter” oraz wybierz opcję dla konfiguracji “Attached to” jako “Internal Network”. Pole “Name” może zostać domyślne. Na cel tego szkolenia zostało zamienione na “SiecPrywatna”.

   

9. Uruchom maszynę wirtualną za pomocą przycisku “Start”. Przy pierwszym rozruchu rozpocznie się instalacja systemu.

   

10. Powtórz kroki 1-9 dla maszyny ubuntu2. Pamiętaj aby maszynie ubuntu2 przydzielić odpowiednio inny adres IP, przykładowo 10.0.0.20.

Instalacja systemu

1. Pierwszym krokiem w instalacji systemu Ubuntu Server LTS jest wybór instalatora. W tym celu za pomocą strzałem góra-dół wybierz opcję “Try or Install Ubuntu Server” oraz zatwierdź wybór za pomocą przycisku Enter.

   

2. Za pomocą strzałem góra-dół wybierz język systemu - “English” lub “Polski” - zależnie od preferencji. Wybór zatwierdź przyciskiem Enter.

   

3. W tej części instalacji mamy możliwość zainstalowania najnowszej dostępnej wersji Ubuntu Server. Nie jest to wymagane, dlatego wykorzystaj opcję “Kontynuuj bez aktualizacji”.

   

4. W zakładce “Konfiguracja klawiatury” domyślnie powinny pojawić się opcje “Układ” oraz “Wariant”, odpowiednie dla wybranego języka. Aby zaakceptować, wybierz opcję “Gotowe” oraz zatwierdź za pomocą przycisku Enter.

   

5. Upewnij się, że opcja “Ubuntu Server” jest zaznaczona oraz potwierdź opcją “Gotowe” za pomocą przycisku Enter.

   

6. Kolejnym krokiem jest konfiguracja interfejsu sieciowego. Pierwszy interfejs sieciowy jest wykorzystywany w połączeniu NAT. Tego interfejsu nie należy edytować. Drugi interfejs posłuży za interfejs w komunikacji w sieci prywatnej pomiędzy maszynami wirtualnymi. W celu jego konfiguracji wybierz drugi interfejs sieciowy za pomocą strzałem góra-dół, rozwiń menu kontekstowe za pomocą przycisku Enter oraz wybierz opcję “Edit IPv4”.

   

7. W otwartym konfiguratorze wprowadź poniższe dane:
   Podsieć: 10.0.0.0/24
   Adres IP: 10.0.0.10
   Brama sieciowa: 10.0.0.255
   Serwery DNS: 8.8.8.8
   Oraz zatwierdź konfigurację za pomocą przycisku Enter, wybierając pole “Zapisz”.

   

8. Zakładka “Konfiguracja proxy” może zostać pominięta bez żadnych zmian. Przejdź dalej za pomocą przycisku Enter.

   

9. Na tym etapie przeprowadzony zostanie krótki test połączenia do repozytorium Ubuntu. Jeśli konfiguracja interfejsów sieciowych została wykonana zgodnie z poradnikiem, wtedy powinniśmy otrzymać informację “This mirror location passed tests.”. Przejdź dalej za pomocą przycisku Enter.

   

10. W zakładce “Konfiguracja pamięci masowej z przewodnikiem” nie jest wymagana żadna zmiana. Przejdź do następnego okna za pomocą przycisku Enter.

    

11. Zakładka “Konfiguracja pamięci masowej” jest swego rodzaju podsumowaniem partycjonowania dysku. Domyślna konfiguracja jest satysfakcjonująca. Przejdź dalej za pomocą przycisku Enter.

    

12. Zaakceptuj informację o usunięciu zawartości wskazanego dysku. Jako iż maszyna wirtualna wykorzystuje zwirtualizowany dysk - twoje dane na komputerze są bezpieczne. Zaakceptuj za pomocą przycisku Enter.

    

13. W zakładce “Ustawienia profilu” wpisz dowolne dane do poświadczeń lub skorzystaj z poniższej konfiguracji:
    Twoje imię: JSystemsSzkolenie
    Your servers name: ubuntu1
    Wybierz nazwę użytkownika: localadmin
    Zatwierdź konfigurację za pomocą przycisku Enter.

    

14. Zakładka “Upgrade to Ubuntu Pro” proponuje aktualizację systemu do wersji Pro, która nie jest wymagana. Przejdź dalej za pomocą przycisku Enter.

    

15. W zakładce “Ustawienia SSH” zaznacz opcję “Zainstaluj serwer SSH”, którą wybierz za pomocą strzałem góra-dół oraz zatwierdź przyciskiem Enter. Przejdź dalej za pomocą przycisku Enter.

    

16. W zakładce “Polecane snapy serwerowe” nie zaznaczaj żadnej opcji, jedynie zaznacz pole “Gotowe” za pomocą strzałem góra-dół oraz przejdź dalej za pomocą przycisku Enter.

    

17. Na tym etapie rozpocznie się instalacja systemu Ubuntu Server LTS, która może potrwać około 5 minut.

    

18. Gdy otrzymasz powiadomienie “Instalacja ukończona!” - a aktualizacja zabezpieczeń została ukończona - wybierz opcję za pomocą strzałem góra-dół “Uruchom ponownie”. Maszyna wirtualna zostanie ponownie uruchomiona.

    

19. Po ponownym uruchomieniu otrzymasz informację o błędzie spowodowanym niemożliwością odłączenia partycji /cdrom. Nie jest to błąd krytyczny i można go całkowicie zignorować. Przejdź dalej za pomocą przycisku Enter.

    

20. Nastąpi pierwszy rozruch systemu. Gdy dojdzie do akcji przedstawionej na zrzucie ekranu, możliwym jest przymus odczekania około 2 minut, zanim instalator przejdzie dalej.

    

21. Po zakończeniu procesu rozruchu powita nas ekran przedstawiony na załączonym zdjęciu. Prośba o podanie loginu do systemu może być mało widoczna, lecz powinna się ona znajdować w lewym górnym rogu ekranu. Możesz bezpośrednio wpisać login użytkownika podany w konfiguracji oraz nacisnąć Enter. Zostaniemy poproszeni o hasło, które również wpisujemy i zatwierdzamy przyciskiem Enter. Należy pamiętać, iż wpisywane hasło jest niewidoczne. Fakt ten może być mylący.

    

22. Powtórz kroki 1-21 dla maszyny ubuntu2. Pamiętaj aby maszynie ubuntu2 przydzielić odpowiednio inny adres IP, przykładowo 10.0.0.20.

Przygotowanie systemu

1. W celu przygotowania systemu najpierw wyczyść informacje wyświetlone w konsoli za pomocą komendy “clear”.

   

2. Rozpocznij przygotowywanie systemu od aktualizacji paczek systemowych za pomocą komendy:
   "sudo apt-get update"
   Zostaniemy poproszeni o hasło, które podaliśmy podczas instalacji oraz logowania.

   

3. Aktualizacja paczek przeprowadzona z sukcesem powinna zaowocować następującymi informacjami jak na załączonym zdjęciu.

   

4. Następnym krokiem jest instalacja podstawowego oprogramowania oraz narzędzi sieciowych za pomocą komendy:
   "sudo apt-get install net-tools"

   

5. Instalacja paczek oraz narzędzi przeprowadzona z sukcesem powinna zaowocować następującymi informacjami jak na załączonym zdjęciu.

   

6. Na tym etapie możemy zweryfikować informacje sieciowe naszej maszyny wirtualnej za pomocą komendy:
   "Ifconfig"
   Drugi wpis - w tym przypadku "enp0s8" podaje informacje na temat interfejsu sieciowego przygotowanego dla sieci prywatnej.

   

7. Powtórz kroki 1-6 dla maszyny ubuntu2.

Test połączenia pomiędzy maszynami wirtualnymi

1. Zestaw okna dwóch uruchomionych maszyn wirtualnych ubuntu1 oraz ubuntu2. Na obu maszynach wykonaj komende "ifconfig". Zapamiętaj poszczególne adresy IP. W tym przypadku są one następujące:
   Ubuntu1: 10.0.0.10
   Ubuntu2: 10.0.0.20

   

2. Zweryfikuj połączenie pomiędzy maszynami za pomocą komendy "ping". Przykłady komend:
   Komenda wykonywana na maszynie wirtualnej ubuntu1: ping 10.0.0.20
   Komenda wykonywana na maszynie wirtualnej ubuntu2: ping 10.0.0.10

   

HOTFIX - jak podłączyć się za pomocą SSH?

Aby połączyć się do hosta za pomocą Putty lub innego klienta SSH, wykonaj poniższe czynności:

1. Przestaw pierwszą kartę sieciową z NAT na "bridged". Zapisz sobie adres MAC tej karty (będzie nam za chwilę potrzebny):

2. Zaloguj się do hosta i sprawdź adres IP tej karty sieciowej. Łatwo odnajdziesz właściwą kartę sieciową za pomocą adresu MAC:

**3. Pobierz program "Putty" z https://www.putty.org/

4. Uruchom Putty i w polu "Host Name" wprowadź adres IP hosta:

5. Zaloguj się swoim użytkownikiem i hasłem. Po zalogowaniu powinien być widoczny taki ekran:

**

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Profesjonalne wdrożenie klastra PostgreSQL na Ubuntu
• ›PostgreSQL - Konfiguracja Patroni z ETCD na Ubuntu
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Ogólny opis

W niniejszym dokumencie omówimy proces tworzenia subskrypcji oraz - podstawowej infrastruktury w chmurze Microsoft Azure, skupiając się na kluczowych elementach, takich jak:

• grupa zasobów (Resource Group)
• sieć wirtualna (Virtual Network)
• sieciowe grupy zabezpieczeń (Network Security Group - NSG).

Połączymy te elementy, konfigurując sieć i uruchamiając dwie maszyny wirtualne. Następnie przeprowadzimy test połączenia pomiędzy tymi maszynami, wykorzystując proste narzędzie sieciowe..

Zrozumienie procesu tworzenia i konfiguracji tych fundamentalnych elementów w Azure jest kluczowe dla każdego, kto chce efektywnie korzystać z infrastruktury chmurowej. Dlatego też ten dokument będzie stanowił krok po kroku przewodnik dla tych, którzy chcą rozpocząć swoją podróż w świecie chmury Azure, jak również dla tych, którzy chcą pogłębić swoją wiedzę na temat konfiguracji sieci i maszyn wirtualnych.

Wymagania

Jedynym wymogiem jest posiadanie konta Microsoft. Jeśli takowego konta nie posiadamy, możemy je utworzyć klikając w poniższy link:
https://signup.live.com

Tworzenie pierwszej subskrypcji w Microsoft Azure

1. Zaloguj się na portal Azure.
   Po utworzeniu konta Microsoft zaloguj się na portal Azure, odwiedzając stronę: https://portal.azure.com

2. Po zalogowaniu się na portalu Azure, wybierz ikonę klucza, oznaczonego jako "Subskrypcje" w pasku szybkiego wyboru. Jeśli takowa ikona nie jest widoczna, możliwym jest jej wyszukanie za pomocą wyszukiwarki, która znajduje się w górnej części ekranu wpisując "Subskrypcje".

   

3. Na stronie "Subskrypcje" kliknij przycisk "Dodaj", aby rozpocząć proces tworzenia nowej subskrypcji.

   

4. Następnie wybierz opcję "Płatność zgodnie z rzeczywistym użyciem" klikając w odpowiednim miejscu "Wybierz ofertę".

   

5. Wypełnij formularz kontaktowy, który jest wymagany do konfiguracji subskrypcji na platformie Microsoft Azure.

6. Zaakceptuj wymagane zgody w formularzu.

   

7. Zweryfikuj się za pomocą numeru telefonu w dogodny dla siebie sposób. Otrzymany kod za pomocą wiadomości SMS lub rozmowy telefonicznej wpisz w następnym oknie.

   

8. Dodaj nową kartę płatniczą lub wybierz już istniejącą kartę, która to zostanie przypisana do konta i nowo-utworzonej subskrypcji. Następnie zatwierdź przyciskiem "Dalej".

   

9. Zaznacz opcję "Brak pomocy technicznej lub korzystam już z pomocy technicznej Premier firmy Microsoft." i potwierdź przyciskiem "Utwórz konto"

   

10. Następnie zostaniemy przeniesieni do kroku, w którym jesteśmy proszeni o ustawienie MFA dla naszego konta - jeśli takowe nie zostało do tej pory skonfigurowane.

    

11. Zostaniemy przeniesieni do ekranu powitalnego, gdzie zaproponowane zostanie nam krótkie szkolenie odnośnie zarządzania zasobami oraz subskrypcją. Możemy skorzystać w propozycji lub zamknąć okno za pomocą przycisku "X", znajdującego się w prawym górnym rogu ekranu.

    

12. Ponownie przechodzimy do zakładki "Subskrypcje" za pomocą paska szybkiego wyboru lub wyszukując tę frazę w wyszukiwarce, znajdującej się w górnej części ekranu.

    

13. Wybieramy naszą nowo utworzoną subskrypcję, klikając na nią.

    

14. Następnie zmieniamy jej nazwę przyjazną dla użytkownika, klikając w przycisk "Zmień nazwę".

    

15. Wybieramy nową nazwę subskrypcji - w tym wypadku jest to "Szkolenie" i klikamy przycisk "Zapisz". Subskrypcja natychmiast zmieni swoją nazwę.

    

Tworzenie grupy zasobów

Pierwszym, a zarazem najbardziej podstawowym zasobem - zaraz po subskrypcji - jest grupa zasobów (resource group). Jest to swoisty kontener lub folder, pozwalający na grupowanie zasobów wedle dowolnej dla nas logiki. Przykładową dobrą praktyką w grupowaniu zasobów jest łączenie ich ze względu na ich tzw. Lifecycle.

1. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Grupy zasobów". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

2. W zakładce "Grupy zasobów" utwórz nowy zasób, klikając przycisk "Utwórz".

   

3. W zakładce "Podstawowe" konfiguratora zasobu "Grupa zasobów", wypełnij następująco poniższe pola:
   Subskrypcja: Szkolenie (lub inna nazwa nadana we wcześniejszych krokach)
   Grupa zasobów: rg-szkolenie
   Region: (Europe) Poland Central

   

4. Zweryfikuj konfigurację w zakładce "Przeglądanie + tworzenie" i utwórz zasób klikając w przycisk "Utwórz".

   

5. Grupa zasobów "rg-szkolenie" powinna zostać utworzona niemalże natychmiast.

Tworzenie maszyn wirtualnych

1. Dane konfiguracyjne maszyn wirtualnych:
   Maszyna wirtualna no. 1
   Subskrypcja: Szkolenie (lub inna nazwa nadana we wcześniejszych krokach)
   Grupa zasobów: rg-szkolenie
   Nazwa maszyny wirtualnej: pg1
   Region: (Europe) Poland Central
   Opcje dostępności: Nie jest wymagana żadna nadmiarowość infrastruktury
   Typ zabezpieczeń: Maszyny wirtualne zaufanego uruchamiania
   Obraz: Ubuntu Server 22.04 LTS - x64 Gen2
   Architektura maszyny wirtualnej: x64
   Rozmiar: Standard_B1ms
   Typ uwierzytelnienia: Hasło
   Nazwa użytkownika: jsystems
   Hasło: Dowolne hasło spełniające wymogi
   Publiczne porty ruchu przychodzącego: Brak
   Podsieć: Subnet1
   Nazwa publicznego adresu IP: pip-pg1

   Maszyna wirtualna no. 2
   Subskrypcja: Szkolenie (lub inna nazwa nadana we wcześniejszych krokach)
   Grupa zasobów: rg-szkolenie
   Nazwa maszyny wirtualnej: pg2
   Region: (Europe) Poland Central
   Opcje dostępności: Nie jest wymagana żadna nadmiarowość infrastruktury
   Typ zabezpieczeń: Maszyny wirtualne zaufanego uruchamiania
   Obraz: Ubuntu Server 22.04 LTS - x64 Gen2
   Architektura maszyny wirtualnej: x64
   Rozmiar: Standard_B1ms
   Typ uwierzytelnienia: Hasło
   Nazwa użytkownika: jsystems
   Hasło: Dowolne hasło spełniające wymogi
   Publiczne porty ruchu przychodzącego: Brak
   Podsieć: Subnet1
   Nazwa publicznego adresu IP: pip-pg2

2. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Maszyny wirtualne". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

3. W zakładce "Maszyny wirtualne" utwórz nowy zasób, klikając przycisk "Utwórz".

   

4. W zakładce "Podstawowe informacje" konfiguratora zasobu "Grupa zasobów", wypełnij następująco poniższe pola:

   

   

5. W zakładce Dyski zmieniamy "Rozmiar dysku systemu operacyjnego" na 32 GB oraz "Typ dysku systemu operacyjnego" na "SSD w warstwie Standardowa".

   

6. W zakładce "Sieć" utworzona zostanie nowa sieć wirtualna wraz z podsiecią. Domyślna konfiguracja jest odpowiednia. Zmieniamy wyłącznie nazwę sieci klikając pod listą konfiguracji "Sieć wirtualna" przycisk "Utwórz nowy".

   

7. Zmieniamy nazwę sieci wirtualnej oraz zatwierdzamy konfigurację za pomocą przycisku "OK".

   

8. Zaznaczamy opcję "Usuwanie publicznego adresu IP i karty sieciowej po usunięciu maszyny wirtualnej".

   

9. W zakładce "Zarządzanie" odznacz opcję "Bezpłatnie włącz plan podstawowy" w sekcji "Microsoft Defender dla Chmury". Pozostałe opcje pozostaw domyślne.

   

10. W zakładce "Monitorowanie" zaznacz opcję "Diagnostyka rozruchu" jako "Wyłącz".

    

11. Wszystkie ustawienia w zakładce "Zaawansowane" pozostawiamy domyślne.

    

12. Wszystkie ustawienia w zakładce "Tagi" pozostawiamy domyślne.

    

13. Zweryfikuj konfigurację w zakładce "Przeglądanie + tworzenie" i utwórz zasób klikając w przycisk "Utwórz".

    

14. Powtórz kroki 2-10 dla maszyny wirtualnej numer 2.

Połączenie z maszyną wirtualną

1. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Maszyny wirtualne". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

2. W centralnym dashboardzie maszyny wirtualnej skopiuj publiczny adres IP i połącz się za pomocą klienta SSH - w tym wypadku PuTTy - do maszyny. Wykonaj tożsame połączenie z drugą maszyną wirtualną.

   

Testowanie połączenia pomiędzy maszynami wirtualnymi

1. Przetestuj połączenie pomiędzy maszynami za pomocą prostej komendy "ping". Adresy prywatne IP znajdują się w dashboardzie maszyn wirtualnych. Jeśli adres sieciowy nie był zmieniany, wtedy maszyny powinny posiadać poniższe adresy IP:
   pg1: 10.0.0.4
   pg2: 10.0.0.5

   

2. Poprawnie skonfigurowane maszyny powinny zezwolić na połączenie za pomocą komendy ping.

   

Kosztorys

Zdecydowana większość zasobów na platformie Microsoft Azure generuje odpowiednie dla siebie koszta. Duża część z tych zasobów pozwala na optymalizację kosztów, przykładowo poprzez wyłączenie usługi, gdy ta nie jest użytkowana. W przypadku konfiguracji przedstawionej w tym szkoleniu, możemy ograniczyć koszta poprzez wyłączenie maszyn wirtualnych, gdy z nich nie korzystamy. Niemniej jednak koszta związane z dyskami czy publicznymi adresami IP pozostaną tak długo, jak długo dany zasób będzie istniał. Koszta przestają być naliczane, gdy całkowicie usuniemy nasze zasoby, kiedy te już nie będą nam potrzebne.

Poniższa tabela prezentuje koszta związane z konfiguracją przedstawioną w szkoleniu.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›PostgreSQL - Konfiguracja Patroni z ETCD na Ubuntu
• ›Wirtualna maszyna Ubuntu w VirtualBox - instalacja krok po kroku
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Ogólny opis

W niniejszym dokumencie omówimy proces tworzenia subskrypcji oraz podstawowej infrastruktury w chmurze Microsoft Azure za pomocą szablonu.

Wymagania

Jedynym wymogiem jest posiadanie konta Microsoft. Jeśli takowego konta nie posiadamy, możemy je utworzyć klikając w poniższy link:
https://signup.live.com

Tworzenie pierwszej subskrypcji w Microsoft Azure

1. Zaloguj się na portal Azure.
   Po utworzeniu konta Microsoft zaloguj się na portal Azure, odwiedzając stronę: https://portal.azure.com

2. Po zalogowaniu się na portalu Azure, wybierz ikonę klucza, oznaczonego jako "Subskrypcje" w pasku szybkiego wyboru. Jeśli takowa ikona nie jest widoczna, możliwym jest jej wyszukanie za pomocą wyszukiwarki, która znajduje się w górnej części ekranu wpisując "Subskrypcje".

   

3. Na stronie "Subskrypcje" kliknij przycisk "Dodaj", aby rozpocząć proces tworzenia nowej subskrypcji.

   

4. Następnie wybierz opcję "Płatność zgodnie z rzeczywistym użyciem" klikając w odpowiednim miejscu "Wybierz ofertę".

   

5. Wypełnij formularz kontaktowy, który jest wymagany do konfiguracji subskrypcji na platformie Microsoft Azure.

6. Zaakceptuj wymagane zgody w formularzu.

   

7. Zweryfikuj się za pomocą numeru telefonu w dogodny dla siebie sposób. Otrzymany kod za pomocą wiadomości SMS lub rozmowy telefonicznej wpisz w następnym oknie.

   

8. Dodaj nową kartę płatniczą lub wybierz już istniejącą kartę, która to zostanie przypisana do konta i nowo-utworzonej subskrypcji. Następnie zatwierdź przyciskiem "Dalej".

   

9. Zaznacz opcję "Brak pomocy technicznej lub korzystam już z pomocy technicznej Premier firmy Microsoft." i potwierdź przyciskiem "Utwórz konto"

   

10. Następnie zostaniemy przeniesieni do kroku, w którym jesteśmy proszeni o ustawienie MFA dla naszego konta - jeśli takowe nie zostało do tej pory skonfigurowane.

    

11. Zostaniemy przeniesieni do ekranu powitalnego, gdzie zaproponowane zostanie nam krótkie szkolenie odnośnie zarządzania zasobami oraz subskrypcją. Możemy skorzystać w propozycji lub zamknąć okno za pomocą przycisku "X", znajdującego się w prawym górnym rogu ekranu.

    

12. Ponownie przechodzimy do zakładki "Subskrypcje" za pomocą paska szybkiego wyboru lub wyszukując tę frazę w wyszukiwarce, znajdującej się w górnej części ekranu.

    

13. Wybieramy naszą nowo utworzoną subskrypcję, klikając na nią.

    

14. Następnie zmieniamy jej nazwę przyjazną dla użytkownika, klikając w przycisk "Zmień nazwę".

    

15. Wybieramy nową nazwę subskrypcji - w tym wypadku jest to "Szkolenie" i klikamy przycisk "Zapisz". Subskrypcja natychmiast zmieni swoją nazwę.

    

Tworzenie grupy zasobów

Pierwszym, a zarazem najbardziej podstawowym zasobem - zaraz po subskrypcji - jest grupa zasobów (resource group). Jest to swoisty kontener lub folder, pozwalający na grupowanie zasobów wedle dowolnej dla nas logiki. Przykładową dobrą praktyką w grupowaniu zasobów jest łączenie ich ze względu na ich tzw. Lifecycle.

1. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Grupy zasobów". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

2. W zakładce "Grupy zasobów" utwórz nowy zasób, klikając przycisk "Utwórz".

   

3. W zakładce "Podstawowe" konfiguratora zasobu "Grupa zasobów", wypełnij następująco poniższe pola:
   Subskrypcja: Szkolenie (lub inna nazwa nadana we wcześniejszych krokach)
   Grupa zasobów: rg-szkolenie
   Region: (Europe) Poland Central

   

4. W zakładce "Tagi" konfiguratora zasobu "Grupa zasobów", wypełnij następująco poniższe pola:
   Nazwa: Cel
   Wartość: Szkolenie

   

5. Zweryfikuj konfigurację w zakładce "Przeglądanie + tworzenie" i utwórz zasób klikając w przycisk "Utwórz".

   

6. Grupa zasobów "rg-szkolenie" powinna zostać utworzona niemalże natychmiast.

Tworzenie konfiguracji za pomocą szablonu

1. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Wdróż szablon niestandardowy". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

2. W konfiguratorze szablonu niestandardowego, w zakładce "Wybierz szablon" wybierz opcję "Utwórz własny szablon w edytorze". Otworzy to okno edytora szablonu.

   

3. Wklej do okna edytora szablonu udostępniony szablon infrastruktury. Zweryfikuj przygotowane zasoby w panelu bocznym. Po weryfikacji zatwierdź szablon za pomocą przycisku "Zapisz".

   

4. W konfiguratorze szablonu niestandardowego - w zakładce "Podstawowe" - wybierz odpowiednią subskrypcję, wcześniej przygotowaną grupę zasobów "rg-szkolenie" oraz region "(Europe) Poland Central". Ostatnim konfigurowalnym polem jest pole "Admin Password" domyślną wartością pola jest JSystems!. Jest to hasło, dzięki któremu zalogujemy się do maszyny. Hasło można ustawić dowolne (minimum 6 znaków, znak specjalny oraz duża/mała litera).

   

5. W ostatniej zakładce "Przejrzy i utwórz" zweryfikuj konfigurację oraz rozpocznij wdrożenie za pomocą przycisku "Utwórz".

   

6. Po kliknięciu przycisku "Utwórz" przeniesieni zostaniemy do dashboardu wdrożenia naszego szablonu niestandardowego. Po zakończonym wdrożeniu możesz przejść do grupy zasobów, klikając przycisk "Przejdź do grupy zasobów".

   

Połączenie z maszyną wirtualną

1. Z ekranu głównego platformy Microsoft Azure wybierz na pasku szybkiego wybierania przycisk "Maszyny wirtualne". Jeśli takowy przycisk nie jest widoczny, wyszukaj tę frazę w wyszukiwarce, umieszczonej na górze strony.

   

2. W centralnym dashboardzie maszyny wirtualnej skopiuj publiczny adres IP i połącz się za pomocą klienta SSH - w tym wypadku PuTTy - do maszyny. Wykonaj tożsame połączenie z drugą maszyną wirtualną.

   

Testowanie połączenia pomiędzy maszynami wirtualnymi

1. Przetestuj połączenie pomiędzy maszynami za pomocą prostej komendy "ping". Adresy prywatne IP znajdują się w dashboardzie maszyn wirtualnych. Jeśli adres sieciowy nie był zmieniany, wtedy maszyny powinny posiadać poniższe adresy IP:
   pg1: 10.0.0.10
   pg2: 10.0.0.20

   

2. Poprawnie skonfigurowane maszyny powinny zezwolić na połączenie za pomocą komendy ping.

   

Kosztorys

Zdecydowana większość zasobów na platformie Microsoft Azure generuje odpowiednie dla siebie koszta. Duża część z tych zasobów pozwala na optymalizację kosztów, przykładowo poprzez wyłączenie usługi, gdy ta nie jest użytkowana. W przypadku konfiguracji przedstawionej w tym szkoleniu, możemy ograniczyć koszta poprzez wyłączenie maszyn wirtualnych, gdy z nich nie korzystamy. Niemniej jednak koszta związane z dyskami czy publicznymi adresami IP pozostaną tak długo, jak długo dany zasób będzie istniał. Koszta przestają być naliczane, gdy całkowicie usuniemy nasze zasoby, kiedy te już nie będą nam potrzebne.

Poniższa tabela prezentuje koszta związane z konfiguracją przedstawioną w szkoleniu.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Profesjonalne wdrożenie klastra PostgreSQL na Ubuntu
• ›PostgreSQL - Przygotowanie hostów - zakres enterprise
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Rozszerzenie PG_CRON pozwala na automatyczne uruchamianie cyklicznych zadań w serwerze PostgreSQL. Możesz to wykorzystać np. do przeładowywania danych w hurtownii danych, czy uruchamiania procesów konserwacyjnych.

Z tego artykułu dowiesz się:

• czym jest pg_cron i w jakim celu się go stosuje,
• jak zainstalować pg_cron na Ubuntu,
• jak zainstalować pg_cron na systemach z rodziny Red Hat,
• w jaki sposób konfigurować automatyczne uruchamianie zadań w PostgreSQL za pomocą pg_cron,
• jak przeglądać zaplanowane zadania,
• jak modyfikować zaplanowane zadania,
• jak wyłączać zaplanowane zadania,
• jak przeglądać historię wykonanych zaplanowanych zdań wraz z ewentualnymi błędami i ich przyczynami.

Zaczynając swoją przygodę z Postgresem, często jedną z pierwszych przeszkód, z którą się stykamy, jest problem planowania cyklicznych zadań w bazie danych. Postgres domyślnie nie posiada takiej funkcjonalności (jak na przykład DBMS_JOB w Oracle), a jedyną możliwością jest zaplanowanie zadań w cronie systemowym. Istnieje jednak rozszerzenie pg_cron, dostępne w oficjalnych repozytoriach PGDG oraz do pobrania i własnej kompilacji ze strony projektu na github (https://github.com/citusdata/pg_cron), umożliwiające zaplanowanie powtarzalnych zadań bezpośrednio w Postgresie z wykorzystaniem składni znanej ze wspomnianego wcześniej unixowego crona.

Instalacja i konfiguracja

Instalacja zależnie od systemu, z którego korzystamy, odbywa się za pomocą yum na systemach z rodziny RedHat lub apt na pochodnych Debiana.

## RHEL, CentOS, Fedora, Rocky

1) wget https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2) sudo yum install pgdg-redhat-repo-latest.noarch.rpm

3) sudo yum install -y pg_cron_15

## Debian, Ubuntu

1) sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

2) wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | \

sudo apt-key add -

3) sudo apt-get update

4) sudo apt-get -y install postgresql-15-cron

Inną możliwością jest pobranie projektu bezpośrednio z githuba i własnoręczna kompilacja.

git clone https://github.com/citusdata/pg_cron.git

cd pg_cron

# upewnij się, że zmienna PATH zawiera ścieżkę do pg_config

# przykładowo: /usr/lib/postgresql/15/bin dla ubuntu, albo /usr/pgsql-15/bin dla redhata

export PATH=/usr/pgsql-15/bin:$PATH

make && sudo PATH=$PATH make install

Następnie dodajemy ‘pg_cron’ do parametru shared_preload_libraries w pliku "postgresql.conf", albo przez ALTER SYSTEM i restartujemy Postgresa, aby zmiany zostały wczytane podczas startu Postgresa.

#Sprawdź czy nie masz już ustawionych jakichś bibliotek w "shared_preload_libraries"

show shared_preload_libraries;

  

#Zmiana parametru w postgresql.conf lub przez ALTER SYSTEM:

alter system set shared_preload_libraries='pg_cron';  #można po przecinku: 'pg_prewarm,pg_cron'

  

# na Ubuntu

/usr/lib/postgresql/15/bin/pg_ctl -D /katalog/pg/data restart -m fast

# na RHEL

/usr/pgsql-15/bin/pg_ctl -D /katalog/pg/data restart -m fast

# ścieżkę do katalogu z danymi znajdziemy za pomocą 

postgres=# show data_directory;

       data_directory          

-----------------------------

 /var/lib/postgresql/15/main

(1 row)

Rozszerzenie tworzymy zawsze tylko w jednej bazie, którą później wykorzystujemy jako pojedynczy punkt do zarządzania wszystkimi zadaniami. Jeżeli planujemy stworzenie rozszerzenia w bazie innej niż domyślna Postgres, powinniśmy dodać do pliku konfiguracyjnego nowy parametr cron.database_name, na przykład:

shared_preload_libraries = 'pg_cron'

cron.database_name = 'apka'

Po ponownym uruchomieniu możemy dodać rozszerzenie do jednej wybranej bazy, w której będziemy planować zadania. Opcjonalnie możemy również nadać uprawnienia dla schematu “cron” użytkownikom, którzy powinni mieć możliwość planowania zadań.

postgres@vagrant:~$ psql -c "create extension pg_cron;" apka

CREATE EXTENSION

postgres@vagrant:~$ psql -c "grant usage on schema cron to planer;" apka

GRANT

Jak skorzystamy z domyślnych wartości i stworzymy rozszerzenie oraz zaplanujemy zadania jako użytkownicy Postgres w bazie Postgres.

postgres@vagrant:~$ psql -c "create extension pg_cron;"

CREATE EXTENSION

Sposoby wykonywania zadań w pg_cron

Domyślnie pg_cron otwiera lokalnie połączenia do bazy, aby wykonywać zaplanowane zadania, dlatego musimy zadbać o odpowiednią konfigurację pg_hba.conf orac .pgpass, jeżeli logowanie wymaga hasła. Korzystając z użytkownika Postgres oraz bazy Postgres, wystarczy zastosować wpis dla połączeń lokalnych za pomocą socketa z metodą autentykacji “peer”.

local - postgres      postgres - peer

Jeżeli chcielibyśmy korzystać z innego użytkownika, lub z hasła, musimy odpowiednio zmodyfikować oba pliki konfiguracyjne.

Drugim sposobem wykorzystania zadań jest korzystanie z procesów tła do wykonywania zadań, zamiast nawiązywania lokalnych połączeń do bazy. Aby pg_cron przygotować do działania w ten sposób, musimy zmienić dwa parametry, oba wymagają restartu Postgresa, aby zmiany weszły w życie:

cron.use_background_workers = on

max_worker_processes = 20

cron.use_background_workers aby pg_cron korzystał z procesów tła oraz za pomocą parametru max_worker_processes określić ile zadań będzie mogło się wykonywać jednocześnie, domyślnie liczba procesów ograniczona jest do 8.

Warto też pamiętać, że pg_cron wykonuje zadania tylko na instancji głównej klastra. Rozszerzenie może być zainstalowane i skonfigurowane na instancjach standby, jednak zadania nie będą wykonywane na serwerach standby do momentu awansowania ich na instancję primary i otwarciu na zapis.

Planowanie zadań

Zadania możemy zaplanować za pomocą funkcji cron.schedule(), która przyjmuje dwie lub trzy wartości. W pierwszej wersji- harmonogram oraz polecenie do wykonania, w drugiej- nazwę zadania, harmonogram oraz polecenie. Harmonogram ustalamy za pomocą składni znanej z systemowego crona.

 ┌───────────── minuty (0 - 59)

 │ ┌────────────── godziny (0 - 23)

 │ │ ┌─────────────── dzień miesiąca (1 - 31)

 │ │ │ ┌──────────────── miesiąc (1 - 12)

 │ │ │ │ ┌───────────────── dzień tygodnia (0 - 7) (0 - 6, niedziela do soboty, 7 to

 │ │ │ │ │                            również niedziela)

 * * * * *

Przykładowe zaplanowanie zadania

SELECT - cron.schedule('select','* * * * *', 'SELECT 1');

Wszystkie zaplanowane zadania możemy znaleźć w tabeli cron.job.
Jeżeli korzystamy z większej liczby użytkowników do planowania zadań, każdy z nich może zobaczyć tylko swoje zadania. Ograniczenie to nie dotyczy użytkownika Postgres, który jest superuserem i może zobaczyć wszystkie zadania. Należy również pamiętać, że użytkownik, który jest “właścicielem” zadania, powinien mieć uprawnienia do obiektów, na których będzie pracował.

postgres=# set role=test;

SET                                                                 ^

postgres=> SELECT - cron.schedule('select','* * * * *', 'SELECT 1');

 schedule 

----------

        1

(1 row)

postgres=> select * from cron.job;

 jobid | schedule - | command - | nodename - | nodeport | database | username | active | jobname 

-------+-----------+----------+-----------+----------+----------+----------+--------+---------

     1 | * * * * * | SELECT 1 | localhost |      5432 | postgres | test      | t        | select

(1 row)

postgres=> set role=planer;

SET

postgres=> select * from cron.job;

 jobid | schedule | command | nodename | nodeport | database | username | active | jobname 

-------+----------+---------+----------+----------+----------+----------+--------+---------

(0 rows)

postgres=> set role=postgres;

SET

postgres=# select * from cron.job;

 jobid | schedule - | command - | nodename - | nodeport | database | username | active | jobname 

-------+-----------+----------+-----------+----------+----------+----------+--------+---------

     1 | * * * * * | SELECT 1 | localhost |      5432 | postgres | test      | t        | select

(1 row)

Wszystkie zadania, które tworzymy za pomocą funkcji cron.schedule(), są domyślnie tworzone w bazie Postgres, chyba że ustawiliśmy inaczej w parametrze cron.database_name oraz w innej bazie stworzyliśmy rozszerzenie. Chcąc tworzyć zadania dla innych baz, powinniśmy skorzystać z funkcji cron.schedule_in_database(). Przyjmuje ona wartości: nazwa zadania, harmonogram, polecenie, nazwa bazy, nazwa użytkownika oraz informację, czy zadanie powinno być aktywne. Jeżeli pominiemy ostatni parametr, domyślnie utworzy się jako aktywny.

postgres=# SELECT cron.schedule_in_database('zadanie w innej bazie','0 6 * * *','SELECT 1', 'app_db','planer','f');

 schedule_in_database 

----------------------

                    2

(1 row)

postgres=# select * from cron.job;

 jobid | schedule - | command - | nodename - | nodeport | database | username | active |          jobname          

-------+-----------+----------+-----------+----------+----------+----------+--------+-----------------------

     1 | * * * * * | SELECT 1 | localhost |      5432 | postgres | test      | t        | select

     2 | 0 6 * * * | SELECT 1 | localhost |      5432 | app_db - | planer - | f        | zadanie w innej bazie

(2 rows)

Tak stworzone zadanie nie będzie się wykonywało do momentu zmiany flagi “active” na “t” za pomocą funkcji cron.alter_job() przyjmującej wartości: jobid, schedule, command, database, username, active. Jedynie pierwsza wartość jest obowiązkowa, pozostałe wartości możemy zmienić, aby zmodyfikować zadanie lub podać dla nich wartość NULL, aby zachować oryginalne wartości.

postgres=# select cron.alter_job(2,null,null,null,null,'t');

 alter_job 

-----------

(1 row)

postgres=# select * from cron.job;

 jobid | schedule - | command - | nodename - | nodeport | database | username | active |          jobname          

-------+-----------+----------+-----------+----------+----------+----------+--------+-----------------------

     1 | * * * * * | SELECT 1 | localhost |      5432 | postgres | test      | t        | select

     2 | 0 6 * * * | SELECT 1 | localhost |      5432 | app_db - | planer - | t        | zadanie w innej bazie

(3 rows)

Zadania, które są już niepotrzebne, można usunąć za pomocą funkcji cron.unschedule(), która przyjmuje jako parametr jobid lub jobname.

select cron.unschedule('zadanie w innej bazie');

select cron.unschedule(2);

Oba powyższe wywołania mają ten sam efekt, spowodują usunięcie drugiego zadania w bazie “app_db”. Jeżeli mielibyśmy więcej niż jedno zadanie z taką samą nazwą, zostanie usunięte tylko jedno, z najniższym jobid.

Historię wykonanych zadań możemy przejrzeć w tabeli cron.job_run_details.

postgres=# select * from cron.job_run_details ; 

 jobid | runid | job_pid | database | username | command - | status | - return_message - | start_time | end_time 

-------+-------+---------+----------+----------+----------+--------+-------------------+------------+----------

     1 |     27 |           | postgres | test      | SELECT 1 | failed | connection failed |               | 

     1 |      1 |           | postgres | test      | SELECT 1 | failed | connection failed |               |

Bardziej szczegółowe informacje odnośnie rezultatu zadania, lub jego błędu, znajdziemy w postgresowym pliku loga. Przykładowo:

postgres@vagrant:/var/log/postgresql$ tail -f postgresql-15-main.log

2023-05-11 19:37:00.007 UTC [35712] LOG: - cron job 1 connection failed

2023-05-11 19:38:00.065 UTC [35712] LOG: - cron job 1 starting: SELECT 1

2023-05-11 19:38:00.070 UTC [45866] test@postgres FATAL: - password authentication failed for user "test"

2023-05-11 19:38:00.070 UTC [45866] test@postgres DETAIL: - User "test" has no password assigned.

        Connection matched pg_hba.conf line 97: "host     all                all                127.0.0.1/32               scram-sha-256"

W powyższym przykładzie widzimy, że pierwsze wykonania zadania nie powiodły się, ponieważ konfiguracja pg_hba.conf wymagała od użytkownika “test” hasła przy logowaniu. Po nadaniu mu hasła oraz stworzeniu pliku .pgpass w katalogu domowym użytkownika Postgres zadanie zaczęło się wykonywać poprawnie.

postgres=# alter user test with password '123';

ALTER ROLE

postgres@vagrant:/var/log/postgresql$ cat ~/.pgpass

*:*:*:test:123

postgres@vagrant:/var/log/postgresql$ tail -f postgresql-15-main.log

2023-05-11 19:40:00.003 UTC [35712] LOG: - cron job 1 starting: SELECT 1

2023-05-11 19:40:00.011 UTC [35712] LOG: - cron job 1 completed: 1 row

postgres=# select * from cron.job_run_details where status = 'succeeded';

 jobid | runid | job_pid | database | username | command - | - status - | return_message |             start_time             |             end_time               

-------+-------+---------+----------+----------+----------+-----------+----------------+-------------------------------+-------------------------------

     1 | - 29 - | - 50703 | postgres | test      | SELECT 1 | succeeded | 1 row                | 2023-05-11 19:40:00.010307+00 | 2023-05-11 19:40:00.010722+00

Powyższy przykład obrazuje, jak w prosty sposób pg_cron może ułatwić planowanie oraz zarządzanie zadaniami cyklicznymi w Postgresie. Dzięki temu, że rozszerzenia oraz ich obiekty są zachowywane w kopiach zapasowych, możemy mieć pewność, iż wszystkie zaplanowane zadania zostaną zachowane nawet w przypadku odtwarzania klastra z backupu na innym serwerze.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Uruchamianie i zatrzymywanie PostgreSQL - pg_ctl i systemctl
• ›PostgreSQL - role grupowe, czyli zbiorcze zarządzanie uprawnieniami
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Rozszerzenie PG_PREWARM pozwala na ładowanie całych obiektów - bazodanowych do pamięci. Dzięki PG_PREWARM możesz wybrać ładowany do - pamięci obiekt, możesz spowodować automatyczne ładowanie obiektów do - pamięci po restarcie, możesz przywracać stan shared_buffers po - restarcie.

Z tego artykułu dowiesz się:

• co to jest pg_prewarm i w jakim celu się go stosuje,- jak zainstalować pg_prewarm,- w jaki sposób za pomocą pg_prewarm ładować do pamięci całe obiekty bazodanowe,- jak z pomocą pg_prewarm przywrócić zawartość shared_buffers po restarcie

PostgreSQL cierpi na problem ten sam, z którym borykają się inne współczesne systemy bazodanowe. Mianowicie każdy restart powoduje wyczyszczenie buforów, pamięci współdzielonej przez użytkowników Postgresa do przechowywania najczęściej odczytywanych danych. Co za tym idzie, po każdym restarcie wydajność zapytań drastycznie spada, ponieważ wszystkie bloki danych muszą być przeczytane z dysku przed wróceniem do wyniku. Aby powrócić do wydajności sprzed restartu, musimy ponownie wypełnić je danymi, co może zająć dłuższy czas, szczególnie przy ogromnych wielkościach buforów współdzielonych (shared_buffers), które nierzadko potrafią mieć setki gigabajtów. Społeczność Postgresa wyszła temu naprzeciw i stworzyła rozszerzenie nazwane pg_prewarm. Pozwala ono na załadowanie obiektów do pamięci shared buffers. Mamy też możliwość wskazać obiekty, które chcemy wczytać, wykonać automatyczny zrzut bloków w shared_buffers do pliku dumpa w momencie zatrzymania klastra lub cyklicznie, aby nawet w przypadku crasha mieć możliwość załadowania danych do buforów. Wczytanie ze zrzutu pamięci może wykonać się automatycznie podczas startu klastra lub możemy wywołać funkcję - uruchamiającą procesy, które zaczną wypełniać pamięć współdzieloną blokami danych z dumpa. Ładowanie zrzutów pamięci odbywa się zawsze za pomocą dwóch procesów roboczych uruchamianych w tle.
Rozszerzenie pg_prewarm jest dostępne z każdą instalacją Postgresa od wersji 11, wcześniejsze wersje mogą wymagać instalacji dodatkowych paczek.

Konfiguracja pg_prewarm

Pierwszym krokiem konfiguracji będzie weryfikacja, czy rozszerzenie jest dostępne w widoku pg_available_extensions, który zwraca wszystkie dostępne rozszerzenia razem z ich wersją oraz krótkim opisem.

postgres=# select * from pg_available_extensions where name = 'pg_prewarm';

    name     | default_version | installed_version |          comment          

------------+-----------------+-------------------+-----------------------

 pg_prewarm | 1.2                |                       | prewarm relation data

(1 row)

Widzimy dostępny pg_prewarm w wersji 1.2, możemy więc przejść do następnego kroku, czyli załadowania rozszerzenia w aktualnej bazie. Dodając nowe rozszerzenia, należy pamiętać - o załadowaniu ich do każdej bazy, w której chcemy z niego korzystać, jednak w przypadku pg_prewarm wystarczy, że dodamy je w bazie Postgresql, ponieważ pamięć współdzielona shared_buffers jest wspólna dla wszystkich baz w klastrze.

postgres=# create extension pg_prewarm;

CREATE EXTENSION

postgres=# select * from pg_available_extensions where name = 'pg_prewarm';

    name     | default_version | installed_version |          comment          

------------+-----------------+-------------------+-----------------------

 pg_prewarm | 1.2                | 1.2                  | prewarm relation data

(1 row)

Po załadowaniu rozszerzenia w kolumnie installed_version widzimy aktualnie zainstalowaną wersję danego rozszerzenia. Jeżeli zainstalowaliśmy paczkę z nowszą wersją rozszerzenia, które mamy załadowane w naszej bazie w widoku pg_available_extensions, będziemy widzieli nową, wyższą wersję w kolumnie default_version, a wartość w kolumnie installed version powiększy się po wywołaniu polecenia "ALTER EXTENSION pg_prewarm UPDATE;", które spowoduje aktualizację rozszerzenia.

pg_prewarm w akcji

Na potrzeby demonstracji prześlę do bazy “postgres” dumpa z przykładowymi danymi:

postgres@vagrant:~$ wget https://jsystems.pl/nowy_blog/download/postgresql/tuning.zip 

postgres@vagrant:~$ psql < tuning.sql

W dumpie znajduje się tabela “companies”, która ma ponad 2GB. Postgres, którego użyję, posiada wartość buforów współdzielonych ustawioną na 4GB, więc powinna się w nich zmieścić cała tabela, pozostawiając 2GB pamięci dla systemu.

postgres=# show shared_buffers;

 shared_buffers 

----------------

 4GB

(1 row)

postgres=# \dt+ companies

                                         List of relations

 Schema |        Name        | Type - | - Owner - | Persistence | Access method | - Size - | Description 

--------+------------------+-------+----------+-------------+---------------+---------+-------------

 public | companies          | table | postgres | permanent - | heap             | 2177 MB |

 

(1 row)

Wykonam teraz kilkakrotnie ten sam select, aby załadować jak najwięcej bloków tabeli companies do pamięci.

postgres=# explain (analyze,buffers)select * from companies;

                        QUERY PLAN                                                                      

------------------------------------------------------------------------------

 Seq Scan on companies - (cost=0.00..298560.52 rows=1999852 width=1060) (actual

           time=0.727..3457.154 rows=2000000 loops=1)

   Buffers: shared read=278562

 Planning:

   Buffers: shared hit=100 read=23

 Planning Time: 6.552 ms

 Execution Time: 3518.307 ms

(6 rows)

postgres=# explain (analyze,buffers)select * from companies;

                        QUERY PLAN                                                                      

------------------------------------------------------------------------------

 Seq Scan on companies - (cost=0.00..298560.52 rows=1999852 width=1060) (actual 

           time=0.032..593.641 rows=2000000 loops=1)

   Buffers: shared hit=32 read=278530

 Planning Time: 0.062 ms

 Execution Time: 646.925 ms

(4 rows)

Pierwsze wykonanie potrzebowało ok 3,5 sekundy do zwrócenia wyniku, po kilku kolejnych wykonaniach część bloków danych została wrzucona do pamięci, a czas wykonania zapytania spadł do około 650 milisekund. W wierszach “Buffers: …” widzimy informację o ilości bloków przeczytanych z pamięci oraz z dysku lub z pamięci podręcznej dysku, “hit” - wartości znalezione w pamięci RAM, “read” - wartości odczytane z dysku. Warto pamiętać, że Postgres korzysta również z cache, więc często nawet jeżeli czegoś nie mamy w buforach współdzielonych, sam fakt, że linux przechowuje je w pamięci podręcznej, pozwala nam znacznie przyspieszyć wykonanie takiego zapytania. Na powyższym przykładzie widzieliśmy, że pierwsze wykonanie czytało wszystko z dysku, przy następnych kolejne bloki lądowały w shared buforach, ale nadal większość czytana była z “dysku” przy jednoczesnym znacznym przyspieszeniu czasu wykonania zapytania. Jest to spowodowane właśnie korzystaniem z pamięci podręcznej, do której linux wrzuca często używane bloki danych.

Sprawdzę teraz, jak będzie wyglądał plan wykonania zapytania po ręcznym załadowaniu całej tabeli companies do pamięci współdzielonej. Zacznę od restartu serwera, aby upewnić się, że pamięć jest pusta - , następnie wywołuję funkcję wczytującą tabele to pamięci i ponownie wykonam select z explain.

postgres=# select pg_prewarm('companies');

 pg_prewarm 

------------

     278562

(1 row)

 

postgres=# explain (analyze,buffers)select * from companies;

                                                       QUERY PLAN                                                                      

-------------------------------------------------------------------------------------------------------------------------

 Seq Scan on companies - (cost=0.00..298567.12 rows=2000512 width=1062) (actual time=0.047..177.284 rows=2000000 loops=1)

   Buffers: shared hit=278562

 Planning Time: 0.033 ms

 Execution Time: 227.135 ms

(4 rows)

Po wczytaniu całej tabeli czas potrzebny na wykonanie zapytania spadł ponownie o ponad połowę w porównaniu do wcześniejszego wyniku!

Powyższy test wykonany był w izolowanych warunkach, na bezczynnej bazie z wykorzystaniem tylko jednego zapytania i tabeli. Sprawdźmy jeszcze, jaką różnicę będziemy w stanie osiągnąć dla bardziej różnorodnego obciążenia wygenerowanego za pomocą pgbench.

Przeprowadziliśmy testy ręczne dla kilku wywołań, teraz sprawdzimy, jaki wzrost wydajności możemy osiągnąć przy użyciu masowych testów benchmarkiem PG_BENCH. Najpierw wygeneruję testowe dane, a następnie uruchomię test trwający minutę. Następnie zrestartuję serwer, aby upewnić się, że pamięci współdzielona i podręczna są wyczyszczone, załaduję tabele za pomocą pg_prewarm i wykonam test ponownie.

postgres@vagrant:~$ pgbench -i -s 150

dropping old tables...

NOTICE: - table "pgbench_accounts" does not exist, skipping

NOTICE: - table "pgbench_branches" does not exist, skipping

NOTICE: - table "pgbench_history" does not exist, skipping

NOTICE: - table "pgbench_tellers" does not exist, skipping

creating tables...

generating data (client-side)...

15000000 of 15000000 tuples (100%) done (elapsed 10.28 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done in 17.21 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 10.38 s, vacuum 0.52 s, primary keys 6.21 s).

postgres=# \dt+

                                         List of relations

 Schema |        Name        | Type - | - Owner - | Persistence | Access method | - Size - | Description 

--------+------------------+-------+----------+-------------+---------------+---------+-------------

 public | pgbench_accounts | table | postgres | permanent - | heap             | 1922 MB | 

 public | pgbench_branches | table | postgres | permanent - | heap             | 40 kB - | 

 public | pgbench_history - | table | postgres | permanent - | heap             | 0 bytes | 

 public | pgbench_tellers - | table | postgres | permanent - | heap             | 104 kB - | 

(4 rows)

postgres@vagrant:~$ pgbench -T 60 -S

pgbench (15.2 (Ubuntu 15.2-1.pgdg22.04+1))

starting vacuum...end.

transaction type: <builtin: select only>

scaling factor: 150

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 60 s

number of transactions actually processed: 373662

number of failed transactions: 0 (0.000%)

latency average = 0.161 ms

initial connection time = 1.953 ms

tps = 6227.712352 (without initial connection time)

Pgbench świeżo po restarcie systemu, z pustymi buforami, w ciągu minuty osiągnął - w sumie 373662 transakcji, 6227 transakcji na sekundę. Wykonam teraz restart serwera i uruchomię test ponownie, ale po wcześniejszym załadowaniu największej tabeli do shared buforów.

postgres=# select pg_prewarm('pgbench_accounts');

 pg_prewarm 

------------

     248895

(1 row)

postgres@vagrant:~$ pgbench -T 60 -S

pgbench (15.2 (Ubuntu 15.2-1.pgdg22.04+1))

starting vacuum...end.

transaction type: <builtin: select only>

scaling factor: 150

query mode: simple

number of clients: 1

number of threads: 1

maximum number of tries: 1

duration: 60 s

number of transactions actually processed: 1173817

number of failed transactions: 0 (0.000%)

latency average = 0.051 ms

initial connection time = 1.689 ms

tps = 19559.914627 (without initial connection time)

Po wstępnym “rozgrzaniu” buforów pgbench osiągnął 1173817 transakcji w sumie, a 19559 transakcji na sekundę, czyli około trzykrotnie lepszy rezultat. Test był przeprowadzony na małej wielkości shared_buffers, tylko kilku tabelach i mało zróżnicowanych zapytaniach. Im więcej obiektów odpytujemy i im większa jest pamięć współdzielona, tym dłużej może trwać rozgrzewanie buforów, a tym samym niższa wydajność bazy może utrzymywać się przez dłuższy czas po restarcie, żeby finalnie zapytania powróciły do wydajności przed restartem.

W powyższych przykładach załadowaliśmy dane z tabeli ręcznie, ale pg_prewarm ma możliwość robienia tego za nas automatycznie, bez jakiejkolwiek ingerencji z naszej strony.
Działa to w ten sposób, że pg_prewarm zrzuca co jakiś czas stan bufora shared_buffers na dysk. W przypadku restartu, po uruchomieniu serwera wczytywany jest stan bufora z dysku z chwili niewiele przed restartem.
Aby z tej funkcjonalności skorzystać, musimy dodać pg_prewarm to do parametru shared_preload_libraries oraz dodać dwa kolejne parametry dla pg_prewarma w pliku postgresql.conf, a także zrestartować klaster. Parametry te, oprócz autoprewarm_interval, są wczytywane tylko podczas startu Postgresa.

shared_preload_libraries = 'pg_prewarm'

pg_prewarm.autoprewarm = true

pg_prewarm.autoprewarm_interval = 300s

Od tej chwili pg_prewarm będzie wykonywał zrzut pamięci co autoprewarm_interval sekund oraz w momencie zatrzymania instancji. Podczas startu uruchomi proces roboczy, który załaduje bloki ze zrzutu do pamięci. W ten sposób odtworzymy stan buforów z chwili max “pg_prewarm.autoprewarm_interval” sekund przed restartem.

Jak widać na powyższym przykładzie restart i spowodowane tym wyczyszczenie pamięci współdzielonej Postgresa nie musi być skomplikowane. W łatwy sposób możemy przeprowadzić te czynności.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów
• ›Migracja z Oracle do PostgreSQL w praktyce
• ›Co to jest KNIME? Tutorial krok po kroku
• ›Co to jest Snowflake? Prosty przewodnik po chmurowej hurtowni danych
• ›Współczesne rozwiązania Big Data 2026

Rozszerzenie PG_AUDIT umożliwia śledzenie działań użytkowników, a także zmian i selectów na tabelach.

Z tego artykułu dowiesz się:

• co to jest pg_audit i w jakim celu się go stosuje,- jakie są alternatywy dla pg_audit,- jak zainstalować pg_audit na Ubuntu,- jak zainstalować pg_audit na systemach z rodziny Red Hat,- jak za pomocą pg_audit audytować wybrane obiekty.

Audytowanie w PostgreSQL

PostgreSQL udostępnia zestaw funkcjonalności umożliwiających skonfigurowanie podstawowego audytowania aktywności do logu. Między innymi audytowanie połączeń do bazy za pomocą parametrów: log_connection, log_disconnection, audytowanie zapytań dzięki parametrom: log_statement czy audytowanie cięższych zapytań: log_temp_files, log_lock_waits. Rozwiązanie to nie wymaga instalowania żadnych dodatkowych rozszerzeń, nie tworzy nowych obiektów i triggerów w bazie, dzięki temu, że wyniki są zapisywane poza klastrem, w pliku loga, nie powoduje obciążenia Postgresa dodatkowymi transakcjami i obiektami, które muszą być obsłużone przez autovacuum. Ale z drugiej strony, nie ma możliwości ograniczenia audytowanych obiektów. Zawsze zapisujemy aktywność w całej instancji, dla wszystkich baz, przez wszystkich użytkowników, przez co dobrze sprawdza się tylko dla baz o małej aktywności. Przy bazach z większym obciążeniem metoda ta może wygenerować bardzo dużo wpisów do pliku loga, nawet kilkadziesiąt GB na godzinę lub więcej.

Innym bardzo prostym sposobem na stworzenie audytowania obiektów, również bez instalacji żadnych dodatkowych rozszerzeń, jest skorzystanie z triggerów. Tutaj już z możliwością wskazania obiektów, które będę audytował.
Na początek stworzę tabelę, do której będę logował wszystkie zapytania na wybranych obiektach.

CREATE TABLE audyt.dziennik_aktywnosci (

    schemat text NOT NULL,

    tabela text NOT NULL,

    uzytkownik text,

    typ text,

    data TIMESTAMP WITH TIME zone NOT NULL DEFAULT CURRENT_TIMESTAMP,

    stara_wartosc text,

    nowa_wartosc text,

    zapytanie text

);

Następnie tworzę funkcję, którą będziemy wywoływać triggerem po każdej wykonanej operacji DML (Data Modification Language - INSERT, UPDATE, DELETE).

CREATE OR REPLACE FUNCTION audyt.zmiana_wartosci() RETURNS TRIGGER AS \(body\)

DECLARE

    stara_wartosc TEXT;

    nowa_wartosc TEXT;

BEGIN

    IF (TG_OP = 'UPDATE') THEN

        stara_wartosc:= ROW(OLD.*);

        nowa_wartosc:= ROW(NEW.*);

        INSERT INTO audyt.dziennik_aktywnosci (schemat,tabela,uzytkownik,typ,stara_wartosc,nowa_wartosc,zapytanie) 

        VALUES (TG_TABLE_SCHEMA::TEXT,TG_TABLE_NAME::TEXT,session_user::TEXT,substring(TG_OP,1,1),stara_wartosc,nowa_wartosc, current_query());

        RETURN NEW;

    ELSIF (TG_OP = 'DELETE') THEN

        stara_wartosc:= ROW(OLD.*);

        INSERT INTO audyt.dziennik_aktywnosci (schemat,tabela,uzytkownik,typ,stara_wartosc,zapytanie)

        VALUES (TG_TABLE_SCHEMA::TEXT,TG_TABLE_NAME::TEXT,session_user::TEXT,substring(TG_OP,1,1),stara_wartosc, current_query());

        RETURN OLD;

    ELSIF (TG_OP = 'INSERT') THEN

        nowa_wartosc:= ROW(NEW.*);

        INSERT INTO audyt.dziennik_aktywnosci (schemat,tabela,uzytkownik,typ,nowa_wartosc,zapytanie) 

        VALUES (TG_TABLE_SCHEMA::TEXT,TG_TABLE_NAME::TEXT,session_user::TEXT,substring(TG_OP,1,1),nowa_wartosc, current_query());

        RETURN NEW;

    ELSE

        RAISE WARNING '[audyt.zmiana_wartosci] - Other action occurred: %, at %',TG_OP,now();

        RETURN NULL;

    END IF;

EXCEPTION

    WHEN data_exception THEN

        RAISE WARNING '[audyt.zmiana_wartosci] - UDF ERROR [DATA EXCEPTION] - SQLSTATE: %, SQLERRM: %',SQLSTATE,SQLERRM;

        RETURN NULL;

    WHEN unique_violation THEN

        RAISE WARNING '[audyt.zmiana_wartosci] - UDF ERROR [UNIQUE] - SQLSTATE: %, SQLERRM: %',SQLSTATE,SQLERRM;

        RETURN NULL;

    WHEN OTHERS THEN

        RAISE WARNING '[audyt.zmiana_wartosci] - UDF ERROR [OTHER] - SQLSTATE: %, SQLERRM: %',SQLSTATE,SQLERRM;

        RETURN NULL;

END;

\(body\)

LANGUAGE plpgsql

SECURITY DEFINER

SET search_path = pg_catalog, audyt;

Stworzę trigger dla tabeli, którą chcę audytować.

CREATE TRIGGER audyt_test

AFTER INSERT OR UPDATE OR DELETE ON test

FOR EACH ROW EXECUTE PROCEDURE audyt.zmiana_wartosci();

Po wykonaniu każdej operacji podanej w triggerze do tabeli audyt.dziennik_aktywnosci zostanie dodany nowy wpis.

SELECT * FROM audyt.dziennik_aktywnosci ;

-[ RECORD 1 ]-+---------------------------------

schemat        | public

tabela          | test

uzytkownik     | postgres

typ             | I

data             | 2023-05-19 19:55:28.370979+00

stara_wartosc | 

nowa_wartosc - | (1,2)

zapytanie      | INSERT INTO test VALUES (1,2);

-[ RECORD 2 ]-+---------------------------------

schemat        | public

tabela          | test

uzytkownik     | postgres

typ             | U

data             | 2023-05-19 19:56:06.715819+00

stara_wartosc | (2,2)

nowa_wartosc - | (2,2)

zapytanie      | UPDATE test SET x=2 WHERE y = 2;

-[ RECORD 3 ]-+---------------------------------

schemat        | public

tabela          | test

uzytkownik     | postgres

typ             | D

data             | 2023-05-19 19:56:57.534169+00

stara_wartosc | (2,2)

nowa_wartosc - | 

zapytanie      | DELETE FROM test WHERE x=2;

(3 rows)

Od razu można zauważyć, że tutaj audytować można tylko zmiany wartości w tabeli (AFTER INSERT OR UPDATE OR DELETE). Nie ma możliwości wywołania triggera dla zapytań, które tylko odczytują dane. Kolejnym problemem jest fakt, że każda transakcja zmieniająca dane w audytowanej tabeli zostanie wydłużona o czas potrzebny na wywołanie funkcji, co przy często modyfikowanej tabeli może się przełożyć sumarycznie na znacznie niższą liczbę transakcji na sekundę.

PgAudit - zaawansowane audytowanie obiektów i sesji użytkowników

PgAudit rozszerza możliwości audytowania w Postgresie o bardziej precyzyjną kontrolę nad logowaniem sesji użytkowników i obiektów. Logowanie odbywa się do pliku na dysku. Rozwiązanie powyższe jest dużo lżejsze niż to z wykorzystaniem triggerów, więc jego wpływ na audytowaną instancję jest znacznie mniejszy.

Pakiety instalacyjne dla rozszerzenia dostępne są w oficjalnych repozytoriach PGDG (PostgreSQL Global Development Group).

### Ubuntu/Debian

sudo apt-get -y install postgresql-15-pgaudit

### RHEL/CentOS

sudo yum install -y pgaudit17_15.x86_64

Przed stworzeniem rozszerzenia w bazie muszę je dodać też do parametru “shared_preload_libraries” i zrestartować instancję.

postgres@vagrant:~$ psql -c "ALTER SYSTEM SET shared_preload_libraries=pg_cron,pgaudit"

# restart na Debian/Ubuntu

/usr/lib/postgresql/15/bin/pg_ctl -D /katalog/pg/data restart -m fast

# restart na RHEL/Centos

/usr/pgsql-15/bin/pg_ctl -D /katalog/pg/data restart -m fast

Po restarcie upewniam się, że rozszerzenie zostało poprawnie załadowane.

SHOW shared_preload_libraries;

  shared_preload_libraries -  

-----------------------------

  pg_cron, pgaudit

SELECT * FROM pg_available_extensions WHERE name LIKE '%audit';

  name - | default_version | installed_version |                comment                

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.7                |                       | provides auditing functionality

Teraz mogę przejść do stworzenia rozszerzenia w bazie oraz ustawienia poziomu audytowania.

CREATE EXTENSION pgaudit;

SELECT * FROM pg_available_extensions WHERE name LIKE '%audit';

  name - | default_version | installed_version |                comment                

---------+-----------------+-------------------+---------------------------------

 pgaudit | 1.7                | 1.7                  | provides auditing functionality

ALTER SYSTEM SET pgaudit.log TO 'read, write';

SELECT pg_reload_conf();

SHOW pgaudit.log;

 pgaudit.log 

-------------

 read, write

Parameter pgaudit.log przyjmuje następujące wartości:

• READ - zapytań odczytujących dane (SELECT, COPY),
• WRITE - zapytań zmieniających dane (INSERT, UPDATE, TRUNCATE oraz COPY, jeżeli miejscem docelowym jest relacja w bazie),
• FUNCTION - funkcji oraz bloków DO,
• ROLE - roli i użytkowników (GRANT, REVOKE, CREATE/ALTER/DROP ROLE),
• DDL (zmiany obiektów, które nie należą do klasy ROLE),
• MISC (pozostałe, np. DISCARD, FETCH, CHECKPOINT, VACUUM),
• ALL - wszystkie powyższe.

Wartości można podawać oddzielone przecinkiem, na powyższym przykładzie audytowane będą wszystkie zapytania, które odczytują i zmieniają dane (READ, WRITE). Można też użyć wartości 'all, -misc, -ddl', za pomocą którego rozpocznę audytowanie wszystkiego oprócz MISC oraz DDL.

Poziom audytu można ustawić też dla każdego z użytkowników oraz dla każdej bazy z osobna, na przykład:

ALTER USER superuser SET pgaudit.log TO 'read, write, ddl';

ALTER DATABASE testdb SET pgaudit.log=read,write,function;

Po włączeniu audytowania Postgres zacznie dodawać do swojego pliku loga dodatkowe wpisy:

postgres@vagrant:~/15/main$ less /var/log/postgresql/postgresql-15-main.log

2023-05-19 19:51:00.153 UTC [5458] test@postgres LOG: - AUDIT: SESSION,1,1,READ,SELECT,,,SELECT 1,<not logged>

2023-05-19 19:51:12.648 UTC [5400] postgres@postgres LOG: - AUDIT: SESSION,38,1,WRITE,INSERT,,,"INSERT INTO test VALUES (1,2);",<not logged>

2023-05-19 19:51:58.831 UTC [5400] postgres@postgres LOG: - AUDIT: SESSION,43,1,WRITE,UPDATE,,,UPDATE test SET x=2 WHERE y = 2;,<not logged>

na końcu każdej linii oznacza, że pgaudit nie loguje wartości parametrów dla zapytań. Jeżeli potrzebowałbym logować parametry zapytań, można je dodać za pomocą parametru pgaudit.log_parameter = on, po czym należy przeładować konfigurację. Parametry pojawią się na końcu linii, oddzielone przecinkiem, a dla zapytań bez parametrów dodana zostanie końcówka .

2023-05-19 20:12:00.043 UTC [1683] LOG: - AUDIT: SESSION,181,1,WRITE,INSERT,,,"INSERT INTO cron.job_run_details (jobid, runid, database, username, command, status) VALUES (\(1,\)2,\(3,\)4,\(5,\)6)","1,5273,postgres,test,SELECT 1,starting"

2023-05-19 20:12:00.057 UTC [5556] test@postgres LOG: - AUDIT: SESSION,1,1,READ,SELECT,,,SELECT 1,<none>

Audytowanie poszczególnych obiektów

PgAudit umożliwia logowanie zapytań na wybranych obiektach. Aby z niego skorzystać, należy stworzyć dedykową rolę, która zostanie “audytorem” i dodać ją do parametru pgaudit.role. Zanim rozpocznę, wyłączę też poprzednie globalne ustawienia audytowania.

ALTER SYSTEM RESET pgaudit.log;

SELECT pg_reload_conf();

SHOW pgaudit.log;

 pgaudit.log 

-------------

 none

CREATE ROLE audytor NOLOGIN;

ALTER SYSTEM SET pgaudit.role TO 'audytor';

SELECT pg_reload_conf();

Od tego momentu każda relacja i kolumna, do której “audytor” ma dostęp, będzie audytowana do pliku loga pod kątem operacji, do której ma uprawnienia.

CREATE TABLE tabela_audytowana (x int, y int);

GRANT SELECT ON tabela_audytowana TO audytor;

INSERT INTO tabela_audytowana VALUES (1,2);

SELECT * FROM tabela_audytowana ;

 x | y 

---+---

 1 | 2

2023-05-19 20:27:30.697 UTC [5622] postgres@postgres LOG: - AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.tabela_audytowana,SELECT * FROM tabela_audytowana ;,<none>

W tym przypadku audytorowi nadałem uprawnienia SELECT, dlatego w logu pojawił się tylko jeden wpis odnośnie SELECT, INSERT został pominięty. Zmienił się też kontekst, AUDIT: OBJECT zamiast wcześniejszego AUDIT: SESSION.

Parametr pgaudit.role przyjmuje jako wartość tylko jednego użytkownika, jeżeli potrzebowałbym stworzyć kilku audytorów, na przykład dla każdej bazy lub aplikacji osobną rolę, mógłbym skorzystać z możliwości Postgresa do dziedziczenia roli.

CREATE ROLE audytor_odczyt NOLOGIN;

CREATE ROLE audytor_zapis NOLOGIN;

GRANT audytor_odczyt TO audytor;

GRANT audytor_zapis TO audytor;

Następnie należałoby dodać odpowiednie uprawnienia. Chcę logować zapytania, które czytają wartości z kolumn ‘x’ i ‘y’, wszystkie INSERT i DELETE oraz UPDATE na kolumnie ‘y’.

GRANT SELECT (x,y) ON tabela_audytowana TO audytor_odczyt ;

GRANT INSERT,UPDATE(y),DELETE ON tabela_audytowana TO audytor_zapis ;

INSERT INTO tabela_audytowana VALUES (2,3);

UPDATE tabela_audytowana SET x = 5 WHERE x = 2;

UPDATE tabela_audytowana SET y = 5 WHERE x = 5;

SELECT * FROM tabela_audytowana ;

 x | y 

---+---

 1 | 2

 5 | 5

2023-05-19 20:40:15.614 UTC [5675] postgres@postgres LOG: - AUDIT: OBJECT,1,1,WRITE,INSERT,TABLE,public.tabela_audytowana,"INSERT INTO tabela_audytowana VALUES (2,3);",<none>

2023-05-19 20:40:49.308 UTC [5675] postgres@postgres LOG: - AUDIT: OBJECT,4,1,WRITE,UPDATE,TABLE,public.tabela_audytowana,UPDATE tabela_audytowana SET y = 5 WHERE x = 5;,<none>

2023-05-19 20:42:51.538 UTC [5675] postgres@postgres LOG: - AUDIT: OBJECT,5,1,READ,SELECT,TABLE,public.tabela_audytowana,SELECT * FROM tabela_audytowana ;,<none>

Ważna uwaga, jeżeli skonfigurowałbym audytowanie sesji użytkowników oraz poszczególnych obiektów jednocześnie, pgaudit dodawałby podwójne wpisy dla wszystkich pasujących zapytań, różniłby się tylko kontekst, “SESSION” lub “OBJECT”.

Tak generowane logi mogę wyparsować w bashu za pomocą narzędzi takich jak grep, awk, - i tym podobne, aby zwracały interesujące mnie wiersze z audytu. Mogę również wczytać plik loga do tabeli w Postgresie i przeanalizować sobie go za pomocą SQLa lub przygotowanych wcześniej widoków, funkcji, itp.

Aby wczytać plik loga do tabeli, muszę się upewnić, że parametry w Postgresie są odpowiednio ustawione. Szczególnie na Ubuntu, gdzie często logging collector jest domyślnie wyłączony, a logowanie odbywa się za pomocą przekierowania informacji zwracanych przez proces Postgrsa do pliku tekstowego. Parametr logging_collector przy zmianie wymaga restartu Postgresa.

CREATE TABLE postgres_log

(

  log_time timestamp(3) with time zone,

  user_name text,

  database_name text,

  process_id integer,

  connection_from text,

  session_id text,

  session_line_num bigint,

  command_tag text,

  session_start_time timestamp with time zone,

  virtual_transaction_id text,

  transaction_id bigint,

  error_severity text,

  sql_state_code text,

  message text,

  detail text,

  hint text,

  internal_query text,

  internal_query_pos integer,

  context text,

  query text,

  query_pos integer,

  location text,

  application_name text,

  backend_type text,

  leader_pid integer,

  query_id bigint,

  PRIMARY KEY (session_id, session_line_num)

);

# ścieżka do pliku powinna odpowiadać ścieżce do pliku loga do którego zapisuje postgres

COPY postgres_log FROM '/var/log/postgresql/postgresql.csv' WITH csv;

Tak stworzoną tabelę mogę w łatwy sposób przeszukiwać za pomocą SQLa.

postgres=# select * from postgres_log where message like 'AUDIT%' AND command_tag = 'INSERT';

-[ RECORD 1] ----------+-------------------------------------------------------------------------------------------------------------------

log_time                  | 2023-05-23 20:07:45.589+00

user_name                  | postgres

database_name             | postgres

process_id                | 10503

connection_from          | [local]

session_id                | 646d16f7.2907

session_line_num        | 3

command_tag               | INSERT

session_start_time      | 2023-05-23 19:41:43+00

virtual_transaction_id | 4/100

transaction_id           | 0

error_severity           | LOG

sql_state_code           | 00000

message                    | AUDIT: OBJECT,1,1,WRITE,INSERT,TABLE,public.tabela_audytowana,"insert into tabela_audytowana values (2,3);",<none>

detail                     | 

hint                       | 

internal_query           | 

internal_query_pos      | 

context                    | 

query                       | 

query_pos                  | 

location                  | 

application_name        | psql

backend_type             | client backend

leader_pid                | 

query_id                  | 0

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Upgrade klastra PostgreSQL - pg_upgrade krok po kroku
• ›PostgreSQL - Rodzaje replikacji
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Słów kilka o najważniejszych pojęciach związanych z administracją serwerami PostgreSQL. Od bazy danych do high availability.

Z tego artykułu dowiesz się:

• jakie są najważniejsze pojęcia związane z bazami danych PostgreSQL,- jaki jest podział fizyczny i logiczny klastra PostgreSQL,- czym są i jak działają pliki WAL,- czym jest i jak działa checkpoint,- jaki jest związek pomiędzy plikami WAL a checkpointami,- jakie są rodzaje kopii zapasowych i czym się charakteryzują,- czym jest replikacja, w jakim celu się ją stosuje i jak działa,- czym jest HA - High Availability - czyli jak zapewnić dostępność klastra przez nawet 99,999% czasu.

Klaster

Pojedyncza instancja instalacji serwera PostgreSQL. - Klaster zawiera wszystkie pliki niezbędne do działania serwera PostgreSQL. Są to pliki danych, pliki konfiguracyjne, a także inne pliki niezbędne do działania serwera np. pliki WAL.

Klaster zawiera w sobie bazy danych, przestrzenie tabel, schematy etc. Klaster ma wspólną konfigurację w plikach takich jak postgresql.conf, postgresql.auto.conf czy pg_hba. Ustawienia na tym poziomie dotyczą wszystkich baz danych.

Przestrzeń pamięci operacyjnej klastra jest współdzielona przez wszystkie zawarte w nim bazy danych. Wspólne są też procesy.

Fizyczne kopie zapasowe - (zimne i gorące) robimy zawsze na poziomie klastra. Nie możemy zrobić fizycznej (w przeciwieństwie do logicznej) kopii zapasowej wybranej bazy danych.

PGDATA

Główny katalog klastra PostgreSQL. Znajdują się tu wszystkie pliki danych, pliki konfiguracyjne oraz wszelkie pliki niezbędne do działania klastra z wyłączeniem plików binarnych, które znajdują się w innej lokalizacji.

Baza danych

Baza danych to osobny zbiór danych w ramach klastra. Umożliwiają odseparowanie logiczne danych np. różnych systemów.

Bazy danych są strukturą logiczną, choć wiążą się ze strukturą fizyczną. Każda baza danych ma swój osobny katalog na serwerze. - Dane pomiędzy poszczególnymi bazami danych są od siebie odseparowane fizycznie i logicznie. Niestety nie są na tyle niezależne jak np. w Oracle czy SQL Server, by można było osobno robić fizyczne kopie zapasowe i osobno przywracać bazy danych. Co prawda można wykonać eksport danych do pliku tekstowego za pomocą pg_dump, ale nie jest to kopia zapasowa w pełnym tego słowa znaczeniu i nie pozwala np. przywrócić bazy do wybranego punktu w czasie.

Przestrzeń tabel

Przestrzenie tabel fizycznie są katalogami. Zakłada się je na przykład, by trzymać część danych na osobnym dysku. Robi się tak, - kiedy chcemy rozłożyć obciążenie I/O na kilka dysków i dzięki temu poprawić wydajność. Możemy też wykorzystać osobne przestrzenie tabel, gdy kończy się miejsce na dysku zawierającym klaster PostgreSQL. W przestrzeniach tabel możemy umieszczać pojedyncze obiekty (tabele, indeksy etc.), ale też całe bazy danych.

Użytkownik/rola

Użytkownik to po prostu konto na które się logujemy. Umożliwia łączenie się do serwera bazodanowego i wykonywanie na nim operacji. Jeśli potrzebujemy konta które ma być właścicielem jakichś obiektów ale nikt nie powinien się na nie logować, tworzymy rolę czyli użytkownika bez możliwości logowania.

Sesja

Sesja to połączenie do bazy danych. Łącząc się do klastra zawsze łączymy się do wybranej bazy danych jako konkretny użytkownik. Każda sesja jest związana ze swoim procesem w systemie operacyjnym po stronie serwera baz danych.

Tuple (krotka)

PostgreSQL wywodzi się od Ingresa, systemu zarządzania bazami danych mającego swoje początki na Uniwersytecie Kalifornijskim Berkeley. Dlatego też wiele pojęć z którymi możemy spotkać się w dokumentacji Postgresa, bądź słuchając/czytając ludzi zajmujących się głównie postgresem, możemy usłyszeć nazwy niepokrywające się z pozostałymi systemami danych. Pierwszy przykład to właśnie “tuple”, po polsku “krotka” czyli uporządkowana kolekcja stałych wartości lub inaczej tablica stałych wartości. A tak naprawdę “tuple” to po prostu wiersz w tabeli.

Relation (relacja)

Tak samo jak w przypadku tuple, relacja to w języku naukowym to po prostu tabela. Warto o tym pamiętać, ponieważ nawet sam PostgreSQL się do tego w ten sposób odwołuje. Np. w widoku pg_class, wartość relkind wskazuje na typ obiektu. I tak kolejno: i = index, S = sequence, t = TOAST table, v = view, m = materialized view, c = composite type, f = foreign table, p = partitioned table, I = partitioned index i wreszcie r = table.

Schemat

Bazy danych zawierają jeden lub więcej schematów, w których znajdują się obiekty bazodanowe. Podział na schematy nie wiąże się z podziałem fizycznym, jest to tylko podział logiczny. Umożliwiają posiadanie kilku tabel o tej samej nazwie, ale w różnych schematach. Pozwalają też łatwiej zarządzać obiektami bazy danych dzięki zorganizowaniu w podgrupy, a także zbiorowe nadawanie i odbieranie uprawnień do obiektów.

Pliki WAL

Zanim zmiany na danych zostaną wprowadzone do plików danych, odnotowywane są w plikach WAL. Zapis do plików WAL musi zawierać wszystko co potrzebne do powtórzenia operacji. Zapis do plików danych następuje w zdarzeniu “checkpoint”, wtedy utrwalane są w nich wszystkie brudne bloki - czyli zmiany które znajdują się tylko w plikach WAL, a nie zostały jeszcze zmienione na poziomie plików danych. Pliki WAL są niezbędne w sytuacji odtwarzania stanu klastra po ewentualnej awarii. W takiej sytuacji przy uruchamianiu serwer PostgreSQL odczytuje wpisy z plików WAL od ostatniego checkpointa i powtarza je, celem odtworzenia stanu klastra tuż przed awarią. Po takim awaryjnym odtworzeniu następuje automatyczny checkpoint.

Checkpoint

W trakcie checkpointa następuje zapis wszystkich brudnych bloków do plików danych. W przypadku awarii PostgreSQL sprawdza punkt czasowy ostatniego checkpoint'a, by określić punkt, od którego ma rozpocząć odzyskiwanie REDO na podstawie plików WAL. Dzięki temu wie, od którego pliku WAL i jakiego offsetu w tym pliku ma rozpocząć odzyskiwanie.

Fizyczna kopia zapasowa

Kopia klastra zawierająca pliki danych, pliki konfiguracyjne - i inne pliki niezbędne do działania klastra. Taka kopia umożliwia odtworzenie tylko całego klastra, a nie pojedynczych baz danych. Dzięki kopii fizycznej i plikom WAL możemy odtworzyć klaster do wskazanego punktu w czasie. Takie kopie zapasowe tworzymy np za pomocą pg_basebackup.

Logiczna kopia zapasowa

To kopia zawierająca instrukcje tworzenia i wypełniania struktur bazodanowych, użytkowników etc. Dotyczy więc tylko logicznej struktury danych. Nie zawiera plików konfiguracyjnych klastra. Plikiem wynikowym może być plik SQL lub plik binarny. Nie współpracuje z plikami WAL, więc nie umożliwia odtworzenia klastra do wskazanego punktu w czasie. Pozwala tworzyć kopie zapasowe dla wybranych baz danych, ale także np dla wybranych tabel. Takie kopie zapasowe tworzymy za pomocą narzędzi pg_dump i pg_dumpall.

Replikacja

PostgreSQL umożliwia stworzenie repliki, czyli serwera będącego kopią serwera źródłowego zasilanego zmianami z serwera źródłowego. Dzięki temu, stan repliki cały czas pozostaje identyczny jak stan serwera master. Aby stworzyć replikę, najpierw tworzymy kopię serwera master na serwerze repliki, a następnie strumieniujemy wszystkie zmiany w plikach WAL z serwera master na serwer repliki. - Serwer replikujący pozostaje w stanie tylko do odczytu. Posiadanie takiej repliki może być użyteczne gdy chcemy stworzyć osobny serwer na potrzeby analityczne - tak aby związane z tym obciążenie przenieść na replikę. Może też nam się przydać gdy coś się stanie z serwerem źródłowym. Możemy przełączyć replikę do trybu zapis-odczyt i dzięki temu może ona przejąć rolę serwera źródłowego.

High Availability - wysoka dostępność

To zestaw technik wykorzystywanych w celu zapewnienia nieprzerwanego dostępu do aplikacji, w tym przypadku bazy danych Postgresql, nawet podczas awarii niektórych komponentów. Dla baz danych, mechanizmy wysokiej dostępności zazwyczaj sprowadzają się do monitoringu statusu postgresa oraz w przypadku problemów z dostępnością wykonywania awaryjnego przerzucenia roli "primary", czyli serwera obsługującego operacje zapisu i odczytu, na replikę która do tej pory obsługiwała jedynie odczyt. Często stosuje się dodatkowy mechanizm "witness", czyli świadka, który jest niezależny od pozostałych serwerów bazodanowych, i może pomóc podjąć decyzję, czy aktualny serwer główny rzeczywiście przestał odpowiadać, czy to tylko tymczasowa przerwa w działaniu sieci pomiędzy serwerem głównym i repliką. Popularnymi narzędziami stosowanymi w Postgresie do osiągnięcia wysokiej dostępności są np. Patroni oraz REPMGR.

A jeżeli już korzystamy z wysokiej dostępności, warto dodać też loadbalancing, czyli automatyczne rozrzucanie połączeń pomiędzy serwerami w klastrze HA w celu ogólnej poprawy wydajności klastra i przyspieszenia odpowiedzi z bazy. Drugim wartym dodania komponentem jest connection pooling, czyli mechanizm pozwalający na poprawę wydajności przy nawiązywaniu i zamykaniu połączeń poprzez utrzymywanie puli stałych otwartych połączeń, które mogą być naprzemiennie wykorzystywane przez różne połączenia z aplikacji. Oba te mechanizmy bardzo często implementuje się po stronie aplikacji, a jeżeli nie jest to możliwe, lub jest trudne do wykonania, dodaje się zewnętrzne narzędzia, takie jak HAProxy dla loadbalancingu oraz pgBouncer dla kolejkowania połączeń.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Upgrade klastra PostgreSQL - pg_upgrade krok po kroku
• ›PostgreSQL - Rodzaje replikacji
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Jak poprawnie wdrożyć klaster PostgreSQL na Ubuntu? Jak sprawić by uruchamiał się automatycznie z systemem? Jak określić położenie PGDATA? Na te i inne pytania znajdziesz odpowiedzi w tym artykule :)

Z tego artykułu dowiesz się:

• jak zainstalować binaria wybranej wersji (a nie - domyślnej dla systemu) na serwerach z systemem Ubuntu,- gdzie co leży,- jak dodać binaria PostgreSQL do PATHa,- jak samemu zdefiniować położenie klastra,- jak skonfigurować by PostgreSQL działał jako usługa (dzięki czemu wygodniej się nim zarządza),- jak skonfigurować automatyczny start PostgreSQL z systemem,- jak skonfigurować system Ubuntu w taki sposób, by nie restartował PostgreSQL w przypadku gdy zacznie kończyć się pamięć RAM,- jak skonfigurować system Ubuntu w taki sposób, by nie wpadał w nieskończony cykl odtwarzania.

Pierwszy krok to stworzenie pliku konfiguracji dla repozytorium jako użytkownik z uprawnieniami sudo albo root. W drugim przypadku pomijamy sudo na początku poleceń z instrukcji:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Pobranie i import klucza dla oficjalnego repozytorium Ubuntu do listy zaufanych kluczy w apt:

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Aktualizacja listy dostępnych pakietów:

sudo apt-get update

Instalacja dostępnych aktualizacji:

sudo apt-get upgrade -y

Restart serwera po aktualizacji niektóre paczki, szczególnie te aktualizujące jądro linuxa, nie będą “aktywne” do następnego startu serwera:

sudo reboot

Przystępujemy do instalacji binariów PostgreSQL. Łączymy się do serwera ponownie (na pewno nas rozłączyło przy restarcie) i wykonujemy:

sudo apt-get -y install postgresql-15

Po instalacji pakietów PostgreSQL - Ubuntu automatycznie stworzy i wystartuje domyślny klaster. Sprawdzamy, czy działa:

systemctl status postgres*

Domyślnie PostgreSQL w Ubuntu będzie miał pliki rozmieszczone w takich lokalizacjach:

Katalog z binariami: /usr/lib/postgresql/15/bin/
Katalog domowy postgresa: /var/lib/postgresql

Część plików konfiguracyjnych znajduje się w /etc/postgresql/15/main. W tym dwa bardzo ważne i często aktualizowane: „postgresql.conf”i „pg_hba.conf”. Zajmiemy się nimi nieco później:

Dosyć często będziemy działać z poziomu użytkownika systemowego postgres (zostaje on utworzony w chwili instalacji PostgreSQL), dlatego warto, by miał - w swoim PATH binarki PostgreSQL. Dzięki temu nie będziemy musieli wskazywać pełnych ścieżek do binarek, które chcemy - użyć. W tym celu logujemy się na postgresa:

sudo su - postgres

Następnie już jako użytkownik systemowy postgres wykonujemy:

cat << EOF >> ~/.bash_profile
PATH=$PATH:/usr/lib/postgresql/15/bin
export PATH

EOF

Zmiana ta nie będzie widoczna od razu. Istnieją dwie możliwości. Możemy - się wylogować i zalogować na użytkownika postgres ponownie lub wykonać skrypt, który przeładuje nam zmienne środowiskowe. Aby przeładować zmienne środowiskowe, - jako użytkownik postgres musimy wykonać:

. ~/.bash_profile

Po tej operacji nasza zmienna środowiskowa PATH powinna zostać uzupełniona o katalog z binarkami PostgreSQL:

PGDATA w wybranej lokalizacji + autostart usługi

Nie zawsze chcemy pozostawić domyślną konfigurację. Przyjmijmy, że planujemy mieć wszystkie pliki danych i konfiguracyjne PostgreSQL w innej lokalizacji, np. na innym dysku. Miejsce, w którym składowane są dane i configi, nazywamy w PostgreSQL PGDATA. Do tego usługa powinna startować automatycznie, korzystając z nowej lokalizacji plików. W tym celu musimy wykonać kilka czynności.

Jeśli planujemy zarządzanie instancjami PostgreSQL za pomocą klastra wysokiej dostępności Patroni, to nie konfigurujemy usługi serwera PostgreSQL (poniżej), ponieważ Patroni sam zajmie się uruchamianiem i wyłączaniem usług PostgreSQL.

Przede wszystkim trzeba zatrzymać aktualnie działającą usługę i wyłączyć jej automatyczne włączanie:

sudo systemctl stop postgresql@15-main.service
sudo systemctl disable postgresql@15-main.service

sudo systemctl stop postgresql.service
sudo systemctl disable postgresql.service

Sprawdzamy, czy usługa na pewno jest wyłączona:

systemctl status postgres*

Jeśli ta lista jest pusta, możemy przystąpić do kolejnej czynności, to jest do utworzenia katalogu na nową PGDATA w wybranym miejscu i spowodowanie, by jej właścicielem był użytkownik systemowy postgres (jest tworzony automatycznie przy instalacji PostgreSQL).

sudo mkdir -m 700 /data_pg
sudo chown postgres: /data_pg/

Teraz należy zainicjalizować klaster, tj. za pomocą postgresowego narzędzia initdb utworzyć niezbędne struktury i pliki. Następnie przechodzimy na użytkownika systemowego postgres i inicjalizujemy klaster:

sudo su - postgres
initdb -D /data_pg/

Jeśli otrzymamy komunikat : “command initdb not found”, - to znaczy, że nie dodaliśmy binarek PostgreSQL do zmiennej PATH lub nie przeładowaliśmy zmiennych środowiskowych użytkownika systemowego postgres. Możemy wrócić do tego punktu i go wykonać albo podawać ścieżkę bezwzględną do konkretnej binarki, np:
/usr/lib/postgresql/15/bin/initdb
Włączamy klaster, by sprawdzić, czy działa:

pg_ctl -D /data_pg/ start

Jeśli widzimy takie informacje również u siebie (chodzi o końcowe “server started”), to znaczy, że nowy klaster działa.

Zatrzymamy teraz klaster, ponieważ za chwilę skonfigurujemy go jako usługę i uruchomimy.

pg_ctl -D /data_pg/ stop

Zadbamy też o to, by usługa PostgreSQL automatycznie się uruchamiała. Inaczej musielibyśmy startować klaster za pomocą “pg_ctl” przy każdym restarcie maszyny.

Przechodzimy teraz do użytkownika systemowego z prawami do sudo i wykonujemy:

sudo nano /lib/systemd/system/postgresql-15.service

Powstanie nowy plik. Wklejamy do niego:

[Unit]
Description=PostgreSQL 15 database server
Documentation=https://www.postgresql.org/docs/15/static/
After=syslog.target
After=network-online.target

[Service]
Type=notify
User=postgres
Group=postgres
Environment=PGDATA=/data_pg/

#Wyłączenie OOM (Out Of Memory) killera dla postgresa:

OOMScoreAdjust=-1000
Environment=PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
Environment=PG_OOM_ADJUST_VALUE=0

ExecStart=/usr/lib/postgresql/15/bin/postmaster -D ${PGDATA}
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT

# wyłączony timeout, żeby postgres mógł w spokoju wykonać crash recovery podczas startu
# inaczej linux mógłby spróbować restartować usługę jeżeli nie wystartowała w X sekund
TimeoutSec=0
TimeoutStartSec=0
TimeoutStopSec=1h

[Install]
WantedBy=multi-user.target

Należy dostosować ten element pliku do swojej ścieżki do PGDATA (jeśli jest inna niż tworzona w tej instrukcji):

Environment=PGDATA=/data_pg/

Zapisujemy plik, włączamy autostart i uruchamiamy usługę:

#włączenie autostartu:

sudo systemctl enable postgresql-15.service

#uruchomienie usługi:

sudo systemctl start postgresql-15.service

Możemy ponownie sprawdzić status usługi:

systemctl status postgresql-15.service

Wykonujemy - restart serwera i sprawdzamy ponownie, czy usługa wstała:

sudo reboot
sudo systemctl status postgresql-15.service

Jeżeli konfigurujemy PostgreSQL jako usługę, to należy startować i zatrzymać klaster już z poziomu systemctl, a nie pg_ctl dlatego, że proces uruchomiony przez pg_ctl i usługa nie wiedzą o sobie wzajemnie.

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›Upgrade klastra PostgreSQL - pg_upgrade krok po kroku
• ›PostgreSQL - katalogi i pliki klastra
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Start/stop, w skrócie

Sterowanie klastrem:

pg_ctl start -D /sciezka/do/data
pg_ctl stop -m fast -D /sciezka/do/data

systemctl restart postgresql

Jak zarządzać stanem klastra? Zarówno za pomocą PG_CTL, jak i usługi systemowej.

Z tego artykułu dowiesz się:

• jak sprawdzać stan usługi PostgreSQL,- jak zatrzymywać, uruchamiać i restartować PostgreSQL za pomocą pg_ctl,- jak zatrzymywać, uruchamiać i restartować PostgreSQL za pomocą usługi,- jak ustawić zmienną środowiskową PGDATA, by nie musieć ciągle podawać położenia klastra,- jak przeładowywać konfigurację bez restartu klastra.

Uruchamiać, zatrzymywać, restartować i przeładowywać konfigurację usługi możemy na dwa sposoby. Albo wykorzystując pg_ctl, albo systemctl. W pierwszym przypadku jest to skrypt PostgreSQL. W drugim- zarządzamy usługą systemu operacyjnego.

Po wykonaniu wszystkich kroków z instrukcji instalacji PostgreSQL - mamy już działającą usługę. Możemy to zweryfikować, wywołując:

systemctl status postgresql-15.service

Uruchamianie, zatrzymywanie i restart za pomocą pg_ctl

Aby uruchamiać, zatrzymywać, restartować czy przeładowywać PostgreSQL za pomocą pg_ctl, przechodzimy najpierw do użytkownika systemowego postgres:

sudo su - postgres

Do startowania i zatrzymywania klastra służy skrypt pg_ctl. Jednak do czasu, aż nie ustawimy zmiennej środowiskowej PGDATA, będziemy musieli wskazać katalog instalacji klastra poprzez przełącznik -D. Startowanie klastra:

pg_ctl -D /data_pg start

Jeśli mamy dodane binaria PostgreSQL do zmiennej środowiskowej PATH użytkownika Postgres, wywołujemy bezpośrednio pg_ctl bez ścieżki do niej. Informacja na temat konfiguracji zmiennej PATH znajduje się w rozdziale o instalacji PostgreSQL. - Jeśli nie mamy dodanego katalogu binariów PostgreSQL do PATHa, możemy też uruchamiać pg_ctl (oraz inne skrypty), podając pełną ścieżkę. Dla Ubuntu:

/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg start

Dla CentOSa:

/usr/pgsql-15/bin/pg_ctl -D /data_pg start

Zatrzymywanie klastra to również wywołanie pg_ctl z przełącznikiem -D, ale z argumentem stop w miejscu start:

pg_ctl -D /data_pg stop

Aby zrestartować klaster, wystarczy dać argument restart:

pg_ctl -D /data_pg restart

Możemy też sprawić, że podawanie katalogu instalacji klastra nie będzie konieczne, konfigurując zmienną środowiskową PGDATA. Możemy to zrobić dla aktualnej sesji:

export PGDATA=/data_pg
pg_ctl stop
pg_ctl start
pg_ctl restart

Możliwe jest - też skonfigurowanie PGDATA dla wszystkich przyszłych sesji. Wystarczy dodać tę zmienną - środowiskową do ~/.bash_profile. Edytujemy plik:

nano ~/.bash_profile

Następnie dodajemy poniższe linijki do tego pliku:

PGDATA=/data_pg
export PGDATA

Po tej czynności wylogowujemy się z użytkownika Postgres i logujemy się ponownie lub uruchamiamy skrypt ~./bash_profile:

. ~/.bash_profile

Możemy teraz sprawdzić, czy zmienna poprawnie się dodała, wywołując:

Echo $PGDATA

Niezależnie od tego, czy ustawiliśmy PGDATA dla sesji czy dla użytkownika, możemy teraz wywoływać pg_ctl bez argumentu -D i wskazywania katalogu domowego PostgreSQL.

pg_ctl stop
pg_ctl start
pg_ctl restart

Pamiętajmy, że jeśli mamy zainstalowane w systemie kilka klastrów równolegle (będą musiały słuchać na innych portach), to pozostałe klastry (poza domyślnym, czyli ustawionym w zmiennej PGDATA) będzie trzeba uruchamiać i zatrzymywać z użyciem przełącznika -D.

Uruchamianie, zatrzymywanie i restart PostgreSQL za pomocą systemctl

Jeśli chcemy mieć klaster w innej lokalizacji niż domyślna „/var/lib/postgresql”, to nie zapomnijmy uaktualnić plik konfiguracyjny usługi “/lib/systemd/system/postgresql-15.service”. Konfiguracja tego pliku została opisana w rozdziale o instalacji PostgreSQL.

Poniższe czynności wykonujemy jako użytkownik systemowy z prawami do sudo!

Startowanie usługi:

sudo systemctl start postgresql-15

Zatrzymywanie usługi:

sudo systemctl stop postgresql-15

Restart usługi:

sudo systemctl restart postgresql-15

Wybierzmy jedną formę startowania i zatrzymywania klastra - - pg_ctl albo systemctl. Jeśli uruchomimy usługę z pg_ctl, to systemctl nic nie wie na temat uruchomienia usługi przez pg_ctl.

Sprawdzanie statusu usługi

Jeśli uruchomimy usługę z poziomu systemctl, to również za jego pomocą możemy sprawdzić stan tej usługi:

sudo systemctl status postgresql-15

Tę komendę możemy wydać również bez sudo jako użytkownik postgres.

Jeśli uruchomimy usługę za pomocą pg_ctl, to systemctl powie, że usługa nie działa, ponieważ nie wie o jej uruchomieniu.

Status usługi dla wskazanego PGDATA można sprawdzić też za pomocą pg_ctl status np. (wykonujemy jako użytkownik systemowy postgres):

Pg_ctl -D /data_pg status

Dostaniemy jasną informację:

Pozostaje jeszcze możliwość sprawdzenie otwartego portu za pomocą nmap. W takim przypadku nie ma znaczenia, czy uruchomimy usługę za pomocą pg_ctl czy systemctl. Jeżeli port jest otwarty, - zostanie to pokazane. Możemy też sprawdzić, czy w katalogu PGDATA (u nas /data_pg) istnieje plik “postmaster.pid”. Plik ten tworzony jest przy starcie klastra i usuwany przy jego zamykaniu. Jest to taki specjalny znacznik określający, czy instancja związana z tą PGDATA jest już uruchomiona.

Sprawdzenie otwartego portu nmapem:

nmap localhost

Sprawdzenie istnienia pliku pid w katalogu domowym PostgreSQL możemy wykonać, korzystając ze zmiennej środowiskowej PGDATA (o ile ją wcześniej skonfigurowaliśmy) lub podając ścieżkę bezwzględną. Poniższe instrukcje wykonujemy jako użytkownik systemowy postgres bądź inny użytkownik - ale mający uprawnienia do sudo (wtedy instrukcję poprzedzamy “sudo”), to jest kwestia uprawnień do tego katalogu. Wyszukujemy w katalogu wszystkie pliki mające w nazwie “postmaster”:

ls $PGDATA | grep postmaster
ls /data_pg | grep postmaster

Jeśli - taki plik istnieje, - ta instancja PostgreSQL jest uruchomiona.

Przeładowywanie konfiguracji

Niektóre parametry wymagają do zmiany restartu, inne tylko przeładowania konfiguracji. - Restart instancji wiąźe się z czyszczeniem wszystkich buforów, a tego z powodu utraty wydajności bazy chcemy uniknąć. W przypadku wpisów w pg_hba.conf (taki ACL - czyli Access Control List określający kto, na jakich zasadach i do czego ma dostęp) wystarczy przeładowanie konfiguracji w miejsce restartu. - W przypadku postgresql.conf (plik z konfiguracją najważniejszych parametrów klastra) jest to zależne od parametru. W postgresql.conf jeśli zmiana jakiegoś parametru wymaga restartu, zostało to przy nim napisane:

Konfigurację możemy przeładować na dwa sposoby: za pomocą pg_ctl i za pomocą psql. W przypadku pg_ctl wywołujemy:

pg_ctl reload

Jeśli nie mamy ustawionego PATHa i PGDATA, trzeba będzie stosownie podać ścieżkę do binarki oraz katalog domowy PostgreSQL który chcemy przeładować.

Dla Ubuntu:

/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg reload

Dla CentOSa:

/usr/pgsql-15/bin/pg_ctl -D /data_pg reload

Konfigurację możemy też przeładować za pomocą psql:

psql -c "select pg_reload_conf()"

Jeśli nie zaktualizowaliśmy zmiennej środowiskowej PATH, dodając do niej binarki PostgreSQL, to musimy podać pełną ścieżkę do psql. Dla Ubuntu:

/usr/lib/postgresql/15/bin/psql -c "select pg_reload_conf()"

Dla CentOSa:

/usr/pgsql-15/bin/psql -c "select pg_reload_conf()"

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›PG_CRON - czyli cykliczne uruchamianie zadań w PostgreSQL
• ›PostgreSQL - Najważniejsze pojęcia
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów

Jak skonfigurować szczegółowe logowanie błędów i zdarzeń w PostgreSQL? Jak wyłapywać wolno działające zapytania? Jak przeszukiwać logi SQLem?

Z tego artykułu dowiesz się:

• jak spowodować rejestrowanie logów do pliku,- jak konfigurować położenie logów,- jak konfigurować nazewnictwo plików logów,- jak konfigurować rotację plików logów,- jak konfigurować poziom logowania,- jak rejestrować w logach wolne zapytania (na potrzeby dalszej analizy i tuningu),- jak rejestrować w logach trwające zbyt długo operacje autovacuum,- jak rejestrować w logach zdarzenia checkpoint wraz z ich statystykami,- jak rejestrować w logach zdarzenia połączenia i rozłączenia sesji,- jak określać prefix linii logu w taki sposób, byśmy mieli komplet informacji o tym kto, z jakiego hosta, jaką aplikacją, kiedy, do której bazy się podłączył i wykonał daną zalogowaną czynność,- jak logować zdarzenia blokad zasobów (niekorzystne z perspektywy tuningu zdarzenie),- jak logować poszczególne typy operacji - tworzące, kasujące lub zmieniające np. tabele i indeksy, zmieniające dane lub wszystkie operacje,- jak logować zdarzenia tworzenia plików tymczasowych (niekorzystne z perspektywy tuningu zdarzenie),- jak generować logi do formatu CSV,- jak przeszukiwać logi za pomocą SQL.

Jeśli PostgreSQL - nie uruchamia się bądź pojawiają się jakieś błędy, pierwsze miejsce, które powinniśmy sprawdzić, to logi serwera PostgreSQL. Zajmiemy się więc teraz konfiguracją tego, gdzie i w jakim formacie logi te będą wyrzucane.

W tym celu musimy omówić kilka istotnych parametrów. Plik konfiguracyjny, w którym znajdziemy ustawienia parametrów, nazywa się "postgresql.conf" i mieści się w katalogu instalacji klastra PostgreSQL - tam, gdzie między innymi pliki danych. W naszym przypadku przyjmujemy, że katalog instalacji klastra (czyli PGDATA) to /data_pg.

Parametry logowania

Pierwszym parametrem który będziemy musieli przestawić będzie "logging_collector" którego włączenie spowoduje dodatkowe przekierowanie strumienia loga do pliku tekstowego w PGDATA. Zmiana parametru "logging_collector" będzie wymagała restartu klastra. Zmiana pozostałych- tylko przeładowania konfiguracji.

Aby sprawdzić aktualne ustawienie dowolnego parametru, należy - zalogować - się z poziomu użytkownika systemowego postgres do psql i zastosować komendę: "show nazwa_parametru":

psql
show logging_collector;

Jeśli nie mamy dodanych binarek PostgreSQL do PATHa i system zgłosi, że nie wie, co to "psql", należy użyć ścieżki bezwzględnej do psql:

/usr/lib/postgresql/15/bin/psql
show logging_collector;

Aby zmienić parametr "logging_collector", musimy zalogować się z poziomu użytkownika systemowego postgres do psql, wykonać komendę: "ALTER SYSTEM", wyjść z psql i zrestartować cały klaster. Można też modyfikować bezpośrednio plik postgresql.conf znajdujący się w PGDATA.

psql
alter system set logging_collector=true;
\q
pg_ctl restart

Jeśli nie mamy dodanych binarek PostgreSQL do PATHa i ustawionego katalogu dla PGDATA, możemy - użyć ścieżek bezwzględnych do wykorzystanych - binarek i wskazać katalog PGDATA za pomocą przełącznika -D:

/usr/lib/postgresql/15/bin/psql
alter system set logging_collector=true;
\q
/usr/lib/postgresql/15/bin/pg_ctl -D /data_pg restart

Zmiana dowolnego z pozostałych parametrów (opisanych tu, związanych z logowaniem) - wymaga tylko przeładowania konfiguracji. Logujemy się z poziomu użytkownika systemowego postgres do psql, wykonujemy komendę: "ALTER SYSTEM" i przeładowujemy konfigurację.

psql
alter system set log_directory='logi';
select pg_reload_conf();

Warto wiedzieć, że zmiana parametrów przez "ALTER SYSTEM" powoduje dodanie nowego wpisu do pliku postgresql.auto.conf. Plik ten jest czytany (razem z postgresql.conf i pg_hba.conf) przy przeładowaniu konfiguracji i starcie klastra. Ponieważ plik postgresql.auto.conf jest czytany po postgresql.conf, to ustawienia w postgresql.auto.conf nadpisują ustawienia postgresql.conf. Inaczej mówiąc, cokolwiek ustawimy przez "ALTER SYSTEM", - będzie to nadpisywało ustawienia tego samego parametru bezpośrednio w pliku postgresql.conf.

logging_collector

Jest to parametr typu boolean - przyjmuje wartości true/false/on/off/t/f/1/0. Włączenie tego parametru powoduje uruchomienie procesu tła, który odpowiada za przekierowanie logów( lecących domyślnie do stderr w Ubuntu ) do plików logów PostgreSQL. W przypadku włączenia tworzony jest katalog w położeniu i nazwie określonych w parametrze "log_directory" i w nim znajdą się pliki logów. Domyślnie parametr "log_directory" ustawiony jest na wartość "log", czyli - logi znajdują się w podkatalogu "log" - katalogu PGDATA. Zmiana "logging_collector" wymaga restartu klastra.

Domyślną wartością dla Ubuntu jest off. Domyślną wartością dla CentOS jest on. W przypadku Ubuntu logi lecą do /var/log/postgresql/. W przypadku CentOs logi domyślnie znajdą się w podkatalogu "log" umiejscowionym w PGDATA.

Na potrzeby testowania pozostałych ustawień opisanych w tym rozdziale należy ustawić - ten parametr na on.

log_directory

Parametr ten określa katalog, w którym będą powstawać pliki logów PostgreSQL. Domyślne ustawienie:

log_directory='log'

Jako wartość możemy podać zarówno ścieżkę bezwzględną jak i względną wobec PGDATA (katalog instalacji klastra). Domyślnie pliki logów będą powstawały w katalogu "log" w PGDATA. Jeśli zamierzamy ustawić ścieżkę bezwzględną, to należy pamiętać, by użytkownik systemowy "postgres" miał uprawnienia do pisania w tym katalogu.
Zmiana "log_directory" wymaga tylko przeładowania ustawień.

log_destination

PostgreSQL wspiera kilka metod logowania wiadomości serwera, między innymi stderr, csvlog, syslog. Domyślna wartość to "stderr". Jeśli chcemy, by logi były dodatkowo zapisywane w pliku csv (np. w celu późniejszego importu do bazy i analizy), musimy zmodyfikować ustawienie tego parametru na taką wartość:

log_destination='stderr,csvlog'

Zmiana "log_directory" wymaga tylko przeładowania ustawień.

log_filename

Parametr określa nazwę pliku loga. Domyślna jego wartość dla Ubuntu:

"postgresql-%Y-%m-%d_%H%M%S.log"

Nazwa loga będzie zawierała datę i czas powstania loga.
Domyślna wartość dla CentOS:

"postgresql-%a.log"

Nazwa loga będzie zawierała skróconą nazwę dnia tygodnia.

Kolejny plik będzie powstawał po upływie czasu określonego w parametrze "log_rotation_age", którego domyślną wartością jest 1 doba.
W nazwie pliku loga możemy stosować wszystkie znaczniki strftime. Listę dostępnych znajdziemy np. tutaj: https://strftime.org/

Zmiana "log_filename" wymaga tylko przeładowania ustawień.

log_rotation_age

Parametr określa maksymalny czas, po jakim tworzony jest nowy plik logu. Domyślną wartością dla tego parametru jest "1d", co oznacza - jeden dzień. Jeśli podajemy wartość bez jednostki, np. tak:

log_rotation_age=30,

będzie to oznaczało 30 minut, - bo taka jest przyjmowana domyślna jednostka. Jeśli chcemy mieć nowy plik loga tworzony co 30 dni a nie minut, to musimy dodać literkę "d":

log_rotation_age=30d

Wartość domyślna (jedna doba) jest dobra dla środowisk produkcyjnych. Dla testów wydajnościowych warto ustawić na 1 godzinę. Parametr ten możemy przestawić na zero, powodując wyłączenie nadpisywania logów:

log_rotation_age=0

Zmiana "log_filename" wymaga tylko przeładowania ustawień.

log_rotation_size

Parametr zbliżony do "log_rotation_age". Dotyczy jednak wielkości logów. Możemy za jego pomocą spowodować, że nowy log będzie tworzony po przekroczeniu przez loga określonej wielkości. Domyślnie parametr ten ustawiony jest na 10MB. Podając wartość liczbową większą od 0, podajemy wartość wyrażoną w kB. Możemy ją ustawić np. tak:

log_rotation_size=1024

lub podając jednostkę:

log_rotation_size='1MB'

co będzie oznaczało w obu przypadkach, że log zostanie nadpisany, gdy osiągnie wielkość 1MB.

Zmiana "log_rotation_size" wymaga tylko przeładowania ustawień.

log_min_messages

Określa poziom logowania, czyli co ma być rejestrowane w logu. Domyślnym ustawieniem jest "warning", ale możemy ten parametr przestawić - w ten sposób:

log_min_messages=info

Poniżej lista dostępnych trybów. Każdy poziom obejmuje również rejestrację z wszystkich wyższych poziomów:

Zmiana "log_min_messages" wymaga tylko przeładowania ustawień.

log_min_duration_statement

Parametr ten umożliwia rejestrowanie w logach informacji o wszystkich zapytaniach trwających dłużej niż czas określony w tym parametrze. Domyślną jednostką tego parametru są milisekundy. Możesz mu ustawić jakąś wartość by wyłapywać zapytania które warto poddać optymalizacji. Domyślna wartość tego parametru to -1, czyli logowanie takich zapytań jest wyłączone. Wartość 0 spowoduje rejestrowanie wszystkich zapytań, w tym zapytań do słowników systemowych, towarzyszących każdemu zapytaniu - więc nie warto tego robić, ponieważ log będzie szybko zapełniany zbędnymi wpisami. Warto ustawić na jakąś rozsądną wartość, np zapytania trwające powyżej 1000ms.
Możesz tę wartość ustawić podając w milisekundach np:

log_min_duration_statement=1000

Lub podając jednostkę:

log_min_duration_statement=1s

albo:

log_min_duration_statement=1min

Zmiana "log_min_duration_statement" wymaga tylko przeładowania ustawień.

log_autovacuum_min_duration

Parametr ten umożliwia rejestrowanie w logach informacji o operacjach autovacuum trwających dłużej niż czas określony w tym parametrze.Domyślna wartość tego parametru to -1, czyli logowanie operacji autovacuum jest wyłączone. Wartość 0 spowoduje rejestrowanie wszystkich operacji autovacuum.
Możesz tę wartość ustawić podając w milisekundach np:

log_autovacuum_min_duration=1000

Lub podając jednostkę:

log_autovacuum_min_duration=1s

albo:

log_autovacuum_min_duration=10min

Zmiana "log_autovacuum_min_duration" wymaga tylko przeładowania ustawień.

log_checkpoints

Parametr ten jest domyślnie włączony i powoduje rejestrowanie wszystkich zdarzeń checkpoint. Wraz z informacją o samym fakcie wystąpienia checkpointa otrzymamy też informacje o czasie jego trwania, a także ilości zapisanych w jego ramach danych. Możesz pozostawić go włączonego:

log_checkpoints=on

lub wyłączyć:

log_checkpoints=off

Zmiana "log_checkpoints" wymaga tylko przeładowania ustawień.

log_connections

Parametr ten umożliwia rejestrowanie w logu wszystkich zdarzeń nawiązania połączenia z klastrem. Rejestrowany jest również adres IP hosta z którego połączenie jest nawiązywane, użytkownik, baza danych i nazwa aplikacji. Domyślnie parametr ten jest wyłączony. Możesz go włączyć:

log_connections=on

lub wyłączyć:

log_connections=off

Zmiana "log_connections" wymaga restartu klastra.

log_disconections

Parametr ten umożliwia rejestrowanie zakończenie trwania połączenia do klastra. Rejestrowany jest adres IP hosta z którego było to połączenie, użytkownik, baza danych, nazwa aplikacji i czas trwania połączenia. Domyślnie parametr ten jest wyłączony. Możesz go włączyć:

log_disconnections=on

lub wyłączyć:

log_disconnections=off

Zmiana "log_disconnections" wymaga restartu klastra.

log_line_prefix

Pozwala skonfigurować prefiks każdej linii logu. Każda linia logu będzie miała format ustawiony przez ten parametr. Warto rozszerzyć sobie standardowe ustawienie o dodatkowe taki, ponieważ domyślnie logowany będzie tylko identyfikator procesu i timestamp (czyli domyślnie jest %m [%p]).Musimy pamiętać, że nie wszystkie tagi będą zawsze uzupełniane - np. w przypadku procesów wewnętrznych. Nierozpoznane tagi będą ignorowane. Dostępne tagi:

Przykładowe ustawienie poniżej, moim zdaniem w miarę wystarczające. Daje nam ono informację o nazwie aplikacji, nazwie hosta, bazy danych, której log dotyczy, użytkownika, który spowodował powstanie loga, id sesji, id procesu systemowego i timestampie zdarzenia:

log_line_prefix='%m [%p]:[%l] user=%u,db=%d,app=%a'

Zmiana "log_line_prefix" wymaga tylko przeładowania ustawień.

log_lock_waits i deadlock_timeout

Parametr log_lock_waits powoduje rejestrowanie w logu transakcji które blokują inne transakcje przez czas określony w parametrze deadlock_timeout. Parametr log_lock_waits jest domyślnie wyłączony. Możesz go włączyć:

log_lock_waits=on

lub wyłączyć:

log_lock_waits=off

Zmiana "log_lock_waits" i "deadlock_timeout" wymaga tylko przeładowania ustawień.

log_statement

Pozwala określić jakie operacje na danych i strukturach będą logowane. Możemy mu ustawić "none" (tak jest domyślnie) - czyli nic nie jest logowane (chyba że wpis do loga będzie wynikał z log_min_duration_statement, log_lock_waits lub log_temp_files). "ddl" - czyli wszystkie operacje tworzące, zmieniające czy kasujące struktury danych. "mod" - czyli operacje zmieniające dane ale nie struktury danych. "all" - wszystkie operacje. Możesz go ustawić w ten sposób:

log_statement='ddl'

Zmiana "log_statement" wymaga tylko przeładowania ustawień.

log_temp_files

Pozwala rejestrować w logach wszystkie zdarzenia które spowodowały tworzenie plików tymczasowych, takie jak sortowanie, hashowanie czy grupowanie. Pomaga nam znaleźć zapytania warte optymalizacji. Domyślną wartością tego parametru jest -1, czyli rejestracja jest wyłączona. Wartość 0 spowoduje zarejestrowanie wszystkich powstających plików tymczasowych. Wartość większa od 0 określa wielkość pliku tymczasowego wyrażonego w kilobajtach powyżej której fakt tworzenia pliku tymczasowego zostanie odnotowany. Możesz go ustawić np. w ten sposób:

log_temp_files=1024

Zmiana "log_temp_files" wymaga tylko przeładowania ustawień.

Log w formacie csv i ładowanie logu do tabeli (w celu późniejszej analizy SQLem)

Logi w formacie CSV

Domyślny format logu jest z reguły niewystarczający do analizy danych w nich zawartych jeżeli nie mamy dobrej znajomości linuksowych narzędzi do parsowania plików teksowych, takich jak grep czy awk. W domyślnej konfiguracji logi zrzucane są do pliku tekstowego, który nadaje się do podglądania pojawiających się komunikatów o błędach etc, ale nie pozwalają np. wyłapać wszystkich wpisów dotyczących długo trwających zapytań. Znalezienie wszystkich takich wpisów w zwykłym pliku tekstowym wymagałoby napisania jakiegoś parsera. Mamy jednak możliwość rejestrowania logów do pliku CSV, który następnie możemy załadować do tabeli. Dzięki temu będziemy mogli przeszukiwać logi za pomocą SQL!

Przede wszystkim musimy spowodować, żeby logi zaczęły być rejestrowane do pliku CSV. W tym celu modyfikujemy parametr "log_destination". Możemy zmienić go w pliku "postgresql.conf" lub za pomocą "alter system...". Trzeba tylko pamiętać o przeładowaniu konfiguracji za pomocą pg_reload_conf(). Jego wartość powinna wyglądać tak:

log_destination='stderr,csvlog'

Osiągamy to - na przykład tak:

psql
alter system set log_destination='stderr,csvlog';
select pg_reload_conf();

Dodajemy frazę "csvlog", domyślnie jest tylko "stderr", by nie nadpisać stderr, a dodać frazę csvlog.

Po tej operacji w naszym katalogu z logami powinien znaleźć się dodatkowy plik z rozszerzeniem "csv":

Wpisy w tym pliku będą - miały stały format prefiksu loga. Ustawienie "log_line_prefix" nie ma na niego wpływu. Wynika to z tego, że załadujemy ten log do tabeli, która ma z góry zdefiniowany format i dane muszą do tego formatu pasować.

Ładowanie logów CSV do tabeli i ich analiza

Poniżej komenda tworząca tabelę, do której będziemy ładować dane.Należy pamiętać, że między wersjami struktura tej tabeli będzie różna - i - dane mogą nie pasować do tabeli. Poniższy przykład dotyczy wersji 15. Jeśli korzystamy z innej wersji, trzeba odnaleźć właściwą strukturę w dokumentacji.

Zalogujemy się do psql z poziomu użytkownika systemowego postgres i stworzymy tę tabelę:

CREATE TABLE postgres_log
(
 - log_time timestamp(3) with time zone,
 - user_name text,
 - database_name text,
 - process_id integer,
 - connection_from text,
 - session_id text,
 - session_line_num bigint,
 - command_tag text,
 - session_start_time timestamp with time zone,
 - virtual_transaction_id text,
 - transaction_id bigint,
 - error_severity text,
 - sql_state_code text,
 - message text,
 - detail text,
 - hint text,
 - internal_query text,
 - internal_query_pos integer,
 - context text,
 - query text,
 - query_pos integer,
 - location text,
 - application_name text,
 - backend_type text,
 - leader_pid integer,
 - query_id bigint,
 - PRIMARY KEY (session_id, session_line_num)
);

Do załadowania tej tabeli posłużymy się poleceniem "copy". Wskazujemy tabelę docelową oraz plik, który ma zostać załadowany. Z poziomu psql wywołujemy (oczywiście zmieniając nazwę pliku loga):

copy postgres_log from '/data_pg/log/postgresql-2023-08-16_000000.csv' with csv;

Po tej czynności w bazie "postgres", w schemacie public, w tabeli postgres_log znajdą się nasze logi. Sprawdzamy je:

\x
select * from postgres_log limit 1;

Lub zmieniamy ustawienia pagera, wyłączając zawijanie wierszy i dodając ich numerację
\setenv PAGER 'less -S -N'

Możemy teraz użyć SQLa do przeszukiwania logów pod kątem interesujących nas informacji.

Logowanie nawiązywanych połączeń

PostgreSQL umożliwia rejestrowanie nowo nawiązywanych sesji. Aby rejestrować nowe połączenia, będziemy musieli włączyć parametr "log_connections", a następnie zrestartować klaster (pg_reload_conf() nie przeładowuje tego parametru). W pierwszej kolejności z poziomu użytkownika systemowego postgres zmiana parametru za pomocą psql:

psql
alter system set log_connections=on;

Po tej operacji cofamy się do poziomu użytkownika z prawami do sudo, restartujemy usługę i sprawdzamy jej status:

sudo systemctl restart postgresql-15
sudo systemctl status postgresql-15

Wracamy do użytkownika systemowego postgres i sprawdzamy ustawienie parametru "log_connections":

psql
show log_connections;

Po wykonaniu tej operacji parokrotnie zalogowałem się i wylogowałem z serwera, zarówno lokalnie jak i po sieci (wymagało to dodatkowych nieopisanych tutaj czynności - dostępem po sieci zajmiemy się nieco później). Następnie podłączyłem się do PostgreSQL (w tym przypadku za pomocą programu DBeaver) i wyświetliłem logi związane z połączeniami za pomocą zapytania:

select log_time,user_name,database_name,connection_from ,message - from postgres_log pl where message like '%connection%';

Mój wynik:

Szkolenie Administracja, replikacja i tuning baz danych PostgreSQL →

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Powiązane artykuły

• ›Kurs administracji PostgreSQL - wybór preworka
• ›PostgreSQL - Konfiguracja Patroni z ETCD na Ubuntu
• ›PostgreSQL - Konfiguracja pgBackRest dla klastra Patroni
• ›Kurs administracji PostgreSQL
• ›PG_PREWARM - prosty i szybki tuning w PostgreSQL
• ›PostgreSQL - PG_REPACK : przenoszenie, przebudowa i klastrowanie tabel i indeksów