คอฟฟี่เบรค #120. ตัวดำเนินการ Java &, && (และ) || (หรือ). ข้อมูลเบื้องต้นเกี่ยวกับ GitOps และ DevOps สำหรับนักพัฒนา

ตัวดำเนินการ Java &, && (และ) || (หรือ)

ที่มา: freeCodeCamp ในภาษาการเขียนโปรแกรม Java เราใช้ตัวดำเนินการเพื่อดำเนินการกับตัวแปร ตัวดำเนินการแบ่งออกเป็นประเภทต่างๆ ได้แก่ ตัวดำเนินการทางคณิตศาสตร์ ตัวดำเนินการมอบหมาย ตัวดำเนินการเปรียบเทียบ ตัวดำเนินการเชิงตรรกะ และอื่นๆ ในบทความนี้ เราจะพูดถึงตัวดำเนินการระดับบิต AND ( & ) รวมถึงตัวดำเนินการเชิงตรรกะ AND ( && ) และ OR ( || )

วิธีใช้ตัวดำเนินการระดับบิต AND

สัญลักษณ์&หมายถึงตัวดำเนินการระดับบิต AND มันประเมินค่าไบนารี่ของตัวเลขที่กำหนด ผลลัพธ์ไบนารี่ของตัวเลขเหล่านี้จะถูกส่งกลับมาให้เราในฐาน 10 เมื่อ ตัวดำเนินการ &เริ่มทำงาน มันจะประเมินค่าของอักขระในตัวเลขทั้งสองโดยเริ่มจากด้านซ้าย ลองดูตัวอย่างเพื่อช่วยให้เข้าใจสิ่งนี้ดีขึ้น:

System.out.println(10 & 12);
// returns 8

จะอธิบายเรื่องนี้อย่างไร? ค่าไบนารี่ของ 10 คือ 1,010 ค่าไบนารี่ของ 12 คือ 1100 นี่คือสิ่งที่เราต้องพิจารณาก่อนที่จะเริ่มการดำเนินการ: 1 และ 0 => 0 0 และ 1 => 0 1 และ 1 => 1 0 และ 0 = > 0 งั้นเรามาดำเนินการกัน สัญลักษณ์แรกของ 10 คือ 1 สัญลักษณ์แรกของ 12 ก็คือ 1 ดังนั้น: 1 และ 1 = 1 เลื่อนไปที่สัญลักษณ์ที่สอง - 0 สำหรับ 10 และ 1 สำหรับ 12: 1 และ 0 = 0 สำหรับสัญลักษณ์ที่สาม - 1 สำหรับ 10 และ 0 สำหรับ 12: 1 และ 0 = 0 สำหรับอักขระที่สี่ - 0 สำหรับ 10 และ 0 สำหรับ 12: 0 และ 0 = 0 ทีนี้มารวมอักขระที่ส่งคืนทั้งหมดเข้าด้วยกัน นี่ทำให้เราได้ 1,000 ค่าไบนารีของ 1,000 ในฐาน 10 คือ 8 ดังนั้นการดำเนินการของเราจึงคืนค่า 8

วิธีใช้ตรรกะและตัวดำเนินการ

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

statment1/condition1 && statemnt2/condition2

ดังที่คุณเห็นข้างต้น มีคำสั่ง/เงื่อนไขสองข้อที่คั่นด้วยคำสั่ง ตัวดำเนินการจะประเมินค่าของทั้งคำสั่ง/เงื่อนไข และให้ผลลัพธ์แก่เราว่าเป็นจริงหรือเท็จ นี่คือตัวอย่าง:

System.out.println((10 > 2) && (8 > 4));
//true

การดำเนินการจะส่งคืนค่าเป็นจริงเนื่องจากทั้งสองเงื่อนไขเป็นจริง: 10 มากกว่า 2 และ 8 มากกว่า 4 หากเงื่อนไขใดเงื่อนไขหนึ่งมีตรรกะที่ไม่ถูกต้อง เราจะได้รับfalse เพื่อให้เข้าใจ ตัวดำเนินการ && ได้ดีขึ้น คุณควรทราบว่าเงื่อนไขทั้งสองจะต้องเป็นจริงจึงจะประเมินเป็นจริงได้ นี่เป็นอีกตัวอย่างหนึ่งที่ส่งคืนfalse :

System.out.println((2 > 10) && (8 > 4));
// false

ที่นี่ 2 ไม่มากกว่า 10 และ 8 มากกว่า 4 - ดังนั้นเราจึงได้false เนื่องจากเงื่อนไขข้อใดข้อหนึ่งไม่ถูกต้อง

• หากเงื่อนไขทั้งสองเป็นจริง => จริง

