Tarkibga o'tish

DevOps: keyingi qadamlar

Bu modul bitta savoldan — "container aslida nima?" — boshlanib, tashqariga qarab kengaydi: Namespaces va cgroups dagi kernel mexanikasi, Docker va Podman: amaliy ishlash dagi kundalik vositalar, Linux CI/CD’da dagi avtomatlashtirilgan build’lar, Linux bulutda (cloud) dagi o'zini o'zi sozlaydigan instansiyalar, Infrastructure as Code asoslari dagi park bo'yicha tayyorlash va Monitoring, logging va automation dagi park bo'yicha observability. Bu mavzularning har biri o'z vositalari ostida 1-moduldan boshlab ko'rib chiqilgan o'sha Linux asoslari edi — jarayonlar, namespace’lar, ruxsatlar, systemd, SSH, log'lar — faqat masshtabda va tobora ko'proq har bir buyruqni qo'lda yozadigan insonsiz qo'llanilgan. Bu yakunlovchi maqola bu poydevor mustahkam bo'lgach, keyin nima kelishini va allaqachon ko'rib chiqilgan qismlar unga qanday bog'lanishini aytib beradi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

  • Kubernetes kabi orkestrator allaqachon ko'rib chiqilgan container asoslari ustiga aslida nima qo'shishini tushuntirish;
  • GitOps’ni shu modulning oldingi qismidagi IaC va CI/CD tushunchalarining aniq, intizomli qo'llanishi sifatida tasvirlash;
  • bu kurs quradigan ko'nikmalarni tasdiqlaydigan soha sertifikatlarini va ularning har biri aslida nimani tekshirishini aytish;
  • shu moduldan keyin keladigan LFCS uslubidagi lab’larga o'z tayyorgarligingizni baholash va qayta ko'rib chiqishni birinchi navbatda nimadan boshlash kerakligini aniqlash.

"Bitta container"dan "orkestratsiya qilingan container’lar parki"gacha

Docker va Podman: amaliy ishlash dagi hamma narsa bir vaqtda bitta host’da ishlaydi: docker run container’ni siz buyruqni yozgan mashinada ishga tushiradi. O'nlab yoki yuzlab container’larni ko'plab hostlar bo'ylab, nosozlikda avtomatik qayta ishga tushirish, yuklama ostida avtomatik masshtablash va host ishdan chiqqanda avtomatik qayta joylashtirish bilan ishga tushirish — container orkestratorlari hal qiladigan muammo. Ularning yetakchisi Kubernetes.

Docker/Podman:  you decide which host, you run the container, you notice if it dies
Kubernetes:     you declare "I want 3 replicas of this container, healthy, always"
                the scheduler decides which hosts, restarts failures, reschedules on host loss

Eng muhimi, Kubernetes Linux containerlari va Namespaces va cgroups dagi container asoslarini almashtirmaydi — u bevosita ularning ustiga quriladi. Kubernetes Pod'i kernel darajasida bitta network namespace’ni bo'lishadigan bir yoki bir nechta container. Uni Linux containerlari maqolasida tasvirlanganidek aynan containerd yoki CRI-O runc ni chaqirib yaratadi. Container CrashLoopBackOff holatida qotib qolganini aytadigan kubectl describe pod muvaffaqiyatsizligi istalgan container nosozligi kabi debug qilinadi: avval kubectl logs, bu yetarli bo'lmasa, Namespaces va cgroups maqolasidagi aynan o'sha usul bilan haqiqiy node’da asosiy container’ning namespace’lariga nsenter orqali kirish. CPU va xotira uchun Kubernetes resursining limit va request qiymatlari YAML ostida xuddi o'sha maqolada qo'lda ko'rsatilganidek, pod cgroup’iga o'rnatilgan cgroup cpu.max va memory.max qiymatlari. Orkestratsiyada boshqa texnologiyalar steki yo'q — bu o'sha primitivlar ustiga qo'yilgan avtomatlashtirish. Bu modul aynan shuning uchun avval primitivlarni qurdi.

GitOps: IaC va CI/CD bitta intizomga birlashgan

Infrastructure as Code asoslari maqolasida infratuzilmani versiyalar nazorati ostidagi fayllarda e’lon qilish, Linux CI/CD’da maqolasida esa har bir commit’da avtomatik quradigan va sinaydigan pipeline’lar ko'rib chiqildi. GitOps — ikkalasini bitta siklga birlashtirish amaliyoti. Git repozitoriysi tizimning kerakli holati uchun yagona haqiqat manbai bo'ladi va avtomatlashtirilgan jarayon ishlab turgan tizimni hozir commit qilingan narsaga uzluksiz moslashtirib turadi — inson tomonidan qo'lda terraform apply yoki kubectl apply umuman ishga tushirilmaydi.

