หลักการสามัญสำนึก 5 ข้อสำหรับการสร้างแอปบนคลาวด์เนทีฟ

แอปพลิเคชัน "คลาวด์เนทีฟ" หรือเรียกง่ายๆ ว่า "คลาวด์" ถูกสร้างขึ้นเพื่อทำงานในโครงสร้างพื้นฐานคลาวด์โดยเฉพาะ โดยทั่วไปแล้วจะถูกสร้างขึ้นเป็นชุดไมโครเซอร์วิสคู่ที่หลวมๆ ที่บรรจุในคอนเทนเนอร์ ซึ่งจะได้รับการจัดการโดยแพลตฟอร์มคลาวด์ แอปพลิเคชันดังกล่าวได้รับการเตรียมพร้อมสำหรับความล้มเหลวตามค่าเริ่มต้น ซึ่งหมายความว่าแอปพลิเคชันเหล่านี้ทำงานได้อย่างน่าเชื่อถือและปรับขนาดได้แม้ในกรณีที่เกิดความล้มเหลวระดับโครงสร้างพื้นฐานร้ายแรง อีกด้านของเหรียญคือชุดข้อจำกัด (สัญญา) ที่แพลตฟอร์มคลาวด์กำหนดกับแอปพลิเคชันคอนเทนเนอร์เพื่อให้สามารถจัดการได้โดยอัตโนมัติ

แม้ว่าตระหนักดีถึงความจำเป็นและความสำคัญของการเปลี่ยนไปใช้แอปพลิเคชันบนระบบคลาวด์ แต่หลายองค์กรยังไม่รู้ว่าจะเริ่มต้นจากตรงไหน ในโพสต์นี้ เราจะดูหลักการหลายประการที่หากปฏิบัติตามเมื่อพัฒนาแอปพลิเคชันแบบคอนเทนเนอร์ จะช่วยให้คุณตระหนักถึงศักยภาพของแพลตฟอร์มคลาวด์ และบรรลุการดำเนินงานที่เชื่อถือได้และการปรับขนาดแอปพลิเคชัน แม้ในกรณีที่เกิดความล้มเหลวร้ายแรงที่โครงสร้างพื้นฐานด้านไอที ระดับ. เป้าหมายสูงสุดของหลักการที่สรุปไว้ในที่นี้คือการเรียนรู้วิธีสร้างแอปพลิเคชันที่สามารถจัดการได้โดยอัตโนมัติโดยแพลตฟอร์มคลาวด์ เช่น Kubernetes

หลักการออกแบบซอฟต์แวร์

ในโลกของการเขียนโปรแกรม หลักการหมายถึงกฎทั่วไปที่ต้องปฏิบัติตามเมื่อพัฒนาซอฟต์แวร์ สามารถใช้เมื่อทำงานกับภาษาการเขียนโปรแกรมใดก็ได้ แต่ละหลักการมีเป้าหมายของตัวเอง เครื่องมือในการบรรลุเป้าหมาย ซึ่งโดยปกติจะเป็นแม่แบบและแนวปฏิบัติ นอกจากนี้ยังมีหลักการพื้นฐานหลายประการสำหรับการสร้างซอฟต์แวร์คุณภาพสูง ซึ่งเป็นหลักการพื้นฐานอื่นๆ ทั้งหมด นี่คือตัวอย่างบางส่วนของหลักการพื้นฐาน:

• จูบ (ทำให้มันเรียบง่าย โง่เขลา) – อย่าทำให้มันซับซ้อน
• แห้ง (อย่าพูดซ้ำ) - อย่าพูดซ้ำ;
• YAGNI (คุณไม่จำเป็นต้องใช้มัน) - อย่าสร้างสิ่งที่ไม่จำเป็นในทันที
• SoC แยกข้อกังวล – แบ่งปันความรับผิดชอบ