• หากเงื่อนไขข้อใดข้อหนึ่งเป็นเท็จ => เท็จ

• หากทั้งสองเงื่อนไขเป็นเท็จ => เท็จ

วิธีใช้ตัวดำเนินการ Boolean OR

เพื่อแสดงถึงตัวดำเนินการ OR เราใช้สัญลักษณ์|| . โอเปอเรเตอร์นี้จะคืนค่าเท็จเฉพาะในกรณีที่ทั้งสองเงื่อนไขเป็นเท็จ นั่นคือ หากเงื่อนไขทั้งสองเป็นจริง เราจะได้เป็นจริงและหากเงื่อนไขใดเงื่อนไขหนึ่งเป็นจริง เราก็จะเป็นจริงเช่น กัน นี่คือไวยากรณ์:

statment1/condition1 || statemnt2/condition2

ลองดูตัวอย่างบางส่วน

System.out.println((6 < 1) || (4 > 2));
// true

True จะถูกส่งกลับคืนมาให้เราเนื่องจากมีเงื่อนไขข้อใดข้อหนึ่งเป็นจริง

• หากเงื่อนไขทั้งสองเป็นจริง => จริง

• หากเงื่อนไขข้อใดข้อหนึ่งเป็นจริง => จริง

• หากทั้งสองเงื่อนไขเป็นเท็จ => เท็จ

บทสรุป

ในบทความนี้ เราได้เรียนรู้วิธีใช้ตัวดำเนินการระดับบิต &และตัวดำเนินการเชิงตรรกะ&&และ||ใน Java . นอกจากนี้เรายังได้เรียนรู้ว่าแต่ละการดำเนินการจะส่งกลับค่าใดขึ้นอยู่กับเงื่อนไขของมัน

ข้อมูลเบื้องต้นเกี่ยวกับ GitOps และ DevOps สำหรับนักพัฒนา

ที่มา: Hackernoon หนึ่งในเป้าหมายหลักของ DevOps คือการช่วยให้นักพัฒนาปรับใช้ฟีเจอร์เพื่อการใช้งานจริงได้อย่างรวดเร็วและปลอดภัยที่สุดเท่าที่จะเป็นไปได้ ซึ่งหมายถึงการสร้างเครื่องมือและกระบวนการที่ทำทุกอย่างตั้งแต่การจัดหาสภาพแวดล้อมการพัฒนาส่วนตัวไปจนถึงการปรับใช้และรักษาความปลอดภัยปริมาณงานการผลิต ในขณะเดียวกัน ความเร่งรีบไม่ควรนำไปสู่ความล้มเหลวร้ายแรง GitOps เป็นวิธีหนึ่งในการทำให้ DevOps เป็นแบบอัตโนมัติ โดยเฉพาะอย่างยิ่ง มันเป็นกลยุทธ์อัตโนมัติโดยใช้เครื่องมือพัฒนา Git เนื่องจากนักพัฒนาได้คอมมิตโค้ดไปยังพื้นที่เก็บข้อมูล Git แบบรวมศูนย์แล้ว (โดยใช้บางอย่างเช่น GitHub, GitLab หรือ BitBucket) นักพัฒนา DevOps จึงสามารถเสียบสคริปต์งานใดๆ ของตนเพื่อสร้าง ทดสอบ หรือปรับใช้แอปพลิเคชันเพื่อให้ทำงานหลังจากทำการเปลี่ยนแปลงโค้ดทุกครั้ง ซึ่งหมายความว่านักพัฒนาสามารถทำงานกับ Git โดยเฉพาะได้ และทุกสิ่งที่ช่วยให้พวกเขานำโค้ดไปใช้จริงจะเป็นแบบอัตโนมัติ

ทำไมต้อง GitOps?

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

• หยุดการสร้างและดูแลรักษาสคริปต์ที่เป็นกรรมสิทธิ์ และใช้กระบวนการที่เป็นสากลแทน

• สร้างแอปและบริการได้รวดเร็วยิ่งขึ้นด้วยกระบวนการปรับใช้แบบสากลที่ระบุ

• ปรับใช้เร็วขึ้นหลังจากทำการเปลี่ยนแปลงโค้ด

• เปิดใช้งานการปรับใช้อัตโนมัติเพื่อการเผยแพร่ที่เร็วขึ้น บ่อยขึ้น และเชื่อถือได้มากขึ้น

• ดำเนินการย้อนกลับและตรวจสอบการปฏิบัติตามรูปแบบการออกแบบที่เปิดเผย

นักพัฒนาชื่นชอบ GitOps

