Linux bulutda (cloud)

Bulut instansiyasi — AWS EC2 instansiyasi, Google Compute Engine VM’i, Azure VM’i, DigitalOcean droplet’i — provayderning dashboard’i va API’si ostida baribir SSH orqali ulanish mumkin bo'lgan, systemd ni ishga tushiradigan, journald ga yozadigan va block qurilmalarni aynan shu kurs davomida ko'rib chiqilganidek mount qiladigan Linux mashinasi. Haqiqatan farq qiladigan narsa — bu mashina qanday paydo bo'lishi va u o'zining kimligini qanday bilib olishi: hech kim konsol oldida o'tirib o'rnatuvchini ishga tushirmaydi. Bu maqola buni mumkin qiladigan ikki mexanizmni — metadata service va cloud-init ni — hamda instansiya to'xtatilgan (terminate qilingan) zahoti diski yo'qolishi mumkin bo'lgan serverdan kelib chiqadigan kichik amaliyotlar to'plamini ko'rib chiqadi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• instance metadata service nima ekanini tushuntirish va unga ishlab turgan instansiya ichidan so'rov yuborish;
• yangi instansiyani birinchi yuklanishda sozlaydigan cloud-init user-data skriptini o'qish va yozish;
• bir martalik (ephemeral) instansiya xotirasini doimiy block xotiradan farqlash va ular orasidan to'g'ri tanlash;
• SSH kalitlarini tayyorlash va IAM rollari haqida shu kursda allaqachon ko'rib chiqilgan autentifikatsiya va avtorizatsiya tushunchalarining bulutga xos kengaytmalari sifatida mulohaza yuritish;
• to'g'ri yuklanmayotgan bulut instansiyasini cloud-init ning o'z log'lari yordamida diagnostika qilish.

Metadata service: instansiya o'zi haqida qanday bilib oladi

Har bir yirik bulut provayderi faqat ishlab turgan instansiya ichidan ulanish mumkin bo'lgan HTTP endpoint’ni taqdim etadi. U instansiyaning o'zi haqidagi savollariga javob beradi: mening ommaviy IP’im qanday, qaysi SSH kalitlariga ishonish kerak, ishga tushirishda menga qanday user-data skripti berilgan. AWS, GCP va boshqa ko'pchilik provayderlarda u hammaga ma’lum link-local manzil — 169.254.169.254 da joylashgan:

curl -s http://169.254.169.254/latest/meta-data/

ami-id
hostname
instance-id
instance-type
local-ipv4
public-ipv4
public-keys/

curl -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... my-launch-key

Bulut konsolida tanlagan SSH kalitingiz hech kim ~/.ssh/authorized_keys ni qo'lda tahrirlamasdan yangi instansiyada qanday ruxsat etilgan bo'lib qolishi aynan shu bilan izohlanadi. Birinchi yuklanish skripti (keyingi bo'limda ko'rib chiqiladi) aynan shu qiymatni metadata service’dan oladi va uni tegishli foydalanuvchining authorized_keys fayliga yozadi. Bu SSH kalit autentifikatsiyasi maqolasida klient tomonidan ko'rib chiqilgan o'sha mexanizm.

cloud-init: yangi instansiyani birinchi yuklanishda sozlash

cloud-init — amalda standart vosita bo'lib, deyarli har bir bulut provayderi beradigan Ubuntu, Debian va RHEL oilasi image’larida standart holatda mavjud. U foydalanuvchi ishga tushirish paytida bergan konfiguratsiyani qo'llash uchun instansiyaning eng birinchi yuklanishida bir marta ishlaydi. Foydalanuvchi bergan bu konfiguratsiya user-data deb ataladi va u yuqorida tasvirlangan metadata service’dan olinadi.

#cloud-config
hostname: web-01
package_update: true
packages:
  - nginx
  - fail2ban
users:
  - name: deploy
    groups: sudo
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... deploy@laptop
runcmd:
  - systemctl enable --now nginx
  - systemctl enable --now fail2ban

Har bir maydon shu kursning boshqa joylarida allaqachon ko'rib chiqilgan administratsiya vazifalariga bevosita mos keladi, faqat ular qo'lda emas, avtomatik qo'llaniladi:

• hostname mashina nomini o'rnatadi — shu kursning boshqa joylarida hostnamectl bilan qo'lda o'rnatilgan o'sha qiymat;
• users va ssh_authorized_keys akkaunt va uning ishonchli kalitini Foydalanuvchi va guruh hisoblari hamda SSH kalit autentifikatsiyasi maqolalarida qo'lda qilish ko'rsatilgandek tayyorlaydi;
• packages va runcmd servislarni interaktiv apt install va systemctl enable --now qilgandek o'rnatadi va ishga tushiradi.

