[FIX] spelling mistakes fixed

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # **DevOps Journey**-ga contributorlik qilish
 
-Loyihamizga hissa qo'shganingiz uchun tashakkur! Muammolar haqida xabar berish, xatolarni tuzatish yoki yangi funksiyalarni taklif qilish bo‘ladimi, biz barchaning hissalarini mamnuniyat bilan qabul qilamiz. To'g'ri hamkorlik qilish uchun quyidagi ko'rsatmalarni ko'rib chiqing.
+Loyihamizga hissa qo'shganingiz uchun tashakkur! Muammolar haqida xabar berish, xatolarni tuzatish yoki yangi funksiyalarni taklif qilish bo'ladimi, biz barchaning hissalarini mamnuniyat bilan qabul qilamiz. To'g'ri hamkorlik qilish uchun quyidagi ko'rsatmalarni ko'rib chiqing.
 
 
 ## Contirbutorlik qilish usullari

pages/guides/cloud/azure-network-sozlash.en-UZ.mdx

@@ -14,7 +14,7 @@ Azure-dagi virtual tarmoqlar foydalanuvchilarga clouddagi resurslarini logical r
 
 Virtual tarmoq ichida subnetlar resurslarni yanada tartibga soladi va trafik oqimini nazorat qiladi. **VNet**-ni bir nechta subnetlarga bo'lish orqali foydalanuvchilar o'zlarining talablaridan kelib chiqqan holda turli xil resurslar to'plamlariga maxsus IP-manzil diapazonlarini belgilashlari mumkin. Ushbu segmentatsiya tarmoq boshqaruvini yaxshilaydi va har bir kichik tarmoqqa moslashtirilgan tarmoq siyosatini amalga oshirish imkonini beradi.
 
-Internal(ichki) IP-manzillar yordamida virtual tarmoq ichidagi resurslarni ulash bir qancha afzalliklarni beradi. Birinchidan, u Azure'ning yuqori tezlikdagi, low-latencyli tarmoq infratuzilmasidan foydalanish orqali resurslar o‘rtasidagi aloqani soddalashtiradi. Ikkinchidan, bu ma'lumotlarni uzatish bilan bog'liq xarajatlarni kamaytiradi, chunki bir xil VNet ichidagi resurslar o'rtasidagi trafik odatda bepul yoki VNet chegarasidan chiqadigan trafik bilan solishtirganda pastroq narxda olinadi. Nihoyat, internal IP-lardan foydalanish tarmoq miqyosini oshiradi, chunki resurslar ichki tarmoq konfiguratsiyasini o'zgartirmasdan qo'shilishi yoki olib tashlanishi mumkin.
+Internal(ichki) IP-manzillar yordamida virtual tarmoq ichidagi resurslarni ulash bir qancha afzalliklarni beradi. Birinchidan, u Azure'ning yuqori tezlikdagi, low-latencyli tarmoq infratuzilmasidan foydalanish orqali resurslar o'rtasidagi aloqani soddalashtiradi. Ikkinchidan, bu ma'lumotlarni uzatish bilan bog'liq xarajatlarni kamaytiradi, chunki bir xil VNet ichidagi resurslar o'rtasidagi trafik odatda bepul yoki VNet chegarasidan chiqadigan trafik bilan solishtirganda pastroq narxda olinadi. Nihoyat, internal IP-lardan foydalanish tarmoq miqyosini oshiradi, chunki resurslar ichki tarmoq konfiguratsiyasini o'zgartirmasdan qo'shilishi yoki olib tashlanishi mumkin.
 
 Qisqa qilib aytganda Tashkilotning har bir loyihasi uchun alohida virtual network yaratish serverlarni internal IP bilan bo'glash eng yaxshi izolatsiya amaliyotlaridan biridir va bu network arxitekturani manage(boshqarish) oson.
 

pages/guides/database/start-mongodb.en-UZ.mdx

@@ -124,9 +124,9 @@ Xulosa qilib aytadigan bo'lsak, MongoDB ma'lumotlar bazasida bir qator collectio
 
 #### Key-Value Pairlar
 