ด้วยเหตุผลทั้งหมดที่ระบุไว้ข้างต้น (และอื่นๆ อีกมากมาย) บริษัทต่างๆ ต้องการแนวทางที่ได้รับการจัดการและเป็นอัตโนมัติสำหรับ CI/CD และ DevOps เพื่อให้ประสบความสำเร็จในการสร้างและบำรุงรักษาแอปพลิเคชันระบบคลาวด์ แต่หากระบบอัตโนมัติคือสิ่งเดียวที่มีอยู่ ทำไม GitOps ถึงดีกว่ากลยุทธ์อื่นๆ (เช่น SlackOps การปรับใช้ตามกำหนดเวลา หรือสคริปต์ธรรมดา) คำตอบนั้นง่ายมาก: นักพัฒนาชื่นชอบ GitOps

Git - เครื่องมือเดียวที่จะจัดการได้ทั้งหมด

ในช่วงไม่กี่ปีที่ผ่านมา เป็นที่ชัดเจนว่า GitOps เป็นหนึ่งในกลยุทธ์การทำงานอัตโนมัติของ DevOps ที่ได้รับคะแนนสูงที่สุดในหมู่นักพัฒนา และไม่ยากที่จะเข้าใจว่าทำไม นักพัฒนาอาศัยอยู่ใน Git พวกเขาจัดเก็บการเปลี่ยนแปลงชั่วคราวใน git, ทำงานร่วมกันโดยใช้ git, ตรวจสอบโค้ดโดยใช้ git และเก็บประวัติและร่องรอยการตรวจสอบของทุกการเปลี่ยนแปลงที่เคยทำมา รวมถึงใน git ด้วย เนื่องจากนักพัฒนาต้องพึ่งพา git เป็นอย่างมาก จึงมีเครื่องมือพิเศษที่สามารถใช้งานได้ ในระบบบูรณาการต่อเนื่องสมัยใหม่ที่มักใช้เพื่อรองรับ GitOps เช่นCircleCI , Github Actions , Gitlab CIและอื่นๆ การกำหนดค่าที่รองรับไปป์ไลน์จะอยู่ในที่เก็บ Git โดยตรง เช่นเดียวกับซอร์สโค้ดของแอปพลิเคชัน การกำหนดค่าเหล่านี้ได้รับการควบคุมเวอร์ชันและมองเห็นได้โดยนักพัฒนาทุกคนที่ทำงานในโปรเจ็กต์นี้ ไม่เพียงแต่พวกเขาจะเห็นว่ากระบวนการไปป์ไลน์คืออะไร แต่ยังสามารถทำการเปลี่ยนแปลงได้อย่างรวดเร็วและง่ายดายตามต้องการ ความง่ายในการเข้าถึงสำหรับนักพัฒนาเป็นสิ่งสำคัญ เนื่องจากพวกเขาเขียนการทดสอบสำหรับแอปพลิเคชันของตน และรับประกันความปลอดภัยและความเสถียร

บริการตนเองเต็มรูปแบบ

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

การทำงานอย่างต่อเนื่องในทุกสิ่ง

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

GitOps ในทางปฏิบัติ

โดยปกติแล้ว การมีส่วนร่วมของนักพัฒนาในกระบวนการนี้ทำให้ทีมต่างๆ ใช้เครื่องมือที่เป็นมิตรต่อผู้ใช้ เช่น Git อย่างกว้างขวาง นอกจากนี้ยังสร้างความสอดคล้องตามธรรมชาติสำหรับขั้นตอนการรวม/ปรับใช้ของ CI/CD ท้ายที่สุดแล้ว มีเพียงสิ่งต่างๆ มากมายที่มีอยู่ในที่เก็บ Git (เช่น คอมมิต คำขอเปิด/ปิด การรวม ฯลฯ) ดังนั้นรูปลักษณ์และความรู้สึกของการใช้งาน GitOps ส่วนใหญ่จึงเกี่ยวข้องกับชุดของขั้นตอนทั่วไป:

1. ดึงคำขอ การทดสอบ และสภาพแวดล้อมการแสดงตัวอย่าง

