Kubernetes üçün PostgreSQL Bəyanatlarına Qısa Baxış, Seçimlərimiz və Təcrübəmiz

Getdikcə müştərilər aşağıdakı sorğuları alırlar: “Biz bunu Amazon RDS kimi istəyirik, lakin daha ucuzdur”; "Biz bunu RDS kimi istəyirik, lakin hər yerdə, istənilən infrastrukturda." Kubernetes-də belə idarə olunan həlli tətbiq etmək üçün PostgreSQL üçün ən populyar operatorların (Stolon, Crunchy Data və Zalando operatorları) hazırkı vəziyyətinə baxdıq və seçimimizi etdik.

Bu məqalə həm nəzəri baxımdan (həlllərin nəzərdən keçirilməsi), həm də praktiki baxımdan (nəyin seçildiyi və nəyin nəticəsi) əldə etdiyimiz təcrübədir. Ancaq əvvəlcə RDS üçün potensial bir əvəz üçün ümumi tələblərin nə olduğunu müəyyən edək...

RDS nədir

İnsanlar RDS haqqında danışarkən, bizim təcrübəmizə görə, onlar idarə olunan DBMS xidməti nəzərdə tuturlar:

1. konfiqurasiya etmək asandır;
2. snapshotlarla işləmək və onlardan bərpa etmək qabiliyyətinə malikdir (üstünlük dəstəyi ilə PITR);
3. master-slave topologiyalarını yaratmağa imkan verir;
4. zəngin uzantılar siyahısına malikdir;
5. audit və istifadəçi/girişin idarə edilməsini təmin edir.

Ümumiyyətlə, tapşırığı yerinə yetirmək üçün yanaşmalar çox fərqli ola bilər, lakin şərti Ansible ilə yol bizə yaxın deyil. (2GIS-dən olan həmkarlar nəticədə oxşar nəticəyə gəldilər onun cəhdi "Postgres-əsaslı əvəzetmə klasterini tez yerləşdirmək üçün alət" yaradın.)

Operatorlar Kubernetes ekosistemində oxşar problemlərin həlli üçün ümumi yanaşmadır. “Flanta”nın texniki direktoru artıq Kubernetes daxilində işə salınan verilənlər bazası ilə bağlı onlar haqqında daha ətraflı danışıb. distol, in onun hesabatlarından biridir.

NB: Tez sadə operatorlar yaratmaq üçün Açıq Mənbə yardım proqramımıza diqqət yetirməyi tövsiyə edirik mərmi operatoru. Bundan istifadə edərək, bunu Go haqqında məlumat olmadan edə bilərsiniz, lakin sistem administratorlarına daha tanış olan üsullarla: Bash, Python və s.

PostgreSQL üçün bir neçə məşhur K8s operatorları var:

• Stolon;
• Crunchy Data PostgreSQL Operatoru;
• Zalando Postgres operatoru.

Gəlin onlara daha yaxından baxaq.

Operator seçimi

Yuxarıda qeyd olunan vacib xüsusiyyətlərə əlavə olaraq, biz - Kubernetes infrastruktur əməliyyatları mühəndisləri olaraq operatorlardan aşağıdakıları da gözləyirdik:

• Git və ilə yerləşdirmə Xüsusi Resurslar;
• pod anti-yaxınlıq dəstəyi;
• node yaxınlığının və ya node seçicisinin quraşdırılması;
• tolerantlıqların quraşdırılması;
• tuning imkanlarının mövcudluğu;
• başa düşülən texnologiyalar və hətta əmrlər.

Hər bir bəndin təfərrüatlarına varmadan (bütün məqaləni oxuduqdan sonra hələ də suallarınız varsa şərhlərdə soruşun), ümumiyyətlə qeyd edəcəm ki, bu parametrlər çoxluq qovşaqlarının ixtisasını daha dəqiq təsvir etmək üçün lazımdır. onları xüsusi tətbiqlər üçün sifariş edin. Bu yolla biz performans və xərc baxımından optimal tarazlığa nail ola bilərik.