Amaliy qiymat bu yerdagi biror qadam yangi ekanida emas. Qiymat shundaki, bir xil sozlangan serverlarning butun parkini bitta fayldan, hech qanday qo'lda aralashuvsiz ishga tushirish mumkin. Bu keyingi maqola quradigan Infrastructure as Code amaliyotlarining bevosita zaruriy sharti.

cloud-init’ning o'z log'larini o'qish

Yangi ishga tushirilgan instansiya uning user-data’sida tasvirlanganidek ko'tarilmasa, ilova yoki systemd ning o'zi aybdor deb taxmin qilishdan ancha oldin birinchi va eng bevosita tekshiriladigan joy — cloud-init’ning o'z log'lari:

sudo cloud-init status --long

status: done
boot_status_code: enabled-by-generator
detail:
DataSource: DataSourceEc2Local

sudo cat /var/log/cloud-init-output.log

/var/log/cloud-init-output.log cloud-init bajargan har bir qadamning birlashtirilgan stdout/stderr’ini tartib bilan yozib oladi. User-data’dagi noto'g'ri YAML chekinishi (juda keng tarqalgan xato), o'rnatilmagan paket yoki xato bergan runcmd qadami — hammasi shu yerda, odatda aynan muvaffaqiyatsiz bo'lgan qator raqami yoki buyruq bilan ko'rinadi.

cloud-init’ning ikkita log'i bor va qaysi biri nima ekanini bilish haqiqiy debug vaqtini tejaydi. /var/log/cloud-init-output.log (yuqorida) — cloud-init bajargan buyruqlarning stdout/stderr’i, ya’ni paket o'rnatish yoki runcmd aslida nima chiqargani. /var/log/cloud-init.log esa cloud-init’ning u o'tgan har bir bosqich haqidagi o'z ichki, vaqt belgili debug log'i bo'lib, ancha nozikroq darajada yoziladi. cloud-init-output.log qadam muvaffaqiyatsiz bo'lganini ko'rsatsa-yu, nega ekanini aniq ko'rsatmasa, ichki tafsilotlar — qaysi datasource ishlatilgani, qaysi modul xato bergani va aynan qaysi bosqichda — /var/log/cloud-init.log da yozilgan bo'ladi.

sudo cloud-init schema --config-file /etc/cloud/cloud.cfg.d/99-user-data.cfg

User-data’ning YAML sxemasini undan instansiya ishga tushirishdan oldin tekshirish ko'pchilik sintaksis xatolarini ishga tushirish yarim yo'lda jimgina muvaffaqiyatsiz bo'lgandan keyin emas, darhol ushlaydi.

Bir martalik va doimiy xotira: haqiqiy oqibatlari bor qaror

Bulut instansiyalari odatda xotiraning ikkita aniq toifasini taklif qiladi va ularni chalkashtirish yangi bulut administratori qilishi mumkin bo'lgan eng og'ir oqibatli xatolardan biri:

lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0  50G  0 disk

AWS’da xvda/nvme0n1 (root qurilma) odatda boot volume bo'lib, standart holatda EBS’ga asoslangan va doimiy bo'ladi. Alohida ulangan qo'shimcha volume’larni (bu yerda xvdf) esa ishga tushirish paytida aslida nima so'ralganiga qarab alohida tekshirish kerak. Provayder konsoli yoki CLI’si (aws ec2 describe-volumes, gcloud compute disks list) — ishonchli manba, chunki qurilma nomining o'zi uning saqlanish kafolatlarini ochib bermaydi.

IAM rollari: ichiga joylangan credential’larsiz avtorizatsiya

Bulut platformalari Eng kam imtiyoz (least privilege) maqolasidagi avtorizatsiya tushunchalarini instansiya darajasiga IAM rollari orqali kengaytiradi (AWS/GCP atamasi; Azure ekvivalentini "managed identity" deb ataydi). Ilovaning konfiguratsiya fayli ichiga uzoq muddatli API kalitini joylash o'rniga instansiyaga rol biriktiriladi va shu instansiyada ishlayotgan har qanday jarayon metadata service’dan — yuqorida SSH kalitlari uchun so'rov yuborilgan o'sha endpoint’dan — qisqa muddatli, avtomatik almashinadigan credential’larni so'rashi mumkin.

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/my-instance-role

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-07-29T18:00:00Z"
}

