Kopš 8. jūlija PostgreSQL izstrādātāji var pievienot pgvector, PostGIS vai pg_cron savam Docker attēlam ar vienu rindu Dockerfile failā, neko nekompilējot. Projekts pglayers publicē 53 PostgreSQL paplašinājumus kā atsevišķus Docker slāņus, ko uzliek virsū oficiālajam postgres attēlam.
Ideja ir vienkārša. Katrs paplašinājums ir uzbūvēts kā minimāls attēls no tukša pamata (FROM scratch) — tajā ir tikai koplietojamās bibliotēkas, control faili, SQL skripti un pareizie ceļi failu sistēmā. Šie attēli paši par sevi nedarbojas kā konteineri; tie ir tikai failu slāņi. Docker tos iekopē oficiālajā postgres attēlā ceļos, kur PostgreSQL tos pats atrod, un tālāk viss notiek kā ierasts.
Kā to lieto
Dockerfile sākas ar oficiālo bāzi un pēc tam pievieno vēlamos paplašinājumus. Trīs rindas dod pgvector, PostGIS un pg_cron:
FROM postgres:17COPY --from=ghcr.io/pglayers/pgx-pgvector:17 / /COPY --from=ghcr.io/pglayers/pgx-postgis:17 / /COPY --from=ghcr.io/pglayers/pgx-pg_cron:17 / /
Pēc būvēšanas atliek izpildīt CREATE EXTENSION. Nav apt-get, nav gcc vai make gala attēlā, nav gaidīšanas, kamēr kompilējas C kods. Docker izvelk gatavos slāņus no reģistra un uzliek tos dažās sekundēs. Kam vajag uzreiz visu, ir gatavs attēls ghcr.io/pglayers/pglayers-full:17, ko palaiž ar vienu docker run.
Kas ir iekšā
Saraksts aptver 53 paplašinājumus vairākās kategorijās. AI iegultņiem ir pgvector un pgvectorscale. Ģeodatiem — PostGIS, pgRouting un h3-pg. Laikrindām — TimescaleDB. Analītikai — pg_duckdb un pg_lake, kas dod piekļuvi Iceberg formāta datiem. DocumentDB pievieno MongoDB vadu protokolu, tā ka lietotne, kas gaida MongoDB, var runāt ar PostgreSQL. Novērošanai ir pgaudit, pg_stat_monitor un pg_wait_sampling; darbu plānošanai pg_cron; replikācijai pglogical un wal2json.
Pilntekstu meklēšanai saraksts iekļauj pg_bigm un rum, tabulu uzturēšanai pg_repack, kas pārbūvē tabulu bez ilgstoša slēdža, un lielo tabulu sadalīšanai pg_partman. Vaicājumu profilēšanai ir plprofiler un pg_qualstats. Visi attēli būvēti gan linux/amd64, gan linux/arm64, tāpēc Docker uz Apple Silicon vai ARM serveriem izvelk pareizo arhitektūru pats. Katrs paplašinājums glabājas savā tegā, piesaistīts konkrētai PostgreSQL versijai, tā ka pgx-pgvector:17 un pgx-pgvector:18 ir divi atsevišķi slāņi.
Attēli nav palaižami konteineri. Tie ir failu slāņi, ko Docker pārklāj virsū postgres attēlam tieši tur, kur dzinējs tos meklē.
PostgreSQL 18 atrisina veco problēmu
Kad vairākus paplašinājumus liek vienā attēlā ar veco metodi, to faili mēdz cīnīties par tiem pašiem ceļiem. pglayers uz PostgreSQL 18 to apiet ar izolētu izkārtojumu: katrs paplašinājums nonāk mapē /extensions/<nosaukums>/, un dzinējs tos atrod caur extension_control_path un dynamic_library_path iestatījumiem. Tā vairs nav failu sadursmju, un blakus var pastāvēt vairākas vienas bibliotēkas versijas. PostgreSQL 17 un 18 slāņi ir stabili, 19 versija ir eksperimentāla, kamēr tā vēl nav sasniegusi galīgo laidienu.
Kur jāuzmanās
pglayers ņem tikai brīvās licences — PostgreSQL, MIT, BSD, Apache 2.0 un ISC. GPL-2.0 paplašinājumi PostGIS un pgRouting ir iekšā caur dinamisko ielādi, bet GPL-3.0, AGPL-3.0 un slēgtā koda paplašinājumi paliek ārpusē. Autors Ismaels Mehija paziņojumā PostgreSQL ziņu lapā norāda arī uz robežām, par ko der zināt pirms darba: pg_lake un pg_duckdb konfliktē, tāpēc abus vienā attēlā likt nedrīkst, un piegādātāju profili (piemēram, azure) ir tikai tuvinājums lokālai izstrādei, nevis produkcijas kopija.
Ir arī jautājums, kas skar jebkuru gatavu bināro slāņu avotu. Kad paplašinājumu neievelk pats no pirmkoda, bet uzņem kā gatavu attēlu no reģistra, uzticēšanās pārceļas uz to, kas šos slāņus būvēja. Hacker News pavedienā tieši šis punkts izraisīja diskusiju — ērtība pret piegādes ķēdes pārbaudāmību. pglayers slāņi ir publiski ghcr.io reģistrā, tā ka saturu var apskatīt, taču ikvienam, kas velk svešus binārus produkcijā, joprojām jāpieņem lēmums, cik tālu tos pārbaudīt.
Kāpēc tas noder
Paplašinājumu kompilēšana Docker attēlā ir sena sāpe: attēls uzblīst ar būvēšanas rīkiem, būve ilgst minūtes, un rezultāts atkarīgs no tā, kāda gcc versija tobrīd bija bāzē. pglayers pieeja ceļu maina uz vienu rindu manifestā, un gala attēlā nepaliek neviens kompilators. Tā kā katrs slānis ir atsevišķs Docker attēls, tos ķeš Docker slāņu kešā — vienu un to pašu pgvector slāni izvelk vienreiz un lieto atkārtoti dažādos attēlos, nevis pārbūvē katrā projektā no jauna. Tas arī padara būves atkārtojamas: viens un tas pats tegs dod vienu un to pašu binārā saturu.
Projekts dokumentācijā to pozicionē kā veidu, kā salikt tieši tos paplašinājumus, kas vajadzīgi, bez lieka svara. Kas grib pārbaudīt pirms iesaistīšanas, var palaist gatavo pglayers-full attēlu lokāli un skatīties, kā CREATE EXTENSION pgvector nostrādā bez viena būvēšanas rīka konteinerā. Pirmajā nedēļā pēc publiskošanas saraksts jau sasniedza 53 paplašinājumus, un jaunu var pieprasīt caur GitHub.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.