อย่างที่คุณเห็น หลักการเหล่านี้ไม่ได้กำหนดกฎเฉพาะใดๆ แต่อยู่ในหมวดหมู่ของสิ่งที่เรียกว่าการพิจารณาสามัญสำนึกโดยพิจารณาจากประสบการณ์จริง ซึ่งมีนักพัฒนาหลายคนแบ่งปันและที่พวกเขาอ้างถึงเป็นประจำ
นอกจากนี้ยังมี มูลฝอย – ชุดของหลักการห้าประการแรกของการเขียนโปรแกรมและการออกแบบเชิงวัตถุ จัดทำโดย Robert Martin SOLID ประกอบด้วยหลักการปลายเปิดที่กว้างและเสริมกัน ซึ่งเมื่อนำมาประยุกต์ใช้ร่วมกัน จะช่วยสร้างระบบซอฟต์แวร์ที่ดีขึ้น และดูแลรักษาระบบให้ดีขึ้นในระยะยาว

หลักการ SOLID เป็นของสาขา OOP และได้รับการกำหนดในภาษาของแนวคิดและแนวคิดดังกล่าว เช่น คลาส อินเทอร์เฟซ และการสืบทอด จากการเปรียบเทียบ หลักการพัฒนาสามารถกำหนดขึ้นสำหรับแอปพลิเคชันบนคลาวด์ได้ เฉพาะองค์ประกอบพื้นฐานในที่นี้เท่านั้นที่จะไม่ใช่คลาส แต่เป็นคอนเทนเนอร์ ด้วยการปฏิบัติตามหลักการเหล่านี้ คุณสามารถสร้างแอปพลิเคชันแบบคอนเทนเนอร์ที่บรรลุเป้าหมายและวัตถุประสงค์ของแพลตฟอร์มคลาวด์ เช่น Kubernetes ได้ดีขึ้น

คอนเทนเนอร์แบบ Cloud-native: แนวทาง Red Hat

ทุกวันนี้ การใช้งานเกือบทุกประเภทสามารถบรรจุลงในภาชนะได้อย่างง่ายดาย แต่เพื่อให้แอปพลิเคชันทำงานอัตโนมัติและควบคุมได้อย่างมีประสิทธิภาพภายในแพลตฟอร์มคลาวด์ เช่น Kubernetes จำเป็นต้องมีความพยายามเพิ่มเติม
พื้นฐานของแนวคิดด้านล่างนี้คือระเบียบวิธี แอพสิบสองปัจจัย และงานอื่นๆ อีกมากมายในด้านต่างๆ ของการสร้างเว็บแอปพลิเคชัน ตั้งแต่การจัดการซอร์สโค้ดไปจนถึงการปรับขนาดโมเดล หลักการที่อธิบายไว้ใช้เฉพาะกับการพัฒนาแอปพลิเคชันแบบคอนเทนเนอร์ที่สร้างขึ้นบนไมโครเซอร์วิสและออกแบบมาสำหรับแพลตฟอร์มคลาวด์ เช่น Kubernetes องค์ประกอบพื้นฐานในการสนทนาของเราคืออิมเมจคอนเทนเนอร์ และรันไทม์คอนเทนเนอร์เป้าหมายคือแพลตฟอร์มการจัดการคอนเทนเนอร์ เป้าหมายของหลักการที่นำเสนอคือการสร้างคอนเทนเนอร์ที่สามารถจัดกำหนดการ การปรับขนาด และการตรวจสอบงานได้โดยอัตโนมัติบนแพลตฟอร์มการจัดการส่วนใหญ่ หลักการไม่ได้นำเสนอตามลำดับโดยเฉพาะ

หลักการข้อกังวลเดียว (SCP)

