Beberapa orang mengatakan distribusi Linux tidak lagi penting dengan container. Pendekatan alternatif, seperti wadah distroless dan scratch, tampaknya menjadi hal yang populer. Tampaknya kita mempertimbangkan dan membuat keputusan teknologi lebih berdasarkan selera mode dan kepuasan emosional langsung daripada memikirkan efek sekunder dari pilihan kita. Kita harus mengajukan pertanyaan seperti:Bagaimana pilihan ini akan mempengaruhi pemeliharaan enam bulan ke depan? Apa tradeoff rekayasa? Bagaimana perubahan paradigma ini memengaruhi sistem pembangunan kami dalam skala besar?
Ini membuat frustrasi untuk menonton. Jika kita lupa bahwa teknik adalah permainan zero-sum dengan pengorbanan terukur—keuntungan dan kerugian, dengan biaya dan manfaat dari pendekatan yang berbeda—kita merugikan diri kita sendiri, kita merugikan majikan kita, dan kita merugikan rekan kerja kita yang pada akhirnya akan mempertahankan kinerja kita. kode merugikan. Terakhir, kami merugikan semua pengelola (salam pengelola!) dengan tidak menghargai pekerjaan yang mereka lakukan.
Memahami masalahnya
Untuk memahami masalahnya, pertama-tama kita harus menyelidiki mengapa kita mulai menggunakan distribusi Linux. Saya akan mengelompokkan alasannya menjadi dua ember utama:kernel dan paket lainnya. Kompilasi kernel sebenarnya cukup mudah. Slackware dan Gentoo (saya masih memiliki titik lemah di hati saya) mengajarkan hal itu kepada kami.
Di sisi lain, sejumlah besar perangkat lunak pengembangan dan runtime yang perlu dikemas untuk sistem Linux yang dapat digunakan dapat menjadi hal yang menakutkan. Selanjutnya, satu-satunya cara Anda dapat memastikan bahwa jutaan permutasi paket dapat diinstal dan bekerja sama adalah dengan menggunakan paradigma lama:kompilasi dan kirimkan bersama-sama sebagai satu hal (yaitu, distribusi Linux). Jadi, mengapa distribusi Linux mengkompilasi kernel dan semua paket bersama-sama? Sederhana:untuk memastikan semuanya bekerja sama.
Pertama, mari kita bicara tentang kernel. Kernelnya istimewa. Mem-boot sistem Linux tanpa kernel yang dikompilasi adalah sedikit tantangan. Ini adalah inti dari sistem operasi Linux, dan ini adalah hal pertama yang kami andalkan saat sistem melakukan booting. Kernel memiliki banyak opsi konfigurasi yang berbeda ketika sedang dikompilasi yang dapat memiliki efek luar biasa pada bagaimana perangkat keras dan perangkat lunak berjalan pada satu. Masalah sekunder dalam bucket ini adalah perangkat lunak sistem, seperti kompiler, pustaka C, dan penerjemah, harus disetel untuk opsi yang Anda buat ke dalam kernel. Gentoo mengajari kami hal ini secara mendalam, yang mengubah semua orang menjadi pengelola distribusi mini.
Yang memalukan (karena saya telah bekerja dengan kontainer selama lima tahun terakhir), saya harus mengakui bahwa saya telah mengkompilasi kernel baru-baru ini. Saya harus membuat KVM bersarang bekerja di RHEL 7 sehingga saya dapat menjalankan OpenShift di mesin virtual OpenStack, di mesin virtual KVM di laptop saya, serta Container Development Kit (CDK) kami. #justsayin Cukuplah untuk mengatakan, saya menjalankan RHEL7 pada kernel 4.X yang baru pada saat itu. Seperti sysadmin yang baik, saya sedikit khawatir bahwa saya melewatkan beberapa opsi konfigurasi dan patch penting. Dan, tentu saja, saya memiliki melewatkan beberapa hal. Mode tidur berhenti berfungsi dengan benar, stasiun dok saya berhenti berfungsi dengan benar, dan ada banyak kesalahan kecil dan acak lainnya. Tapi itu bekerja cukup baik untuk demo langsung OpenShift di OpenStack, dalam satu mesin virtual KVM di laptop saya. Ayolah, itu agak 'menyenangkan, kan? Tapi saya ngelantur…
Sekarang, mari kita bicara tentang semua paket lainnya. Sementara kernel dan perangkat lunak sistem terkait mungkin sulit untuk dikompilasi, masalah yang jauh lebih besar dari perspektif beban kerja adalah mengompilasi ribuan paket untuk memberi kita sistem Linux yang dapat digunakan. Setiap paket membutuhkan keahlian materi pelajaran. Beberapa perangkat lunak hanya perlu menjalankan tiga perintah:./configure , buat , dan lakukan pemasangan . Lainnya memerlukan banyak keahlian materi pelajaran mulai dari menambahkan pengguna dan mengonfigurasi default tertentu di dll untuk menjalankan skrip pasca-instal dan menambahkan file unit systemd. Serangkaian keterampilan yang diperlukan untuk ribuan perangkat lunak berbeda yang mungkin Anda gunakan menakutkan bagi setiap orang. Namun, jika Anda menginginkan sistem yang dapat digunakan dengan kemampuan untuk mencoba perangkat lunak baru kapan pun Anda mau, Anda harus mempelajari cara mengompilasi dan menginstal perangkat lunak baru bahkan sebelum Anda dapat mulai belajar menggunakannya. Itulah Linux tanpa distribusi Linux. Itulah masalah rekayasa yang Anda setujui ketika Anda mengabaikan distribusi Linux.
Intinya adalah Anda harus membangun semuanya bersama-sama untuk memastikannya bekerja sama dengan tingkat keandalan yang waras, dan dibutuhkan banyak pengetahuan untuk membangun kelompok paket yang dapat digunakan. Ini lebih banyak pengetahuan daripada yang pernah dipelajari dan dipertahankan oleh pengembang atau sysadmin tunggal mana pun. Setiap masalah yang saya jelaskan berlaku untuk host wadah Anda (kernel dan perangkat lunak sistem) dan gambar wadah (perangkat lunak sistem dan semua paket lainnya)—perhatikan tumpang tindihnya; ada compiler, library C, interpreter, dan JVM di image container juga.
Solusi
Anda sudah tahu ini, tetapi distribusi Linux adalah solusinya. Berhenti membaca dan kirim pengelola paket terdekat Anda (sekali lagi, salam pengelola!) e-card (tunggu, apakah saya baru saja memberikan usia saya?). Serius, orang-orang ini melakukan banyak pekerjaan, dan itu benar-benar kurang dihargai. Kubernetes, Istio, Prometheus, dan Knative:Saya melihat Anda. Waktu Anda juga akan tiba, ketika Anda berada dalam mode pemeliharaan, digunakan secara berlebihan, dan kurang dihargai. Saya akan menulis artikel yang sama lagi, mungkin tentang Kubernetes, dalam waktu sekitar tujuh hingga 10 tahun.
Prinsip pertama dengan pembuatan container
Ada pengorbanan untuk membangun dari awal dan membangun dari gambar dasar.
Membangun dari gambar dasar
Membangun dari gambar dasar memiliki keuntungan bahwa sebagian besar operasi pembangunan tidak lebih dari instalasi atau pembaruan paket. Itu bergantung pada banyak pekerjaan yang dilakukan oleh pengelola paket dalam distribusi Linux. Ini juga memiliki keuntungan bahwa acara tambalan enam bulan—atau bahkan 10 tahun—dari sekarang (dengan RHEL) adalah acara administrator operasi/sistem (yum update), bukan acara pengembang (yang memerlukan pemilahan kode untuk mencari tahu mengapa beberapa argumen fungsi tidak lagi berfungsi).
Mari kita klik dua kali pada itu sedikit. Kode aplikasi bergantung pada banyak perpustakaan mulai dari perpustakaan munging JSON hingga pemetaan relasional objek. Tidak seperti kernel Linux dan Glibc, jenis perpustakaan ini berubah dengan sangat sedikit hal untuk melanggar kompatibilitas API. Itu berarti bahwa tiga tahun dari sekarang acara tambalan Anda kemungkinan akan menjadi acara perubahan kode, bukan acara pembaruan yang enak. Oke, biarkan itu meresap. Pengembang, Anda akan diarahkan pada pukul 2 pagi jika tim keamanan tidak dapat menemukan peretasan firewall untuk memblokir eksploitasi.
Membangun dari gambar dasar tidak sempurna; ada kekurangannya, seperti ukuran semua dependensi yang terseret. Ini hampir selalu membuat gambar kontainer Anda lebih besar daripada membangun dari awal. Kerugian lainnya adalah Anda tidak akan selalu memiliki akses ke kode upstream terbaru. Hal ini dapat membuat developer frustrasi, terutama saat Anda hanya ingin mendapatkan sesuatu, tetapi tidak sefrustrasi saat membuka halaman untuk melihat library yang tidak terpikirkan selama tiga tahun oleh pengelola upstream yang telah berubah sepanjang waktu .
Jika Anda seorang pengembang web dan melihat saya, saya punya satu kata untuk Anda:DevOps. Itu berarti Anda membawa pager, teman saya.
Membangun dari awal
Scratch build memiliki keuntungan karena ukurannya yang sangat kecil. Ketika Anda tidak bergantung pada distribusi Linux dalam wadah, Anda memiliki banyak kontrol, yang berarti Anda dapat menyesuaikan semuanya untuk kebutuhan Anda. Ini adalah model terbaik, dan valid dalam kasus penggunaan tertentu. Keuntungan lainnya adalah Anda memiliki akses ke paket-paket terbaru. Anda tidak perlu menunggu distro Linux untuk memperbarui apa pun. Anda memegang kendali, jadi Anda memilih kapan akan menghabiskan pekerjaan rekayasa untuk memasukkan perangkat lunak baru.
Ingat, ada biaya untuk mengendalikan semuanya. Seringkali, memperbarui ke pustaka baru dengan fitur baru menyeret perubahan API yang tidak diinginkan, yang berarti memperbaiki ketidaksesuaian dalam kode (dengan kata lain, mencukur yak). Mencukur yak pada jam 2 pagi saat aplikasi tidak berfungsi tidak menyenangkan. Untungnya, dengan container, Anda dapat memutar kembali dan mencukur yak pada hari kerja berikutnya, tetapi itu masih akan memakan waktu Anda untuk memberikan nilai baru bagi bisnis, fitur baru untuk aplikasi Anda. Selamat datang di kehidupan seorang sysadmin.
Oke, begitulah, ada kalanya membangun dari awal masuk akal. Saya akan sepenuhnya mengakui bahwa program Golang dan program C yang dikompilasi secara statis adalah dua kandidat yang layak untuk pembuatan awal/tanpa distro. Dengan jenis program ini, setiap pembuatan wadah adalah acara kompilasi. Anda masih harus khawatir tentang kerusakan API tiga tahun dari sekarang, tetapi jika Anda adalah toko Golang, Anda harus memiliki keahlian untuk memperbaikinya dari waktu ke waktu.
Kesimpulan
Pada dasarnya, distribusi Linux melakukan banyak pekerjaan untuk menghemat waktu Anda—pada sistem Linux biasa atau dengan container. Pengetahuan yang dimiliki pengelola sangat luar biasa dan sangat dimanfaatkan tanpa benar-benar dihargai. Adopsi kontainer telah membuat masalah menjadi lebih buruk karena semakin diabstraksikan.
Dengan host kontainer, distribusi Linux menawarkan Anda akses ke ekosistem perangkat keras yang luas, mulai dari sistem ARM kecil, hingga 128 kotak CPU x86 raksasa, hingga VM penyedia cloud. Mereka menawarkan mesin kontainer yang berfungsi dan runtime kontainer yang siap pakai, jadi Anda cukup menyalakan kontainer dan membiarkan orang lain khawatir tentang membuat semuanya berfungsi.
Untuk gambar kontainer, distribusi Linux menawarkan akses mudah ke banyak perangkat lunak untuk proyek Anda. Bahkan ketika Anda membangun dari awal, Anda mungkin akan melihat bagaimana pengelola paket membuat dan mengirimkan barang—seniman yang baik adalah pencuri yang baik—jadi, jangan meremehkan pekerjaan ini.
Jadi, terima kasih kepada semua pengelola di Fedora, RHEL (Frantisek, Anda adalah pahlawan saya), Debian, Gentoo, dan setiap distribusi Linux lainnya. Saya menghargai pekerjaan yang Anda lakukan, meskipun saya adalah "pria kontainer".