Langkah pertama untuk menggunakan Kubernetes ialah meletakkan aplikasi anda dalam bekas. Dalam siri ini, kami akan melihat cara anda boleh mencipta imej bekas yang kecil dan selamat.
Terima kasih kepada Docker, mencipta imej kontena tidak pernah semudah ini. Tentukan imej asas, tambahkan perubahan anda dan buat bekas.
Walaupun teknik ini bagus untuk bermula, menggunakan imej asas lalai boleh membawa kepada kerja yang tidak selamat dengan imej besar yang penuh dengan kelemahan.
Selain itu, kebanyakan imej dalam Docker menggunakan Debian atau Ubuntu untuk imej asas, dan sementara ini memberikan keserasian yang sangat baik dan penyesuaian mudah (fail Docker hanya mengambil dua baris kod), imej asas boleh menambah ratusan megabait beban tambahan pada bekas anda. Sebagai contoh, fail node.js mudah untuk aplikasi "hello-world" Go adalah kira-kira 700 megabait, manakala aplikasi sebenar anda hanya bersaiz beberapa megabait.
Jadi semua beban kerja tambahan ini adalah pembaziran ruang digital dan tempat persembunyian yang bagus untuk kelemahan keselamatan dan pepijat. Jadi mari kita lihat dua cara untuk mengurangkan saiz imej bekas.
Yang pertama ialah penggunaan imej asas yang kecil, yang kedua ialah penggunaan Corak Pembina. Menggunakan imej asas yang lebih kecil mungkin merupakan cara paling mudah untuk mengurangkan saiz bekas anda. Kemungkinan besar, bahasa atau tindanan yang anda gunakan menyediakan imej aplikasi asal yang jauh lebih kecil daripada imej lalai. Mari lihat bekas node.js kami.
Secara lalai dalam Docker, saiz imej asas nod:8 ialah 670 MB dan nod: saiz imej 8-alpine hanya 65 MB, iaitu 10 kali lebih kecil. Dengan menggunakan imej asas Alpine yang lebih kecil, anda akan mengurangkan saiz bekas anda dengan ketara. Alpine ialah pengedaran Linux yang kecil dan ringan yang sangat popular di kalangan pengguna Docker kerana ia serasi dengan banyak aplikasi sambil memastikan bekas kecil. Tidak seperti imej "nod" Docker standard, "node:alpine" mengalih keluar banyak fail perkhidmatan dan program, meninggalkan hanya fail yang mencukupi untuk menjalankan aplikasi anda.
Untuk beralih ke imej asas yang lebih kecil, cuma kemas kini Dockerfile untuk mula bekerja dengan imej asas baharu:
Kini, tidak seperti imej onbuild lama, anda perlu menyalin kod anda ke dalam bekas dan memasang sebarang kebergantungan. Dalam Dockerfile baharu, bekas bermula dengan imej nod:alpine, kemudian mencipta direktori untuk kod, memasang kebergantungan menggunakan pengurus pakej NPM dan akhirnya menjalankan server.js.
Peningkatan ini menghasilkan bekas yang bersaiz 10 kali lebih kecil. Jika bahasa pengaturcaraan atau timbunan anda tidak mempunyai fungsi pengurangan imej asas, gunakan Alpine Linux. Ia juga akan menyediakan keupayaan untuk mengurus sepenuhnya kandungan kontena. Menggunakan imej asas kecil ialah cara terbaik untuk membuat bekas kecil dengan cepat. Tetapi pengurangan yang lebih besar boleh dicapai menggunakan Corak Pembina.
Dalam bahasa yang ditafsirkan, kod sumber mula-mula dihantar kepada jurubahasa dan kemudian dilaksanakan secara langsung. Dalam bahasa yang disusun, kod sumber mula-mula ditukar kepada kod yang disusun. Walau bagaimanapun, kompilasi sering menggunakan alat yang sebenarnya tidak diperlukan untuk menjalankan kod. Ini bermakna anda boleh mengeluarkan sepenuhnya alatan ini daripada bekas terakhir. Anda boleh menggunakan Corak Pembina untuk ini.
Kod dibuat dalam bekas pertama dan disusun. Kod yang disusun kemudiannya dibungkus ke dalam bekas terakhir tanpa penyusun dan alat yang diperlukan untuk menyusun kod tersebut. Mari jalankan aplikasi Go melalui proses ini. Mula-mula, kita akan beralih daripada imej onbuild ke Alpine Linux.
Dalam Dockerfile baharu, bekas bermula dengan imej golang:alpine. Ia kemudian mencipta direktori untuk kod, menyalinnya ke dalam kod sumber, membina kod sumber itu dan menjalankan aplikasi. Bekas ini jauh lebih kecil daripada bekas binaan, tetapi ia masih mengandungi pengkompil dan alatan Go lain yang kami tidak perlukan. Jadi mari kita ekstrak program yang disusun dan masukkan ke dalam bekasnya sendiri.
Anda mungkin melihat sesuatu yang pelik dalam fail Docker ini: ia mengandungi dua baris FROM. Bahagian 4 baris pertama kelihatan betul-betul sama dengan Dockerfile sebelumnya kecuali ia menggunakan kata kunci AS untuk menamakan peringkat ini. Bahagian seterusnya mempunyai baris FROM baharu untuk memulakan imej baharu, di mana bukannya imej golang:alpine kita akan menggunakan Raw alpine sebagai imej asas.
Raw Alpine Linux tidak mempunyai sebarang sijil SSL yang dipasang, yang akan menyebabkan kebanyakan panggilan API melalui HTTPS gagal, jadi mari pasang beberapa sijil CA akar.
Sekarang datang bahagian yang menyeronokkan: untuk menyalin kod yang disusun dari bekas pertama ke bekas kedua, anda hanya boleh menggunakan arahan COPY yang terletak pada baris 5 bahagian kedua. Ia hanya akan menyalin satu fail aplikasi dan tidak akan menjejaskan alat utiliti Go. Fail Docker berbilang peringkat baharu akan mengandungi imej kontena yang bersaiz 12 megabait sahaja, berbanding dengan imej kontena asal iaitu 700 megabait, yang merupakan perbezaan yang besar!
Oleh itu, menggunakan imej asas kecil dan Corak Pembina ialah cara terbaik untuk mencipta bekas yang lebih kecil tanpa banyak kerja.
Ada kemungkinan bahawa bergantung pada tindanan aplikasi, terdapat cara tambahan untuk mengurangkan saiz imej dan bekas, tetapi adakah bekas kecil benar-benar mempunyai manfaat yang boleh diukur? Mari kita lihat dua kawasan di mana bekas kecil sangat berkesan - prestasi dan keselamatan.
Untuk menilai peningkatan prestasi, pertimbangkan tempoh proses mencipta bekas, memasukkannya ke dalam pendaftaran (tolak), dan kemudian mengambilnya dari sana (tarik). Anda boleh melihat bahawa bekas yang lebih kecil mempunyai kelebihan tersendiri berbanding bekas yang lebih besar.
Docker akan cache lapisan supaya binaan seterusnya akan menjadi sangat pantas. Walau bagaimanapun, banyak sistem CI yang digunakan untuk membina dan menguji bekas tidak menyimpan lapisan cache, jadi terdapat penjimatan masa yang ketara. Seperti yang anda lihat, masa untuk membina bekas besar, bergantung pada kuasa mesin anda, adalah dari 34 hingga 54 saat, dan apabila menggunakan bekas dikurangkan menggunakan Corak Pembina - dari 23 hingga 28 saat. Untuk operasi seperti ini, peningkatan produktiviti ialah 40-50%. Jadi cuma fikirkan tentang berapa kali anda membina dan menguji kod anda.
Selepas bekas dibina, anda perlu menolak imejnya (tolak imej bekas) ke dalam pendaftaran bekas supaya anda boleh menggunakannya dalam kelompok Kubernetes anda. Saya syorkan menggunakan Pendaftaran Kontena Google.
Dengan Google Container Registry (GCR), anda hanya membayar storan mentah dan perangkaian, dan tiada yuran pengurusan kontena tambahan. Ia peribadi, selamat dan sangat pantas. GCR menggunakan banyak helah untuk mempercepatkan operasi tarik. Seperti yang anda lihat, memasukkan bekas Imej Bekas Docker menggunakan go:onbuild akan mengambil masa dari 15 hingga 48 saat, bergantung pada prestasi komputer, dan operasi yang sama dengan bekas yang lebih kecil akan mengambil masa dari 14 hingga 16 saat dan untuk mesin yang kurang produktif kelebihan dalam kelajuan operasi meningkat sebanyak 3 kali ganda. Untuk mesin yang lebih besar, masanya adalah lebih kurang sama, memandangkan GCR menggunakan cache global untuk pangkalan data imej yang dikongsi, bermakna anda tidak perlu memuatkannya sama sekali. Dalam komputer berkuasa rendah, CPU adalah halangan, jadi kelebihan menggunakan bekas kecil adalah lebih besar di sini.
Jika anda menggunakan GCR, saya amat mengesyorkan menggunakan Google Container Builder (GCB) sebagai sebahagian daripada sistem binaan anda.
Seperti yang anda lihat, penggunaannya membolehkan anda mencapai hasil yang lebih baik dalam mengurangkan tempoh operasi Bina+Tekan berbanding mesin yang produktif - dalam kes ini, proses membina dan menghantar bekas ke hos dipercepatkan hampir 2 kali ganda . Selain itu, anda mendapat 120 minit binaan percuma setiap hari, yang meliputi keperluan bangunan kontena anda dalam kebanyakan kes.
Seterusnya ialah metrik prestasi yang paling penting β kelajuan mendapatkan semula atau memuat turun, Tarik bekas. Dan jika anda tidak begitu mengambil berat tentang masa yang dihabiskan untuk operasi tolak, maka panjang proses tarik mempunyai kesan yang serius terhadap prestasi sistem keseluruhan. Katakan anda mempunyai sekumpulan tiga nod dan salah satu daripadanya gagal. Jika anda menggunakan sistem pengurusan seperti Google Kubernetes Engine, ia akan menggantikan nod yang mati dengan yang baharu secara automatik. Walau bagaimanapun, nod baharu ini akan kosong sepenuhnya dan anda perlu menyeret semua bekas anda ke dalamnya untuk mula berfungsi. Jika operasi tarik mengambil masa yang cukup lama, kluster anda akan berjalan pada prestasi yang lebih rendah sepanjang masa.
Terdapat banyak kes di mana ini boleh berlaku: menambahkan nod baharu pada kluster, menaik taraf nod, atau bertukar kepada bekas baharu untuk penggunaan. Oleh itu, meminimumkan masa pengekstrakan tarik menjadi faktor utama. Tidak dapat dinafikan bahawa kontena kecil memuat turun lebih cepat daripada bekas yang besar. Jika anda menjalankan berbilang bekas dalam kelompok Kubernetes, penjimatan masa boleh menjadi ketara.
Lihat perbandingan ini: operasi tarik pada bekas kecil mengambil masa 4-9 kali lebih singkat, bergantung pada kuasa mesin, daripada operasi yang sama menggunakan go:onbuild. Menggunakan imej asas kontena kecil yang dikongsi dengan ketara mempercepatkan masa dan kelajuan di mana nod Kubernetes baharu boleh digunakan dan datang dalam talian.
Mari kita lihat isu keselamatan. Bekas yang lebih kecil dianggap lebih selamat daripada yang lebih besar kerana ia mempunyai permukaan serangan yang lebih kecil. Betul ke? Salah satu ciri Google Container Registry yang paling berguna ialah keupayaan untuk mengimbas bekas anda secara automatik untuk mencari kelemahan. Beberapa bulan yang lalu saya mencipta kedua-dua bekas binaan dan berbilang peringkat, jadi mari kita lihat jika terdapat sebarang kelemahan di sana.
Hasilnya menakjubkan: hanya 3 kerentanan sederhana dikesan dalam bekas kecil, dan 16 kerentanan kritikal dan 376 kerentanan lain ditemui dalam bekas besar. Jika kita melihat kandungan bekas yang besar, kita dapat melihat bahawa kebanyakan masalah keselamatan tidak ada kaitan dengan aplikasi kita, tetapi berkaitan dengan program yang kita tidak gunakan pun. Jadi apabila orang bercakap tentang permukaan serangan yang besar, itulah yang mereka maksudkan.
Pengambilan adalah jelas: bina bekas kecil kerana ia memberikan prestasi sebenar dan faedah keselamatan kepada sistem anda.
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali 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 - daripada $99! Baca tentang
Sumber: www.habr.com