İndi keçək PostgreSQL operatorlarının özlərinə.

1. Stolon

Stolon İtaliyanın Sorint.lab şirkətindən artıq qeyd olunan hesabat DBMS üçün operatorlar arasında bir növ standart hesab olunurdu. Bu kifayət qədər köhnə layihədir: onun ilk ictimai buraxılışı 2015-ci ilin noyabrında baş verdi (!) və GitHub repozitoriyası demək olar ki, 3000 ulduz və 40-dan çox iştirakçıya malikdir.

Həqiqətən, Stolon düşünülmüş memarlığın əla nümunəsidir:

Bu operatorun cihazı hesabatda və ya ətraflı şəkildə tapıla bilər layihə sənədləri. Ümumiyyətlə, onun təsvir edilən hər şeyi edə biləcəyini söyləmək kifayətdir: uğursuzluq, şəffaf müştəri girişi üçün proksilər, ehtiyat nüsxələr... Bundan başqa, proksilər bir son nöqtə xidməti vasitəsilə çıxışı təmin edir – aşağıda müzakirə olunan digər iki həlldən fərqli olaraq (onların hər biri üçün iki xidmət var). bazaya daxil olmaq).

Bununla belə, Stolon Xüsusi Resurslar yoxdur, buna görə də onu elə yerləşdirmək olmaz ki, Kubernetes-də DBMS nümunələri yaratmaq asan və tez olsun – “qaynar tortlar kimi”. İdarəetmə kommunal vasitəsilə həyata keçirilir stolonctl, yerləşdirmə Helm diaqramı vasitəsilə həyata keçirilir və xüsusi olanlar ConfigMap-də müəyyən edilir və müəyyən edilir.

Bir tərəfdən məlum olur ki, operator əslində operator deyil (axı CRD-dən istifadə etmir). Ancaq digər tərəfdən, K8-lərdə resursları istədiyiniz kimi konfiqurasiya etməyə imkan verən çevik bir sistemdir.

Ümumiləşdirsək, şəxsən bizim üçün hər bir verilənlər bazası üçün ayrıca diaqram yaratmaq optimal görünmürdü. Ona görə də alternativlər axtarmağa başladıq.

2. Xırtıldayan Data PostgreSQL Operatoru

Crunchy Data-dan operator, gənc Amerika startapı məntiqli alternativ kimi görünürdü. Onun ictimai tarixi 2017-ci ilin martında ilk buraxılışı ilə başlayır, o vaxtdan bəri GitHub repozitoriyası 1300-dən az ulduz və 50-dən çox iştirakçı alıb. Sentyabr ayının son buraxılışı Kubernetes 1.15-1.18, OpenShift 3.11+ və 4.4+, GKE və VMware Enterprise PKS 1.3+ ilə işləmək üçün sınaqdan keçirilib.

Crunchy Data PostgreSQL Operatorunun arxitekturası da qeyd olunan tələblərə cavab verir:

İdarəetmə kommunal vasitəsilə baş verir pgo, lakin o, öz növbəsində Kubernetes üçün Xüsusi Resurslar yaradır. Buna görə operator bizi potensial istifadəçilər kimi sevindirdi:

• CRD vasitəsilə nəzarət var;
• rahat istifadəçi idarəetməsi (həmçinin CRD vasitəsilə);
• digər komponentlərlə inteqrasiya Crunchy Data Container Suite — PostgreSQL üçün konteyner şəkillərinin xüsusi kolleksiyası və onunla işləmək üçün kommunal proqramlar (o cümlədən pgBackRest, pgAudit, töhfədən genişlənmələr və s.).

Bununla birlikdə, Crunchy Data operatorundan istifadə etməyə başlamaq cəhdləri bir neçə problemi ortaya qoydu:

