นี่เป็นโพสต์แรกในชุดโพสต์เกี่ยวกับการเปลี่ยนแปลง การปรับปรุง และการเพิ่มเติมในการอัปเดตแพลตฟอร์ม Red Hat OpenShift 4.0 ที่กำลังจะมาถึง ซึ่งจะช่วยให้คุณเตรียมพร้อมสำหรับการเปลี่ยนไปใช้เวอร์ชันใหม่
นับตั้งแต่วินาทีที่ชุมชน Kubernetes ที่เพิ่งเริ่มต้นรวมตัวกันครั้งแรกที่สำนักงานในซีแอตเทิลของ Google ในฤดูใบไม้ร่วงปี 2014 โครงการ Kubernetes มีเป้าหมายที่จะปฏิวัติวิธีการพัฒนาและปรับใช้ซอฟต์แวร์ในปัจจุบัน ในเวลาเดียวกัน ผู้ให้บริการคลาวด์สาธารณะยังคงลงทุนอย่างแข็งขันในการพัฒนาโครงสร้างพื้นฐานและบริการ ซึ่งทำให้การทำงานด้านไอทีและการสร้างซอฟต์แวร์ง่ายขึ้นและเข้าถึงได้มากขึ้น และทำให้มีราคาที่เอื้อมถึงอย่างไม่น่าเชื่อ ซึ่งมีน้อยคนนักที่จะจินตนาการได้ในตอนเริ่มต้น ทศวรรษ
แน่นอนว่า การประกาศบริการคลาวด์ใหม่แต่ละรายการนั้นมาพร้อมกับการพูดคุยกันมากมายระหว่างผู้เชี่ยวชาญบน Twitter และมีการถกเถียงกันในหัวข้อต่างๆ มากมาย รวมถึงการสิ้นสุดของยุคโอเพ่นซอร์ส การลดลงของไอทีในองค์กร และสิ่งที่หลีกเลี่ยงไม่ได้ ของการผูกขาดซอฟต์แวร์ใหม่ บนคลาวด์ และวิธีที่กระบวนทัศน์ X ใหม่จะมาแทนที่กระบวนทัศน์อื่นๆ ทั้งหมด
จำเป็นต้องพูด ข้อพิพาททั้งหมดนี้โง่มาก
ความจริงก็คือไม่มีอะไรจะหายไป และทุกวันนี้เราสามารถเห็นการเติบโตแบบก้าวกระโดดในผลิตภัณฑ์ขั้นสุดท้ายและวิธีการพัฒนาอันเนื่องมาจากการเกิดขึ้นของซอฟต์แวร์ใหม่ๆ ในชีวิตของเราอย่างต่อเนื่อง และแม้ว่าทุกสิ่งรอบตัวจะเปลี่ยนไป แต่โดยพื้นฐานแล้วทุกอย่างจะยังคงไม่เปลี่ยนแปลง นักพัฒนาซอฟต์แวร์จะยังคงเขียนโค้ดที่มีข้อผิดพลาด วิศวกรฝ่ายปฏิบัติการและผู้เชี่ยวชาญด้านความน่าเชื่อถือจะยังคงเดินไปรอบๆ พร้อมเพจเจอร์ และรับการแจ้งเตือนอัตโนมัติใน Slack ผู้จัดการจะยังคงทำงานในแง่ของ OpEx และ CapEx และทุกครั้งที่เกิดความล้มเหลว นักพัฒนาอาวุโสจะ ถอนหายใจอย่างเศร้าๆ กับคำว่า “บอกแล้ว”...
โอ้จริงเหรอ ควรจะหารือกันคือเครื่องมือที่เราสามารถใช้ได้เพื่อสร้างผลิตภัณฑ์ซอฟต์แวร์ที่ดีขึ้น และวิธีที่เครื่องมือเหล่านั้นสามารถปรับปรุงความปลอดภัยและทำให้การพัฒนาง่ายขึ้นและเชื่อถือได้มากขึ้น เมื่อโครงการมีความซับซ้อนมากขึ้น ความเสี่ยงใหม่ๆ ก็เกิดขึ้น และทุกวันนี้ชีวิตของผู้คนต้องพึ่งพาซอฟต์แวร์มากจนนักพัฒนาต้องพยายามทำงานให้ดีขึ้น
Kubernetes เป็นหนึ่งในเครื่องมือดังกล่าว งานอยู่ระหว่างดำเนินการเพื่อรวม Red Hat OpenShift เข้ากับเครื่องมือและบริการอื่นๆ ให้เป็นแพลตฟอร์มเดียวซึ่งจะทำให้ซอฟต์แวร์มีความน่าเชื่อถือมากขึ้น จัดการได้ง่ายขึ้น และปลอดภัยสำหรับผู้ใช้มากขึ้น
ด้วยเหตุนี้ ทีม OpenShift จึงถามคำถามง่ายๆ หนึ่งข้อ:
คุณจะทำให้การทำงานกับ Kubernetes ง่ายขึ้นและสะดวกยิ่งขึ้นได้อย่างไร
คำตอบนั้นชัดเจนอย่างน่าประหลาดใจ:
- ทำให้การใช้งานด้านที่ซับซ้อนบนคลาวด์หรือภายนอกคลาวด์เป็นไปโดยอัตโนมัติ
- มุ่งเน้นไปที่ความน่าเชื่อถือในขณะที่ซ่อนความซับซ้อน
- ยังคงทำงานอย่างต่อเนื่องเพื่อเผยแพร่การอัปเดตที่ง่ายและปลอดภัย
- บรรลุการควบคุมและตรวจสอบได้
- มุ่งมั่นที่จะสร้างความมั่นใจในความปลอดภัยสูงในเบื้องต้น แต่ไม่ต้องเสียค่าใช้จ่ายในการใช้งาน
OpenShift รุ่นถัดไปควรคำนึงถึงทั้งประสบการณ์ของผู้สร้างและประสบการณ์ของนักพัฒนารายอื่นที่กำลังใช้งานซอฟต์แวร์ในวงกว้างในบริษัทที่ใหญ่ที่สุดในโลก นอกจากนี้ยังต้องคำนึงถึงประสบการณ์ที่สั่งสมมาทั้งหมดของระบบนิเวศแบบเปิดที่รองรับโลกสมัยใหม่ในปัจจุบันด้วย ในขณะเดียวกันก็จำเป็นต้องละทิ้งความคิดเก่าของนักพัฒนามือสมัครเล่นและก้าวไปสู่ปรัชญาใหม่ของอนาคตอัตโนมัติ จำเป็นต้องเชื่อมช่องว่างระหว่างวิธีการปรับใช้ซอฟต์แวร์แบบเก่าและแบบใหม่ และใช้ประโยชน์จากโครงสร้างพื้นฐานที่มีอยู่ทั้งหมดอย่างเต็มที่ ไม่ว่าจะโฮสต์โดยผู้ให้บริการคลาวด์รายใหญ่ที่สุดหรือทำงานบนระบบขนาดเล็กที่ Edge
จะบรรลุผลนี้ได้อย่างไร?
ที่ Red Hat เป็นเรื่องปกติที่จะต้องทำงานที่น่าเบื่อและไม่เห็นคุณค่าเป็นเวลานาน เพื่อรักษาชุมชนที่จัดตั้งขึ้นและป้องกันการปิดโครงการที่บริษัทเกี่ยวข้อง ชุมชนโอเพ่นซอร์สประกอบด้วยนักพัฒนาที่มีความสามารถจำนวนมากซึ่งสร้างสิ่งที่พิเศษที่สุด - ความบันเทิง การศึกษา การเปิดโอกาสใหม่ ๆ และสวยงาม แต่แน่นอนว่าไม่มีใครคาดหวังให้ผู้เข้าร่วมทุกคนก้าวไปในทิศทางเดียวกันหรือไล่ตามที่มีร่วมกัน เป้าหมาย บางครั้งจำเป็นต้องควบคุมพลังงานนี้และเปลี่ยนเส้นทางไปในทิศทางที่ถูกต้องเพื่อพัฒนาพื้นที่ที่จะเป็นประโยชน์ต่อผู้ใช้ของเรา แต่ในขณะเดียวกัน เราต้องติดตามการพัฒนาชุมชนของเราและเรียนรู้จากพวกเขา
เมื่อต้นปี 2018 Red Hat เข้าซื้อโครงการ CoreOS ซึ่งมีมุมมองที่คล้ายกันเกี่ยวกับอนาคต - ปลอดภัยและเชื่อถือได้มากขึ้น ซึ่งสร้างขึ้นบนหลักการโอเพ่นซอร์ส บริษัทได้ทำงานเพื่อพัฒนาแนวคิดเหล่านี้เพิ่มเติมและนำไปปฏิบัติ โดยนำปรัชญาของเราไปปฏิบัติ - พยายามทำให้แน่ใจว่าซอฟต์แวร์ทั้งหมดทำงานอย่างปลอดภัย งานทั้งหมดนี้สร้างขึ้นบน Kubernetes, Linux, คลาวด์สาธารณะ, คลาวด์ส่วนตัว และโปรเจ็กต์อื่น ๆ นับพันที่สนับสนุนระบบนิเวศดิจิทัลสมัยใหม่ของเรา
OpenShift 4 รุ่นใหม่จะมีความชัดเจน เป็นอัตโนมัติ และเป็นธรรมชาติมากขึ้น
แพลตฟอร์ม OpenShift จะทำงานร่วมกับระบบปฏิบัติการ Linux ที่ดีที่สุดและน่าเชื่อถือที่สุด พร้อมการรองรับฮาร์ดแวร์ Bare Metal, ระบบเสมือนจริงที่สะดวกสบาย, การเขียนโปรแกรมโครงสร้างพื้นฐานอัตโนมัติ และแน่นอนว่ารวมถึงคอนเทนเนอร์ (ซึ่งโดยพื้นฐานแล้วเป็นเพียงอิมเมจ Linux)
แพลตฟอร์มจะต้องมีความปลอดภัยตั้งแต่เริ่มต้น แต่ยังช่วยให้นักพัฒนาสามารถทำซ้ำได้ง่าย กล่าวคือ มีความยืดหยุ่นและปลอดภัยเพียงพอ ในขณะที่ยังคงให้ผู้ดูแลระบบสามารถตรวจสอบและจัดการได้อย่างง่ายดาย
ควรอนุญาตให้ซอฟต์แวร์ทำงาน "เป็นบริการ" และไม่นำไปสู่การเติบโตของโครงสร้างพื้นฐานที่ไม่สามารถจัดการได้สำหรับผู้ปฏิบัติงาน
จะช่วยให้นักพัฒนามุ่งเน้นไปที่การสร้างผลิตภัณฑ์จริงสำหรับผู้ใช้และลูกค้า คุณจะไม่ต้องลุยลุยป่าดงดิบของการตั้งค่าฮาร์ดแวร์และซอฟต์แวร์ และภาวะแทรกซ้อนจากอุบัติเหตุทั้งหมดจะหมดไป
OpenShift 4: แพลตฟอร์ม NoOps ที่ไม่ต้องการการบำรุงรักษา
В อธิบายงานเหล่านั้นที่ช่วยกำหนดวิสัยทัศน์ของบริษัทสำหรับ OpenShift 4 เป้าหมายของทีมคือลดความซับซ้อนของงานประจำวันในการดำเนินงานและบำรุงรักษาซอฟต์แวร์ให้มากที่สุดเท่าที่จะเป็นไปได้ เพื่อทำให้กระบวนการเหล่านี้ง่ายและผ่อนคลาย ทั้งสำหรับผู้เชี่ยวชาญที่เกี่ยวข้องกับการใช้งานและสำหรับนักพัฒนา แต่คุณจะเข้าใกล้เป้าหมายนี้ได้อย่างไร? จะสร้างแพลตฟอร์มสำหรับการรันซอฟต์แวร์ที่ต้องมีการแทรกแซงน้อยที่สุดได้อย่างไร? NoOps หมายถึงอะไรในบริบทนี้
หากคุณพยายามที่จะเป็นนามธรรมสำหรับนักพัฒนาแนวคิดของ "ไร้เซิร์ฟเวอร์" หรือ "NoOps" หมายถึงเครื่องมือและบริการที่ช่วยให้คุณสามารถซ่อนองค์ประกอบ "การดำเนินงาน" หรือลดภาระนี้ให้กับนักพัฒนาได้
- ไม่ได้ทำงานกับระบบ แต่ใช้กับอินเทอร์เฟซแอปพลิเคชัน (API)
- ไม่ต้องกังวลกับการติดตั้งซอฟต์แวร์ - ให้ผู้ให้บริการดำเนินการแทนคุณ
- อย่ากระโดดเข้าสู่การสร้างเฟรมเวิร์กขนาดใหญ่ทันที - เริ่มต้นด้วยการเขียนส่วนเล็กๆ ที่จะทำหน้าที่เป็น "แบบเอกสารสำเร็จรูป" พยายามทำให้โค้ดนี้ทำงานกับข้อมูลและเหตุการณ์ต่างๆ ไม่ใช่กับดิสก์และฐานข้อมูล
เป้าหมายเช่นเดิมคือการเร่งการพัฒนาซอฟต์แวร์ซ้ำ ให้โอกาสในการสร้างผลิตภัณฑ์ที่ดีขึ้น และเพื่อให้นักพัฒนาไม่ต้องกังวลเกี่ยวกับระบบที่ซอฟต์แวร์ของเขาทำงาน นักพัฒนาที่มีประสบการณ์ตระหนักดีว่าการมุ่งเน้นไปที่ผู้ใช้สามารถเปลี่ยนภาพได้อย่างรวดเร็ว ดังนั้นคุณไม่ควรใช้ความพยายามมากเกินไปในการเขียนซอฟต์แวร์ เว้นแต่คุณจะแน่ใจจริงๆ ว่าจำเป็น
สำหรับผู้เชี่ยวชาญด้านการบำรุงรักษาและการปฏิบัติการ คำว่า “NoOps” อาจฟังดูน่ากลัวเล็กน้อย แต่เมื่อสื่อสารกับวิศวกรภาคสนาม จะเห็นได้ชัดว่ารูปแบบและเทคนิคที่พวกเขาใช้มุ่งเป้าไปที่การรับรองความน่าเชื่อถือและความน่าเชื่อถือ (Site Reliability Engineering, SRE) มีความคล้ายคลึงกันหลายประการกับรูปแบบที่อธิบายไว้ข้างต้น:
- อย่าจัดการระบบ - ทำให้กระบวนการจัดการเป็นระบบอัตโนมัติ
- อย่าใช้ซอฟต์แวร์ - สร้างไปป์ไลน์เพื่อปรับใช้
- หลีกเลี่ยงการรวมบริการทั้งหมดของคุณเข้าด้วยกันและปล่อยให้ความล้มเหลวประการหนึ่งทำให้ทั้งระบบล้มเหลว โดยกระจายบริการเหล่านั้นไปทั่วโครงสร้างพื้นฐานทั้งหมดของคุณโดยใช้เครื่องมืออัตโนมัติ และเชื่อมต่อบริการเหล่านั้นในลักษณะที่สามารถตรวจสอบและติดตามได้
SRE รู้ว่ามีบางอย่างผิดพลาดได้ และพวกเขาจะต้องติดตามและแก้ไขปัญหา ดังนั้นพวกเขาจึงทำงานตามปกติโดยอัตโนมัติและตั้งค่าข้อผิดพลาดล่วงหน้า เพื่อให้พวกเขาพร้อมที่จะจัดลำดับความสำคัญและตัดสินใจเมื่อเกิดปัญหา
Kubernetes ใน OpenShift เป็นแพลตฟอร์มที่ออกแบบมาเพื่อแก้ปัญหาหลักสองประการ: แทนที่จะบังคับให้คุณเข้าใจเครื่องเสมือนหรือ API ตัวโหลดบาลานเซอร์ แต่กลับทำงานร่วมกับนามธรรมที่มีลำดับสูงกว่า - กระบวนการปรับใช้และบริการ แทนที่จะติดตั้งตัวแทนซอฟต์แวร์ คุณสามารถรันคอนเทนเนอร์ได้ และแทนที่จะเขียนสแต็กการตรวจสอบของคุณเอง ให้ใช้เครื่องมือที่มีอยู่แล้วในแพลตฟอร์ม ดังนั้น สูตรลับของ OpenShift 4 จึงไม่มีความลับจริงๆ เป็นเพียงเรื่องของการนำหลักการ SRE และแนวคิดแบบไร้เซิร์ฟเวอร์มาสรุปเชิงตรรกะเพื่อช่วยนักพัฒนาและวิศวกรฝ่ายปฏิบัติการ:
- ทำให้โครงสร้างพื้นฐานที่แอปพลิเคชันใช้เป็นอัตโนมัติและเป็นมาตรฐาน
- เชื่อมโยงกระบวนการปรับใช้และการพัฒนาเข้าด้วยกันโดยไม่จำกัดผู้พัฒนาเอง
- การตรวจสอบให้แน่ใจว่าการเปิดตัว การตรวจสอบ และการรักษาความปลอดภัยบริการ ฟีเจอร์ แอปพลิเคชัน หรือสแตกทั้งหมดลำดับที่ XNUMX นั้นไม่ยากไปกว่าครั้งแรก
แต่อะไรคือความแตกต่างระหว่างแพลตฟอร์ม OpenShift 4 กับรุ่นก่อนและจากแนวทาง "มาตรฐาน" ในการแก้ไขปัญหาดังกล่าว? อะไรเป็นตัวขับเคลื่อนขนาดสำหรับทีมปฏิบัติการและทีมปฏิบัติการ เนื่องจากพระมหากษัตริย์ในสถานการณ์เช่นนี้เป็นกลุ่ม ดังนั้น,
- เราตรวจสอบให้แน่ใจว่าวัตถุประสงค์ของคลัสเตอร์นั้นชัดเจน (ที่รัก คลาวด์ ฉันเลือกคลัสเตอร์นี้เพราะฉันทำได้)
- มีเครื่องจักรและระบบปฏิบัติการเพื่อรองรับคลัสเตอร์ (ฝ่าบาท)
- จัดการสถานะของโฮสต์จากคลัสเตอร์ ลดการสร้างใหม่ (ดริฟท์)
- สำหรับแต่ละองค์ประกอบที่สำคัญของระบบ จำเป็นต้องมีพี่เลี้ยงเด็ก (กลไก) ที่จะติดตามและขจัดปัญหา
- ความล้มเหลวของ *ทุกด้าน* หรือองค์ประกอบของระบบและกลไกการกู้คืนที่เกี่ยวข้องถือเป็นเรื่องปกติของชีวิต
- โครงสร้างพื้นฐานทั้งหมดจะต้องได้รับการกำหนดค่าผ่าน API
- ใช้ Kubernetes เพื่อรัน Kubernetes (ใช่ ใช่ นั่นไม่ได้พิมพ์ผิด)
- การอัพเดตควรติดตั้งได้ง่ายและไม่ยุ่งยาก หากใช้เวลาคลิกมากกว่าหนึ่งครั้งในการติดตั้งการอัปเดต แสดงว่าเรากำลังทำอะไรผิดพลาดอย่างเห็นได้ชัด
- การตรวจสอบและแก้ไขส่วนประกอบใดๆ ไม่ควรเป็นปัญหา ดังนั้นการติดตามและการรายงานทั่วทั้งโครงสร้างพื้นฐานทั้งหมดจึงควรเป็นเรื่องง่ายและสะดวก
ต้องการเห็นความสามารถของแพลตฟอร์มในการดำเนินการหรือไม่?
OpenShift 4 เวอร์ชันตัวอย่างพร้อมให้นักพัฒนาใช้งานได้แล้ว ด้วยตัวติดตั้งที่ใช้งานง่าย คุณสามารถรันคลัสเตอร์บน AWS บน Red Had CoreOS ได้ หากต้องการใช้การแสดงตัวอย่าง คุณเพียงต้องมีบัญชี AWS เพื่อจัดเตรียมโครงสร้างพื้นฐานและชุดบัญชีเพื่อเข้าถึงภาพตัวอย่าง
- หากต้องการเริ่มต้นให้ไปที่ และคลิก "เริ่มต้น"
- เข้าสู่ระบบบัญชี Red Hat ของคุณ (หรือสร้างบัญชีใหม่) และทำตามคำแนะนำเพื่อตั้งค่าคลัสเตอร์แรกของคุณ
หลังจากติดตั้งสำเร็จ โปรดดูบทช่วยสอนของเรา เพื่อทำความเข้าใจระบบและแนวคิดอย่างลึกซึ้งยิ่งขึ้นที่ทำให้แพลตฟอร์ม OpenShift 4 เป็นวิธีที่ง่ายและสะดวกในการรัน Kubernetes
ลองใช้ OpenShift ใหม่และแบ่งปันความคิดเห็นของคุณ เรามุ่งมั่นที่จะทำให้การทำงานกับ Kumbernetes สามารถเข้าถึงได้และง่ายดายที่สุดเท่าที่จะเป็นไปได้ อนาคตของ NoOps จะเริ่มต้นตั้งแต่วันนี้
และตอนนี้ให้ความสนใจ!
ในที่ประชุม ในวันที่ 20 เมษายน Vadim Rutkovsky หนึ่งในนักพัฒนา OpenShift จะจัดมาสเตอร์คลาส - เขาจะทำลายสิบคลัสเตอร์และบังคับให้พวกเขาแก้ไข ชำระค่าสัมมนาแล้ว แต่เมื่อใช้รหัสส่งเสริมการขาย #RedHat คุณจะได้รับส่วนลด 37%
มาสเตอร์คลาสเวลา 17:15 น. - 18:15 น. และบูธเปิดตลอดทั้งวัน เสื้อยืด หมวก สติ๊กเกอร์ - เหมือนเดิม!
ฮอลล์ #2
“ที่นี่จำเป็นต้องเปลี่ยนทั้งระบบ: เราซ่อมแซมคลัสเตอร์ k8 ที่เสียหายพร้อมกับกลไกที่ได้รับการรับรอง”
ที่มา: will.com