ขั้นตอนแรกของการปรับใช้กับ Kubernetes คือการวางแอปพลิเคชันของคุณไว้ในคอนเทนเนอร์ ในซีรีส์นี้ เราจะมาดูกันว่าคุณสามารถสร้างคอนเทนเนอร์อิมเมจขนาดเล็กที่ปลอดภัยได้อย่างไร
ขอบคุณ Docker การสร้างอิมเมจคอนเทนเนอร์ง่ายกว่าที่เคย ระบุอิมเมจพื้นฐาน เพิ่มการเปลี่ยนแปลง และสร้างคอนเทนเนอร์
แม้ว่าเทคนิคนี้จะดีสำหรับการเริ่มต้นใช้งาน แต่การใช้อิมเมจพื้นฐานเริ่มต้นสามารถนำไปสู่การทำงานที่ไม่ปลอดภัยกับอิมเมจขนาดใหญ่ที่เต็มไปด้วยช่องโหว่ได้
นอกจากนี้ อิมเมจส่วนใหญ่ใน Docker ใช้ Debian หรือ Ubuntu เป็นอิมเมจพื้นฐาน และถึงแม้จะให้ความเข้ากันได้ดีเยี่ยมและการปรับแต่งที่ง่ายดาย (ไฟล์ Docker ใช้โค้ดเพียงสองบรรทัด) แต่อิมเมจพื้นฐานก็สามารถเพิ่มภาระเพิ่มเติมได้หลายร้อยเมกะไบต์ในคอนเทนเนอร์ของคุณ ตัวอย่างเช่น ไฟล์ node.js แบบธรรมดาสำหรับแอปพลิเคชัน Go "hello-world" มีขนาดประมาณ 700 เมกะไบต์ ในขณะที่แอปพลิเคชันจริงของคุณมีขนาดเพียงไม่กี่เมกะไบต์เท่านั้น
ดังนั้นภาระงานพิเศษทั้งหมดนี้จึงเป็นการสิ้นเปลืองพื้นที่ดิจิทัลและเป็นที่ซ่อนที่ดีสำหรับช่องโหว่ด้านความปลอดภัยและจุดบกพร่อง ลองมาดูสองวิธีในการลดขนาดของคอนเทนเนอร์อิมเมจ
อย่างแรกคือการใช้อิมเมจฐานขนาดเล็ก อย่างที่สองคือการใช้ Builder Pattern การใช้อิมเมจฐานที่เล็กลงอาจเป็นวิธีที่ง่ายที่สุดในการลดขนาดคอนเทนเนอร์ของคุณ เป็นไปได้มากว่าภาษาหรือสแต็กที่คุณใช้จะมีอิมเมจแอปพลิเคชันต้นฉบับที่เล็กกว่าอิมเมจเริ่มต้นมาก มาดูคอนเทนเนอร์ node.js ของเรากันดีกว่า
ตามค่าเริ่มต้นใน Docker ขนาดอิมเมจพื้นฐานของโหนด: 8 คือ 670 MB และขนาดอิมเมจฐานของโหนด: 8-alpine มีขนาดเพียง 65 MB ซึ่งก็คือเล็กกว่า 10 เท่า การใช้อิมเมจฐาน Alpine ที่เล็กลง คุณจะลดขนาดคอนเทนเนอร์ลงได้อย่างมาก Alpine เป็นดิสทริบิวชั่น Linux ขนาดเล็กและน้ำหนักเบาซึ่งได้รับความนิยมอย่างมากในหมู่ผู้ใช้ Docker เพราะมันเข้ากันได้กับแอพพลิเคชั่นมากมายในขณะที่ยังคงรักษาคอนเทนเนอร์ให้มีขนาดเล็ก ไม่เหมือนกับอิมเมจ "node" ของ Docker มาตรฐาน "node:alpine" จะลบไฟล์และโปรแกรมบริการจำนวนมาก เหลือเพียงไฟล์ที่เพียงพอต่อการรันแอปพลิเคชันของคุณ
หากต้องการย้ายไปยังอิมเมจพื้นฐานที่เล็กลง เพียงอัปเดต Dockerfile เพื่อเริ่มทำงานกับอิมเมจพื้นฐานใหม่:
ตอนนี้ ไม่เหมือนกับอิมเมจ onbuild แบบเก่า คุณต้องคัดลอกโค้ดของคุณลงในคอนเทนเนอร์และติดตั้งการขึ้นต่อกันใดๆ ใน Dockerfile ใหม่ คอนเทนเนอร์จะเริ่มต้นด้วยอิมเมจ node:alpine จากนั้นสร้างไดเร็กทอรีสำหรับโค้ด ติดตั้งการขึ้นต่อกันโดยใช้ตัวจัดการแพ็คเกจ NPM และรัน server.js ในที่สุด
การอัพเกรดนี้ส่งผลให้คอนเทนเนอร์มีขนาดเล็กลง 10 เท่า หากภาษาการเขียนโปรแกรมหรือสแต็กของคุณไม่มีฟังก์ชันการลดขนาดรูปภาพพื้นฐาน ให้ใช้ Alpine Linux นอกจากนี้ยังจะช่วยให้สามารถจัดการเนื้อหาของคอนเทนเนอร์ได้อย่างเต็มที่ การใช้อิมเมจฐานขนาดเล็กเป็นวิธีที่ดีเยี่ยมในการสร้างคอนเทนเนอร์ขนาดเล็กอย่างรวดเร็ว แต่การลดลงที่มากขึ้นสามารถทำได้โดยใช้รูปแบบตัวสร้าง
ในภาษาที่แปล ซอร์สโค้ดจะถูกส่งผ่านไปยังล่ามก่อนแล้วจึงดำเนินการโดยตรง ในภาษาที่คอมไพล์ ซอร์สโค้ดจะถูกแปลงเป็นโค้ดที่คอมไพล์ก่อน อย่างไรก็ตาม การคอมไพล์มักจะใช้เครื่องมือที่ไม่จำเป็นจริงๆ ในการรันโค้ด ซึ่งหมายความว่าคุณสามารถลบเครื่องมือเหล่านี้ออกจากคอนเทนเนอร์สุดท้ายได้อย่างสมบูรณ์ คุณสามารถใช้รูปแบบตัวสร้างสำหรับสิ่งนี้
รหัสถูกสร้างขึ้นในคอนเทนเนอร์แรกและคอมไพล์ โค้ดที่คอมไพล์แล้วจะถูกบรรจุลงในคอนเทนเนอร์สุดท้ายโดยไม่มีคอมไพเลอร์และเครื่องมือที่จำเป็นในการคอมไพล์โค้ดนั้น มาเรียกใช้แอปพลิเคชัน Go ผ่านกระบวนการนี้กันดีกว่า ก่อนอื่น เราจะย้ายจากอิมเมจ onbuild ไปยัง Alpine Linux
ใน Dockerfile ใหม่ คอนเทนเนอร์จะเริ่มต้นด้วยอิมเมจ golang:alpine จากนั้นจะสร้างไดเร็กทอรีสำหรับโค้ด คัดลอกลงในซอร์สโค้ด สร้างซอร์สโค้ดนั้น และรันแอปพลิเคชัน คอนเทนเนอร์นี้มีขนาดเล็กกว่าคอนเทนเนอร์ onbuild มาก แต่ยังคงมีคอมไพเลอร์และเครื่องมือ Go อื่นๆ ที่เราไม่ต้องการจริงๆ ลองแยกโปรแกรมที่คอมไพล์แล้วไปใส่ในคอนเทนเนอร์ของมันเอง
คุณอาจสังเกตเห็นสิ่งแปลก ๆ ในไฟล์ Docker นี้: ประกอบด้วยบรรทัด FROM สองบรรทัด ส่วน 4 บรรทัดแรกมีลักษณะเหมือนกับ Dockerfile ก่อนหน้าทุกประการ ยกเว้นว่าจะใช้คีย์เวิร์ด AS เพื่อตั้งชื่อสเตจนี้ ส่วนถัดไปจะมีบรรทัด FROM ใหม่เพื่อเริ่มอิมเมจใหม่ โดยที่แทนที่จะใช้อิมเมจ golang:alpine เราจะใช้ Raw Alpine เป็นอิมเมจพื้นฐาน
Raw Alpine Linux ไม่ได้ติดตั้งใบรับรอง SSL ซึ่งจะทำให้การเรียก API ส่วนใหญ่ผ่าน HTTPS ล้มเหลว ดังนั้นมาติดตั้งใบรับรอง CA รูทบางตัวกัน
มาถึงส่วนที่สนุกแล้ว: ในการคัดลอกโค้ดที่คอมไพล์แล้วจากคอนเทนเนอร์แรกไปยังคอนเทนเนอร์ที่สอง คุณสามารถใช้คำสั่ง COPY ที่อยู่บนบรรทัดที่ 5 ของส่วนที่สองได้ มันจะคัดลอกไฟล์แอปพลิเคชันเพียงไฟล์เดียวและจะไม่ส่งผลกระทบต่อเครื่องมือยูทิลิตี้ Go ไฟล์ Docker แบบหลายขั้นตอนใหม่จะมีคอนเทนเนอร์อิมเมจที่มีขนาดเพียง 12 เมกะไบต์ เทียบกับคอนเทนเนอร์อิมเมจเดิมที่มีขนาด 700 เมกะไบต์ ซึ่งแตกต่างอย่างมาก!
ดังนั้นการใช้อิมเมจฐานขนาดเล็กและ Builder Pattern จึงเป็นวิธีที่ดีในการสร้างคอนเทนเนอร์ที่มีขนาดเล็กลงโดยไม่ต้องทำงานมากนัก
เป็นไปได้ว่ามีวิธีเพิ่มเติมในการลดรูปภาพและขนาดคอนเทนเนอร์ ทั้งนี้ขึ้นอยู่กับสแต็กแอปพลิเคชัน แต่คอนเทนเนอร์ขนาดเล็กจะมีประโยชน์ที่สามารถวัดผลได้จริงหรือไม่ มาดูสองประเด็นที่คอนเทนเนอร์ขนาดเล็กมีประสิทธิภาพอย่างมาก ได้แก่ ประสิทธิภาพและความปลอดภัย
ในการประเมินการเพิ่มประสิทธิภาพ ให้พิจารณาระยะเวลาของกระบวนการสร้างคอนเทนเนอร์ การแทรกลงในรีจิสตรี (พุช) จากนั้นดึงข้อมูลจากที่นั่น (ดึง) คุณจะเห็นว่าคอนเทนเนอร์ขนาดเล็กมีข้อได้เปรียบเหนือคอนเทนเนอร์ขนาดใหญ่อย่างเห็นได้ชัด
นักเทียบท่าจะแคชเลเยอร์ดังนั้นการสร้างครั้งต่อไปจะรวดเร็วมาก อย่างไรก็ตาม ระบบ CI จำนวนมากที่ใช้ในการสร้างและทดสอบคอนเทนเนอร์ไม่ได้แคชเลเยอร์ จึงช่วยประหยัดเวลาได้มาก อย่างที่คุณเห็น เวลาในการสร้างคอนเทนเนอร์ขนาดใหญ่ ขึ้นอยู่กับพลังของเครื่องจักรของคุณคือจาก 34 ถึง 54 วินาที และเมื่อใช้คอนเทนเนอร์ลดลงโดยใช้รูปแบบตัวสร้าง - จาก 23 เป็น 28 วินาที สำหรับการดำเนินการประเภทนี้ ผลผลิตจะเพิ่มขึ้น 40-50% ลองคิดดูว่าคุณสร้างและทดสอบโค้ดของคุณกี่ครั้ง
หลังจากสร้างคอนเทนเนอร์แล้ว คุณจะต้องพุชอิมเมจของคอนเทนเนอร์ (พุชอิมเมจคอนเทนเนอร์) ลงในรีจีสทรีคอนเทนเนอร์ เพื่อที่จะนำไปใช้ในคลัสเตอร์ Kubernetes ได้ ฉันแนะนำให้ใช้ Google Container Registry
เมื่อใช้ Google Container Registry (GCR) คุณจะชำระค่าพื้นที่เก็บข้อมูลดิบและเครือข่ายเท่านั้น และไม่มีค่าธรรมเนียมการจัดการคอนเทนเนอร์เพิ่มเติม เป็นส่วนตัว ปลอดภัย และรวดเร็วมาก GCR ใช้เทคนิคมากมายเพื่อเร่งการดำเนินการดึง อย่างที่คุณเห็น การแทรกคอนเทนเนอร์ Docker Container Image โดยใช้ go:onbuild จะใช้เวลา 15 ถึง 48 วินาที ขึ้นอยู่กับประสิทธิภาพของคอมพิวเตอร์ และการดำเนินการเดียวกันกับคอนเทนเนอร์ขนาดเล็กจะใช้เวลา 14 ถึง 16 วินาที และสำหรับเครื่องจักรที่มีประสิทธิภาพน้อยกว่า ความได้เปรียบในด้านความเร็วในการทำงานเพิ่มขึ้น 3 เท่า สำหรับเครื่องขนาดใหญ่ เวลาก็ใกล้เคียงกัน เนื่องจาก GCR ใช้แคชส่วนกลางสำหรับฐานข้อมูลรูปภาพที่แชร์ ซึ่งหมายความว่าคุณไม่จำเป็นต้องโหลดรูปภาพเลย ในคอมพิวเตอร์ที่ใช้พลังงานต่ำ CPU คือคอขวด ดังนั้นข้อได้เปรียบของการใช้คอนเทนเนอร์ขนาดเล็กจึงยิ่งใหญ่กว่ามาก
หากคุณใช้ GCR ฉันขอแนะนำอย่างยิ่งให้ใช้ Google Container Builder (GCB) เป็นส่วนหนึ่งของระบบบิลด์ของคุณ
อย่างที่คุณเห็น การใช้งานช่วยให้คุณบรรลุผลลัพธ์ที่ดีกว่ามากในการลดระยะเวลาของการดำเนินการ Build+Push มากกว่าแม้แต่เครื่องจักรที่มีประสิทธิผล - ในกรณีนี้ กระบวนการสร้างและส่งคอนเทนเนอร์ไปยังโฮสต์จะถูกเร่งขึ้นเกือบ 2 เท่า . นอกจากนี้ คุณจะได้รับนาทีการสร้างฟรี 120 นาทีทุกวัน ซึ่งครอบคลุมความต้องการในการสร้างคอนเทนเนอร์ของคุณในกรณีส่วนใหญ่
ถัดมาเป็นตัวชี้วัดประสิทธิภาพที่สำคัญที่สุด – ความเร็วในการดึงข้อมูลหรือดาวน์โหลดดึงคอนเทนเนอร์ และหากคุณไม่สนใจเวลาที่ใช้ในการดำเนินการพุชมากนัก ความยาวของกระบวนการดึงจะมีผลกระทบร้ายแรงต่อประสิทธิภาพโดยรวมของระบบ สมมติว่าคุณมีคลัสเตอร์สามโหนดและหนึ่งในนั้นล้มเหลว หากคุณใช้ระบบการจัดการ เช่น Google Kubernetes Engine ระบบจะแทนที่โหนดที่ไม่ทำงานด้วยโหนดใหม่โดยอัตโนมัติ อย่างไรก็ตาม โหนดใหม่นี้จะว่างเปล่าโดยสิ้นเชิง และคุณจะต้องลากคอนเทนเนอร์ทั้งหมดของคุณลงไปเพื่อให้โหนดเริ่มทำงานได้ หากการดำเนินการดึงใช้เวลานานเพียงพอ คลัสเตอร์ของคุณจะทำงานด้วยประสิทธิภาพที่ต่ำกว่าตลอดเวลา
มีหลายกรณีที่อาจเกิดขึ้นได้ เช่น การเพิ่มโหนดใหม่ให้กับคลัสเตอร์ การอัพเกรดโหนด หรือแม้แต่การเปลี่ยนไปใช้คอนเทนเนอร์ใหม่เพื่อปรับใช้ ดังนั้นการลดเวลาในการสกัดแบบดึงให้เหลือน้อยที่สุดจึงกลายเป็นปัจจัยสำคัญ ปฏิเสธไม่ได้ว่าคอนเทนเนอร์ขนาดเล็กจะดาวน์โหลดเร็วกว่าคอนเทนเนอร์ขนาดใหญ่มาก หากคุณใช้งานหลายคอนเทนเนอร์ในคลัสเตอร์ Kubernetes การประหยัดเวลาอาจเกิดขึ้นได้มาก
ดูการเปรียบเทียบนี้: การดึงบนคอนเทนเนอร์ขนาดเล็กใช้เวลาน้อยลง 4-9 เท่า ขึ้นอยู่กับกำลังของเครื่อง เมื่อเทียบกับการดำเนินการเดียวกันโดยใช้ go:onbuild การใช้อิมเมจฐานคอนเทนเนอร์ขนาดเล็กที่ใช้ร่วมกันจะช่วยเพิ่มความเร็วและเวลาในการปรับใช้โหนด Kubernetes ใหม่และออนไลน์ได้อย่างมาก
มาดูประเด็นเรื่องความปลอดภัยกัน คอนเทนเนอร์ขนาดเล็กถือว่าปลอดภัยกว่าคอนเทนเนอร์ขนาดใหญ่มากเนื่องจากมีพื้นผิวการโจมตีที่เล็กกว่า จริงเหรอ? หนึ่งในคุณสมบัติที่มีประโยชน์ที่สุดของ Google Container Registry คือความสามารถในการสแกนคอนเทนเนอร์ของคุณเพื่อหาช่องโหว่โดยอัตโนมัติ เมื่อไม่กี่เดือนที่ผ่านมา ฉันได้สร้างทั้งคอนเทนเนอร์ onbuild และ multistage ดังนั้นเรามาดูกันว่ามีช่องโหว่ใดๆ ที่นั่นหรือไม่
ผลลัพธ์ที่ได้นั้นน่าทึ่งมาก: ตรวจพบช่องโหว่ระดับปานกลางเพียง 3 รายการในคอนเทนเนอร์ขนาดเล็ก และพบช่องโหว่ร้ายแรง 16 รายการและช่องโหว่อื่นๆ 376 รายการในคอนเทนเนอร์ขนาดใหญ่ หากเราดูเนื้อหาของคอนเทนเนอร์ขนาดใหญ่ เราจะเห็นว่าปัญหาด้านความปลอดภัยส่วนใหญ่ไม่เกี่ยวข้องกับแอปพลิเคชันของเรา แต่เกี่ยวข้องกับโปรแกรมที่เราไม่ได้ใช้ด้วยซ้ำ ดังนั้นเมื่อผู้คนพูดถึงพื้นผิวการโจมตีขนาดใหญ่ นั่นคือสิ่งที่พวกเขาหมายถึง
สิ่งสำคัญที่ชัดเจนคือ สร้างคอนเทนเนอร์ขนาดเล็กเนื่องจากคอนเทนเนอร์เหล่านี้ให้ประสิทธิภาพที่แท้จริงและคุณประโยชน์ด้านความปลอดภัยแก่ระบบของคุณ
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com