• Dözümlülük imkanı yox idi - yalnız nodeSelector təmin edilir.
• Vəziyyəti təsdiq edən tətbiq yerləşdirməyimizə baxmayaraq, yaradılmış podlar Yerləşdirmənin bir hissəsi idi. StatefulSets-dən fərqli olaraq, Deployments disklər yarada bilməz.

Son çatışmazlıq gülməli anlara səbəb olur: sınaq mühitində bir disklə 3 replika işlətməyi bacardıq. yerli saxlama, operatorun 3 replikanın işlədiyini bildirməsinə səbəb olur (hətta olmasa da).

Bu operatorun başqa bir xüsusiyyəti onun müxtəlif köməkçi sistemlərlə hazır inteqrasiyasıdır. Məsələn, pgAdmin və pgBounce quraşdırmaq asandır sənədləşdirmə əvvəlcədən konfiqurasiya edilmiş Grafana və Prometey hesab olunur. Son zamanlar buraxılış 4.5.0-beta1 Layihə ilə təkmilləşdirilmiş inteqrasiya ayrıca qeyd olunur pgMonitor, bunun sayəsində operator qutudan kənarda PgSQL ölçülərinin aydın vizuallaşdırılmasını təklif edir.

Bununla birlikdə, Kubernetes tərəfindən yaradılan resursların qəribə seçimi bizi fərqli bir həll tapmağa məcbur etdi.

3. Zalando Postgres Operatoru

Biz Zalando məhsullarını çoxdan tanıyırıq: Zaleniumdan istifadə təcrübəmiz var və təbii ki, cəhd etdik Patroni onların PostgreSQL üçün məşhur HA həllidir. Şirkətin yaradılmasına yanaşması haqqında Postgres operatoru onun müəlliflərindən biri Aleksey Klyukin efirdə deyib Postgres-Çərşənbə axşamı # 5, və bunu bəyəndik.

Bu, məqalədə müzakirə olunan ən gənc həlldir: ilk buraxılış 2018-ci ilin avqustunda baş verdi. Bununla belə, rəsmi buraxılışların sayının az olmasına baxmayaraq, layihə GitHub-da 1300+ ulduz və maksimum töhfə verənlərin sayı (70+) olan Crunchy Data həllini populyarlıq baxımından artıq keçərək uzun bir yol keçib.

"Başlıq altında" bu operator zamanla sınaqdan keçirilmiş həllərdən istifadə edir:

• Patroni və Spilo Sürücülük üçün,
• WAL-E - ehtiyat nüsxələri üçün,
• PgBouncer - əlaqə hovuzu kimi.

Zalando-dan operator arxitekturası belə təqdim olunur:

Operator tamamilə Xüsusi Resurslar vasitəsilə idarə olunur, avtomatik olaraq konteynerlərdən StatefulSet yaradır, sonra onu poda müxtəlif yan arabalar əlavə etməklə fərdiləşdirmək olar. Bütün bunlar Crunchy Data operatoru ilə müqayisədə əhəmiyyətli üstünlükdür.

Baxılan 3 variant arasından Zalando-dan həlli seçdiyimiz üçün onun imkanlarının əlavə təsviri dərhal tətbiq təcrübəsi ilə birlikdə aşağıda təqdim olunacaq.

Zalandodan Postgres Operatoru ilə məşq edin

Operatorun yerləşdirilməsi çox sadədir: sadəcə olaraq GitHub-dan cari buraxılışı endirin və kataloqdan YAML fayllarını tətbiq edin. təzahür edir. Alternativ olaraq siz də istifadə edə bilərsiniz operatorhub.

Quraşdırıldıqdan sonra quraşdırma barədə narahat olmalısınız qeydlər və ehtiyat nüsxələri üçün saxlama. Bu ConfigMap vasitəsilə edilir postgres-operator operatoru quraşdırdığınız ad sahəsində. Repozitoriyalar konfiqurasiya edildikdən sonra siz ilk PostgreSQL klasterinizi yerləşdirə bilərsiniz.