หลักการนี้มีความคล้ายคลึงกับหลักการความรับผิดชอบเดียวหลายประการ SRP) ซึ่งเป็นส่วนหนึ่งของชุด SOLID และระบุว่าทุกอ็อบเจ็กต์ต้องมีความรับผิดชอบเดียว และความรับผิดชอบนั้นจะต้องถูกห่อหุ้มไว้อย่างสมบูรณ์ในคลาส ประเด็นของ SRP คือความรับผิดชอบทุกอย่างเป็นเหตุผลของการเปลี่ยนแปลง และชั้นเรียนต้องมีเหตุผลเดียวเท่านั้นในการเปลี่ยนแปลง

ใน SCP เราใช้คำว่า "ความกังวล" แทนคำว่า "ความรับผิดชอบ" เพื่อบ่งบอกถึงระดับนามธรรมที่สูงกว่าและวัตถุประสงค์ที่กว้างขึ้นของคอนเทนเนอร์เมื่อเปรียบเทียบกับคลาส OOP และหากเป้าหมายของ SRP คือการมีเหตุผลเดียวในการเปลี่ยนแปลง เบื้องหลัง SCP ก็คือความปรารถนาที่จะขยายความสามารถในการนำกลับมาใช้ใหม่และเปลี่ยนคอนเทนเนอร์ การปฏิบัติตาม SRP และสร้างคอนเทนเนอร์ที่แก้ไขปัญหาเดียวและดำเนินการในลักษณะที่ใช้งานได้อย่างสมบูรณ์ คุณจะเพิ่มโอกาสในการนำอิมเมจคอนเทนเนอร์นั้นกลับมาใช้ใหม่ในบริบทของแอปพลิเคชันที่แตกต่างกัน

หลักการของ SCP ระบุว่าแต่ละคอนเทนเนอร์ควรแก้ปัญหาเดียวและทำได้ดี ยิ่งไปกว่านั้น SCP ในโลกของคอนเทนเนอร์นั้นบรรลุได้ง่ายกว่า SRP ในโลกของ OOP เนื่องจากคอนเทนเนอร์มักจะรันกระบวนการเดียว และส่วนใหญ่แล้วกระบวนการนี้จะแก้ไขงานเดียว

หากไมโครเซอร์วิสคอนเทนเนอร์ต้องแก้ปัญหาหลายอย่างพร้อมกัน ก็สามารถแบ่งออกเป็นคอนเทนเนอร์งานเดียวและรวมเข้าด้วยกันภายในพ็อดเดียว (หน่วยของการปรับใช้แพลตฟอร์มคอนเทนเนอร์) โดยใช้เทมเพลตไซด์คาร์และคอนเทนเนอร์เริ่มต้น นอกจากนี้ SCP ยังทำให้ง่ายต่อการเปลี่ยนคอนเทนเนอร์เก่า (เช่น เว็บเซิร์ฟเวอร์หรือนายหน้าข้อความ) ด้วยคอนเทนเนอร์ใหม่ที่ช่วยแก้ปัญหาเดียวกัน แต่มีการขยายฟังก์ชันการทำงานหรือปรับขนาดได้ดีขึ้น

หลักการสังเกตสูง (HOP)

เมื่อใช้คอนเทนเนอร์เป็นวิธีการรวมแพ็กเกจและรันแอปพลิเคชัน ตัวแอปพลิเคชันจะถือเป็นกล่องดำ อย่างไรก็ตาม หากสิ่งเหล่านี้เป็นคอนเทนเนอร์บนคลาวด์ พวกเขาจะต้องจัดเตรียม API พิเศษให้กับรันไทม์เพื่อตรวจสอบความสมบูรณ์ของคอนเทนเนอร์ และดำเนินการตามความเหมาะสม หากจำเป็น หากไม่มีสิ่งนี้ คุณจะไม่สามารถรวมระบบอัตโนมัติของการอัปเดตคอนเทนเนอร์และการจัดการวงจรการใช้งานได้ ซึ่งจะทำให้เสถียรภาพและการใช้งานของระบบซอฟต์แวร์แย่ลง

