Ide besar seputar unikernels

Ide besar seputar unikernels

Tahukah Anda bahwa Linux mendekati usia 30 tahun? Tahukah Anda bahwa Unix berusia sekitar 50 tahun? Saya tidak bermaksud menjatuhkannya — saya telah menggunakan Linux sejak mereka didistribusikan di disket. Namun, Unix dibuat untuk mesin seperti PDP-7 — Anda tahu, jenis yang memenuhi seluruh dinding.

PDP-7 – komputer mini yang diproduksi oleh Digital Equipment Corporation

Tapi, pernahkah Anda bertanya-tanya seperti apa sistem operasi yang dibangun pada tahun 2022?

Hari ini, infrastruktur cloud sangat kompleks sehingga orang-orang devops/SRE menarik gaji yang terkadang melebihi insinyur perangkat lunak normal.

Keamanan siber sangat buruk sehingga setidaknya ada satu pelanggaran data besar setiap minggu sekarang. Jika Anda melihat bot penambang kripto ilegal yang menginfeksi k8s cluster, mereka benar-benar memiliki kode yang memburu bot lain dan mengusir mereka dari server sebelum melakukan hal lain. Bot sedang berperang – itulah keadaan keamanan siber kami.

Jujur, bagus bahwa Hollywood bukanlah kehidupan nyata karena semua masalah keamanan siber bahkan tidak mendekati seberapa buruk hal-hal yang sebenarnya bisa terjadi. Ini tidak seperti seseorang yang telah meretas pembangkit listrik tenaga nuklir sebelumnya — *batuk*.

Unikernel bisa cepat

Kami menjalankan situs web seperti ops.city dan nanos.org sebagai unikernels Go di Google Cloud. Kami secara rutin melakukan benchmark server web yang berjalan 2X lebih cepat di Google dan 3X lebih cepat di AWS.... Kami telah mencatat hal-hal seperti Redis mendorong rata-rata 20% lebih banyak pada alat benchmarknya.

Angka tidak berbohong.

...
Buka Webserver di Nanos vs Debian 10 “Buster” Linux di GCP G1-Small

Tidak ada algoritme khusus yang digunakan di sini – hanya arsitektur yang memungkinkan hal ini terjadi. Beberapa orang bertanya apakah Anda bisa menggunakan sesuatu seperti Alpine dan mendapatkan hasil yang sama. Sayangnya, jawabannya tidak. Linux seperti 30 juta baris kode dan tidak semuanya dapat dikecualikan dengan membuat kernel khusus.

Misalnya, ketika Anda menghapus hal-hal seperti dukungan beberapa proses, Anda mulai melihat betapa menularnya dukungan itu sebenarnya . Yang menyentuh penjadwal, yang menyentuh memori bersama, yang menyentuh sinyal, yang menyentuh banyak hal, jadi itu bukan sesuatu di mana Anda bisa masuk dan ifdef/menambalnya. Demikian pula, seccomp juga tidak melakukan semua yang kita inginkan.

Unikernel juga dapat boot dengan cepat. Ini adalah poin yang aneh untuk dibuat, karena hal-hal seperti Petasan biasanya muncul di benak orang ketika disebutkan. Namun, unikernels mengekspos keanehan menarik lainnya yang tidak akan pernah Anda lihat sebelumnya saat Anda menerapkannya. Misalnya, kami membuat server web Rust kecil yang ada di Google dan menyuntikkan kerusakan pada setiap permintaan. Itu akan segera reboot, siap untuk melayani permintaan berikutnya secara instan. Namun, setiap kali reboot itu datang dengan penyebab tata letak memori baru ASLR, yang dari perspektif keamanan sangat menarik. Itu salah satu cara untuk benar-benar mengacaukan kepala penyerang!

Sejujurnya, kami bahkan belum melakukan hal-hal keren dengan unikernels. Bayangkan jika Anda dapat menyetel unikernel Anda tergantung pada apakah jaringan berat atau sistem file berat. Bayangkan betapa lebih mudahnya penenunan biner dan penghapusan kode mati otomatis dalam sistem seperti itu. Beberapa aplikasi suka menautkan ke setiap perpustakaan di bawah matahari bahkan jika mereka hanya menggunakan satu fungsi darinya.

