2022-04-29
Ta metoda zadziała, jeśli np. chcesz systematycznie sprawdzać dostępność wybranej usługi w różnych regionach. Można też wykorzystywać API do tworzenia obiektów, ale akurat w tym przypadku, powiedziałbym że są inne wygodniejsze metody.
- Trzeba mieć utworzone konto, dobrym wyborem jest service principal. Powinno wystarczyć polecenie w postaci
|
|
<span class="hljs-keyword">az ad sp create-for-rbac </span><span class="hljs-parameter">--scopes</span> /subscriptions/mySubscriptionID |
W zwróconym wyniku można odnaleźć: clientId, clientSecret, Będą one potrzebne w kolejnych krokach. Proces tworzenia service principal jest opisany dokładniej tutaj: Create an Azure service principal – Azure CLI | Microsoft Docs
- Trzeba uzyskać tzw. Authorization Bareer. Można to zrobić dowolnym narzędziem do pracy z web service. Tu korzystam z curl, ale postman jest też ok. Zamaksowany identyfikator w adresie url, to tenantId:
|
|
curl -d 'grant_type=client_credentials&client_id=6*****6&client_secret=y******6& resource=https://management.azure.com' https://login.microsoftonline.com/6*****a/oauth2/token |
- Ta czynność odpowiada logowaniu do Azure. W odpowiedzi zostanie zwrócony dluuugi klucz, który należy wykorzystywać w kolejnych zapytaniach API wysylanych do Azure:
|
|
curl -X GET -H "Authorization: Bearer e*****A" https://management.azure.com/subscriptions/8*****9//providers/Microsoft.DBForPostgreSql?api-version=2020-06-01 > availability.json |
Tym razem w URL pojawia się już adres wskazujący na usługę, o której chcemy się dowiedzieć pownych rzeczy. Tutaj tą usługą jest baza danych PostgreSQL
Z dużym prawdopodobieństwem pobrany plik JSON nie będzie miał ładnego formatu, ale można nad tym popracować:
|
|
cat availability.json | python3 -m json.tool > availability-format.json |
A jesli np. chesz dowiedzieć się w którym regionie, jakie availability grupy są dostępne to możesz to zrobić tak:
|
|
import json f = open('availability-format.json', 'r') data = json.load(f) l1 = data['resourceTypes'] fs = [i for i in l1 if i["resourceType"] == "flexibleServers"] f0 = fs[0] zm = f0['zoneMappings'] loczone = [ [m['location'], m['zones']] for m in zm] for i in loczone: print(f'{i[0]} : {i[1]}') |
Linki:
Azure REST API reference documentation | Microsoft Docs
Operations – List – REST API (Azure PostgreSQL) | Microsoft Docs
Need Rest API to get the availability zones information on the basis of Object selected in a particular region · Issue #3594 · Azure/azure-rest-api-specs (github.com)
Test a REST API with curl | Baeldung
Access Azure API with a bearer token for impersonation – Sander van de Velde (wordpress.com)
Calling Azure REST API via curl. A straightforward post to invoke Azure… | by Davide Mauri | Medium
Check Name Availability – Execute – REST API (Azure PostgreSQL) | Microsoft Docs
2022-03-25
W Linuxach jest ciekawie i różnorodnie… dzięki temu się nie nudzimy. Jeśli chcesz doinstalowywać do swojej instlacji Pythona dodatkowe pakiety, to miło byłoby mieć pip (podobno jego nazwę należy rekurencyjnie rozwinąć do pip installs python)
Co jeśli pip nie jest zainstalowany? Zakładam, że mamy na systemie Pythona 3. W takim przypadku zaczynamy od instalacji pakietu python3-pip:
|
|
sudo apt update sudo apt install python3-pip |
Od tej pory pip powinien już być dostępny i lepiej jest korzystać z polecenia pip3, co wyraźnie wskazuje, że chodzi o 3-cią wersję Pythona i stowarzyszonych narzędzi:
Teraz, jeśli chcesz zainstalować bibliotekę scrapy, wystarczy, że użyjesz:
a aby wylistować dostępne i zainstalowane pakiety
Jeśli jakiś pakiet chcesz zaktualizować użyj:
|
|
pip3 install --upgrade nazwa_pakietu |
A jak zabawki Ci się znudzą i chcesz je odinstalować to z pomocą przyjdzie:
|
|
pip3 uninstall nazwa_pakietu |
2022-03-25
A czemu by nie? Czemu by nie zadbać o potwierdzony i ciągle wymuszany stan firewalla na swoich serwerach?
Nim jednak włączymy ufw, upewnijmy się, że firewall będzie akceptował połączenia na port 22 SSH. W tym przypadku zezwalamy tez na połączenie na port 80. Dopiero ostatni krok, to rzeczywiste włączenie firewalla:
|
|
- name: Add role for OpenSSH community.general.ufw: rule: allow port: 22 proto: tcp - name: Create firewall exception for WWW community.general.ufw: rule: allow port: 80 proto: tcp #delete: yes - name: Activate UFW community.general.ufw: state: enabled |
Jeśli z kolei chcielibyśmy regułę dotyczącą http wykluczyć (ale jej jawnie nie zabraniać, bo do zabronienia należałoby skorzystać z reject), to wystarczy odkomentować linijkę delete:yes
2022-03-25
Definiując w playbooku instalację pakietu przez ansible można to zrobić na RedHat, Centos, Fedora o tak:
|
|
tasks: - name: install nginx yum: name: vsftpd state: present |
no ale, jeśli masz Ubuntu, to należałoby użyć apt:
|
|
tasks: - name: install vsftpd apt: name: nginx state: present |
Co kraj to obyczaj, co edycja to inna instalacja… ale można również skorzystać z modułu packages – jedna uniwersalna metoda:
|
|
tasks: - name: Install nginx package: name: nginx state: present |
2022-03-25
nginx na dobre wyparł już ze świata Linuxa starego poczciwego httpd/Apache (zdanie z przymróżeniem oka). Oto krótki przewodnik instalacji nginx na Ubuntu
Zaczynamy od instalacji samego pakietu:
|
|
sudo apt update sudo apt install nginx |
Podczas instalacji pakietu dzieje się jedna fajna rzecz. Nginx dodaje reguły aplikacyjne do firewalla ufw. Można je wylistować korzystając z:
Są trzy domyślne zestawy: HTTP, HTTPS i Full (zawierający zarówno http jak i https). Można je włączyć uruchamiając np:
|
|
sudo ufw allow 'Nginx Full' |
Jeśli chcesz zachować kontrolę nad zmianami w firewall możesz też otwierać zamykać porty samodzielnie korzystając z nazw protokołów lub nawet numerów portów:
|
|
sudo ufw allow https sudo ufw allow 443 |
Status firewalla można sprawdzić poleceniem
a spodziewany wynik to np coś w tym stylu:
|
|
Status: active To Action From -- ------ ---- 443/tcp ALLOW Anywhere 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere Nginx Full ALLOW Anywhere 443/tcp (v6) ALLOW Anywhere (v6) 22/tcp (v6) ALLOW Anywhere (v6) 80/tcp (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6) |
Gdyby status ufw był inactive, to włączenie firewalla wykonasz przez
Jednak przed włączeniem ufw, warto sprawdzić, czy np. zezwalamy na połączenia na porcie 22 (ssh). Niestety nie ma komendy, która by pozwoliła to zzrobić za prośrednictem ufw. Można za to wszystkie reguły podejrzeć w pliku:
|
|
sudo cat /etc/ufw/user.rules |
Wróćmy do konfiguracji nginx. Warto by było, żeby usługa startowała automatycznie po uruchomieniu systemu:
|
|
systemctl enable nginx systemctl start nginx systemctl status nginx |
Domyślna konfiguracja nginx znajduje się w /etc/nginx/nginx.conf. Domyślnie serwer nasłuchuje tylko na porcie 80 i root wskazuje na pliki w katalogu /var/www/html
Konfigurację można (i należy) docelowo zmienić tak, aby mogła obsługiwać multi-site.
Całkiem ładny opis instalacji ingx jest też tu
https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04
Manual do ufw tutaj:
https://ubuntu.com/server/docs/security-firewall
i tu:
How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server | DigitalOcean
2022-03-16
Jest wiele sytuacji, w których w bazie danych trzeba zapisać unikalne informacje, oznaczone unikalnym identyfikatorem. Tak jest zresztą nie tylko w bazach danych. Idziesz do urzędu, a na wejściu musisz pobrać numerek, dzięki czemu od razu jesteś zakolejkowany 🙂
Obiektem, który w bazie danych generuje kolejne wartości jest tzw. SEQUENCE. Bardzo podstawowa definicja sequence może wyglądać tak:
|
|
CREATE SEQUENCE ticket_id INCREMENT 1 START 101; |
Ilekroć będziesz odwoływać się do ticket_id, z wykorzystaniem funkcji nextvalue, będziesz otrzymywać kolejne numerki począwszy od 101. Sqeunce ma mnóstwo parametrów dotyczących tego, jak ma wyglądać generowanie kolejnych wartości i znajdziesz je w helpie.
Załóżmy, że została utworzona taka oto tabela:
|
|
create table tickets(id integer, title text); |
Typowe wykorzystanie sequence wygląda tak:
|
|
insert into tickets(id, title) values(nextval('ticket_id'),'issue1'), (nextval('ticket_id'),'issue2'); |
W efekcie, w tabeli znajdują się teraz następujące rekordy:
|
|
select * from tickets; id | title -----+-------- 101 | issue1 102 | issue2 |
Pięknie… ale…. dla danego sequence nie wiadomo, gdzie on jest wykorzystywany. Można by było oczywiście dochodzić do tego po nazwie. Skoro ktoś nazwał sequence ticket_id, to może jest jakaś tabela z ticket-ami?
Tabele można też zdefiniować tak:
|
|
CREATE TABLE color ( color_id INT GENERATED BY DEFAULT AS IDENTITY (START WITH 10 INCREMENT BY 10), color_name VARCHAR NOT NULL ); |
Zasada pracy tej tabeli jest podobna, jak w przpadku sequence, a gdyby słowo DEFAULT zamienić na ALWAYS, to wartości dla color_id nie tylko, że nie trzeba by podawać – nie można jej podać, bo będzie ona generowana przez PostgreSQL samodzielnie.
|
|
insert into color (color_name) values ('pink'), ('green'), ('yellow'); INSERT 0 3 select * from color; color_id | color_name ----------+------------ 10 | pink 20 | green 30 | yellow |
Jest jednak pewna różnica. Jeśli zajrzymy do widoku information_schema.sequences, to znajdziemy tam tylko informacje o pierwszym sequence (tym stworzonym jawnie i osobno). Jeśli jednak zajrzymy do tabeli systemowej pg_sequences, to będą tam już obie!
No ale skoro utworzenie sequence nastąpiło automatycznie podczas tworzenia tabeli – to nie ma siły. Gdzieś musiał zostać ślad po tym, z jakim sequence jest powiązana kolumna color_id. Rzeczywiście:
|
|
select pg_get_serial_sequence('public.color', 'color_id'); |
W efekcie dostaniemy:
|
|
pg_get_serial_sequence --------------------------- public.color_color_id_seq |
A jak zidentyfikować, te ręcznie tworzone sequence? Niestety – chyba odkryliśmy regułę, jak nie należy korzystać z sequence. Jeśli sequence jest obiektem „na boku” i nie podlega przypisaniu do tabeli, jest to tylko maszyna wydająca numerki, stojąca gdzieś w portierni naszej bazy danych, to po prostu nie jest przypisana do żadnej tabeli/kolumny w tabeli. Logikę generowania wartości id w tabeli tickets, zna w tym przypadku tylko programista aplikacji.
Co ciekawe, jeśli tabela została utworzona poleceniem:
|
|
CREATE TABLE Towns ( id SERIAL UNIQUE NOT NULL, code VARCHAR(10) NOT NULL, -- not unique article TEXT, name TEXT NOT NULL, -- not unique department VARCHAR(4) NOT NULL, UNIQUE (code, department) ); |
to poniższe zapytanie również wykryje relację między kolumną id, a automatycznie utworzonym sequence:
|
|
SELECT d.refobjid::regclass, a.attname FROM pg_sequences s JOIN pg_depend d ON d.objid = CONCAT(s.schemaname,'.', s.sequencename)::regclass JOIN pg_attribute a ON a.attrelid = d.refobjid AND a.attnum = d.refobjsubid; |
A tak BTW, skąd PostgreSQL wie, jak się ze sobą te obiekty wiążą? Jest jeszcze jedna tabela systemowa o nazwie pg_sequence, gdzie dla każdego sequence można odnaleźć jego identyfikator. Dzięki temu, działa następujące zapytanie, które – przyjmijmy – odpowiada na pytanie – gdzie jest używany obiekt sequence:
|
|
SELECT seqclass.relname AS sequence_name, seqclass.relfilenode AS sequenceref, dep.refobjid AS depobjref, depclass.relname AS table_name FROM pg_class AS seqclass JOIN pg_sequence AS seq ON seq.seqrelid = seqclass.relfilenode JOIN pg_depend AS dep ON seq.seqrelid = dep.objid JOIN pg_class AS depclass ON dep.refobjid = depclass.relfilenode; |
[ Referece: https://sadique.io/blog/2019/05/07/viewing-sequence-ownership-information-in-postgres/ ]
2022-03-16
Jeden z ostatnich kroków migracji danych, to sprawdzenie, czy migracja „niczego nie zgubiła”. Potencjalnie można się np. spodziewać, że tuż po zakończeniu migracji, jakiś zbłąkany użytkownik dopisał swoje rekordy do źródłowej bazy danych, a my tego rekordu nie przenieśliśmy. Jeden z „topornych” sposobów sprawdzenia, czy żaden rekord nie zostanie utracony, jest po prostu policzenie rekordów w źródłowej i docelowej bazie danych.
Najpierw wypadałoby ustalić, jakie mamy schematy w bazie. Robimy to głównie po to, żeby wykluczyć z raportu schematy systemowe, względnie inne, które mają być z jakiegoś powodu ominięte. psql pozwala na uruchomienie skróconego polecenia \dn, ale ta właśnie pomija schematy systemowe. Dlatego proponuję:
SELECT schema_name FROM information_schema.schemata;
Oto możliwy wynik:
|
|
schema_name -------------------- public information_schema pg_catalog pg_toast_temp_1 pg_temp_1 pg_toast |
Znając schematy bazy danych, pora na sztuczkę. Poniższe zapytanie automatycznie zbierze ze wszystkich tabel z wybranych schematów liczbę rekordów. Ponieważ zapytanie jest uruchamiane na faktycznych danych (a nie np. ze statystyk), jego wykonanie może zająć chwilę czasu. Zapytanie jest sprytne, bo korzysta z możliwości wykonania XML w tym zapytaniu. Poniekąd więc dla każdego rekordu zwracanego z tabel systemowych uruchomi się jeszcze jedno zapytanie XML, zliczające liczbę rekordów:
|
|
select table_schema, table_name, (xpath('/row/cnt/text()', xml_count))[1]::text::int as row_count from ( select table_name, table_schema, query_to_xml(format('select count(*) as cnt from %I.%I', table_schema, table_name), false, true, '') as xml_count from information_schema.tables where table_schema NOT LIKE 'pg_%' and table_schema != 'information_schema' ) t |
U mnie zwrcony wynik wygląda mniej więcej tak:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
table_schema | table_name | row_count --------------+--------------------+----------- public | pg_stat_statements | 0 public | towns4 | 1000000 public | pg_buffercache | 262144 public | towns5 | 1000000 public | towns | 1000000 public | towns2 | 1000000 public | towns3 | 1000000 public | towns6 | 1000000 public | towns7 | 1000000 public | towns8 | 1000000 public | towns9 | 1000000 public | towns0 | 1000000 public | large_test | 20000000 public | a_table | 1013 (14 rows) |
Powyższe zapytanie można by uruchomić na obu bazach danych i po prostu porównać uzyskane wyniki – czy to excelu, czy pythonie, czy palcem na ekranie – obojętnie.
Istnieją też inne propozycje rozwiązania tego problemu, ale niekoniecznie zliczające rekordy co do jednego, np. zapytanie:
|
|
SELECT relname, n_tup_ins - n_tup_del as rowcount FROM pg_stat_all_tables WHERE schemaname NOT LIKE 'pg_%' and schemaname != 'information_schema'; |
zwraca:
|
|
relname | rowcount ------------+---------- towns | 1044898 towns5 | 1000000 towns6 | 1000000 a_table | 1016 towns4 | 1000000 large_test | 20000000 towns7 | 1000000 towns2 | 1000000 towns0 | 1000000 towns9 | 1000000 towns8 | 1000000 towns3 | 1000000 (12 rows) |
ale już dla tabeli a_table, widać różnice… Jeśli więc, chcesz mieć dokładne wyniki, to musisz liczyć wszystko. Z pomocą powyższych zapytań będzie to i tak rozwiązanie automatyczne, tylko może z punktu widzenia PostgreSQL, jakby trochę na piechotę.