ในทางปฏิบัติ แอปพลิเคชันแบบคอนเทนเนอร์ควรมี API เป็นอย่างน้อยสำหรับการตรวจสอบสถานภาพประเภทต่างๆ: การทดสอบความสดและการทดสอบความพร้อม หากแอปพลิเคชันอ้างว่าทำได้มากกว่านั้น จะต้องจัดให้มีวิธีการอื่นในการตรวจสอบสถานะของตน ตัวอย่างเช่น การบันทึกเหตุการณ์สำคัญผ่าน STDERR และ STDOUT สำหรับการรวมบันทึกโดยใช้ Fluentd, Logstash และเครื่องมืออื่นๆ ที่คล้ายคลึงกัน รวมถึงการผสานรวมกับไลบรารีการรวบรวมการติดตามและการวัด เช่น OpenTracing, Prometheus เป็นต้น

โดยทั่วไป แอปพลิเคชันยังคงสามารถถือเป็นกล่องดำได้ แต่จะต้องมาพร้อมกับ API ทั้งหมดที่แพลตฟอร์มต้องการ เพื่อตรวจสอบและจัดการในวิธีที่ดีที่สุดเท่าที่จะเป็นไปได้

หลักการความสอดคล้องของวงจรชีวิต (LCP)

LCP เป็นสิ่งที่ตรงกันข้ามกับ HOP แม้ว่า HOP ระบุว่าคอนเทนเนอร์จะต้องเปิดเผย API การอ่านไปยังแพลตฟอร์ม แต่ LCP ต้องการให้แอปพลิเคชันสามารถรับข้อมูลจากแพลตฟอร์มได้ ยิ่งไปกว่านั้น คอนเทนเนอร์ต้องไม่เพียงแค่รับเหตุการณ์เท่านั้น แต่ยังต้องปรับตัวหรือตอบสนองต่อเหตุการณ์เหล่านั้นด้วย จึงเป็นที่มาของชื่อหลักการซึ่งถือได้ว่าเป็นข้อกำหนดในการจัดหาแพลตฟอร์มด้วยการเขียน API

แพลตฟอร์มมีเหตุการณ์ประเภทต่างๆ เพื่อช่วยจัดการวงจรการใช้งานของคอนเทนเนอร์ แต่มันขึ้นอยู่กับแอพพลิเคชั่นเองที่จะตัดสินใจว่าจะรับรู้อันไหนและจะตอบสนองอย่างไร

เห็นได้ชัดว่าเหตุการณ์บางอย่างมีความสำคัญมากกว่าเหตุการณ์อื่นๆ ตัวอย่างเช่น หากแอปพลิเคชันไม่ทนต่อการขัดข้องได้ดี จะต้องยอมรับข้อความ signal: ยุติ (SIGTERM) และเริ่มต้นรูทีนการยกเลิกโดยเร็วที่สุดเพื่อจับสัญญาณ: kill (SIGKILL) ที่ตามมาหลัง SIGTERM

นอกจากนี้ เหตุการณ์ต่างๆ เช่น PostStart และ PreStop ยังมีความสำคัญต่อวงจรการใช้งานของแอปพลิเคชันอีกด้วย ตัวอย่างเช่น หลังจากเปิดตัวแอปพลิเคชัน อาจต้องใช้เวลาอุ่นเครื่องก่อนจึงจะสามารถตอบสนองคำขอได้ หรือแอปพลิเคชันจะต้องปล่อยทรัพยากรด้วยวิธีพิเศษบางอย่างเมื่อปิดระบบ

หลักการไม่เปลี่ยนรูปของภาพ (IIP)

