Programming ∀

Endi sekin directionchani olib manashu concept ustida ishlayman. O'ylaymanki bu ideyalar DevOpslar uchun yoqimli ergonomik tilda ishlash imkoniyatiga sabab bo'ladi. Shu sababdan IaC mavzusida sizlarni nimalar qiynasa uyalmasdan aytaveringlar 🙂

imports {
  DebianConfs,
  RedhatConfs
}

type OS = Debian | RedHat

configurations Debian = DebianConfs
configurations RedHat = RedhatConfs

Haskellga o'xshab qoldi-a )) Hullas bu masalada ancha ideyalar kelyabti.

imports {
  DebianConfs,
  RedhatConfs
}

type OS = Debian | RedHat

configurations = match os {
  Debian => DebianConfs
  RedHat => RedhatConfs
}

Bunisi esa rustga o'xshaydi. Qisqasi ADT va Patternmatch bo'lsa tassavur qiling siz Os tipiga yangi member qo'shsangiz compiler error beradi sababi uning configurationlarini defiine qilishiz shart. Bu esa manabunaqa holatlarda esdan chiqarmaslikga yordam beradi. Configlarni esa module qivolib bosaverasiz.

Barbir miyyada eslab qolishingiz kerak nima qo'shgan qo'shmaganizni.

Xitoyliklar qilayotgan kernel OSS ekanmi 🤔 Tushunishimcha rustda ekan to'liq. Bu mavzuda contextda borlar bilganlarizni ulashing ularni kerneli qanday ekani qiziq ))

Multi master k8sda etcd external etcd )) Manimcha ko'pchilik clusterni setup qilganida k8s componentlarga etibor qilmaydi, oqibatda biror muammo chiqsa qiynalib yuradi. Shaxsiyga manashunaqa masalada yozishgan edi. K8s eslab olishga biroz vaqt ketti va ohiri mana yechim. Multi master clusterda eng birinchi target etcdni external olib chiqamiz. Bu aynan etcd o'zi bilan direct ishlashga va kuberga bog'liq bo'lib qolmaslikga yordam beradi intensivlikni oshiradi. Mani tajribamda bunaqa yechim ko'proq foydali bo'lgan pod ichiga tiqanimdan ko'ra. Ammo support ham alohida bo'ladi... Qo'shimcha resurs: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

Haskell kundan kunga baqquvatlashib boryabti haliyam😎

Endi bu masla ham orzu havasda, kotta bollani jentrasiga o’xshgagan.

IAC maslasida qilgan researchlarimdan hulosa deyarli hamma platformlarda configuration qilish ancha noqulay, ayniqsa sizda juda ko'p serverlar va turli component va applicationlar bo'lsa hammasini code bilan manage qilishingiz azob undan azoblisi esa anashu stateni ushlab turish. Nix misolida immutable configlarni ko'rdik mana. Ammo serverlarga mos kelmaydigan joylari bor yani nix pull basedi ishlaydi. Agar manashu narsa push based ishlasachi ? Keyingi masala. Sevimli va qadrli kubernetes to'liq mutable infrastructure. Biz resource management uchun turli resoruce policylar qilib chiqamiz. Turli access controllar vaxakazo policylar qilamiz. Ho'sh bular aniq ishlashiga proof bormi ? Bu savol manda ochiq, hamma holatlar hisobga olingan deya olmayman. Chunki tajribamda man qilgan xatoni deb buzib qo'yganman ko'p narsani. Demak hammasini miyyamda ushlashim kerak. Ho'sh mani miyyamga qancha kubernetes configlari sig'adi ? Ko'p emas-a )) Sizga ham ko'p sig'maydi. Lekin bizda dokumentatsiya aynan shunga yoziladiku... deymiz ammo doyim doc va infrani birga olib yurmaymiz )) Demak bu narsani eslab qolishni yoki proof qilishni ham kuber hal etsin. Masalan trash-app pod uchun max 4G ram ajratishni so'rasam. Agar mumkin bo'lsa aniq ajratsin doyimiy va stabil. Agar bo'lmasa xatolik bersin clusterda buncha resurs yo'qligi haqida. Ahir nima uchun bechora devopslar hammasini kallasida ushlashi kerak? Nega hammasini duplicate qilishi kerak ? Agar hammasi bunday bo'lsa manavi ishlatilinyotgan tooling yanayam ko'p og'riqlarga sabab bo'lyabtiku ))

Agar qanaqadir hcl tushunadigan syntax analyserlar bo'lsa nechi % code duplication ekanini aniqlasa bo'ladi. DevOps stuffda juda ham ko'p muammolar bor, tassavur ham qilolmaysiz. Terraform nisbatan yaxshi narsa, ammo to'nnalab yozilgan yaml filelarni ko'rgan dasturchini mazasi qochadi. Umuman hamma narsalar taxta va bordak. Agar manashunaqa muammolar tog'irlansa bu soha vakillari anchagina baxtli bo'lishadi. O'ylashim bo'yicha bularni ham ma'lum darajada abstraction bilan osonlikcha boshqarsa bo'ladi. Juda ham ko'p automatinlar osongina bitib ketadi. Oldinlari compiler, interpreterlarga umuman language developmentga deyarli ish yo'q deb juda katta xato fikrlagan ekanman. Xozirda manabunaqa holatlarni ko'rib o'zim uchun notes yozib ketyabman skillarni oshirsam manashu muammolarni birortasini aniq hal etaman.

Qaranglar qancha code duplication bor🥲