-Har bir MongoDB documenti filedlar ro'yxatidan iborat. Bu key-value pairlariga teng. Fied sintaktik jihatdan yaroqli bo‘lishi uchun `:` belgisi bilan ajratilgan key va valueni o‘z ichiga olishi kerak. MongoDB-da barcha ma'lumotlar fieldlarda saqlanishi kerak, shuning uchun key-value pairlari birgalikda ma'lumotlar bazasining butun tarkibini ifodalaydi.
+Har bir MongoDB documenti filedlar ro'yxatidan iborat. Bu key-value pairlariga teng. Fied sintaktik jihatdan yaroqli bo'lishi uchun `:` belgisi bilan ajratilgan key va valueni o'z ichiga olishi kerak. MongoDB-da barcha ma'lumotlar fieldlarda saqlanishi kerak, shuning uchun key-value pairlari birgalikda ma'lumotlar bazasining butun tarkibini ifodalaydi.
 
-Keylarning nomlari documentlar va filedlar soni ham farq qilishi mumkin. Tur muvofiqligi(type consistency) tatbiq etilmaydi. Shu sababli, bitta collectiondagi ikkita document tubdan farq qilishi mumkin. Field sxemasi oldindan belgilanishi shart emas. Foydalanuvchilar istalgan vaqtda collectionning qolgan qismidan qat'i nazar, yangi fieldlarni qo‘shishlari yoki mavjudlarini o‘chirishlari va o‘zgartirishlari mumkin. SQL-ga asoslangan ma'lumotlar bazasidagi table columi ancha cheklangan. Relation  ma'lumotlar bazasida columnlar tablening barcha rowlari bo'ylab mos keladi. Bundan tashqari, columnning mazmuni har bir rowda bir xil turga ega bo'lishi kerak.
+Keylarning nomlari documentlar va filedlar soni ham farq qilishi mumkin. Tur muvofiqligi(type consistency) tatbiq etilmaydi. Shu sababli, bitta collectiondagi ikkita document tubdan farq qilishi mumkin. Field sxemasi oldindan belgilanishi shart emas. Foydalanuvchilar istalgan vaqtda collectionning qolgan qismidan qat'i nazar, yangi fieldlarni qo'shishlari yoki mavjudlarini o'chirishlari va o'zgartirishlari mumkin. SQL-ga asoslangan ma'lumotlar bazasidagi table columi ancha cheklangan. Relation  ma'lumotlar bazasida columnlar tablening barcha rowlari bo'ylab mos keladi. Bundan tashqari, columnning mazmuni har bir rowda bir xil turga ega bo'lishi kerak.
 
 Key-valuelar BSON formatida yozilgan. Tajribali foydalanuvchilar BSON ma'lumotlarini qisman dekodlashi mumkin, ammo ular odatda to'liq tushunarli bo'lishi uchun JSONga dekodlanishi kerak. Har bir document juda ko'p sonli filedlarni o'z ichiga olishi mumkin.
 

pages/guides/k8s/k8s-architecture.en-UZ.mdx

@@ -388,7 +388,7 @@ Buni yaxshiroq tushunish uchun ikkita asosiy tushunchani ko'rib chiqaylik:
 
 **Open Container Initiative (OCI)** Bu container formatlari va runtimelari uchun standartlar to'plami
 
-Kubernetes Container Runtime Interface (CRI) bilan mos keladigan bir nechta container runtimelarini (CRI-O, Docker Engine, containerd va boshqalar) qo‘llab-quvvatlaydi. Bu shuni anglatadiki, ushbu containerning barcha runtimelari CRI interfeysini amalga oshiradi va gRPC CRI API-larini (runtime va image servicening endpointlari) namoyish etadi.
+Kubernetes Container Runtime Interface (CRI) bilan mos keladigan bir nechta container runtimelarini (CRI-O, Docker Engine, containerd va boshqalar) qo'llab-quvvatlaydi. Bu shuni anglatadiki, ushbu containerning barcha runtimelari CRI interfeysini amalga oshiradi va gRPC CRI API-larini (runtime va image servicening endpointlari) namoyish etadi.
 
 Kubernetes tizimni container runtimedan ajratish uchun turli runtimelarini ulash imkonini beruvchi Container Runtime Interface (CRI) ni taqdim etdi. CRI ikkita asosiy gRPC servicelarini belgilaydi:
 

pages/guides/k8s/k8s-cert-manager.en-UZ.mdx