เป็นที่ยอมรับกันโดยทั่วไปว่าแอปพลิเคชันที่มีคอนเทนเนอร์ควรยังคงไม่เปลี่ยนแปลงหลังจากสร้างขึ้น แม้ว่าแอปพลิเคชันเหล่านั้นจะทำงานในสภาพแวดล้อมที่แตกต่างกันก็ตาม สิ่งนี้ทำให้จำเป็นต้องจัดพื้นที่จัดเก็บข้อมูลภายนอก ณ รันไทม์ (กล่าวคือ เพื่อใช้เครื่องมือภายนอกสำหรับสิ่งนี้) และต้องอาศัยการกำหนดค่าภายนอกเฉพาะรันไทม์ แทนที่จะแก้ไขหรือสร้างคอนเทนเนอร์ที่ไม่ซ้ำกันสำหรับแต่ละสภาพแวดล้อม หลังจากการเปลี่ยนแปลงแอปพลิเคชัน อิมเมจคอนเทนเนอร์จะต้องถูกสร้างใหม่และปรับใช้กับสภาพแวดล้อมทั้งหมดที่ใช้ อย่างไรก็ตาม ในการจัดการระบบไอที จะใช้หลักการที่คล้ายกัน เรียกว่า หลักการของความไม่เปลี่ยนแปลงของเซิร์ฟเวอร์และโครงสร้างพื้นฐาน

เป้าหมายของ IIP คือการป้องกันการสร้างอิมเมจคอนเทนเนอร์แยกต่างหากสำหรับสภาพแวดล้อมรันไทม์ที่แตกต่างกัน และใช้อิมเมจเดียวกันทุกที่พร้อมกับการกำหนดค่าเฉพาะสภาพแวดล้อมที่เหมาะสม การปฏิบัติตามหลักการนี้ช่วยให้คุณสามารถนำแนวทางปฏิบัติที่สำคัญดังกล่าวไปใช้จากมุมมองของระบบอัตโนมัติของระบบคลาวด์ เช่น การย้อนกลับและย้อนกลับของการอัปเดตแอปพลิเคชัน

หลักการกำจัดกระบวนการ (PDP)

ลักษณะที่สำคัญที่สุดประการหนึ่งของคอนเทนเนอร์คือความคงตัวชั่วคราว: อินสแตนซ์ของคอนเทนเนอร์นั้นสร้างได้ง่ายและทำลายได้ง่าย ดังนั้นจึงสามารถเปลี่ยนเป็นอินสแตนซ์อื่นได้อย่างง่ายดายทุกเมื่อ อาจมีสาเหตุหลายประการสำหรับการทดแทนดังกล่าว: ความล้มเหลวในการทดสอบความสามารถในการให้บริการ ขนาดของแอปพลิเคชัน การถ่ายโอนไปยังโฮสต์อื่น ทรัพยากรแพลตฟอร์มหมด หรือสถานการณ์อื่น ๆ

ด้วยเหตุนี้ แอปพลิเคชันที่มีคอนเทนเนอร์จึงต้องคงสถานะไว้โดยใช้วิธีการภายนอก หรือใช้แผนการกระจายภายในที่มีความซ้ำซ้อนสำหรับสิ่งนี้ นอกจากนี้ แอปพลิเคชันจะต้องเริ่มต้นอย่างรวดเร็วและปิดเครื่องอย่างรวดเร็ว และเตรียมพร้อมสำหรับความล้มเหลวของฮาร์ดแวร์ที่ร้ายแรงอย่างกะทันหัน

แนวปฏิบัติประการหนึ่งที่ช่วยนำหลักการนี้ไปใช้ก็คือการรักษาภาชนะให้มีขนาดเล็ก สภาพแวดล้อมระบบคลาวด์สามารถเลือกโฮสต์เพื่อเปิดใช้งานอินสแตนซ์คอนเทนเนอร์ได้โดยอัตโนมัติ ดังนั้นยิ่งคอนเทนเนอร์เล็กลงเท่าใด คอนเทนเนอร์ก็จะเริ่มทำงานเร็วขึ้นเท่านั้น โดยจะคัดลอกไปยังโฮสต์เป้าหมายผ่านเครือข่ายได้เร็วขึ้น

หลักการกักกันตนเอง (S-CP)

