[FIX] fixed errors in author images

pages/guides/cloud/aws-ecs-ecr-pipeline.en-UZ.mdx

@@ -10,7 +10,7 @@ Assalom aleykum
 **ECS** — bu **E**lastic **C**ontainer **S**ervice bu service . Asosiy 3 qismdan iborat bo'lgan bu service sizdan ketma-ketlik talab qiladi.
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/1.webp)
 
-**1->** **Cluster** - 3 xildagi serverlarda ishlashi mumkin **1-EC2, 2-FARGATE, 3-EXTERNAL**(AWS da bo'lmagan boshqa server). Uni o’zining alohida deployment qismida **“Failure detection”** bor. Bu shunday ishlaydi — (**“Turned on, rollback on failures turned on for circuit breaker”**) va unga Service qo’shiladi.
+**1->** **Cluster** - 3 xildagi serverlarda ishlashi mumkin **1-EC2, 2-FARGATE, 3-EXTERNAL**(AWS da bo'lmagan boshqa server). Uni o'zining alohida deployment qismida **“Failure detection”** bor. Bu shunday ishlaydi — (**“Turned on, rollback on failures turned on for circuit breaker”**) va unga Service qo'shiladi.
 
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/2.webp)
 
@@ -19,41 +19,41 @@ Assalom aleykum
 
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/4.webp)
 
-**3->** **Task Definition** yozib olinadi va unda siz qaysi va nechta container ishlatmoqchi bo’lganingiz, ularga serverdan qancha **CPU** va **Memory** berishingizni yozib qo’ysangiz bo’ladi.Albatta buni ham qaysi Infrastructurada ishlatishingiz berilishi kerak **(EC2, Fargate, External)**. Bunga keyinroq yana to’xtalib o’tamiz. Agar loyiha kichkina va oddiy bo’ladigan bo’lsa bularni default holatda qoldirsa ham bo’ladi . Agar unga miqdoriy cheklov bermoqchi bo’lsangiz siz u container qanday turdagi server (EC2 , Fargate, External) da turganini bilishingiz kerak. Agar Server CPUsi 4 bo’lib siz container ga 6 beradigan bo’lsangiz service qulashi ham mumkin
+**3->** **Task Definition** yozib olinadi va unda siz qaysi va nechta container ishlatmoqchi bo'lganingiz, ularga serverdan qancha **CPU** va **Memory** berishingizni yozib qo'ysangiz bo'ladi.Albatta buni ham qaysi Infrastructurada ishlatishingiz berilishi kerak **(EC2, Fargate, External)**. Bunga keyinroq yana to'xtalib o'tamiz. Agar loyiha kichkina va oddiy bo'ladigan bo'lsa bularni default holatda qoldirsa ham bo'ladi . Agar unga miqdoriy cheklov bermoqchi bo'lsangiz siz u container qanday turdagi server (EC2 , Fargate, External) da turganini bilishingiz kerak. Agar Server CPUsi 4 bo'lib siz container ga 6 beradigan bo'lsangiz service qulashi ham mumkin
 
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/5.webp)
 
-Task definition ikki xil usul bilan ochsa bo’ladi, Json bu ancha mukammal va tez bo’ladigani. Agar yangi foydalanuvchi bo’lsangiz UI qismi bilan qilish tafsiya beriladi.
+Task definition ikki xil usul bilan ochsa bo'ladi, Json bu ancha mukammal va tez bo'ladigani. Agar yangi foydalanuvchi bo'lsangiz UI qismi bilan qilish tafsiya beriladi.
 
-Task definition da yozilgan struktura sizni servicengiz yoki cluster da ishlashida muammo chiqishi mumkin, qachonki siz ularni Infrastructurasini har xil qilgan bo’lsangiz. Nega deysizmi ? Chunki bu container va uni qanday qurilma (OS) da build qilishingizga qarab ishlaydi.
+Task definition da yozilgan struktura sizni servicengiz yoki cluster da ishlashida muammo chiqishi mumkin, qachonki siz ularni Infrastructurasini har xil qilgan bo'lsangiz. Nega deysizmi ? Chunki bu container va uni qanday qurilma (OS) da build qilishingizga qarab ishlaydi.
 