Developer merges a change to the Git repo
   │
   ▼
GitOps controller (e.g., Argo CD, Flux) detects the diff
   │
   ▼
Controller reconciles the live cluster to match the repo
   │
   ▼
Drift from the repo is automatically corrected, continuously

Bu Infrastructure as Code asoslari maqolasida ko'tarilgan siljish muammosini bevosita yopadi. Siljish faqat kimdir tasodifan terraform plan ni keyingi safar ishga tushirgandagina aniqlanish o'rniga, GitOps controller uzluksiz tekshiradi va avtomatik moslashtiradi. Buning evazi u yerda ko'tarilgan o'sha murosa: tegishli commit’siz, to'g'ridan-to'g'ri ishlab turgan tizimga qo'llanilgan favqulodda qo'lda tuzatishni hamma narsani bir xil saqlashi kerak bo'lgan o'sha avtomatlashtirish jimgina bekor qiladi. Shuning uchun GitOps jamoalari "tuzatishni Git’ga commit qilish"ni ixtiyoriy keyingi qadam emas, hodisaga javob berishning bir qismi deb hisoblaydi.

Sertifikatlar qayerga to'g'ri keladi

Uchta sertifikat bu kurs, ayniqsa bu modul quradigan ko'nikmalarga yaqin mos keladi. Ularning har biri aslida nimani tasdiqlashini bilishga arziydi, chunki ular turli narsalarni tekshiradi:

  • LFCS (Linux Foundation Certified System Administrator) aynan shu kursning boshidan 14-modulgacha ko'rib chiqilgan bitta host administratsiyasi ko'nikmalarini tasdiqlaydi: foydalanuvchilar, ruxsatlar, xotira, tarmoq, systemd, troubleshooting. Shu moduldan keyin darhol keladigan LFCS lab’lari moduli aynan shu imtihonning vazifaga asoslangan, jonli tizimdagi savollar uslubi uchun amaliy mashg'ulot sifatida qurilgan.
  • LFCE (Linux Foundation Certified Engineer) LFCS ustiga quriladi va tarmoq servislari, xavfsizlik hamda cron asoslari dan boshlab shu modulgacha ko'rib chiqilgan turdagi avtomatlashtirishga ko'proq urg'u beradi.
  • CKA (Certified Kubernetes Administrator) shu moduldagi container asoslarini zaruriy shart deb hisoblaydi va aynan Kubernetes klasterini boshqarishni tekshiradi. Bu kundalik ish faqat container’lar emas, orkestratsiya bo'lib qolganda tabiiy keyingi sertifikat.

Ularning hech biri boshqasining doirasini almashtirmaydi. Mustahkam Linux asoslari bo'lmagan CKA egasi klaster muammosi Kubernetes darajasidagi emas, node darajasidagi kernel, cgroup yoki tarmoq muammosi bo'lib chiqqan zahoti qiynaladi. Bu keng tarqalgan, haqiqiy nosozlik va bu kurs avval Linux poydevorini qurish orqali aynan shu bo'shliqning oldini olish uchun shunday tuzilgan.

Intervyuda: "siz Kubernetes’ni bilasiz — Linux’ni haqiqatan bilasizmi?"

Bu savol u yoki bu shaklda tajribasi butunlay container va orkestrator atrofida bo'lgan, ortida quyi darajadagi troubleshooting bo'lmagan nomzodlarga tez-tez beriladi. Kuchli javob aynan shu maqola hozirgina chizgan bog'liqlikni ko'rsatadi: Kubernetes tarmoq muammosi ostida ko'pincha veth/network namespace muammosi bo'ladi, pod’ning OOM tomonidan o'ldirilishi esa Namespaces va cgroups maqolasida ko'rib chiqilgan o'sha dmesg va cgroup fayllarini tekshirish bilan aniqlanadigan cgroup memory.max hodisasi. "Pod’ni qayta ishga tushirib, umid qilish" esa diagnostika emas. Intervyuerlar buni aynan abstraksiyaning o'zi ishdan chiqqanda orkestratorning abstraksiya qatlamidan pastda debug qila oladigan nomzodlarni saralash uchun so'raydi.

O'z tayyorgarligingizni baholash