ตามหลักการนี้ ในขั้นตอนการประกอบ ส่วนประกอบที่จำเป็นทั้งหมดจะรวมอยู่ในคอนเทนเนอร์ คอนเทนเนอร์ควรสร้างขึ้นบนสมมติฐานที่ว่าระบบมีเคอร์เนล Linux เพียงอย่างเดียว ดังนั้นไลบรารีเพิ่มเติมที่จำเป็นทั้งหมดควรอยู่ในคอนเทนเนอร์นั้นเอง นอกจากนี้ ยังควรมีสิ่งต่างๆ เช่น รันไทม์สำหรับภาษาการเขียนโปรแกรมที่เกี่ยวข้อง แพลตฟอร์มแอปพลิเคชัน (หากจำเป็น) และการขึ้นต่อกันอื่นๆ ที่จำเป็นในขณะที่แอปพลิเคชันคอนเทนเนอร์กำลังทำงาน

มีข้อยกเว้นสำหรับการกำหนดค่าที่แตกต่างกันไปในแต่ละสภาพแวดล้อม และต้องระบุ ณ รันไทม์ เช่น ผ่าน Kubernetes ConfigMap

แอปพลิเคชันอาจมีส่วนประกอบต่างๆ ที่อยู่ในคอนเทนเนอร์ เช่น คอนเทนเนอร์ DBMS ที่แยกจากกันภายในแอปพลิเคชันเว็บที่มีคอนเทนเนอร์ ตามหลักการ S-CP ไม่ควรรวมคอนเทนเนอร์เหล่านี้เข้าด้วยกัน แต่ควรทำเพื่อให้คอนเทนเนอร์ DBMS มีทุกสิ่งที่จำเป็นสำหรับการทำงานของฐานข้อมูล และคอนเทนเนอร์แอปพลิเคชันเว็บมีทุกสิ่งที่จำเป็นสำหรับการทำงานของเว็บ แอปพลิเคชันเว็บเซิร์ฟเวอร์เดียวกัน ด้วยเหตุนี้ ในขณะรันไทม์ คอนเทนเนอร์ของเว็บแอปพลิเคชันจะขึ้นอยู่กับคอนเทนเนอร์ DBMS และเข้าถึงได้ตามต้องการ

หลักการกักขังรันไทม์ (RCP)

หลักการ S-CP กำหนดวิธีการสร้างคอนเทนเนอร์และสิ่งที่ไบนารีของอิมเมจควรมี แต่คอนเทนเนอร์ไม่ได้เป็นเพียง "กล่องดำ" ที่มีลักษณะเฉพาะเพียงอย่างเดียว นั่นก็คือขนาดไฟล์ ในระหว่างการดำเนินการ คอนเทนเนอร์จะใช้มิติอื่น เช่น จำนวนหน่วยความจำที่ใช้ เวลา CPU และทรัพยากรระบบอื่นๆ

และที่นี่หลักการ RCP มีประโยชน์ โดยที่คอนเทนเนอร์จะต้องตัดความต้องการทรัพยากรระบบและถ่ายโอนไปยังแพลตฟอร์ม ด้วยโปรไฟล์ทรัพยากรของแต่ละคอนเทนเนอร์ (จำนวน CPU, หน่วยความจำ, เครือข่าย และทรัพยากรดิสก์ที่ต้องการ) แพลตฟอร์มจึงสามารถดำเนินการกำหนดเวลาและปรับขนาดอัตโนมัติ จัดการความจุด้านไอที และรักษาระดับ SLA สำหรับคอนเทนเนอร์ได้อย่างเหมาะสมที่สุด

นอกเหนือจากการตอบสนองความต้องการทรัพยากรของคอนเทนเนอร์แล้ว สิ่งสำคัญคือแอปพลิเคชันจะต้องไม่เกินขอบเขตของตัวเองด้วย มิฉะนั้น เมื่อเกิดการขาดแคลนทรัพยากร แพลตฟอร์มก็มีแนวโน้มที่จะรวมไว้ในรายการแอปพลิเคชันที่จำเป็นต้องยุติหรือย้าย