-Masalan siz bironta narsani Docker bilan Windowsda build qilib keyin uni Linux da yoki Mac **(ARM)** da run qilib ko’ring. AWS dagi EC2,FARGATE ham huddi shunday. Albatta EC2 ning ham **g** type — **Graviton** turi bor. bu sizdan ECS da build qiladigan containerni ECR dan keladigan container image ga qo’yiladigan sharti. Ko’p odamlar shu masalada xato qilishadi va tushunmaslikdan vaqt yo’qotiladi. Agar bu narsalarni ochishda bironta mayda detallariga tushunmasangiz **AWS workshop**ga kirib o’rganishingizni tafsiya beraman.
+Masalan siz bironta narsani Docker bilan Windowsda build qilib keyin uni Linux da yoki Mac **(ARM)** da run qilib ko'ring. AWS dagi EC2,FARGATE ham huddi shunday. Albatta EC2 ning ham **g** type — **Graviton** turi bor. bu sizdan ECS da build qiladigan containerni ECR dan keladigan container image ga qo'yiladigan sharti. Ko'p odamlar shu masalada xato qilishadi va tushunmaslikdan vaqt yo'qotiladi. Agar bu narsalarni ochishda bironta mayda detallariga tushunmasangiz **AWS workshop**ga kirib o'rganishingizni tafsiya beraman.
 
 
-**ECR** — bu **E**lastic **C**ontainer **R**egistry, ha bu AWS ga kirmasdan oldin ishlatgan Gitlab Container registery yoki alohida serverga qo’ygan Registery, unchalik ham qiyin emas, ishlash arxitekturasi deyarli bir xil. Nega aynan AWS dagi registery dan foydalanishimiz kerak o’zimizni tayyor registery turganda ? Bunga javob AWS o’zini servise larini ko’pini faqat o’zining servislari bilan ishlatishishni talab qiladi, Albatta hozir qo’shimcha xizmatlari ham qo’shilmoqda — Gitlab, Github, Bitbucketlar ham bor va ularga integratsiya qilsangiz ham bo’ladi. Lekin muammo sizning **SCM(SourceCodeManager)**ning verisyasi — Agar alohida kampaniya uchun ko’tarilgan bo’lsa, va unga har bir repositoriyani ulab chiqish vaqtingiz va ba’zida tushunarsiz muammolar chiqishi bilan bog’liq. Umuman olganda hohishingizga qarab.
+**ECR** — bu **E**lastic **C**ontainer **R**egistry, ha bu AWS ga kirmasdan oldin ishlatgan Gitlab Container registery yoki alohida serverga qo'ygan Registery, unchalik ham qiyin emas, ishlash arxitekturasi deyarli bir xil. Nega aynan AWS dagi registery dan foydalanishimiz kerak o'zimizni tayyor registery turganda ? Bunga javob AWS o'zini servise larini ko'pini faqat o'zining servislari bilan ishlatishishni talab qiladi, Albatta hozir qo'shimcha xizmatlari ham qo'shilmoqda — Gitlab, Github, Bitbucketlar ham bor va ularga integratsiya qilsangiz ham bo'ladi. Lekin muammo sizning **SCM(SourceCodeManager)**ning verisyasi — Agar alohida kampaniya uchun ko'tarilgan bo'lsa, va unga har bir repositoriyani ulab chiqish vaqtingiz va ba'zida tushunarsiz muammolar chiqishi bilan bog'liq. Umuman olganda hohishingizga qarab.
 
-**Code Pipeline** — Bu service turi sizga 2 yoki unda ko’p service larni bir-biri bilan o’rtasida qandaydur doimiy ishni bajarish uchun ishlatiladi,buni Workshop yoki Docslar orqali kerak bo’lgan toollardan foydalansangiz bo’ladi. Bu mavzu uchun **ECR + ECS** . Pipeline structurasi oddiy lekin har bir Pipeline dagi Stage larni bir biriga bog’lovchi ya’ni Artifact lar ni tushunish kerak. Code Pipeline ochishda sizdan 4 ta qadam talab qilinadi. Birinchisi bu Source ya’ni Pipeline qandaydur vazifa bajarish uchun uning o’sha vazifada aytilgan qadamlarni qaysi narsa ustida bajarishi . Masalan siz kitoblaringizni taklash uchun shkaf kerak bo’lganidek. Keyingi Qadam Deploy, ya’ni loyihani ECS ga deploy qilish. Lekin bu 2 Stage bilan ish bitmaydi. Aytganimdek Code Pipeline har bitta qadam o’rtasida kirish va chiqish Artifact talab qiladi.
+**Code Pipeline** — Bu service turi sizga 2 yoki unda ko'p service larni bir-biri bilan o'rtasida qandaydur doimiy ishni bajarish uchun ishlatiladi,buni Workshop yoki Docslar orqali kerak bo'lgan toollardan foydalansangiz bo'ladi. Bu mavzu uchun **ECR + ECS** . Pipeline structurasi oddiy lekin har bir Pipeline dagi Stage larni bir biriga bog'lovchi ya'ni Artifact lar ni tushunish kerak. Code Pipeline ochishda sizdan 4 ta qadam talab qilinadi. Birinchisi bu Source ya'ni Pipeline qandaydur vazifa bajarish uchun uning o'sha vazifada aytilgan qadamlarni qaysi narsa ustida bajarishi . Masalan siz kitoblaringizni taklash uchun shkaf kerak bo'lganidek. Keyingi Qadam Deploy, ya'ni loyihani ECS ga deploy qilish. Lekin bu 2 Stage bilan ish bitmaydi. Aytganimdek Code Pipeline har bitta qadam o'rtasida kirish va chiqish Artifact talab qiladi.
 