Manashu narsaga pattern matching qo'sha.

resource "google_cloud_scheduler_job" "version_every_minute"{}

resource "google_cloud_scheduler_job" "version_every_two_minutes"{}

Manashunaqa qisqa va ergonomik code hosil bo'ladi.

resource "google_cloud_scheduler_job" (minutes){
    match minutes{
         "version_every_minute" {}
          "version_every_two_minutes" {}
    }
}

https://github.com/hashicorp/hcl/blob/main/hclsyntax/spec.md

Xojatxonaga ham laptop bilan kiradiganlarni kim ? A) Managerlar B) Project Managerlar C) Product managerlar

A) Quic sababli hamma yoqda muammo. B) Uzoffline sababdan muammo. C) Ikkala javob tog'ri.

Engineerlarni manashunaqa practicelarni qilishga majburlayman agar DevOps or SRE bo'lsam. Agar CTO bo'lsam FPga majburlayman🙂 Shu sabab oddiy backendchi bo'lib yashaganim afzal mansab tegsa o'zimdan ketib qolarkanman )) Ammo OTeL sizga ko'p yordam beradi ishonavering.

Jaeger V2 Unveiled: Distributed Tracing Powered by OpenTelemetry https://horovits.medium.com/jaeger-v2-unveiled-distributed-tracing-powered-by-opentelemetry-be612dbee774 #jaeger #opentelemetry #observability #tracing

Bitta spec qilib olib template based bosaverasiz. Ha boilerplate yaxshi practice emas. Ammo aynan IaC uchun expirement qilib ko'rmoqchiman. Chunki juda ham katta abstraction bo'lmaydi common usecaselarga mos specni o'zi bilan 95% hoaltni yopa olar ekanmiz. Endi shu boilerdan nima kutyabman aytaymi ? 1. Bizga task kelib tushganidan boshlab infrani yetkazib berish vaqtini qisqartirish. Common infralar va distrolar uchun. Expected avg time: 20-30m Ideal: 15m 2. Upgrade, reconfiguration maintenance. Update va upgradelar vaqt olishi mumkin + roolbacklar bilan. Expected avg time: 40m Ideal: 15-30m 3. Managing complexity, katta infra bo'lsa ham kichik bo'lsa ham birxil flowga tushaveradi. O'ylamaymanki bir vaqtning o'zida 1k inventory bo'lib ketadi deb. Kegin statistika bo'yicha juda ham ko'pchilik serverlar popular distrolarda ishlaydi. BSDlarni kamroq uchratasiz. Asosiy qiyinchlik inventory va infra uchun spec yozishda. 4. Spec va Infra docs va requirements bir biriga aniq mos bo'ladi. Faqat o'rtasidagi bog'liqlikni qurish kerak bunga ham yechimlar o'ylayabman. Agar manashu narsani amalga oshirolsam masalan N serverga nginx 1.26 versiya deb spec yozigan bo'lsa demak aniq manashu versiya bo'ladi ! Qog'ozbozlik va amaliyot consistent bo'ladi. 5. Pipelines, barcha infralar uchun alohida pipelinelar qursa bo'ladi yani bitta infra uchun firewall, iptables yana nimadirlar majburib bo'lsa prosto pipelinesga qo'shib ketasiz. PS: Hullas muammo chiqdimi hal qilish va xizmat ko'rsatish eng minimal vaqt oralig'ida bo'lishi kerak. Manashu main goal. Xizmat sifatini esa albatta kallada ushlamaymiz code bilan hal etamiz !

Ansibleni ham biroz odambashara qilib ishlatsa bo'ladi ekan. Hullas manashu yerdagi configlarimdan to'liq inventory generate qilsa bo'ladi )) 1. Yaml lint ishlatish required 2. Paybooklarni generic qilib olish kerek hammasini galxe bo'lsa ham. 3. Default installationlarga manashunga o'xshagan notation qilinsa kegin buni asosida sodda documentation generate qilsa bo'ladi. targets o'ylab topilgan iplar. PS: Expiremental Nix based yechimlar ham ketyabti paralellno. Nixda shunaqa narsalarni module qilib olib bosaverasiz 😊 Faqat Dilivery biroz muammoli, ansibleda push bo'lgani uchun deploy va roolback oson.

Boshlang'ich Dev*Opslar uchun tavsiya perf, tcpdump, iotop shu kabi toolar o'zi bilan ishlashni o'rganing oldin. Ko'pchilik manitoring dashboarlarni ochsa dovdirab qoladi kerak kerak emas narsalar uchun dashboard chizib tashlaydi. Yo'q unaqasi ketmaydi siz frontendchi emassiz dashboard chizib o'tiradigan har bir parametr sizga qanaqadir ma'lumot beradi, endi shu ma'lumot qanchalik o'rinli va foydali ekaniga qarab chizish kerak )) Bu yerda Perfomance Observability mavzusidan ko'p narsa bor. Monitoring uchun esa htop, iotop, iostat vaxakazolardan boshlasangiz bo'ladi. Shularni ishlatib ko'rsangiz boshida qiynalasiz ammo kegin ELK bo'ladimi Grafanami yana boshqasimi hammasini cook qilasiz )) ular oson bo'lib qoladi. https://www.brendangregg.com/linuxperf.html

Manashu narsa zo'rda, linuxda xclip prosto, ptosto 😁 Vault bilan hamma narsaning ham integratsiyasi bo'lmagani uchun haligacha keylarimni olib yuraman.