Unikernel memberi kita peluang bagus untuk melakukan beberapa sudah lama tertunda pembersihan rumah.

Unikernel diisolasi

Isolasi unikernelslah yang membuat saya tertarik, datang dari industri keamanan. Tidak ada pengguna atau kata sandi – menarik. Tidak ada cangkang. Tidak ada login jarak jauh atau ssh. Lebih penting lagi, unikernels hanya dapat menjalankan satu dan hanya satu aplikasi per VM. Jadi itu berarti dalam tumpukan server web khas Anda, Anda memiliki satu VM sebagai server web yang sebenarnya dan satu lagi untuk database Anda (Anda mungkin sudah melakukan ini).

Konsep ini jauh lebih dalam. Ketika Anda berpikir tentang penyerang yang membobol server Anda, itu persis seperti perampok yang membobol rumah Anda. Mereka masuk dengan menendang pintu atau memecahkan jendela tapi bukan itu mengapa mereka mendobrak masuk rumah. Mereka datang untuk senjata, perhiasan, uang, dan TV layar datar. Untuk hacker, itu sama. Memecah perangkat lunak Anda dengan mengeksploitasi bug hanyalah cara untuk masuk ke server. Itulah sebabnya manajemen patch dan pemindaian kerentanan tidak benar-benar mengurangi jumlah pelanggaran keamanan dalam berita.

Tujuan akhir penyerang adalah untuk menjalankan program mereka – mereka tidak peduli dengan program Anda. Program-program tersebut dapat dijalankan mysqldump... terhadap database Anda, atau mungkin menginstal penambang kripto. Terlepas dari itu, selalu ada bagian lain dari perangkat lunak - biasanya banyak perangkat lunak. Itu sebabnya sebagian besar eksploitasi memfokuskan kode shell mereka pada forking shell. Sebuah shell secara inheren dibangun untuk menjalankan banyak program. Saat Anda mengetik ...ls..., ...ps aux..., atau ...cd

 Anda memanggil perintah itu, tetapi itu adalah program lain.  Tidak ada yang berfungsi di tanah unikernel....

Jadi, meskipun Anda mungkin dapat memperoleh penggunaan beberapa memori pada perangkat lunak yang rentan, Anda mungkin sekarang mengalami kesulitan untuk melakukan sesuatu yang berguna dengannya. Adakah yang pernah melihat klien MySQL yang ditulis dalam gadget ROP murni?

Unikernel itu sederhana

Dekade terakhir telah melihat infrastruktur besar-besaran merayap dan meskipun mudah untuk menyalahkan alat, perusahaan menerbitkan sejumlah besar perangkat lunak sekarang.

Jadi, seberapa sederhana? Anda dapat mendorong aplikasi Anda ke Google Cloud hanya dengan dua perintah. Kumpulan perintah yang sama ini hanya membutuhkan ~20 detik sebelum situs Anda ditayangkan di AWS:

 ops image create -c config-prod-myapp.json myapp -i myapp -t gcp -z us-west2-a instance ops create myapp -c config -prod-myapp.json -z us-west2-a -d myapp.com -t gcp 

Saat pertama kali diperkenalkan dengan unikernels, banyak orang bertanya-tanya, “Di mana Kubernetes untuk mengatur unikernels? Apakah saya harus menginvestasikan semua waktu dan energi ini untuk mempelajari hal lain?” Jawabannya adalah tidak ada, dan tidak perlu ada. Mengapa? Saat kami menerapkan unikernels ke AWS atau Google, kami membuat AMI baru setiap kali Anda menekan tombol penerapan (jangan khawatir, seluruh proses dapat memakan waktu kurang dari 20 detik). VM tidak menginstal Linux sama sekali - itu hanya aplikasi Anda. Perangkat penyimpanan dan jaringan yang mendasari semuanya ditangani oleh cloud pilihan Anda, jadi saat Anda dapat mengonfigurasinya, Anda tidak perlu mengelolanya. Ini adalah perbedaan yang signifikan. Anda dapat menganggapnya sebagai tanpa server tanpa penguncian karena perintah yang sama berfungsi pada penyedia cloud mana pun di luar sana. Dengan mengalihkan beban tanggung jawab ini ke penyedia cloud, Anda memaksa cloud untuk melakukan yang terbaik (mengelola infrastruktur), dan Anda melakukan yang terbaik (mengelola aplikasi Anda).