-**Artifact** — bu 2 xil ko’rinishda (**zip** va **archive**) bo’lib u o’zini ichida har bir qadamda ishlatilgan strukturani qandaydur fayl turida saqlab ketadi va u **S3 bucket**larni ichiga qo’yiladi.
+**Artifact** — bu 2 xil ko'rinishda (**zip** va **archive**) bo'lib u o'zini ichida har bir qadamda ishlatilgan strukturani qandaydur fayl turida saqlab ketadi va u **S3 bucket**larni ichiga qo'yiladi.
 
 Har bir Code Pipeline dagi Stagedan Input va Output artifact berilishi talab qilinadi, bu aytganimdek bitta oldingi yoki boshlanish nuqtasi qanday va qaysi holatda amalga oshirishi talab qilinganidek.Bu holatda nima qilamiz ?
 
-Biz 2 ta Stage ya’ni qadam bilan biz hohlagan natijani ololmaymiz ? Agar ECR dagi imageni ECS ga deploy qilish kerak bo’lsa ) .
-Chunki ECS bizdan `.json` formatdagi struktura shakllanga fayl so’raydi, ECR dan chiqgan artifact ham `.json` lekin boshqa sxemadagi. Bir .json ichidagi sxema `{}` bundan qavslar bilan boshlangan bo’lsa bittasi `[]` bundan. Bunda biz nima qilamiz ?
+Biz 2 ta Stage ya'ni qadam bilan biz hohlagan natijani ololmaymiz ? Agar ECR dagi imageni ECS ga deploy qilish kerak bo'lsa ) .
+Chunki ECS bizdan `.json` formatdagi struktura shakllanga fayl so'raydi, ECR dan chiqgan artifact ham `.json` lekin boshqa sxemadagi. Bir .json ichidagi sxema `{}` bundan qavslar bilan boshlangan bo'lsa bittasi `[]` bundan. Bunda biz nima qilamiz ?
 
-Stagelar soni ko’paytiramiz. Unga **Code Commit** hamda **CodeBuild** qo’shamiz. Shu bilan bizda 4 ta stage(qadam) paydo bo’ladi . Bu ikki service bizga `{ }` bu turdagi `.json` faylni `[ ]` bu turdagisiga convert qilishimiz uchun. hohlasangiz o’zingiz ishlatadigan CI/CD bilan S3 credentiallarini olib upload qiling, hohlasangiz Code Build orqali.
+Stagelar soni ko'paytiramiz. Unga **Code Commit** hamda **CodeBuild** qo'shamiz. Shu bilan bizda 4 ta stage(qadam) paydo bo'ladi . Bu ikki service bizga `{ }` bu turdagi `.json` faylni `[ ]` bu turdagisiga convert qilishimiz uchun. hohlasangiz o'zingiz ishlatadigan CI/CD bilan S3 credentiallarini olib upload qiling, hohlasangiz Code Build orqali.
 
-Code Commit bu o’zida Fayllar saqlovchi bir repository, unda bizdagi `.yml` fayllar va boshqa hohlagan vazifa uchun fayllar qo’ysangiz bo’ladi va ularni build qilish uchun CodeBuilddan **buildproject** ochiladi.
+Code Commit bu o'zida Fayllar saqlovchi bir repository, unda bizdagi `.yml` fayllar va boshqa hohlagan vazifa uchun fayllar qo'ysangiz bo'ladi va ularni build qilish uchun CodeBuilddan **buildproject** ochiladi.
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/6.webp)
 va bundan chiqgan natija S3 bucketga tashlanishini shu qadamlar orasida berib ketishingiz mumkin.
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/7.webp)
 
 Shu ketma-ketlikda biz **CodePipeline**dagi Build Stagega Commit stagedan chiqgan artifactni Deploy stagega artifact sifatida Builddan chiqaradigna artifactimizni beramiz, unga hohlagan nom berishingiz mumkin.
 ![gitlab-ci](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/cloud/aws-ecs-ecr/8.webp)
 
-Hozircha hammasi shu . Agar hamma qadamlar to’g’ri bajarilsa siz hohlagan natijani olasiz )
+Hozircha hammasi shu . Agar hamma qadamlar to'g'ri bajarilsa siz hohlagan natijani olasiz )
 
-Bu mavzu haqida savol va takliflarni Telegram orqali ham fikr bildirsangiz bo’ladi [**LINK**](https://t.me/nurilloh_an)
+Bu mavzu haqida savol va takliflarni Telegram orqali ham fikr bildirsangiz bo'ladi [**LINK**](https://t.me/nurilloh_an)
 
 Hammaga rahmat !
 

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

@@ -126,7 +126,7 @@ Xulosa qilib aytadigan bo'lsak, MongoDB ma'lumotlar bazasida bir qator collectio
 
 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-objects.en-UZ.mdx

@@ -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

@@ -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

@@ -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