diff --git a/pages/guides/cloud/aws-ecs-ecr-pipeline.en-UZ.mdx b/pages/guides/cloud/aws-ecs-ecr-pipeline.en-UZ.mdx index ed6ec48..e53a555 100644 --- a/pages/guides/cloud/aws-ecs-ecr-pipeline.en-UZ.mdx +++ b/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,31 +19,31 @@ 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) @@ -51,9 +51,9 @@ va bundan chiqgan natija S3 bucketga tashlanishini shu qadamlar orasida berib ke 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 ! diff --git a/pages/guides/cloud/azure-network-sozlash.en-UZ.mdx b/pages/guides/cloud/azure-network-sozlash.en-UZ.mdx index 072b2df..bd2738d 100644 --- a/pages/guides/cloud/azure-network-sozlash.en-UZ.mdx +++ b/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. diff --git a/pages/guides/database/start-mongodb.en-UZ.mdx b/pages/guides/database/start-mongodb.en-UZ.mdx index eca914e..6dd7097 100644 --- a/pages/guides/database/start-mongodb.en-UZ.mdx +++ b/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. diff --git a/pages/guides/k8s/k8s-objects.en-UZ.mdx b/pages/guides/k8s/k8s-objects.en-UZ.mdx index e9db9f8..62c3f58 100644 --- a/pages/guides/k8s/k8s-objects.en-UZ.mdx +++ b/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 diff --git a/pages/guides/konteyner/dockerfile-yozish.en-UZ.mdx b/pages/guides/konteyner/dockerfile-yozish.en-UZ.mdx index 28a5b70..3b6d74e 100644 --- a/pages/guides/konteyner/dockerfile-yozish.en-UZ.mdx +++ b/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 diff --git a/pages/guides/monitoring/gnp-monitoring.en-UZ.mdx b/pages/guides/monitoring/gnp-monitoring.en-UZ.mdx index 355541b..1ea3d33 100644 --- a/pages/guides/monitoring/gnp-monitoring.en-UZ.mdx +++ b/pages/guides/monitoring/gnp-monitoring.en-UZ.mdx @@ -363,7 +363,7 @@ sudo apt-get update **5->** Grafana-ning open-source versiyasini o'rnatish -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. ```bash diff --git a/pages/tutorials/article/_meta.en-UZ.json b/pages/tutorials/article/_meta.en-UZ.json index 67596ef..2f1659f 100644 --- a/pages/tutorials/article/_meta.en-UZ.json +++ b/pages/tutorials/article/_meta.en-UZ.json @@ -195,8 +195,8 @@ "level": "Hamma uchun", "category": "DevOps", "author": { - "name": "Otabek Ismoilov", - "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/ismoilovdev.jpeg" + "name": "Manuchehr Usmonov", + "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/manuchehr_usmonov.jpg" }, "createdAt": "2024.03.29", "minutesRead": 20, @@ -216,8 +216,8 @@ "level": "Hamma uchun", "category": "DevOps", "author": { - "name": "Otabek Ismoilov", - "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/ismoilovdev.jpeg" + "name": "Manuchehr Usmonov", + "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/manuchehr_usmonov.jpg" }, "createdAt": "2024.04.08", "minutesRead": 20, @@ -237,8 +237,8 @@ "level": "Hamma uchun", "category": "DevOps", "author": { - "name": "Otabek Ismoilov", - "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/ismoilovdev.jpeg" + "name": "Manuchehr Usmonov", + "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/manuchehr_usmonov.jpg" }, "createdAt": "2024.04.08", "minutesRead": 20, @@ -292,5 +292,26 @@ "toc": false, "pagination": true } + }, + "api-gateway-nima": { + "title": "API Gateway nima?", + "longTitle": "API Gateway nima?", + "description": "API Gateway nima?", + "level": "Hamma uchun", + "category": "DevOps", + "author": { + "name": "Gayratjon Rayimjonov", + "image": "https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/tutorials/authors/gayratjon_rayimjonov.jpeg" + }, + "createdAt": "2024-08-03", + "minutesRead": 40, + "href": "/tutorials/article/api-gateway-nima", + "theme": { + "breadcrumb": false, + "footer": true, + "sidebar": false, + "toc": false, + "pagination": true + } } } diff --git a/pages/tutorials/article/api-gateway-nima.en-UZ.mdx b/pages/tutorials/article/api-gateway-nima.en-UZ.mdx new file mode 100644 index 0000000..ce3c2e3 --- /dev/null +++ b/pages/tutorials/article/api-gateway-nima.en-UZ.mdx @@ -0,0 +1,67 @@ +import { Callout } from "nextra-theme-docs"; + +# API Gateway nima? + +***Microservice*** + +Tasavvur qiling online do'kon yaratmoqchisiz. Ilovangizda quyidagi imkoniyatlar mavjud: + +* **Buyurtma berish** +* **Mahsulot haqida ma'lumotlar olish** +* **Mahsulot ro'yxatini olish** + +Shu xususiyatar asosida bizda bir nechta servislar(mikroservices) mavjud: + +* **Product Service** +* **Order Service** +* **Pricing Service** +* **Account Service** +* **Customer Review Service** +* **Inventory Service** + +Ilovangizdan foydalanish davomida foydalanuvchi bir necha servislardan foydalanadi. Agar siz asosiy oynaga kirib biror bir mahsulotga qidiruv bersangiz, mahsulotlar roʻyxatini chiqarib beradi. Bu roʻyxat shakllanish jarayonida yuqoridagi servislarga murojaat qilib mahsulot nomi, narxi, mahsulot tarixi va hokazolarni list ko'rinishida taqdim etadi. (quyidagi rasm) + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/1.webp) + +Shunday qilib mahsulotni ko'rsatadigan kod **product servis**, **account servis**, **customer review servis**lardan ma'lumotlarni olib bizga ko'rsatadi. + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/2.webp) + +Bu grafikdagi klient ilovasi API **kompasitor** vazifasini bajaradi. U bir nechta servis larni chaqiradi va birlashtiradi. + +Bu holatda maummo nimada? + +Yondashuv oqilona bo'lib ko'rinsada unda jiddiy muammolar mavjud. + + +* **1. User ma'lumotlarini olish uchun birnechta api ga request jo'natish.** Foydalanuvchi ma'lumotini olish uchun bir nechta so'rovlarni amalga oshirish kerak va foydalanuvchi so'rovlarini ketma-ketlikda bajarish kerak. Bu ketma-ketlikni amalga oshirish uchun api kompozitsiyon kodini yozish talab qilinadi va bu potensial murakkab vazifa. + +* **2. Serviselar o'zgarishidagi muammolar(Lack Of Encapsulation).** Ma'lumki servislarga to'g'ridan to'g'ri kirishda ko'plab muammolar mavjud. Application rivojlanib borar ekan, bazida api larni o'zgartirishga to'g'ri keladi. Natijada o'zgargan api lardan foydalanayotgan mijozlarda(web, andorid, iOS) larda api bilan bo'gliq muammolar paydo bo'ladi. + +* **3. Mos kelmaydigan protokol(Unfriendly Protocol).** Bazi servis lar gRPC yoki AMQP messaging protokollar ishlatilishi mumkin. Bu ichki servis lar uchun juda zo'r yechim bo'lishi mumkin. Lekin mobile klient yoki veb klientlar uchun anchgina muammo bo'lishi mumkin. Yoki baʼzi bir protokol mexanizmlarini klient platformalarida moslashtirish qiyin bo'lishi mumkin. + +**Bu holatda qanday yechim qilish mumkin?** degan tabiiy savol tug'ilishi mumkun. Endi bu muammoni yechimi haqida gaplashsak. + +**Yechim:** + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/3.webp) + +**API Gateway(AG)** — bu mikroservislar to’plami uchun yagona kirish nuqtasi vazifasini bajaradigan servis. + +API Gateway klientdan kelgan request(soʻrov)larni qabul qiladi, ularni tegishli mikroservis larga yo’naltiradi va ularni javobini mijozga qaytaradi. + +API Gateway marshrutlash, **autentifikatsiya** va **rate limiting** kabi vazifalar uchun javobgardir. Bu mikroservislarga o’zlarining individual vazifalariga e’tibor qaratish imkonini beradi va tizimning umumiy ishlashi va mashtablashni(scalability) yaxshilaydi. + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/4.webp) + +## Request Routing +API Gatewayning asosiy funktsiyalaridan biri so’rovlarni marshrutlashdir. API Gatewayning so’rovlarni mos keladigan servislarga yo’naltirish orqali ba’zi API operatsiyalarini amalga oshiradi. So’rovni qabul qilganda, API Gateway requestni qaysi servisga yo’naltirish kerakligini ko’rsatadigan marshrutlash xaritasiga murojaat qiladi. + +## API Composition +API Gateway API tarkibini ham ta’minlaydi. Men buni bazi bir misol yordamida tushuntiraman. + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/5.webp) + +Yuqoridagi rasmda ko’rsatilganidek, Android klient bir nechta API so’rovlarini amalga oshiryapti. + +![api-gateway-nima](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/api-gateway-nima/6.webp) \ No newline at end of file diff --git a/pages/tutorials/article/linux-kernel.en-UZ.mdx b/pages/tutorials/article/linux-kernel.en-UZ.mdx index 96b13d0..d5b89fd 100644 --- a/pages/tutorials/article/linux-kernel.en-UZ.mdx +++ b/pages/tutorials/article/linux-kernel.en-UZ.mdx @@ -410,7 +410,7 @@ Tasavvur qiling-a, bir guruh shaxslar loyiha ustida hamkorlik qilmoqda, masalan, Loyiha menejeri har bir guruh a'zosiga o'z mahorati va tajribasidan kelib chiqqan holda aniq vazifalarni belgilash orqali loyihani boshlaydi. Ushbu vazifani belgilash operatsion tizimda processni yaratishga o'xshaydi. -Loyiha davomida loyiha menejeri har bir topshiriqning(task) bajarilishini nazorat qilib, belgilangan muddatlarga rioya etilishini va loyihaning yo‘lda davom etishini ta’minlaydi. Ular vazifalarni qayta belgilashlari yoki kerak bo'lganda ustuvorliklarni sozlashlari mumkin, xuddi operatsion tizimdagi process scheduling kabi. +Loyiha davomida loyiha menejeri har bir topshiriqning(task) bajarilishini nazorat qilib, belgilangan muddatlarga rioya etilishini va loyihaning yo‘lda davom etishini ta'minlaydi. Ular vazifalarni qayta belgilashlari yoki kerak bo'lganda ustuvorliklarni sozlashlari mumkin, xuddi operatsion tizimdagi process scheduling kabi. Loyiha menejeri, shuningdek, byudjet, vaqt va jihozlar kabi resurslarni boshqaradi va ularni jamoa ishini qo'llab-quvvatlash uchun to'g'ri taqsimlaydi. Ushbu resurslarni taqsimlash operatsion tizim proceslar o'rtasida tizim resurslarini qanday boshqarishi bilan taqqoslanadi. diff --git a/pages/tutorials/article/netflix-deploy.en-UZ.mdx b/pages/tutorials/article/netflix-deploy.en-UZ.mdx index b89dd0e..fe3a492 100644 --- a/pages/tutorials/article/netflix-deploy.en-UZ.mdx +++ b/pages/tutorials/article/netflix-deploy.en-UZ.mdx @@ -975,7 +975,7 @@ Pipelinedagi ushbu maxsus bosqich Docker konteynerli ilovasini yaratish va deplo * **Credentialsdan foydalanish ->** DockerHub hisob ma'lumotlarini xavfsiz boshqarish uchun `withCredentials `dan foydalanadi `(credentialsId: 'dockerhub')`. Yani bu Jenkins credentialsdan secretlarni olib pipelineda xavfsiz ishlatadi. `dockerhub` credentialsdan user va parol ajratib olinib unga 2ta variable(o'zgaruvchi)ga beriladi va ishlatiladi. Koddagi qism `[usernamePassword(credentialsId: 'dockerhub', usernameVariable: 'DOCKER_USERNAME', passwordVariable: 'DOCKER_PASSWORD')]` -* **Docker Login ->** Taqdim etilgan hisob ma’lumotlari (`DOCKER_USERNAME` va `DOCKER_PASSWORD`) yordamida Docker login buyrug‘ini bajaradi va Docker Registryga kiradi. +* **Docker Login ->** Taqdim etilgan hisob ma'lumotlari (`DOCKER_USERNAME` va `DOCKER_PASSWORD`) yordamida Docker login buyrug‘ini bajaradi va Docker Registryga kiradi. * **Docker Build ->** `docker build` buyrug'i yordamida Docker imageni yaratadi: **TMDB_V3_API_KEY** build argumentini **API_KEY** qiymati bilan o‘rnatadi. Docker Imageni belgilangan `${REGISTRY_URL}/${CONTAINER_NAME}:${BUILD_NUMBER}` bilan teg qo'yiladi va loyihamizdagi Dockerfile ko'rsatib build qilinadi. diff --git a/pages/tutorials/article/wasm.en-UZ.mdx b/pages/tutorials/article/wasm.en-UZ.mdx index 04436ee..a7fab1e 100644 --- a/pages/tutorials/article/wasm.en-UZ.mdx +++ b/pages/tutorials/article/wasm.en-UZ.mdx @@ -19,7 +19,7 @@ WebAssembly platformadan mustaqil, ya'ni u turli xil operatsion tizimlar va arxi Wasm-ning asosiy afzalliklaridan biri uning JavaScript va boshqa veb-texnologiyalar bilan uzluksiz integratsiyalashuvidir, bu ishlab chiquvchilarga WebAssembly-dan foydalangan holda o'z ilovalarining ishlash uchun muhim bo'lgan qismlarini optimallashtirishga imkon beradi, shu bilan birga JavaScript-ning boshqa komponentlar uchun qulayligi va moslashuvchanligini saqlab qoladi. -2015-yilda e’lon qilingan va birinchi marta 2017-yil mart oyida chiqarilgan WebAssembly 2019-yil 5-dekabrda `World Wide Web Consortium` tavsiyasiga aylandi va 2021-yilda `ACM SIGPLAN` tomonidan Dasturlash tillari uchun dasturiy ta’minot mukofotini oldi. `World Wide Web Consortium (W3C)` standartni Mozilla, Microsoft, Google, Apple, Fastly, Intel va Red Hat hissalari bilan saqlab turadi. +2015-yilda e'lon qilingan va birinchi marta 2017-yil mart oyida chiqarilgan WebAssembly 2019-yil 5-dekabrda `World Wide Web Consortium` tavsiyasiga aylandi va 2021-yilda `ACM SIGPLAN` tomonidan Dasturlash tillari uchun dasturiy ta'minot mukofotini oldi. `World Wide Web Consortium (W3C)` standartni Mozilla, Microsoft, Google, Apple, Fastly, Intel va Red Hat hissalari bilan saqlab turadi. ![WASM](https://raw.githubusercontent.com/devops-journey-uz/assets/main/images/article/wasm/2.png)