Məsələn, standart yerləşdirməmiz belə görünür:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

Bu manifest formada yan arabası olan 3 nümunədən ibarət klaster yerləşdirir postgres_exporter, ondan tətbiq ölçülərini götürürük. Gördüyünüz kimi, hər şey çox sadədir və istəsəniz, sözün həqiqi mənasında qeyri-məhdud sayda klaster yarada bilərsiniz.

Buna diqqət yetirməyə dəyər veb idarəetmə paneli - postgres-operator-ui. O, operatorla birlikdə gəlir və klasterlər yaratmağa və silməyə, həmçinin operator tərəfindən hazırlanmış ehtiyat nüsxələrlə işləməyə imkan verir.

PostgreSQL klasterlərinin siyahısı

Yedək idarəetmə

Digər maraqlı xüsusiyyət dəstəkdir Komandalar API. Bu mexanizm avtomatik olaraq yaradır PostgreSQL-də rollar, istifadəçi adlarının nəticə siyahısına əsasən. API sonra avtomatik olaraq rolların yaradıldığı istifadəçilərin siyahısını qaytarmağa imkan verir.

Problemlər və həll yolları

Bununla belə, operatorun istifadəsi tezliklə bir sıra əhəmiyyətli çatışmazlıqları aşkar etdi:

1. nodeSelector dəstəyinin olmaması;
2. ehtiyat nüsxələrini söndürmək mümkün deyil;
3. verilənlər bazası yaratmaq funksiyasından istifadə edərkən standart imtiyazlar görünmür;
4. Bəzən sənədlər yoxdur və ya köhnəlmiş olur.

Xoşbəxtlikdən, onların bir çoxunu həll etmək olar. Sondan başlayaq - problemlər sənədlər.

Çox güman ki, ehtiyat nüsxəni necə qeydiyyatdan keçirməyin və ehtiyat kovasını Operator UI-yə necə qoşmağın həmişə aydın olmadığı faktı ilə qarşılaşacaqsınız. Sənədlər keçərək bu barədə danışır, lakin əsl təsviri var PR:

1. sirr açmaq lazımdır;
2. parametr kimi operatora ötürür pod_environment_secret_name operator parametrləri ilə CRD-də və ya ConfigMap-da (operatoru necə quraşdırmaq qərarına gəldiyinizdən asılı olaraq).

Ancaq göründüyü kimi, bu, hazırda mümkün deyil. Ona görə yığdıq operatorunuzun versiyası bəzi əlavə üçüncü tərəf inkişafları ilə. Bu barədə daha ətraflı məlumat üçün aşağıya baxın.

Əgər ehtiyat nüsxə üçün parametrləri operatora ötürsəniz, yəni - wal_s3_bucket və AWS S3-də giriş düymələri, sonra o hər şeyi ehtiyat nüsxə edəcək: təkcə istehsalda əsaslar deyil, həm də səhnələşdirmə. Bu bizə yaraşmadı.

Operatordan istifadə edərkən PgSQL üçün əsas Docker sarğısı olan Spilo üçün parametrlərin təsvirində məlum oldu: bir parametr ötürə bilərsiniz. WAL_S3_BUCKET boş, bununla da ehtiyat nüsxələrini söndürür. Üstəlik, böyük sevinc tapdım hazır PR, biz dərhal çəngəlimizə qəbul etdik. İndi sadəcə əlavə etmək lazımdır enableWALArchiving: false PostgreSQL klaster resursuna.

Bəli, 2 operatoru işlətməklə bunu fərqli etmək imkanı var idi: biri səhnələşdirmə üçün (ehtiyatsız), ikincisi isə istehsal üçün. Amma biz biri ilə barışa bildik.

Yaxşı, biz S3 üçün verilənlər bazasına girişi necə ötürməyi öyrəndik və ehtiyat nüsxələri yaddaşa daxil olmağa başladı. Operator UI-də ehtiyat nüsxə səhifələrini necə işlətmək olar?