@@ -84,7 +84,7 @@ spec:
         ingress:
           class: nginx
 ```
-Ushbu konfiguratsiya **Let's Encrypt**  cert-meneger yordamida TLS sertifikatining avtomatlashtirilgan chiqarilishi va yangilanishini sozlash uchun zarurdir. **ClusterIssuer** cluster miqyosidagi resource bo‘lib, u bir nechta namescpasega taalluqlidir va sertifikat boshqaruvchini clusterdagi Ingress resourcelari bilan bog'langan domenlar uchun **TLS** sertifikatlarini olish va yangilash uchun **Let's Encrypt**'ning **ACME** serveri bilan o'zaro ishlashni sozlaydi.
+Ushbu konfiguratsiya **Let's Encrypt**  cert-meneger yordamida TLS sertifikatining avtomatlashtirilgan chiqarilishi va yangilanishini sozlash uchun zarurdir. **ClusterIssuer** cluster miqyosidagi resource bo'lib, u bir nechta namescpasega taalluqlidir va sertifikat boshqaruvchini clusterdagi Ingress resourcelari bilan bog'langan domenlar uchun **TLS** sertifikatlarini olish va yangilash uchun **Let's Encrypt**'ning **ACME** serveri bilan o'zaro ishlashni sozlaydi.
 
 **email** qismiga ishlaydigan o'zimizni emailimizni yozib ishga tushiramiz.
 

pages/guides/k8s/k8s-kirish.en-UZ.mdx

@@ -6,7 +6,7 @@ import { Callout } from "nextra-theme-docs";
 
 Kubernetes konteynerlashtirilgan workloadlari va servicelarni boshqarish uchun portativ, kengaytiriladigan, open source platforma bo'lib, deklarativ konfiguratsiya va avtomatlashtirishni osonlashtiradi. U katta, tez rivojlanayotgan ekotizimga ega. Kubernetes servicelari, supporti va tollari keng tarqalgan.
 
-Kubernetes nomi yunon tilidan kelib chiqqan bo'lib, boshqaruvchi(helmsman) yoki uchuvchi(pilot) degan ma'noni anglatadi. K8s qisqartma sifatida `K` va `s` o'rtasidagi sakkizta harfni hisoblash natijasida paydo bo'ladi. Google Kubernetes loyihasini 2014-yilda ochiq manbalar asosida yaratdi. Kubernetes Googlening 15 yildan ortiq ishlab chiqarish workloadlarini boshqarish tajribasini hamjamiyatning eng ilg‘or g‘oyalari va amaliyotlari bilan birlashtiradi.
+Kubernetes nomi yunon tilidan kelib chiqqan bo'lib, boshqaruvchi(helmsman) yoki uchuvchi(pilot) degan ma'noni anglatadi. K8s qisqartma sifatida `K` va `s` o'rtasidagi sakkizta harfni hisoblash natijasida paydo bo'ladi. Google Kubernetes loyihasini 2014-yilda ochiq manbalar asosida yaratdi. Kubernetes Googlening 15 yildan ortiq ishlab chiqarish workloadlarini boshqarish tajribasini hamjamiyatning eng ilg'or g'oyalari va amaliyotlari bilan birlashtiradi.
 
 ## Ortga qaytish
 

pages/guides/k8s/k8s-objects.en-UZ.mdx

@@ -105,7 +105,7 @@ Podlar applicationning ish muhitini qamrab oladi: dasturiy ta'minot(software), r
 
 Kubernetesda Service - bu podlarning logical setini(to'plamini) va ularga kirish(access) policyni belgilaydigan abstraction. Ushbu abstraction iste'molchilarning(consumer) Podlar va Podlarni o'zlari qanday ko'rishlari o'rtasida ajratish imkonini beradi. Podlar doimiy bo'lmagan(non-permanent) resurslar bo'lsa, bu kashf qilish va doimiy mavjudlik(continuous availability) uchun muammo tug'diradi. Servicelar buni Podlarga o'zining barqaror(stable) IP manzilini va Serviceni tanlash mezonlariga(selector criteria) mos keladigan joriy ishlayotgan Podlar to'plamiga load-balancing qiluvchi trafikni berish orqali hal qiladi.
 
-Servicelar Kubernetes obyektlarini guruhlash va tanlashning standart usuli bo‘lgan teglar(label) va selectorlardan foydalangan holda Podlar to‘plamiga mos keladi. Misol uchun, Service `app=backend` labeli bilan barcha podlarni boshqarish mumkin. Pod ushbu labelga ega bo'lsa va selectorga mos kelsa, trafik unga Service orqali yo'naltirilishi mumkin.
+Servicelar Kubernetes obyektlarini guruhlash va tanlashning standart usuli bo'lgan teglar(label) va selectorlardan foydalangan holda Podlar to'plamiga mos keladi. Misol uchun, Service `app=backend` labeli bilan barcha podlarni boshqarish mumkin. Pod ushbu labelga ega bo'lsa va selectorga mos kelsa, trafik unga Service orqali yo'naltirilishi mumkin.
 
 ![k8s](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/k8s/objects/7.jpg)
 
@@ -253,7 +253,7 @@ Kengroq Kubernetes ekotizimida siz qo'shimcha xatti-harakatlarni ta'minlaydigan
 
 ### Labellar va Selectorlar
 
-Kubernetes-da labellar va selectorlar clusteringizdagi obyektlarning kichik to'plamlarini tartibga solish va tanlash imkonini beruvchi key conceptlardir. Ular toifalarga(categorize) ajratish va aniqlash uchun Kubernetes obyektlariga (masalan, Podlar, Servicelar yoki Deploymentlar) biriktirishingiz mumkin bo‘lgan metama'lumotlardir. Labellar obyektlar bilan bog'langan key/value juftliklari bo'lib, selectorlar ushbu labellar asosida obyektlarni filtrlash uchun ishlatiladi.
+Kubernetes-da labellar va selectorlar clusteringizdagi obyektlarning kichik to'plamlarini tartibga solish va tanlash imkonini beruvchi key conceptlardir. Ular toifalarga(categorize) ajratish va aniqlash uchun Kubernetes obyektlariga (masalan, Podlar, Servicelar yoki Deploymentlar) biriktirishingiz mumkin bo'lgan metama'lumotlardir. Labellar obyektlar bilan bog'langan key/value juftliklari bo'lib, selectorlar ushbu labellar asosida obyektlarni filtrlash uchun ishlatiladi.
 
 #### Labellar
 

pages/guides/konteyner/dockerfile-yozish.en-UZ.mdx

@@ -244,7 +244,7 @@ EXPOSE 3000
 # Node.js ilovasini ishga tushirish buyrug'i
 CMD ["npm", "start"]
 ```
