თუ რამე წაგიკითხავთ AI-ის მიერ გენერირებული კოდის უსაფრთხოდ გაშვებაზე, სიტყვა microVM გინახავთ, ჩვეულებრივ Firecracker-ის გვერდით. მას ჩვეულებრივ ხსნიან ან როგორც „მსუბუქ ვირტუალურ მანქანას“ (სიმართლეა, მაგრამ უსარგებლო), ან ბირთვის შიგნეულობის დიაგრამით. აქ არის შუალედური ვერსია.
ორი ძველი ვარიანტი და რატომ არცერთი არ ერგება
დავიწყოთ იმ ორი რამით, რომელთა შორისაც microVM დგას.
კონტეინერი თქვენს მანქანაზე ჩვეულებრივი პროცესების ჯგუფია, რომლებსაც ბირთვი „მოტყუებაზე“ დასთანხმდა. namespaces მათ საკუთარ ფაილურ სისტემას, პროცესების სიასა და ქსელს აჩვენებს; cgroups ზღუდავს, რამდენი CPU და მეხსიერება შეუძლიათ გამოიყენონ. ის მილიწამებში ირთვება, რადგან არაფერი ახალი არ იტვირთება. მაგრამ ჰოსტზე ყველა კონტეინერი ერთსა და იმავე ბირთვს ესაუბრება. ბირთვის ხარვეზი, რომელიც ერთი კონტეინერიდან მიღწევადია, ყველა მათგანიდან გასასვლელია.
ვირტუალურ მანქანას თავისი ბირთვი მოაქვს. ჰოსტის CPU აპარატურული ვირტუალიზაციის (Linux-ზე KVM) მეშვეობით სტუმარს ისე უშვებს, თითქოს მას საკუთარი კომპიუტერი ჰქონდეს. საზღვარი ჰიპერვიზორია, რომელიც ბირთვის ასობით სისტემურ გამოძახებაზე გაცილებით ნაკლებს ააშკარავებს. ფასი სიმძიმეა. კლასიკური ვირტუალური მანქანა მთელ PC-ს ემულირებს: ფირმვეარს, PCI სალტეს, USB კონტროლერებს, ვიდეობარათს, ზოგჯერ ხმის ბარათსაც. ის ამ ყველაფრის გავლით ირთვება, წამებიდან წუთებამდე სჭირდება და თითოეულ ეგზემპლარს ათეულობით ან ასეულობით მეგაბაიტი ზედნადები აქვს.
ანალოგია, რომელიც საკმაოდ კარგად მუშაობს: კონტეინერები ერთი შენობის ბინებია, საერთო საძირკვლით, მილებითა და გაყვანილობით. ვირტუალური მანქანები ცალკე სახლებია. სახლები უფრო უსაფრთხო მეზობლებია, მაგრამ 20-წამიანი სტუმრობისთვის სახლს არავინ აშენებს.
რას აშორებს Firecracker
Firecracker არის virtual machine monitor (პროგრამა, რომელიც KVM-ის თავზე ვირტუალურ მანქანას აწყობს და უშვებს), დაწერილი Rust-ზე და ღია კოდით 2018 წლიდან. ის ერთი საქმისთვის შეიქმნა: საერთო აპარატურაზე ერთმანეთისადმი უნდობელი, ხანმოკლე დატვირთვების უზარმაზარი რაოდენობის გაშვება. ამას ძირითადად რაღაცების წაშლით აღწევს:
- არც ფირმვეარი, არც აპარატურის აღმოჩენა. ბირთვი პირდაპირ მეხსიერებაში იტვირთება და ეშვება. არაფერი ეძებს მოწყობილობებს, რომლებიც არ არსებობს.
- პაწაწინა მოწყობილობების მოდელი. ქსელის ბარათი, ბლოკური მოწყობილობა, სერიული კონსოლი და კიდევ რამდენიმე, ყველა virtio (ვირტუალური მანქანებისთვის შექმნილი მოწყობილობები და არა ფიზიკურის იმიტაცია). არც USB, არც გრაფიკა, არც PCI.
- პატარა, მეხსიერების მხრივ უსაფრთხო კოდის ბაზა. ნაკლები კოდი, რომელიც მოწყობილობებს ემულირებს, ნიშნავს ნაკლებ ადგილს ხარვეზისთვის, რომელიც სტუმარს ჰოსტამდე მიუშვებს.
- გალია თავად VMM-ის გარშემო. Firecracker-ის ყოველი პროცესი chroot-ში მუშაობს, seccomp ფილტრებით, რომლებიც მის სისტემურ გამოძახებებს ზღუდავს, და cgroups-ით, რომლებიც მის რესურსებს ზღუდავს. სტუმრიდან რამე რომ გამოსულიყო, ჰოსტზე კი არა, გალიაში აღმოჩნდებოდა.
ციფრები, რომლებსაც თავად პროექტი აქვეყნებს: მომხმარებლის სივრცე სულ რაღაც 125 ms-ში და 5 MiB-ზე ნაკლები მეხსიერების ზედნადები თითო microVM-ზე. ეს ლაბორატორიის საუკეთესო მაჩვენებლებია; ნამდვილ sandbox-ს ასევე სჭირდება დისკისა და ქსელის მომზადება და შიგნით აგენტი, რომელიც ბრძანებების მისაღებად მზადაა, ამიტომ ჩვენი დაახლოებით ერთ წამში მზადდება. ეს მაინც საკმარისად ახლოსაა კონტეინერის სიჩქარესთან, რომ ყოველი ამოცანისთვის ერთი შექმნათ და შემდეგ გადააგდოთ.
კონტეინერი თუ microVM პრაქტიკაში
| კონტეინერი | Firecracker microVM | |
|---|---|---|
| ბირთვი | ჰოსტთან საერთო | საკუთარი |
| საზღვარი ჰოსტთან | სისტემური გამოძახებები საერთო ბირთვში | ჰიპერვიზორი + პატარა VMM |
| ჩართვის დრო | მილიწამები | ~0.1–1 წმ |
| ზედნადები ეგზემპლარზე | ძალიან მცირე | რამდენიმე MiB |
| მოწყობილობები | რასაც ჰოსტი ააშკარავებს | ქსელი, დისკი, კონსოლი |
| GPU | შესაძლებელია | არა |
| კარგია | სანდო კოდისთვის, აპების შეფუთვისთვის | არასანდო კოდისთვის, მრავალმოიჯარიანი დატვირთვებისთვის |
მნიშვნელოვანი მეორე სტრიქონია. კონტეინერის შემთხვევაში კითხვა „შეუძლია ამ კოდს გაქცევა?“ ხდება „არის თუ არა ჰოსტის ბირთვში სადმე მიღწევადი ხარვეზი?“. microVM-ის შემთხვევაში კი — „არის თუ არა ხარვეზი ჰიპერვიზორში ან რამდენიმე ვირტუალურ მოწყობილობაში?“. მეორე ზედაპირი გაცილებით პატარაა და სწორედ მას იცავენ ღრუბლოვანი პლატფორმები საკუთარი მრავალმოიჯარიანი ჰოსტინგისთვის.
რაზე ამბობთ უარს
microVM უფასო განახლება არ არის.
- არც GPU, არც ეკრანი. ის კოდის გასაშვებადაა, არა დესკტოპებისა ან გრაფიკული დატვირთვებისთვის.
- ნაკლები მოწყობილობა, ნაკლები მოქნილობა. ყველაფერი, რაც ნამდვილ აპარატურას ან ბირთვის მოდულების გრძელ სიას ელის, აქ თავს კომფორტულად ვერ იგრძნობს.
- საზღვრებს მაინც პოლიტიკა სჭირდება. microVM ღია გამავალი ტრაფიკით მაინც შეძლებს ისეთი ტრაფიკის გაგზავნას, რომელიც არ გინდათ; ის, რომელშიც თქვენი API გასაღებებია, მაინც შეძლებს მათ გაჟონვას. იზოლაცია ჰოსტს იცავს სტუმრისგან და არა თქვენს საიდუმლოებებს კოდისგან, რომელსაც თავად გადაეცით ისინი.
როგორ იყენებს ამას ჩვენი sandbox-ები
ყოველი EQVPS sandbox ერთი Firecracker microVM-ია საკუთარი ბირთვით, 0.25 vCPU-სა და 512 MB-დან 8 vCPU-სა და 16 GB-მდე. მას მოყვება Python 3.12, Node.js 22, bash, git და curl, აქვს გამავალი ინტერნეტი და არ აქვს შემომავალი პორტები. დროებითი sandbox-ები იშლება, როცა დაასრულებთ; persistent-ები ინახავს თავის დისკს, ხოლო პაუზა microVM-ის სნეპშოტს დისკზე წერს, ასე რომ, გაგრძელებამდე არაფერი ღირს. დაპაუზებული სნეპშოტები 14 დღე ინახება. ამის შემდეგ sandbox იშლება და მისი id აბრუნებს 410 sandbox_deleted-ს.
კონტეინერების ნაცვლად microVM ერთი მიზეზით ავირჩიეთ: sandbox-ში გაშვებული კოდი, ჩანაფიქრით, ისეთი კოდია, რომელიც არავის გადაუხედავს. AI აგენტის შედეგი, უცნობის pull request, მოდელის მიერ დაწერილი ათასი პროგრამის ბენჩმარკი. ამისთვის საკუთარი ბირთვი ის საზღვარია, რომლის ფასის გადახდაც ღირს. იმის დეტალები, რაც მის გარშემო ავაწყვეთ — ტარიფები, კვოტები, 55-წამიანი ლიმიტი სინქრონული ბრძანებებისთვის — sandbox-ების დოკუმენტაციაშია.
თუ გსურთ ეს საზღვარი სხვა ვარიანტებს უფრო სიღრმისეულად შეადაროთ, იზოლაციის დონეები არასანდო კოდისთვის პროცესებს, კონტეინერებს, microVM-ებსა და სრულ ვირტუალურ მანქანებს გვერდიგვერდ აყენებს. ხოლო თუ წამობრივმა ფასმა მიიპყრო თქვენი ყურადღება, როგორ მუშაობს სინამდვილეში წამობრივი ბილინგი გამოთვლებს აჩვენებს.
კომენტარები
ჯერ არ არის კომენტარები. იყავით პირველი.