เมื่อเราพูดถึงการให้ความสำคัญกับคลาวด์เป็นหลัก เรากำลังพูดถึงวิธีการทำงานของเรา
ข้างต้น เราได้กำหนดหลักการทั่วไปจำนวนหนึ่งที่กำหนดรากฐานด้านระเบียบวิธีสำหรับการสร้างแอปพลิเคชันคอนเทนเนอร์คุณภาพสูงสำหรับสภาพแวดล้อมระบบคลาวด์

โปรดทราบว่านอกเหนือจากหลักการทั่วไปเหล่านี้ คุณจะต้องมีวิธีการและเทคนิคขั้นสูงเพิ่มเติมในการทำงานกับคอนเทนเนอร์ด้วย นอกจากนี้ เรามีคำแนะนำสั้นๆ บางประการที่เฉพาะเจาะจงมากขึ้นและควรนำไปใช้ (หรือไม่ใช้) ขึ้นอยู่กับสถานการณ์:

• พยายามลดขนาดรูปภาพ: ลบไฟล์ชั่วคราวและอย่าติดตั้งแพ็คเกจที่ไม่จำเป็น - ยิ่งขนาดคอนเทนเนอร์เล็กลงเท่าไร การประกอบและคัดลอกไปยังโฮสต์เป้าหมายผ่านเครือข่ายก็จะเร็วขึ้นเท่านั้น
• มุ่งเน้นไปที่ User-ID ที่กำหนดเอง: อย่าใช้คำสั่ง sudo หรือรหัสผู้ใช้พิเศษใดๆ เพื่อเปิดใช้คอนเทนเนอร์ของคุณ
• ทำเครื่องหมายพอร์ตที่สำคัญ: คุณสามารถตั้งค่าหมายเลขพอร์ตขณะรันไทม์ได้ แต่ควรระบุโดยใช้คำสั่ง EXPOSE จะดีกว่า เพราะจะทำให้ผู้อื่นและโปรแกรมใช้รูปภาพของคุณได้ง่ายขึ้น
• จัดเก็บข้อมูลถาวรบนไดรฟ์ข้อมูล: ข้อมูลที่ควรคงอยู่หลังจากคอนเทนเนอร์ถูกทำลายควรถูกเขียนลงในไดรฟ์ข้อมูล
• เขียนข้อมูลเมตาของรูปภาพ: แท็ก ป้ายกำกับ และคำอธิบายประกอบทำให้รูปภาพใช้งานได้ง่ายขึ้น - นักพัฒนารายอื่นจะขอบคุณ
• ซิงโครไนซ์โฮสต์และรูปภาพ: แอปพลิเคชันคอนเทนเนอร์บางตัวต้องการให้คอนเทนเนอร์ซิงค์กับโฮสต์ในแอตทริบิวต์บางอย่าง เช่น เวลาหรือหมายเลขเครื่อง
• โดยสรุป เราแชร์เทมเพลตและแนวปฏิบัติที่ดีที่สุดที่จะช่วยให้คุณนำหลักการที่ระบุไว้ข้างต้นไปใช้ได้อย่างมีประสิทธิภาพมากขึ้น:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  Leanpub.com/k8spatterns
  12factor.net

การสัมมนาผ่านเว็บเกี่ยวกับเวอร์ชันใหม่ของ OpenShift Container Platform – 4
11 มิถุนายน เวลา 11.00 น.

สิ่งที่คุณจะได้เรียนรู้:

• Red Hat Enterprise Linux CoreOS ที่ไม่เปลี่ยนรูป
• ตาข่ายบริการ OpenShift
• กรอบงานตัวดำเนินการ
• กรอบความคิดดั้งเดิม

ที่มา: will.com