Operator UI-yə 3 dəyişən əlavə etməlisiniz:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Bundan sonra, ehtiyat nüsxələrin idarə edilməsi əlçatan olacaq ki, bu da bizim vəziyyətimizdə səhnələşdirmə ilə işi asanlaşdıracaq və əlavə skriptlər olmadan istehsaldan dilimləri çatdırmağa imkan verəcəkdir.

Digər üstünlük Teams API ilə iş və operator alətlərindən istifadə edərək verilənlər bazası və rollar yaratmaq üçün geniş imkanlar idi. Bununla belə yaradılmışdır rolların standart olaraq heç bir hüquqları yox idi. Müvafiq olaraq, oxumaq hüququ olan istifadəçi yeni cədvəlləri oxuya bilmədi.

Niyə belədir? Kodeksdə olmasına baxmayaraq yoxdur zəruri GRANT, onlar həmişə istifadə edilmir. 2 üsul var: syncPreparedDatabases и syncDatabases. Ilə syncPreparedDatabases - bölmədə olmasına baxmayaraq preparedDatabases yoxdur şərti var defaultRoles и defaultUsers rollar yaratmaq üçün defolt hüquqlar tətbiq edilmir. Bu hüquqların avtomatik tətbiq edilməsi üçün yamaq hazırlayırıq.

Bizə aid olan təkmilləşdirmələrdə son nöqtə - yamaq, yaradılmış StatefulSet-ə Node Affinity əlavə edir. Müştərilərimiz tez-tez spot nümunələrdən istifadə edərək xərcləri azaltmağa üstünlük verirlər və onlar açıq şəkildə verilənlər bazası xidmətlərinə ev sahibliyi etməyə dəyməzlər. Bu problem tolerantlıq yolu ilə həll edilə bilər, lakin Node Affinity-nin olması daha çox güvən verir.

Nə oldu?

Yuxarıdakı problemlərin həllinin nəticələrinə əsasən, biz Postgres Operatorunu Zalando-dan daxil etdik anbarınız, bu cür faydalı yamaqlarla toplandığı yer. Və daha çox rahatlıq üçün biz də topladıq Docker şəkli.

Qəbul edilən PR-ların siyahısı:

• Docker-də operator üçün təhlükəsiz yüngül görüntü yaratmaq;
• ehtiyat nüsxələrini söndürmək;
• k8-lərin cari versiyaları üçün resurs versiyalarının yenilənməsi;
• Node Affinity tətbiqi.

İcma bu PR-ları dəstəkləsə, çox yaxşı olar ki, onlar operatorun növbəti versiyası (1.6) ilə yuxarıya doğru getsinlər.

Bonus! İstehsal miqrasiyası uğur hekayəsi

Əgər Patroni istifadə etsəniz, canlı istehsal minimum fasilələrlə operatora köçürülə bilər.

Spilo ilə S3 yaddaşı vasitəsilə gözləmə qrupları yaratmağa imkan verir Wal-E, PgSQL ikili jurnalı əvvəlcə S3-də saxlandıqda və sonra replika ilə çıxarıldıqda. Ancaq varsa nə etməli heç bir Wal-E tərəfindən köhnə infrastrukturda istifadə olunur? Bu problemin həlli artıqdır təklif olundu mərkəzdə.

PostgreSQL məntiqi replikasiyası xilasetmə işinə gəlir. Bununla belə, nəşrlərin və abunələrin necə yaradılacağına dair təfərrüata girməyəcəyik, çünki... planımız fiasko idi.

Fakt budur ki, verilənlər bazasında milyonlarla cərgədən ibarət bir neçə yüklənmiş cədvəl var idi, üstəlik, onlar daim doldurulur və silinirdi. Sadə abunə с copy_data, yeni replika ustadan bütün məzmunu kopyalayanda o, sadəcə olaraq master ilə ayaqlaşa bilmir. Məzmunun surətini çıxarmaq bir həftə işlədi, amma usta ilə heç vaxt məşğul olmadı. Sonda bu, problemi həll etməyə kömək etdi məqalə Avito həmkarları: istifadə edərək məlumat ötürə bilərsiniz pg_dump. Mən bu alqoritmin bizim (bir qədər dəyişdirilmiş) versiyasını təsvir edəcəyəm.