Shu moduldan keyin keladigan LFCS lab’lari ga o'tishdan oldin adolatli o'z-o'zini tekshirish — quyidagilarni hech narsaga qaramasdan qila olasizmi:

  • namespace va cgroup o'rtasidagi farqni tushuntirish va ikkalasini unshare hamda qo'lda o'rnatilgan cgroup cheklovi bilan ko'rsatish;
  • Dockerfile qurish, hosil bo'lgan image’ni ishga tushirish va uning ma’lumotlarini volume bilan saqlab qolish;
  • idempotent Ansible vazifasini yozish va ikkinchi ishga tushirishdagi changed natijasi nega muammoni bildirishini tushuntirish;
  • journalctl -p err chiqishini o'qish va uni aniq muvaffaqiyatsiz systemd unit’i bilan bog'lash;
  • Serverni mustahkamlash (hardening) maqolasiga tayanib, firewall qoidasi uchun nega ufw enable dan oldin SSH allow qoidasini tasdiqlash kerakligini ovoz chiqarib tushuntirish.

Agar ulardan birortasi ishonchsiz tuyulsa, tegishli maqolani — ularning ko'pchiligiga yuqorida bevosita havola berilgan — lab’lar modulidan oldin ikkinchi marta o'qib chiqishga arziydi. Chunki u modul bu modul materialini qaytadan o'rgatmaydi, balki uni ishlaydigan poydevor deb hisoblaydi.

Keng tarqalgan xatolar

  • Container aslida nima ekanini avval tushunmasdan Kubernetes YAML sintaksisini o'rganish. Yuqorida ko'rsatilganidek, ko'pchilik haqiqiy Kubernetes troubleshooting'i oxir-oqibat shu modulning oldingi qismidagi container va kernel asoslariga qaytib keladi. Ularni o'tkazib yuborish orkestrator darajasidagi har qanday debug qilish qanchalik chuqur bora olishiga chegara qo'yadi.
  • Ostida ishonchli, idempotent IaC bo'lmasdan GitOps vositalarini joriy qilish. GitOps kerakli holatni uzluksiz qo'llashni avtomatlashtiradi. U ishonchsiz yoki idempotent bo'lmagan konfiguratsiyani tuzatmaydi — shunchaki o'sha ishonchsiz konfiguratsiyani tez-tez va kamroq inson tekshiruvi bilan qo'llaydi.
  • Sertifikatlarni noto'g'ri tartibda quvish. Mustahkam LFCS darajasidagi asoslarsiz CKA’ga urinish aynan yuqoridagi intervyu bo'limida tasvirlangan "orkestratorni biladi, OS’ni emas" bo'shlig'ini keltirib chiqaradi.
  • Bu modulni poydevor emas, marra chizig'i deb hisoblash. Container orkestratsiyasi, service mesh va GitOps’ning har biri o'z ko'p oylik o'rganish yo'nalishi bo'lishi uchun yetarlicha katta. Bu modulning vazifasi ularning hammasini to'liq qamrab olish emas, ularning ostidagi Linux zamini mustahkam ekanini ta’minlash edi.

Mashqlar

  1. Maqolaga qaytib qaramasdan, namespace nimani cheklashi va cgroup nimani cheklashi o'rtasidagi farqni o'z so'zlaringiz bilan tushuntiring, keyin javobingizni Namespaces va cgroups bilan solishtirib tekshiring.
  2. Yuqorida muhokama qilingan uchta sertifikatdan joriy maqsadlaringizga mos keladiganini tanlang va o'sha sertifikatning e’lon qilingan imtihon maqsadlariga nisbatan butun kursdan o'zingizni eng kam ishonchli his qiladigan uchta mavzuni sanab o'ting.
  3. GitOps ish jarayonini joriy qilish erta emas, xavfsiz keyingi qadam bo'lishi uchun (Infrastructure as Code asoslari dagi) IaC’ingiz haqida nima to'g'ri bo'lishi kerakligini qisqa paragrafda tasvirlab bering.
  4. LFCS lab’lari moduliga o'ting va birinchi troubleshooting vaziyatini maslahatlarsiz bajarib ko'ring. Agar biror oldingi maqolaga qaytishga to'g'ri kelgan bo'lsa, aynan qaysi biriga qaytganingizni yozib qo'ying.

Xulosa

Container orkestratsiyasi, GitOps va ular atrofida qurilgan sertifikat yo'llari bu kurs ko'rib chiqqan narsalardan alohida fan emas. Ular bu modul tartib bilan ko'rib chiqqan namespaces, cgroups, container’lar, IaC va CI/CD asoslari ustiga bevosita qo'yilgan avtomatlashtirish va masshtab. Ularning istalgan birini debug qilish oxir-oqibat o'sha poydevorga qaytib tusha olishni talab qiladi. Keyingi LFCS lab’lari — bu poydevor LFCS imtihonining o'zi foydalanadigan jonli tizimdagi, vazifaga asoslangan sharoitlarda bevosita sinovdan o'tkaziladigan joy.

Manbalar