Langkah pertama penerapan ke Kubernetes adalah menempatkan aplikasi Anda dalam sebuah container. Dalam seri ini, kita akan melihat bagaimana Anda dapat membuat image container kecil dan aman.
Berkat Docker, membuat image container tidak pernah semudah ini. Tentukan gambar dasar, tambahkan perubahan Anda, dan buat wadah.
Meskipun teknik ini bagus untuk memulai, menggunakan gambar dasar default dapat menyebabkan pekerjaan tidak aman dengan gambar besar yang penuh kerentanan.
Selain itu, sebagian besar image di Docker menggunakan Debian atau Ubuntu untuk image dasar, dan meskipun ini memberikan kompatibilitas yang sangat baik dan penyesuaian yang mudah (file Docker hanya membutuhkan dua baris kode), image dasar dapat menambahkan ratusan megabyte beban tambahan ke container Anda. Misalnya, file node.js sederhana untuk aplikasi Go "hello-world" berukuran sekitar 700 megabyte, sedangkan aplikasi Anda yang sebenarnya hanya berukuran beberapa megabyte.
Jadi semua beban kerja tambahan ini hanya membuang-buang ruang digital dan merupakan tempat persembunyian yang bagus untuk kerentanan keamanan dan bug. Jadi mari kita lihat dua cara untuk memperkecil ukuran gambar container.
Yang pertama adalah penggunaan gambar dasar kecil, yang kedua adalah penggunaan Builder Pattern. Menggunakan gambar dasar yang lebih kecil mungkin merupakan cara termudah untuk mengurangi ukuran penampung Anda. Kemungkinan besar, bahasa atau tumpukan yang Anda gunakan menyediakan gambar aplikasi asli yang jauh lebih kecil dari gambar default. Mari kita lihat wadah node.js kita.
Secara default di Docker, ukuran gambar dasar node:8 adalah 670 MB, dan ukuran gambar node: 8-alpine hanya 65 MB, yaitu 10 kali lebih kecil. Dengan menggunakan gambar dasar Alpine yang lebih kecil, Anda akan mengurangi ukuran wadah Anda secara signifikan. Alpine adalah distribusi Linux kecil dan ringan yang sangat populer di kalangan pengguna Docker karena kompatibel dengan banyak aplikasi sekaligus menjaga container tetap kecil. Berbeda dengan gambar "node" Docker standar, "node:alpine" menghapus banyak file layanan dan program, hanya menyisakan file dan program yang cukup untuk menjalankan aplikasi Anda.
Untuk berpindah ke gambar dasar yang lebih kecil, cukup perbarui Dockerfile untuk mulai bekerja dengan gambar dasar baru:
Sekarang, tidak seperti image onbuild yang lama, Anda perlu menyalin kode Anda ke dalam container dan menginstal dependensi apa pun. Di Dockerfile baru, kontainer dimulai dengan gambar node:alpine, lalu membuat direktori untuk kode tersebut, menginstal dependensi menggunakan manajer paket NPM, dan terakhir menjalankan server.js.
Peningkatan ini menghasilkan kontainer yang berukuran 10 kali lebih kecil. Jika bahasa pemrograman atau tumpukan Anda tidak memiliki fungsi pengurangan gambar dasar, gunakan Alpine Linux. Ini juga akan memberikan kemampuan untuk mengelola isi wadah secara penuh. Menggunakan gambar dasar kecil adalah cara terbaik untuk membuat container kecil dengan cepat. Namun pengurangan yang lebih besar dapat dicapai dengan menggunakan Pola Pembangun.
Dalam bahasa yang ditafsirkan, kode sumber pertama-tama diteruskan ke penerjemah dan kemudian langsung dieksekusi. Dalam bahasa yang dikompilasi, kode sumber terlebih dahulu diubah menjadi kode yang dikompilasi. Namun, kompilasi sering kali menggunakan alat yang sebenarnya tidak diperlukan untuk menjalankan kode. Ini berarti Anda dapat mengeluarkan alat-alat ini sepenuhnya dari wadah terakhir. Anda dapat menggunakan Pola Pembuat untuk ini.
Kode dibuat di wadah pertama dan dikompilasi. Kode yang dikompilasi kemudian dikemas ke dalam wadah akhir tanpa kompiler dan alat yang diperlukan untuk mengkompilasi kode tersebut. Mari jalankan aplikasi Go melalui proses ini. Pertama, kita akan berpindah dari image onbuild ke Alpine Linux.
Di Dockerfile baru, container dimulai dengan image golang:alpine. Ia kemudian membuat direktori untuk kode tersebut, menyalinnya ke dalam kode sumber, membuat kode sumber tersebut, dan menjalankan aplikasi. Kontainer ini jauh lebih kecil dibandingkan kontainer onbuild, namun masih berisi kompiler dan alat Go lainnya yang sebenarnya tidak kita perlukan. Jadi mari kita ekstrak saja program yang telah dikompilasi dan masukkan ke dalam wadahnya sendiri.
Anda mungkin melihat sesuatu yang aneh pada file Docker ini: file ini berisi dua baris FROM. Bagian 4 baris pertama terlihat sama persis dengan Dockerfile sebelumnya hanya saja menggunakan kata kunci AS untuk memberi nama tahap ini. Bagian selanjutnya memiliki baris FROM baru untuk memulai gambar baru, di mana alih-alih gambar golang:alpine kita akan menggunakan Raw alpine sebagai gambar dasar.
Raw Alpine Linux tidak menginstal sertifikat SSL apa pun, yang akan menyebabkan sebagian besar panggilan API melalui HTTPS gagal, jadi mari kita instal beberapa sertifikat root CA.
Sekarang sampai pada bagian yang menyenangkan: untuk menyalin kode yang dikompilasi dari wadah pertama ke wadah kedua, Anda cukup menggunakan perintah COPY yang terletak di baris 5 bagian kedua. Itu hanya akan menyalin satu file aplikasi dan tidak akan mempengaruhi alat utilitas Go. File Docker multi-tahap yang baru akan berisi image container yang hanya berukuran 12 megabyte, dibandingkan dengan image container asli yang berukuran 700 megabyte, yang merupakan perbedaan besar!
Jadi menggunakan gambar dasar kecil dan Pola Pembuat adalah cara bagus untuk membuat wadah yang jauh lebih kecil tanpa banyak pekerjaan.
Ada kemungkinan bahwa tergantung pada tumpukan aplikasi, ada cara tambahan untuk mengurangi ukuran gambar dan wadah, namun apakah wadah kecil benar-benar memiliki manfaat yang terukur? Mari kita lihat dua area di mana kontainer kecil sangat efektif β kinerja dan keamanan.
Untuk mengevaluasi peningkatan performa, pertimbangkan durasi proses pembuatan container, memasukkannya ke dalam registri (push), lalu mengambilnya dari sana (pull). Anda dapat melihat bahwa wadah yang lebih kecil memiliki keunggulan tersendiri dibandingkan wadah yang lebih besar.
Docker akan menyimpan lapisan-lapisan tersebut dalam cache sehingga pembangunan berikutnya akan sangat cepat. Namun, banyak sistem CI yang digunakan untuk membangun dan menguji kontainer tidak melakukan cache lapisan, sehingga menghemat waktu secara signifikan. Seperti yang Anda lihat, waktu untuk membuat container besar, bergantung pada kekuatan mesin Anda, adalah dari 34 menjadi 54 detik, dan saat menggunakan container dikurangi menggunakan Pola Pembuat - dari 23 menjadi 28 detik. Untuk operasi semacam ini, peningkatan produktivitas akan mencapai 40-50%. Jadi pikirkan saja berapa kali Anda membuat dan menguji kode Anda.
Setelah container dibuat, Anda perlu memasukkan image-nya (push container image) ke dalam registry container agar Anda dapat menggunakannya di cluster Kubernetes Anda. Saya sarankan menggunakan Google Container Registry.
Dengan Google Container Registry (GCR), Anda hanya membayar penyimpanan mentah dan jaringan, dan tidak ada biaya pengelolaan container tambahan. Ini pribadi, aman dan sangat cepat. GCR menggunakan banyak trik untuk mempercepat operasi penarikan. Seperti yang Anda lihat, memasukkan container Docker Container Image menggunakan go:onbuild akan memakan waktu 15 hingga 48 detik, bergantung pada kinerja komputer, dan operasi yang sama dengan container yang lebih kecil akan memakan waktu 14 hingga 16 detik, dan untuk mesin yang kurang produktif keuntungan dalam kecepatan operasi meningkat 3 kali lipat. Untuk mesin yang lebih besar, waktunya hampir sama, karena GCR menggunakan cache global untuk database gambar bersama, artinya Anda tidak perlu memuatnya sama sekali. Pada komputer berdaya rendah, CPU adalah penghambatnya, jadi keuntungan menggunakan wadah kecil jauh lebih besar di sini.
Jika Anda menggunakan GCR, saya sangat merekomendasikan penggunaan Google Container Builder (GCB) sebagai bagian dari sistem build Anda.
Seperti yang Anda lihat, penggunaannya memungkinkan Anda mencapai hasil yang jauh lebih baik dalam mengurangi durasi operasi Build+Push daripada mesin produktif - dalam hal ini, proses pembuatan dan pengiriman container ke host dipercepat hampir 2 kali lipat . Selain itu, Anda mendapatkan 120 menit pembangunan gratis setiap hari, yang dalam banyak kasus memenuhi kebutuhan pembangunan kontainer Anda.
Berikutnya adalah metrik kinerja yang paling penting β kecepatan mengambil, atau mengunduh, Pull container. Dan jika Anda tidak terlalu peduli dengan waktu yang dihabiskan untuk operasi push, maka lamanya proses penarikan akan berdampak serius pada kinerja sistem secara keseluruhan. Katakanlah Anda memiliki sekelompok tiga node dan salah satunya gagal. Jika Anda menggunakan sistem manajemen seperti Google Kubernetes Engine, maka secara otomatis node yang mati akan diganti dengan yang baru. Namun, node baru ini akan benar-benar kosong dan Anda harus menyeret semua container Anda ke dalamnya agar dapat mulai berfungsi. Jika operasi penarikan memakan waktu cukup lama, klaster Anda akan berjalan dengan performa yang lebih rendah sepanjang waktu.
Ada banyak kasus di mana hal ini dapat terjadi: menambahkan node baru ke cluster, mengupgrade node, atau bahkan beralih ke container baru untuk penerapan. Oleh karena itu, meminimalkan waktu ekstraksi tarikan menjadi faktor kunci. Tidak dapat dipungkiri bahwa pengunduhan container kecil jauh lebih cepat dibandingkan container besar. Jika Anda menjalankan beberapa container dalam satu cluster Kubernetes, penghematan waktu bisa sangat signifikan.
Lihatlah perbandingan ini: operasi penarikan pada container kecil membutuhkan waktu 4-9 kali lebih sedikit, tergantung pada daya mesin, dibandingkan operasi yang sama menggunakan go:onbuild. Menggunakan image berbasis container kecil yang dibagikan secara signifikan mempercepat waktu dan kecepatan penerapan node Kubernetes baru dan online.
Mari kita lihat masalah keamanan. Kontainer yang lebih kecil dianggap jauh lebih aman dibandingkan kontainer yang lebih besar karena memiliki permukaan serangan yang lebih kecil. Benarkah? Salah satu fitur paling berguna dari Google Container Registry adalah kemampuan untuk memindai kerentanan container Anda secara otomatis. Beberapa bulan yang lalu saya membuat container onbuild dan multistage, jadi mari kita lihat apakah ada kerentanan di sana.
Hasilnya luar biasa: hanya 3 kerentanan sedang yang terdeteksi dalam wadah kecil, dan 16 kerentanan kritis dan 376 kerentanan lainnya ditemukan dalam wadah besar. Jika kita melihat isi wadah yang besar, kita dapat melihat bahwa sebagian besar masalah keamanan tidak ada hubungannya dengan aplikasi kita, tetapi terkait dengan program yang bahkan tidak kita gunakan. Jadi ketika orang berbicara tentang permukaan serangan yang besar, itulah yang mereka maksud.
Kesimpulannya jelas: buatlah container kecil karena container tersebut memberikan manfaat kinerja dan keamanan nyata pada sistem Anda.
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com