-Ushbu Node.js misolida `EXPOSE` insturctioni konteyner ichidagi Node.js ilovasi `3000`-portda tinglashini(listen) bildiradi. Bu ko‘plab Node.js ilovalari uchun umumiy senariy bo‘lishi mumkin, chunki ular odatda ushbu portdan default bo‘yicha foydalanadilar.
+Ushbu Node.js misolida `EXPOSE` insturctioni konteyner ichidagi Node.js ilovasi `3000`-portda tinglashini(listen) bildiradi. Bu ko'plab Node.js ilovalari uchun umumiy senariy bo'lishi mumkin, chunki ular odatda ushbu portdan default bo'yicha foydalanadilar.
 
 ### VOLUME
 
@@ -262,7 +262,7 @@ VOLUME /app/data
 
 Ushbu misolda `VOLUME` insturctioni konteyner ichidagi `/app/data` da moint pointni yaratadi. Konteynerni ishga tushirish paytida ushbu jildga yozilgan har qanday ma'lumotlar konteynerning yoziladigan qatlamidan(writable layer) tashqarida saqlanadi, bu esa konteyner to'xtatilgandan yoki o'chirilgandan keyin ham doimiy(persistent) va mavjud bo'ladi.
 
-`VOLUME` dan foydalanish bo‘yicha bir nechta asosiy fikrlarga e'tibor qaratish muhim:
+`VOLUME` dan foydalanish bo'yicha bir nechta asosiy fikrlarga e'tibor qaratish muhim:
 
 * **Persisting Data(Doimiy ma'lumotlar):** Belgilangan volume mountga yozilgan har qanday ma'lumotlar, hatto konteyner o'chirib tashlangan bo'lsa ham saqlanib qoladi. Bu ma'lumotlarni konteyner instancelarida almashish va qayta ishlatish imkonini beradi.
 
@@ -329,7 +329,7 @@ CMD ["npm", "start"]
 ```
 `USER` instructioni Node.js asosiy imagesida mavjud bo'lmagan `root` foydalanuvchisi bo'lgan node foydalanuvchisiga o'tadi. Foydalanuvchilarni almashtirishdan oldin, dastur ishlayotgan vaqtda o'z fayllariga kirishini ta'minlash uchun dastur jildining egaligi node foydalanuvchisiga o'zgartiriladi.
 
-`USER` instructionidan foydalanish xavfsizlik maqsadlari uchun juda muhim, chunki `root` bo‘lmagan foydalanuvchilar bilan konteynerlarni ishga tushirish konteynerlashtirilgan ilova ichidagi xavfsizlik zaifliklarining potentsial ta'sirini kamaytiradi. Ammo shuni yodda tutingki, Dockerfile'dagi ba'zi operatsiyalar `root` huquqlarini talab qilishi mumkin, shuning uchun Dockerfile'da foydalanuvchini belgilashda xavfsizlikning eng yaxshi amaliyotlari bilan operatsion talablarni muvozanatlash juda muhimdir.
+`USER` instructionidan foydalanish xavfsizlik maqsadlari uchun juda muhim, chunki `root` bo'lmagan foydalanuvchilar bilan konteynerlarni ishga tushirish konteynerlashtirilgan ilova ichidagi xavfsizlik zaifliklarining potentsial ta'sirini kamaytiradi. Ammo shuni yodda tutingki, Dockerfile'dagi ba'zi operatsiyalar `root` huquqlarini talab qilishi mumkin, shuning uchun Dockerfile'da foydalanuvchini belgilashda xavfsizlikning eng yaxshi amaliyotlari bilan operatsion talablarni muvozanatlash juda muhimdir.
 
 ### Namunalar
 

pages/guides/monitoring/gnp-monitoring.en-UZ.mdx

@@ -241,7 +241,7 @@ node_exporter
 ```bash
 sudo useradd -rs /bin/false node_exporter
 ```
-**8->** `systemctl` foydalanishi uchun service faylini yarating. Fayl `node_exporter.service` deb nomlanishi va quyidagi formatga ega bo‘lishi kerak. Maydonlarning ko'pchiligi oldingi bo'limda tasvirlanganidek, `prometheus.service` da topilgan maydonlarga o'xshaydi.
+**8->** `systemctl` foydalanishi uchun service faylini yarating. Fayl `node_exporter.service` deb nomlanishi va quyidagi formatga ega bo'lishi kerak. Maydonlarning ko'pchiligi oldingi bo'limda tasvirlanganidek, `prometheus.service` da topilgan maydonlarga o'xshaydi.
 
 ```bash
 sudo nano /etc/systemd/system/node_exporter.service
@@ -293,7 +293,7 @@ Client Nodelari endi monitoringga tayyor. Clientlarni `prometheus.yml` ga qo'shi
 sudo nano /etc/prometheus/prometheus.yml
 ```
 
-**2->** Joblar ro'yxatini o'z ichiga olgan `scrape_configs` bo'limini toping. Unda hozirda prometheus nomli bitta job ro‘yxati keltirilgan. Bu job `9090`-portdagi local Prometheus taskini nazorat qiladi. Prometheus taski ostiga `remote_collector` `job_name`ga ega ikkinchi jobni qo'shing. Quyidagi ma'lumotlarni kiriting.
+**2->** Joblar ro'yxatini o'z ichiga olgan `scrape_configs` bo'limini toping. Unda hozirda prometheus nomli bitta job ro'yxati keltirilgan. Bu job `9090`-portdagi local Prometheus taskini nazorat qiladi. Prometheus taski ostiga `remote_collector` `job_name`ga ega ikkinchi jobni qo'shing. Quyidagi ma'lumotlarni kiriting.
 
 ```bash filename="/etc/prometheus/prometheus.yml" /172.78.1.89:9100/
 ...
@@ -363,7 +363,7 @@ sudo apt-get update
 **5->** Grafana-ning open-source versiyasini o'rnatish
 
 <Callout type="info" emoji="">
-Grafana'ning Enterprise relizini o‘rnatish uchun uning o‘rniga `sudo apt-get install grafana-enterprise` buyrug‘idan foydalaning.
+Grafana'ning Enterprise relizini o'rnatish uchun uning o'rniga `sudo apt-get install grafana-enterprise` buyrug'idan foydalaning.
 </Callout>
 
 ```bash

pages/guides/web-server/haproxy-load-balancing.en-UZ.mdx

@@ -213,7 +213,7 @@ Bu backend nodelarni belgilaydi va bir nechta konfiguratsiya variantlarini belgi
 
 * **`http-request set-header X-Forwarded-Port %[dst_port]`** Backend serverlariga yuborilgan HTTP so'rovlarida **X-Forwarded-Port** headerini o'rnatadi. U so'rov yuborilgan HAProxy serverining destination portini o'z ichiga oladi.
 
-* **`http-request add-header X-Forwarded-Proto https if { ssl_fc }`** HAProxy'ga kiruvchi so‘rov **HTTPS**(ssl_fc) orqali qabul qilingan bo‘lsa, **X-Forwarded-Proto** headerini HTTP so‘rovlariga qo‘shadi. Ushbu header client tomonidan so'rovni amalga oshirishda foydalaniladigan protokolni ko'rsatadi.
+* **`http-request add-header X-Forwarded-Proto https if { ssl_fc }`** HAProxy'ga kiruvchi so'rov **HTTPS**(ssl_fc) orqali qabul qilingan bo'lsa, **X-Forwarded-Proto** headerini HTTP so'rovlariga qo'shadi. Ushbu header client tomonidan so'rovni amalga oshirishda foydalaniladigan protokolni ko'rsatadi.
 * **`option httpchk HEAD / HTTP/1.1\r\nHost:localhost`** Backend serverlari uchun HTTP health checkni sozlaydi. U serverlarning sog'lig'ini tekshirish(health check) uchun HTTP versiyasi va **Host** headeri **localhost** ga o'rnatilgan holda root(ildiz) yo'liga ("`/`") **HTTP HEAD** so'rovini yuboradi. HAProxy ushbu tekshiruvdan kiruvchi so'rovlarni ko'rib chiqish uchun server mavjudligini aniqlash uchun foydalanadi.
 
 * **`server node1 185.168.1.21:3000 check` va `server node2 185.168.1.22:3000 check`** Backend **backendnodes** ichida ikkita serverni (node1 va node2) belgilaydi. Har bir server IP manzili va port raqami (mos ravishda 185.168.1.21:3000 va 185.168.1.22:3000) bilan aniqlanadi. Tekshirish(check) kalit so'zi HAProxy sozlangan health check metodi (**option httpchk**) yordamida ushbu serverlarning sog'lig'ini muntazam ravishda tekshirishi kerakligini bildiradi. Ushbu serverlar kiruvchi so'rovlarni bajarishga tayyor.
@@ -442,7 +442,7 @@ listen stats
 
 `acl devops_journey_acl hdr(host) -i devops-journey.uz` **Host** headerida [**devops-journey.uz**](https://devops-journey.uz/) so'rovlarini tekshiradigan `devops_journey_acl` nomli **ACL** yaratadi. `hdr(host)` ACL kiruvchi HTTP so'rovlarining **Host** headeriini tekshirishini bildiradi. `i` Katta-kichik harflarsiz moslikni bajaradi.
 
-`use_backend devops_journey_backend if devops_journey_acl` Kiruvchi so'rovning **Host** headerida `devops-journey.uz` bo'lsa, va **devops_journey_acl** ga mos keladigan so'rovlarni **devops_journey_backend** nomli maxsus backend serverlarga yo'naltiradi. `devops_journey_acl` shartiga mos kelmaydigan so‘rovlar `backendnodes` backendga yo‘naltiriladi.
+`use_backend devops_journey_backend if devops_journey_acl` Kiruvchi so'rovning **Host** headerida `devops-journey.uz` bo'lsa, va **devops_journey_acl** ga mos keladigan so'rovlarni **devops_journey_backend** nomli maxsus backend serverlarga yo'naltiradi. `devops_journey_acl` shartiga mos kelmaydigan so'rovlar `backendnodes` backendga yo'naltiriladi.
 
 
 Qisqa qilib aytganda, **Host** headeriga asoslangan so'rovlarni moslashtirish uchun **ACL** (`devops_journey_acl`) dan foydalanadi, xususan, domen [**devops-journey.uz**](https://devops-journey.uz/) bo'lgan so'rovlarni yo'naltiradi. Ushbu shartga mos keladigan so'rovlar **devops_journey_backend**dagi serverlarga yo'naltiriladi, qolgan barcha so'rovlar esa default backend **backendnodes**ga yo'naltiriladi.