หลังจากที่นักพัฒนาใช้เวลาในการเขียนโค้ดสำหรับฟีเจอร์ใหม่ของพวกเขาแล้ว โดยทั่วไปแล้วพวกเขาจะคอมมิตโค้ดนั้นไปยังสาขา Git ใหม่ และส่งคำขอ Pull หรือคำขอMergeกลับไปยังสาขาหลักของพื้นที่เก็บข้อมูล นักพัฒนาทำเช่นนี้ทุกวัน ข้อความแจ้งกำหนดให้ผู้จัดการด้านเทคนิคตรวจสอบการเปลี่ยนแปลงรหัสและอนุมัติให้รวมเข้ากับรหัสแอปพลิเคชันหลัก นี่เป็นโอกาสที่ดีสำหรับ DevOps ในการเพิ่มงานเพิ่มเติม ด้วยการเชื่อมต่อกับเหตุการณ์เปิด/ปิดที่สร้างโดยกระบวนการคำขอดึงนี้โดยใช้เครื่องมือการรวมอย่างต่อเนื่อง (CI) ทีม DevOps จึงสามารถทริกเกอร์การดำเนินการทดสอบหน่วย การสร้างสภาพแวดล้อมการแสดงตัวอย่าง และการดำเนินการทดสอบการรวมกับสภาพแวดล้อมเหล่านั้น เครื่องมือนี้ช่วยให้วิศวกรสร้างความไว้วางใจในการเปลี่ยนแปลงโค้ดได้อย่างรวดเร็ว และช่วยให้ผู้จัดการผลิตภัณฑ์สามารถดูการเปลี่ยนแปลงโค้ดผ่านสภาพแวดล้อมการแสดงตัวอย่างก่อนผสานรวม ความไว้วางใจที่ใกล้ชิดหมายถึงการหลอมรวมที่เร็วขึ้น ยิ่งป้อนข้อมูลบ่อยน้อยลง การย้อนกลับที่ซับซ้อนและสับสนก็จะน้อยลงตามไปด้วย เทคนิค GitOps นี้เป็นกุญแจสำคัญสำหรับทีมพัฒนาและการผลิตที่รวดเร็วและมีสุขภาพดีขึ้น

2. รวมเข้ากับต้นแบบและปรับใช้ในการจัดเตรียม

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

3. ลดการเผยแพร่และปรับใช้กับการใช้งานจริง

ในที่สุด หลังจากที่ผู้จัดการและวิศวกรมีเวลาตรวจสอบและทดสอบการเปลี่ยนแปลงล่าสุดในสาขาอัปสตรีม ทีมงานก็พร้อมที่จะเผยแพร่รุ่นและปรับใช้กับการใช้งานจริง! งานนี้มักจะดำเนินการโดยผู้จัดการรุ่น ซึ่งเป็นสมาชิกในทีมเฉพาะ (หรือหมุนเวียน) ที่ได้รับมอบหมายให้รันสคริปต์การปรับใช้และติดตามการเผยแพร่ สมาชิกในทีมนี้จะต้องตรวจสอบว่าสคริปต์ที่ถูกต้องอยู่ที่ใด ลำดับใดในการเรียกใช้สคริปต์ โดยไม่ใช้ GitOps และไลบรารีและแพ็คเกจที่ถูกต้องทั้งหมดที่จำเป็นในการเรียกใช้สคริปต์ได้รับการติดตั้งบนเครื่องของตนหรือไม่ ด้วย GitOps เราสามารถเชื่อมโยงการปรับใช้นี้กับเหตุการณ์ที่ใช้ Git อื่น นั่นคือการสร้างรีลีสหรือแท็ก สิ่งที่ผู้จัดการ Release ต้องทำคือสร้าง “release” ใหม่ ซึ่งมักใช้ semver เป็นชื่อ งานในการสร้างและปรับใช้การเปลี่ยนแปลงโค้ดจะทำงานโดยอัตโนมัติ เช่นเดียวกับงานส่วนใหญ่ที่ดำเนินการโดยเครื่องมือ CI งานเหล่านั้นจะได้รับการกำหนดค่าด้วยตำแหน่งของสคริปต์และลำดับของไลบรารีและแพ็คเกจที่จำเป็นในการรัน

เครื่องมือ GitOps

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

การทำคอนเทนเนอร์ด้วย Docker

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

โครงสร้างพื้นฐานเป็นรหัส (IaC)

มีหลายสิ่งหลายอย่างในการเตรียมโครงสร้างพื้นฐานและการปรับใช้แอปพลิเคชันที่ไม่ได้จัดเก็บไว้ใน Dockerfile สำหรับทุกสิ่งทุกอย่าง มีโซลูชันโครงสร้างพื้นฐานตามโค้ด (IaC) เช่นTerraform , Cloudformationและอื่นๆ โซลูชันเหล่านี้ช่วยให้นักพัฒนาสามารถอธิบายส่วนอื่นๆ ของแอปพลิเคชัน เช่น ทรัพยากร Kubernetes, โหลดบาลานเซอร์, ระบบเครือข่าย, ความปลอดภัย และอื่นๆ ในลักษณะที่เปิดเผย เช่นเดียวกับการกำหนดค่า CI และ Dockerfiles ที่อธิบายไว้ก่อนหน้านี้ เทมเพลต IaC สามารถควบคุมเวอร์ชันและแชร์กับนักพัฒนาทุกคนในทีมของคุณได้