Bu yerda qaytarilgan credential’larning muddati tugaydi (Expiration maydoni), odatda bir necha soat ichida. Bu konfiguratsiya fayliga qattiq yozilgan statik, uzoq muddatli API kalitiga nisbatan bevosita yaxshilanish. Chunki bunday kalitning muddati o'z-o'zidan hech qachon tugamaydi va oshkor bo'lsa, kimdir payqab, uni qo'lda bekor qilmaguncha amal qilib turaveradi. Bu shu kursda allaqachon ko'rib chiqilgan eng kam imtiyoz tamoyilining bulutga xos ekvivalenti: instansiyaga biriktirilgan IAM rolini uning ish yukiga aynan kerak bo'lgan ruxsatlar bilan cheklang, undan kengroq emas. Eng kam imtiyoz (least privilege) maqolasi xuddi shu g'oyani Linux foydalanuvchi akkauntining sudo qoidalari uchun aynan shunday bayon qiladi.

Keng tarqalgan xatolar

• IAM roli o'rniga bulut credential’larini ilovaga qattiq yozish. Bu IAM rollari yo'q qilish uchun mavjud bo'lgan aynan o'sha uzoq muddatli, almashtirilmaydigan secret xavfini qaytaradi va bulutga deploy qilingan ilovalarning haqiqiy xavfsizlik auditlarida odatiy topilma.
• Holatni saqlaydigan ma’lumotlarni "vaqtincha" bir martalik xotiraga joylashtirib, birinchi to'xtatish/terminate hodisasidan oldin ko'chirishni unutish. Yuqorida ko'rib chiqilganidek, bu keyinchalik tuzatib bo'ladigan xato emas.
• Birinchi yuklanish konfiguratsiyasi muvaffaqiyatsiz bo'lganini avval /var/log/cloud-init-output.log ni o'qish o'rniga SSH orqali kirib, taxmin qilib debug qilish. Log deyarli har doim muvaffaqiyatsiz bo'lgan aniq qadamni to'g'ridan-to'g'ri nomlab beradi.
• Ishonchsiz kirish ma’lumotlarini qabul qiladigan biror ilova ishlayotgan instansiyada IMDSv1 (yoki mustahkamlanmagan ekvivalent)ni maqbul deb hisoblash. Yuqorida ko'rib chiqilganidek, bu nazariy tashvish emas, hujjatlashtirilgan va amalda foydalanilgan attack surface.

Mashqlar

1. Lab instansiyasida (yoki sinov uchun cloud-localds orqali cloud-init o'rnatilgan mahalliy VM’da) instansiyaning o'z hostname’i va ommaviy kaliti uchun metadata service’ga so'rov yuboring va bu ikki qiymat u yerga qanday kelib qolganini tushuntiring.
2. root bo'lmagan sudo foydalanuvchisini yaratadigan, nginx ni o'rnatadigan va ishga tushiradigan cloud-init user-data faylini yozing. Keyin ataylab YAML chekinish xatosini kiriting va natijada yuzaga kelgan muvaffaqiyatsizlikni topish uchun cloud-init-output.log dan foydalaning.
3. Haqiqiy yoki lab bulut instansiyasida lsblk ni ishga tushiring va provayder hujjatlaridan foydalanib, ro'yxatdagi qaysi qurilmalar bir martalik, qaysilari doimiy ekanini aniqlang. Hech qachon ishlatmagan provayderda buni qanday aniqlagan bo'lardingiz, tushuntiring.
4. IAM rolining vaqtinchalik credential’lari muhit o'zgaruvchisida saqlangan statik API kalitidan nega yaxshiroq xavfsizlik holati ekanini oldingi moduldagi eng kam imtiyoz tamoyili bilan bog'lab, ikki-uch jumlada tushuntiring.

Xulosa

Bulut instansiyasi — o'z kimligi va konfiguratsiyasini metadata service orqali bilib oladigan va birinchi yuklanishda shu service’ning user-data’sini o'qiydigan cloud-init orqali o'zini sozlaydigan oddiy Linux mashinasi. Bu shu kurs davomida ko'rib chiqilgan o'sha administratsiya vazifalari (foydalanuvchilar, SSH kalitlari, paketlarni o'rnatish, servislarni ishga tushirish), faqat qo'lda emas, avtomatlashtirilgan va ishga tushirish paytida qo'llanilgan holda. Bir martalik instansiya xotirasi va doimiy block xotira juda boshqa-boshqa saqlanish kafolatlariga ega va ular ongli ravishda tanlanishi kerak. IAM rollari esa statik, uzoq muddatli credential’larni qisqa muddatli, avtomatik almashinadiganlariga almashtirib, eng kam imtiyoz tamoyilini bulut API’siga kirishga kengaytiradi. Infrastructure as Code asoslari xuddi shu cloud-init user-data tushunchasini olib, uni butun infratuzilma parkini versiyalangan, takrorlanadigan konfiguratsiya sifatida e’lon qilishgacha umumlashtiradi.

Manbalar

• AWS hujjatlari: Instance metadata and user data
• cloud-init hujjatlari
• Google Cloud hujjatlari: Storing and retrieving instance metadata
• AWS hujjatlari: IAM roles for Amazon EC2