İdeya ondan ibarətdir ki, siz müəyyən bir təkrarlama yuvasına bağlanmış əlil abunəlik edə bilərsiniz və sonra əməliyyat nömrəsini düzəldə bilərsiniz. İstehsal işləri üçün nüsxələri var idi. Bu vacibdir, çünki replika ardıcıl zibil yaratmağa kömək edəcək və ustadan dəyişikliklər almağa davam edəcək.

Miqrasiya prosesini təsvir edən sonrakı əmrlər aşağıdakı host qeydlərindən istifadə edəcək:

1. ustad — mənbə serveri;
2. replika 1 — köhnə istehsal üzrə axın surəti;
3. replika 2 - yeni məntiqi replika.

Miqrasiya planı

1. Sxemdəki bütün cədvəllər üçün master-da abunə yaradın public baza dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. Masterdə replikasiya yuvası yaradın:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. Köhnə replikada replikasiyanı dayandırın:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. Magistrdən əməliyyat nömrəsini alın:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. Köhnə replikadan zibil çıxarın. Bunu bir neçə mövzuda edəcəyik, bu da prosesi sürətləndirməyə kömək edəcək:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. Dumpı yeni serverə yükləyin:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. Dumpı endirdikdən sonra siz axın replikasında təkrarlamağa başlaya bilərsiniz:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. Gəlin yeni məntiqi replikada abunə yaradaq:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. Gəlin əldə edək oid abunəliklər:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. Tutaq ki, alındı oid=1000. Tranzaksiya nömrəsini abunəyə tətbiq edək:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. Replikasiyaya başlayaq:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. Abunəlik statusunu yoxlayın, replikasiya işləməlidir:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. Replikasiya başlandıqdan və verilənlər bazası sinxronlaşdırıldıqdan sonra siz keçid edə bilərsiniz.

13. Replikasiyanı söndürdükdən sonra ardıcıllığı düzəltmək lazımdır. Bu yaxşı təsvir edilmişdir wiki.postgresql.org saytındakı məqalədə.

Bu plan sayəsində keçid minimum gecikmələrlə baş verdi.

Nəticə

Kubernetes operatorları müxtəlif hərəkətləri K8s resurslarının yaradılmasına qədər azaldaraq sadələşdirməyə imkan verir. Bununla birlikdə, onların köməyi ilə diqqətəlayiq avtomatlaşdırma əldə etdikdən sonra, onun bir sıra gözlənilməz nüanslar da gətirə biləcəyini xatırlamaq lazımdır, ona görə də operatorlarınızı ağıllı seçin.

PostgreSQL üçün üç ən məşhur Kubernetes operatorunu nəzərdən keçirərək layihəni Zalando-dan seçdik. Və biz bununla müəyyən çətinlikləri dəf etməli olduq, lakin nəticə həqiqətən sevindirici oldu, ona görə də bu təcrübəni bəzi digər PgSQL qurğularına genişləndirməyi planlaşdırırıq. Bənzər həllərdən istifadə təcrübəniz varsa, şərhlərdə təfərrüatları görməkdən şad olarıq!

PS

Bloqumuzda da oxuyun:

• «Verilənlər bazaları və Kubernetes (baxış və video hesabat)";
• «Postgres Çərşənbə axşamı №5: PostgreSQL və Kubernetes. CI/CD. Test avtomatlaşdırılması";
• «K8-lərdə Redis operatoru ilə bir hekayə və bu verilənlər bazasından məlumatların təhlili üçün kommunal proqramların mini icmalı.

Mənbə: www.habr.com