Hal ini membuat mendorong aplikasi Anda untuk mendorong dengan sangat mudah.

Jika aplikasi mogok (yang terjadi pada setiap pengembang perangkat lunak di luar sana, tidak peduli seberapa bagus mereka), seluruh VM akan mogok. Yang menarik dari debugging ini adalah sebenarnya jauh lebih mudah untuk di-debug daripada sistem Linux. Mengapa? Karena hanya ada satu program yang dimaksud. Anda tidak mencambuk ... lsof

 untuk mencari tahu proses apa yang memuntahkan koneksi sampah atau proses mana yang tidak memiliki pengaturan rotasi log yang tepat dan mencegah Anda memasukkan SSH ke dalam instance. layanan pemantauan Radar kami cukup banyak sebelumnya.  Makan dogfood kami sendiri dan menjalankannya sebagai unikernel Nanos memungkinkan kami untuk menghitung banyak masalah.  Bug jaringan, bug penyimpanan, semuanya berfungsi.  Itu sebabnya kami tahu ini berfungsi dengan baik sekarang karena kami harus masuk dan memperbaiki banyak bug.  Namun, ketika macet, kami dapat dengan mudah mengekspor gambar VM dan mengunduhnya secara lokal dan menjalankannya.  Kami dapat melampirkan ...gdb
 padanya dan menunjukkan secara langsung di mana itu mengalami masalah.  Kami juga dapat mengekspor jejak tumpukan.  Anda benar-benar dapat mengkloning VM ini di prod, secara real-time tanpa downtime, dan bermain-main dengan klon juga.  Saya dapat membayangkan segala macam hal menarik yang dapat Anda lakukan selain men-debug dengan fungsionalitas seperti itu. 

Saya ingat waktu lain kami men-debug masalah jaringan di Google. Seseorang telah melaporkan situs kami tidak muncul untuk mereka, tapi itu muncul untuk kami. Aneh. Ternyata MTU diatur ke nomor yang berbeda. Kami dapat menemukan masalah dengan mudah dan memperbaiki tumpukan TCP/IP.

Unikernel jauh lebih mudah untuk di-debug daripada sistem Linux normal.

Virtualisasi, SMP, dan ledakan teknologi kedua

Paradigma lama satu server dengan satu sistem operasi yang menampung banyak aplikasi tidak masuk akal lagi.

Jika Anda bekerja di perusahaan yang lebih dari 10 atau 20 orang, Anda tidak memiliki satu server. Anda memiliki banyak server. Jika Anda bekerja di perusahaan seperti Uber atau Airbnb, Anda tidak memiliki satu database. Anda memiliki ribuan database. Itu ribuan sistem operasi yang harus dikelola juga.

Ingat grafik ini?

Do you remember this graphic?

Google menulis makalah, lalu menulis makalah lain, dan banyak lagi makalah kemudian akhirnya menulis sebuah buku yang pada dasarnya mengatakan bahwa pusat data adalah komputer seukuran gudang.

Ide besar seputar unikernels, setidaknya dalam hal cloud, adalah bahwa jika pusat data adalah komputer, maka cloud adalah sistem operasinya... — jadi mari kita mulai memperlakukannya seperti satu dan berhenti mengelola mikro ribuan individu.



Siap menjalankan unikernel pertama Anda? Lihat ops.city dan nanos.org. Tidak ada cara yang lebih baik untuk memahami apa ini dan bagaimana cara kerjanya selain mencobanya.


Baca selengkapnya