OpenShift - คู่มือฉบับย่อ

OpenShift เป็นแพลตฟอร์มการพัฒนาระบบคลาวด์เป็นบริการ (PaaS) ซึ่งโฮสต์โดย Red Hat เป็นแพลตฟอร์มที่ใช้งานง่ายบนคลาวด์โอเพ่นซอร์สที่ใช้ในการสร้างทดสอบและเรียกใช้แอปพลิเคชันและในที่สุดก็ปรับใช้บนคลาวด์

OpenShift สามารถจัดการแอปพลิเคชันที่เขียนด้วยภาษาต่างๆเช่น Node.js, Ruby, Python, Perl และ Java หนึ่งในคุณสมบัติหลักของ OpenShift คือสามารถขยายได้ซึ่งช่วยให้ผู้ใช้รองรับแอปพลิเคชันที่เขียนในภาษาอื่น ๆ

OpenShift มาพร้อมกับแนวคิดต่างๆของการจำลองเสมือนเป็นเลเยอร์นามธรรม แนวคิดพื้นฐานเบื้องหลัง OpenShift นั้นขึ้นอยู่กับการจำลองเสมือน

Virtualization

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

มันทำงานอย่างไร

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

สถาปัตยกรรมทางกายภาพและเสมือนจริง

ประเภทของ Virtualization

  • Application Virtualization- ในวิธีนี้แอปพลิเคชันจะแยกตัวออกจากระบบปฏิบัติการพื้นฐาน วิธีนี้มีประโยชน์มากในการเรียกใช้แอปพลิเคชันแบบแยกส่วนโดยไม่ขึ้นอยู่กับระบบปฏิบัติการที่อยู่ข้างใต้

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

  • Data Virtualization - เป็นวิธีการสรุปและหลีกหนีจากวิธีการดั้งเดิมของข้อมูลและการจัดการข้อมูล

  • Server Virtualization- ในวิธีนี้ทรัพยากรที่เกี่ยวข้องกับเซิร์ฟเวอร์จะถูกจำลองเสมือนซึ่งรวมถึงเซิร์ฟเวอร์ทางกายภาพกระบวนการและระบบปฏิบัติการ ซอฟต์แวร์ที่เปิดใช้งานนามธรรมนี้มักเรียกว่าไฮเปอร์ไวเซอร์

  • Storage Virtualization - เป็นกระบวนการรวมอุปกรณ์จัดเก็บข้อมูลหลายเครื่องไว้ในอุปกรณ์จัดเก็บข้อมูลเดียวที่จัดการจากคอนโซลกลางเดียว

  • Network Virtualization - เป็นวิธีการที่ทรัพยากรเครือข่ายที่มีอยู่ทั้งหมดจะถูกรวมเข้าด้วยกันโดยการแยกแบนด์วิดท์และแชนเนลที่มีอยู่ซึ่งแต่ละช่องจะไม่แยกจากกัน

OpenShift

OpenShift เป็นแพลตฟอร์มแอปพลิเคชันที่เปิดใช้งานระบบคลาวด์เป็นบริการ (PaaS) เป็นเทคโนโลยีโอเพ่นซอร์สที่ช่วยให้องค์กรย้ายโครงสร้างพื้นฐานและแพลตฟอร์มแอปพลิเคชันแบบเดิมจากสื่อเสมือนจริงไปยังระบบคลาวด์

OpenShift รองรับแอปพลิเคชันที่หลากหลายซึ่งสามารถพัฒนาและปรับใช้บนแพลตฟอร์มคลาวด์ OpenShift ได้อย่างง่ายดาย OpenShift โดยทั่วไปรองรับแพลตฟอร์มสามประเภทสำหรับนักพัฒนาและผู้ใช้

โครงสร้างพื้นฐานเป็นบริการ (IaaS)

ในรูปแบบนี้ผู้ให้บริการจัดเตรียมเครื่องเสมือนระดับฮาร์ดแวร์พร้อมกับการกำหนดค่าฮาร์ดแวร์เสมือนที่กำหนดไว้ล่วงหน้าบางส่วน มีคู่แข่งหลายรายในพื้นที่นี้เริ่มจาก AWS Google cloud, Rackspace และอื่น ๆ อีกมากมาย

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

ซอฟต์แวร์เป็นบริการ (SaaS)

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

แพลตฟอร์มเป็นบริการ (PaaS)

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

ทำไมต้องใช้ OpenShift

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

OpenShift ให้ข้อตกลงระดับการบริการที่แตกต่างกันเมื่อพูดถึงแผนการบริการ

Free - แผนนี้ จำกัด ไว้ที่สามปีโดยมีพื้นที่ 1GB ต่อคน

Bronze - แผนนี้รวม 3 ปีและขยายได้ถึง 16 ปีพร้อมพื้นที่ 1GB ต่อปี

Sliver - นี่คือแผนทองสัมฤทธิ์ 16 ปี แต่มีความจุ 6GB โดยไม่มีค่าใช้จ่ายเพิ่มเติม

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

คุณสมบัติ

OpenShift รองรับคุณสมบัติหลายอย่าง มีไม่กี่คน -

  • รองรับหลายภาษา
  • รองรับหลายฐานข้อมูล
  • ระบบตลับที่ขยายได้
  • การจัดการเวอร์ชันซอร์สโค้ด
  • การปรับใช้ด้วยคลิกเดียว
  • การสนับสนุนหลายสภาพแวดล้อม
  • ขั้นตอนการทำงานของนักพัฒนาที่ได้มาตรฐาน
  • การพึ่งพาและการจัดการการสร้าง
  • การปรับขนาดแอปพลิเคชันอัตโนมัติ
  • คอนโซลเว็บที่ตอบสนอง
  • Rich Command-line Toolset
  • SSH ระยะไกลเข้าสู่แอปพลิเคชัน
  • รองรับ API ที่เหลือ
  • กองแอปพลิเคชันตามความต้องการแบบบริการตนเอง
  • บริการฐานข้อมูลในตัว
  • การผสานรวมและการจัดการรีลีสอย่างต่อเนื่อง
  • การรวม IDE
  • การดีบักแอปพลิเคชันจากระยะไกล

OpenShift เกิดขึ้นจากฐานที่ชื่อ OpenShift V2 ซึ่งส่วนใหญ่ขึ้นอยู่กับแนวคิดของปีและตลับหมึกโดยที่ส่วนประกอบแต่ละส่วนมีข้อกำหนดเริ่มตั้งแต่การสร้างเครื่องจักรจนถึงการปรับใช้แอปพลิเคชันตั้งแต่การสร้างจนถึงการปรับใช้แอปพลิเคชัน

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

year- สามารถกำหนดเป็นเครื่องโลหะหมีหรือเซิร์ฟเวอร์ที่มีข้อกำหนดบางประการเกี่ยวกับทรัพยากรหน่วยความจำและ CPU พวกเขาถือเป็นหน่วยพื้นฐานสำหรับการเรียกใช้แอปพลิเคชัน

Application - สิ่งเหล่านี้อ้างถึงแอปพลิเคชันหรือแอปพลิเคชันการรวมใด ๆ ที่จะติดตั้งและทำงานบนสภาพแวดล้อม OpenShift

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

OpenShift Origin- นี่คือการเพิ่มชุมชนหรือ OpenShift เวอร์ชันโอเพ่นซอร์ส เป็นที่รู้จักกันในชื่อโครงการต้นน้ำสำหรับอีกสองเวอร์ชัน

OpenShift Online - เป็น PaaS pubic เป็นบริการที่โฮสต์บน AWS

OpenShift Enterprise - เป็น OpenShift เวอร์ชันชุบแข็งพร้อม ISV และใบอนุญาตผู้ขาย

OpenShift ออนไลน์

OpenShift online เป็นข้อเสนอของชุมชน OpenShift โดยใช้ซึ่งสามารถสร้างปรับใช้และปรับขนาดแอปพลิเคชันที่มีคอนเทนเนอร์บนคลาวด์สาธารณะได้อย่างรวดเร็ว เป็นแพลตฟอร์มการพัฒนาแอปพลิเคชันระบบคลาวด์สาธารณะและโฮสติ้งของ Red Hat ซึ่งเปิดใช้งานการจัดเตรียมการจัดการและการปรับขนาดแอปพลิเคชันโดยอัตโนมัติซึ่งช่วยให้นักพัฒนามุ่งเน้นไปที่การเขียนตรรกะของแอปพลิเคชัน

การตั้งค่าบัญชีบน Red Hat OpenShift Online

Step 1 - ไปที่เบราว์เซอร์และเยี่ยมชมเว็บไซต์ https://manage.openshift.com/

Step 2 - หากคุณมีบัญชี Red Hat ให้ลงชื่อเข้าใช้บัญชี OpenShift โดยใช้รหัสเข้าสู่ระบบ Red Hat และรหัสผ่านโดยใช้ URL ต่อไปนี้ https://developers.redhat.com

Step 3 - หากคุณไม่มีการเข้าสู่ระบบบัญชี Red Hat ให้สมัครใช้บริการออนไลน์ OpenShift โดยใช้ลิงก์ต่อไปนี้

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

หลังจากเข้าสู่ระบบคุณจะเห็นหน้าต่อไปนี้

เมื่อคุณมีทุกอย่างเรียบร้อยแล้ว Red Hat จะแสดงรายละเอียดบัญชีพื้นฐานดังที่แสดงในภาพหน้าจอต่อไปนี้

สุดท้ายเมื่อคุณเข้าสู่ระบบคุณจะพบหน้าต่อไปนี้

แพลตฟอร์มคอนเทนเนอร์ OpenShift

แพลตฟอร์มคอนเทนเนอร์ OpenShift เป็นแพลตฟอร์มระดับองค์กรที่ช่วยให้หลายทีมเช่นทีมพัฒนาและทีมปฏิบัติการด้านไอทีสร้างและปรับใช้โครงสร้างพื้นฐานแบบคอนเทนเนอร์ คอนเทนเนอร์ทั้งหมดที่สร้างขึ้นใน OpenShift ใช้เทคโนโลยี Docker containerization ที่เชื่อถือได้มากซึ่งสามารถปรับใช้บนศูนย์ข้อมูลใดก็ได้ของแพลตฟอร์มคลาวด์ที่โฮสต์แบบสาธารณะ

แพลตฟอร์มคอนเทนเนอร์ OpenShift เป็นที่รู้จักอย่างเป็นทางการในชื่อ OpenShift Enterprises เป็นแพลตฟอร์มส่วนตัวในสถานที่ของ Red Hat เป็นบริการที่สร้างขึ้นจากแนวคิดหลักของแอปพลิเคชันคอนเทนเนอร์ที่ขับเคลื่อนโดย Docker ซึ่ง Kubernetes จัดการการควบคุมและการดูแลระบบ

กล่าวอีกนัยหนึ่ง OpenShift นำ Docker และ Kubernetes มารวมกันในระดับองค์กร เป็นซอฟต์แวร์แพลตฟอร์มคอนเทนเนอร์สำหรับหน่วยงานองค์กรในการปรับใช้และจัดการผู้สมัครในโครงสร้างพื้นฐานที่เลือกเอง ตัวอย่างเช่นการโฮสต์อินสแตนซ์ OpenShift บนอินสแตนซ์ AWS

แพลตฟอร์มคอนเทนเนอร์ OpenShift มีให้บริการใน two package levels.

OpenShift Container Local- สำหรับนักพัฒนาที่ต้องการปรับใช้และทดสอบแอปพลิเคชันบนเครื่องท้องถิ่น แพ็คเกจนี้ส่วนใหญ่ใช้โดยทีมพัฒนาในการพัฒนาและทดสอบแอปพลิเคชัน

OpenShift Container Lab - ออกแบบมาสำหรับการประเมินแอปพลิเคชันแบบขยายตั้งแต่การพัฒนาจนถึงการปรับใช้ไปจนถึงสภาพแวดล้อมก่อนการผลิต

OpenShift เฉพาะ

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

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

คุณสมบัติของ OpenShift เฉพาะ

OpenShift ทุ่มเทนำเสนอแพลตฟอร์มแอปพลิเคชันโซลูชันที่กำหนดเองบนคลาวด์สาธารณะและสืบทอดมาจากเทคโนโลยี OpenShift 3

  • Extensible and Open - สิ่งนี้สร้างขึ้นจากแนวคิดแบบเปิดของ Docker และนำไปใช้บนคลาวด์เนื่องจากสามารถใช้จ่ายเองได้ตามต้องการและเมื่อจำเป็น

  • Portability - เนื่องจากสร้างขึ้นโดยใช้ Docker แอปพลิเคชันที่ทำงานบน Docker สามารถจัดส่งจากที่หนึ่งไปยังอีกที่หนึ่งได้อย่างง่ายดายโดยรองรับ Docker

  • Orchestration - ด้วย OpenShift 3 หนึ่งในคุณสมบัติหลักของการจัดระเบียบคอนเทนเนอร์และการจัดการคลัสเตอร์ได้รับการสนับสนุนโดยใช้ Kubernetes ซึ่งมาพร้อมกับ OpenShift เวอร์ชัน 3

  • Automation - OpenShift เวอร์ชันนี้เปิดใช้งานด้วยคุณสมบัติของการจัดการซอร์สโค้ดการสร้างระบบอัตโนมัติและการปรับใช้อัตโนมัติซึ่งทำให้เป็นที่นิยมอย่างมากในตลาดในฐานะแพลตฟอร์มในฐานะผู้ให้บริการ

คู่แข่งของ OpenShift

Google App Engine- นี่คือแพลตฟอร์มฟรีของ Google สำหรับการพัฒนาและโฮสต์แอปพลิเคชันเว็บ แอปเอ็นจิ้นของ Google นำเสนอแพลตฟอร์มการพัฒนาและการปรับใช้ที่รวดเร็ว

Microsoft Azure - Azure cloud โฮสต์โดย Microsoft บนศูนย์ข้อมูลของตน

Amazon Elastic Cloud Compute - เป็นบริการในตัวที่ให้บริการโดย Amazon ซึ่งช่วยในการพัฒนาและโฮสต์แอปพลิเคชันเว็บที่ปรับขนาดได้บนคลาวด์

Cloud Foundry - เป็นแพลตฟอร์ม PaaS แบบโอเพ่นซอร์สสำหรับแอปพลิเคชัน Java, Ruby, Python และ Node.js

CloudStack - CloudStack ของ Apache เป็นโครงการที่พัฒนาโดย Citrix และได้รับการออกแบบมาเพื่อเป็นคู่แข่งโดยตรงของ OpenShift และ OpenStack

OpenStack - เทคโนโลยีคลาวด์อื่นที่ Red Hat จัดเตรียมไว้สำหรับการประมวลผลแบบคลาวด์

Kubernetes - เป็นเทคโนโลยีการจัดการโดยตรงและการจัดการคลัสเตอร์ที่สร้างขึ้นเพื่อจัดการคอนเทนเนอร์ Docker

OpenShift เป็นระบบเลเยอร์โดยแต่ละเลเยอร์จะถูกผูกไว้อย่างแน่นหนากับเลเยอร์อื่นโดยใช้คลัสเตอร์ Kubernetes และ Docker สถาปัตยกรรมของ OpenShift ได้รับการออกแบบให้สามารถรองรับและจัดการคอนเทนเนอร์ Docker ซึ่งโฮสต์อยู่ด้านบนของเลเยอร์ทั้งหมดโดยใช้ Kubernetes ซึ่งแตกต่างจาก OpenShift V2 เวอร์ชันก่อนหน้าคือ OpenShift V3 เวอร์ชันใหม่รองรับโครงสร้างพื้นฐานแบบคอนเทนเนอร์ ในรุ่นนี้ Docker ช่วยในการสร้างคอนเทนเนอร์ที่ใช้ Linux ที่มีน้ำหนักเบาและ Kubernetes รองรับงานในการจัดเตรียมและจัดการคอนเทนเนอร์บนโฮสต์หลาย ๆ โฮสต์

ส่วนประกอบของ OpenShift

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

Kubernetes Master Machine Components

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

API Server- Kubernetes เป็นเซิร์ฟเวอร์ API ที่ให้การดำเนินการทั้งหมดในคลัสเตอร์โดยใช้ API เซิร์ฟเวอร์ API ใช้อินเทอร์เฟซซึ่งหมายความว่าเครื่องมือและไลบรารีต่างๆสามารถสื่อสารกับมันได้อย่างง่ายดาย kubeconfig เป็นแพ็คเกจพร้อมกับเครื่องมือฝั่งเซิร์ฟเวอร์ที่สามารถใช้สำหรับการสื่อสาร มันแสดง Kubernetes API”

Controller Manager- ส่วนประกอบนี้มีหน้าที่รับผิดชอบต่อนักสะสมส่วนใหญ่ที่ควบคุมสถานะของคลัสเตอร์และปฏิบัติงาน ถือได้ว่าเป็น daemon ที่รันในลูปแบบไม่สิ้นสุดและมีหน้าที่รวบรวมและส่งข้อมูลไปยังเซิร์ฟเวอร์ API ทำงานเพื่อรับสถานะที่ใช้ร่วมกันของคลัสเตอร์จากนั้นทำการเปลี่ยนแปลงเพื่อนำสถานะปัจจุบันของเซิร์ฟเวอร์ไปสู่สถานะที่ต้องการ ตัวควบคุมที่สำคัญ ได้แก่ ตัวควบคุมการจำลองตัวควบคุมปลายทางตัวควบคุมเนมสเปซและตัวควบคุมบัญชีบริการ ตัวจัดการคอนโทรลเลอร์เรียกใช้คอนโทรลเลอร์ประเภทต่างๆเพื่อจัดการกับโหนดปลายทางและอื่น ๆ

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

ส่วนประกอบโหนด Kubernetes

ต่อไปนี้เป็นองค์ประกอบหลักของเซิร์ฟเวอร์โหนดซึ่งจำเป็นในการสื่อสารกับ Kubernetes ต้นแบบ

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

Kubelet Service- นี่คือบริการเล็ก ๆ ในแต่ละโหนดซึ่งมีหน้าที่ในการถ่ายทอดข้อมูลไปยังและจากบริการเครื่องบินควบคุม มันโต้ตอบกับ etcd store เพื่ออ่านรายละเอียดการกำหนดค่าและค่าไรท์ สิ่งนี้สื่อสารกับคอมโพเนนต์หลักเพื่อรับคำสั่งและทำงาน จากนั้นกระบวนการ kubelet จะรับผิดชอบในการรักษาสถานะการทำงานและโหนดเซิร์ฟเวอร์ จัดการกฎเครือข่ายการส่งต่อพอร์ต ฯลฯ

Kubernetes Proxy Service- นี่คือบริการพร็อกซีที่ทำงานบนแต่ละโหนดและช่วยในการทำให้บริการพร้อมใช้งานสำหรับโฮสต์ภายนอก ช่วยในการส่งต่อคำขอแก้ไขตู้คอนเทนเนอร์ Kubernetes Proxy Service สามารถดำเนินการโหลดบาลานซ์แบบดั้งเดิมได้ ตรวจสอบให้แน่ใจว่าสภาพแวดล้อมเครือข่ายสามารถคาดเดาได้และสามารถเข้าถึงได้ แต่ในขณะเดียวกันก็แยกได้เช่นกัน มันจัดการพ็อดบนโหนดไดรฟ์ข้อมูลความลับสร้างการตรวจสอบความสมบูรณ์ของคอนเทนเนอร์ใหม่ ฯลฯ

Integrated OpenShift Container Registry

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

ข้อกำหนดที่ใช้บ่อย

Image- อิมเมจ Kubernetes (Docker) เป็นส่วนประกอบสำคัญของ Containerized Infrastructure ณ ตอนนี้ Kubernetes รองรับเฉพาะอิมเมจ Docker เท่านั้น คอนเทนเนอร์แต่ละอันในพ็อดจะมีอิมเมจ Docker ทำงานอยู่ข้างใน เมื่อกำหนดค่าพ็อดคุณสมบัติรูปภาพในไฟล์คอนฟิกูเรชันจะมีไวยากรณ์เหมือนกับคำสั่ง Docker

Project - สามารถกำหนดเป็นเวอร์ชันที่เปลี่ยนชื่อของโดเมนซึ่งมีอยู่ใน OpenShift V2 เวอร์ชันก่อนหน้า

Container - เป็นภาพที่สร้างขึ้นหลังจากใช้งานอิมเมจบนโหนดคลัสเตอร์ Kubernetes

Node- โหนดเป็นเครื่องจักรที่ทำงานในคลัสเตอร์ Kubernetes ซึ่งเรียกอีกอย่างว่า minion for master เป็นหน่วยงานที่สามารถเป็นอินสแตนซ์จริง VM หรือคลาวด์

Pod- พ็อดคือชุดของคอนเทนเนอร์และที่เก็บข้อมูลภายในโหนดของคลัสเตอร์ Kubernetes เป็นไปได้ที่จะสร้างพ็อดที่มีภาชนะหลายอันอยู่ข้างใน ตัวอย่างเช่นการเก็บคอนเทนเนอร์ฐานข้อมูลและคอนเทนเนอร์เว็บเซิร์ฟเวอร์ไว้ในพ็อด

ในบทนี้เราจะเรียนรู้เกี่ยวกับการตั้งค่าสภาพแวดล้อมของ OpenShift

ความต้องการของระบบ

ในการตั้งค่า OpenShift ขององค์กรเราจำเป็นต้องมีบัญชี Red Hat ที่ใช้งานได้ เนื่องจาก OpenShift ทำงานบนสถาปัตยกรรมหลักและโหนดของ Kubernetes เราจึงจำเป็นต้องตั้งค่าทั้งสองอย่างบนเครื่องแยกกันโดยเครื่องหนึ่งทำหน้าที่เป็นหลักและทำงานอื่น ๆ บนโหนด ในการตั้งค่าทั้งสองอย่างมีข้อกำหนดขั้นต่ำของระบบ

การกำหนดค่าเครื่องหลัก

ต่อไปนี้เป็นข้อกำหนดขั้นต่ำของระบบสำหรับการกำหนดค่าเครื่องหลัก

  • เครื่องฐานที่โฮสต์บนทางกายภาพเสมือนหรือบนสภาพแวดล้อมคลาวด์ใด ๆ

  • อย่างน้อย Linux 7 พร้อมแพ็กเกจที่จำเป็นบนอินสแตนซ์นั้น

  • 2 แกน CPU

  • RAM อย่างน้อย 8 GB

  • หน่วยความจำฮาร์ดดิสก์ภายใน 30 GB

การกำหนดค่าเครื่องโหนด

  • อิมเมจพื้นฐานทางกายภาพหรือเสมือนตามที่กำหนดสำหรับเครื่องต้นแบบ
  • อย่างน้อย Linux 7 บนเครื่อง
  • นักเทียบท่าที่ติดตั้งรุ่นไม่ต่ำกว่า 1.6
  • 1 แกน CPU
  • แรม 8 GB
  • ฮาร์ดดิสก์ 15 GB สำหรับโฮสต์ภาพและ 15 GB สำหรับจัดเก็บภาพ

คำแนะนำทีละขั้นตอนในการตั้งค่า OpenShift

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

Step 1- ก่อนอื่นให้ติดตั้ง Linux บนทั้งสองเครื่องโดยที่ Linux 7 ควรเป็นเวอร์ชันที่น้อยที่สุด สามารถทำได้โดยใช้คำสั่งต่อไปนี้หากมีการสมัครสมาชิก Red Hat ที่ใช้งานอยู่

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

เมื่อเราติดตั้งแพ็กเกจพื้นฐานทั้งหมดข้างต้นในทั้งสองเครื่องแล้วขั้นตอนต่อไปคือการตั้งค่า Docker บนเครื่องที่เกี่ยวข้อง

Step 2- กำหนดค่า Docker เพื่อให้สามารถสื่อสารที่ไม่ปลอดภัยบนเครือข่ายท้องถิ่นเท่านั้น สำหรับสิ่งนี้ให้แก้ไขไฟล์ Docker ภายใน / etc / sysconfig หากไม่มีไฟล์อยู่คุณต้องสร้างด้วยตนเอง

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

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

Step 3 - สร้างคีย์บนเครื่องหลักจากนั้นคัดลอกคีย์ id_rsa.pub ไปยังไฟล์คีย์ที่ได้รับอนุญาตของเครื่องโหนดซึ่งสามารถทำได้โดยใช้คำสั่งต่อไปนี้

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

เมื่อคุณตั้งค่าทั้งหมดข้างต้นเรียบร้อยแล้วขั้นต่อไปคือการตั้งค่า OpenShift เวอร์ชัน 3 บนเครื่องหลัก

Step 4 - จากเครื่องต้นแบบให้เรียกใช้คำสั่ง curl ต่อไปนี้

# sh <(curl -s https://install.openshift.com/ose)

คำสั่งดังกล่าวจะวางการตั้งค่าสำหรับ OSV3 ขั้นตอนต่อไปคือการกำหนดค่า OpenShift V3 บนเครื่อง

หากคุณไม่สามารถดาวน์โหลดจากอินเทอร์เน็ตได้โดยตรงก็สามารถดาวน์โหลดได้จาก https://install.openshift.com/portable/oo-install-ose.tgz เป็นแพ็กเกจ tar ที่โปรแกรมติดตั้งสามารถรันบนเครื่องหลักภายในเครื่อง

เมื่อเรามีการตั้งค่าพร้อมแล้วเราต้องเริ่มต้นด้วยการกำหนดค่าจริงของ OSV3 บนเครื่อง การตั้งค่านี้มีความเฉพาะเจาะจงมากเพื่อทดสอบสภาพแวดล้อมสำหรับการผลิตจริงเรามี LDAP และสิ่งอื่น ๆ

Step 5 - บนเครื่องต้นแบบกำหนดค่ารหัสต่อไปนี้ที่อยู่ภายใต้ /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

จากนั้นสร้างผู้ใช้มาตรฐานสำหรับการดูแลระบบเริ่มต้น

# htpasswd -c /root/users.htpasswd admin

Step 6- เนื่องจาก OpenShift ใช้ Docker Registry ในการกำหนดค่ารูปภาพเราจึงจำเป็นต้องกำหนดค่ารีจิสทรีของ Docker ใช้สำหรับสร้างและจัดเก็บอิมเมจ Docker หลังจากสร้าง

สร้างไดเร็กทอรีบนเครื่องโหนด OpenShift โดยใช้คำสั่งต่อไปนี้

# mkdir /images

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

# oc login
Username: system:admin

เปลี่ยนเป็นโปรเจ็กต์ที่สร้างตามค่าเริ่มต้น

# oc project default

Step 7 - สร้าง Docker Registry

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

แก้ไขสิทธิ์ของผู้ใช้

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

สร้างและแก้ไขรีจิสตรีรูปภาพ

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - สร้างเส้นทางเริ่มต้น

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

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

จากนั้นแก้ไขสิทธิ์ของผู้ใช้

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - กำหนดค่า DNS

ในการจัดการคำขอ URL OpenShift ต้องการสภาพแวดล้อม DNS ที่ใช้งานได้ จำเป็นต้องมีการกำหนดค่า DNS นี้เพื่อสร้างไวด์การ์ดซึ่งจำเป็นสำหรับการสร้างไวลด์การ์ด DNS ที่ชี้ไปที่เราเตอร์

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- ขั้นตอนสุดท้ายคือการตั้งค่าเซิร์ฟเวอร์ github บนเครื่องต้นแบบ OpenShift V3 ซึ่งเป็นทางเลือก สามารถทำได้อย่างง่ายดายโดยใช้ลำดับคำสั่งต่อไปนี้

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

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

ก่อนที่จะเริ่มการตั้งค่าและการปรับใช้แอปพลิเคชันจริงเราจำเป็นต้องเข้าใจคำศัพท์และแนวคิดพื้นฐานบางประการที่ใช้ใน OpenShift V3

ภาชนะและรูปภาพ

รูปภาพ

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

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

ในการดึงและสร้างภาพออกมาให้เรียกใช้คำสั่งต่อไปนี้ OC เป็นไคลเอนต์ในการสื่อสารกับสภาพแวดล้อม OpenShift หลังจากเข้าสู่ระบบ

$ oc create –f Tesing_for_Image_pull

คอนเทนเนอร์

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

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

ต่อไปนี้เป็นข้อกำหนดสำหรับการกำหนดคอนเทนเนอร์ที่มีรูปภาพหลายรูปทำงานอยู่ภายใน

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

ในการกำหนดค่าข้างต้นเราได้กำหนดพ็อดหลายคอนเทนเนอร์ที่มีภาพ Tomcat และ MongoDB สองภาพอยู่ภายใน

พ็อดและบริการ

พ็อด

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

Single Container Pod - สิ่งเหล่านี้สามารถสร้างได้อย่างง่ายดายด้วยคำสั่ง OC หรือโดยไฟล์ yml การกำหนดค่าพื้นฐาน

$ oc run <name of pod> --image = <name of the image from registry>

สร้างด้วยไฟล์ yaml ง่ายๆดังนี้

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

เมื่อสร้างไฟล์ด้านบนแล้วไฟล์จะสร้างพ็อดด้วยคำสั่งต่อไปนี้

$ oc create –f apache.yml

Multi-Container Pod- พ็อดหลายคอนเทนเนอร์คือพ็อดที่เรามีคอนเทนเนอร์มากกว่าหนึ่งตู้ที่ทำงานอยู่ภายในนั้น สร้างขึ้นโดยใช้ไฟล์ yaml ดังต่อไปนี้

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

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

Service- เนื่องจากเรามีชุดคอนเทนเนอร์ที่ทำงานอยู่ภายในพ็อดในทำนองเดียวกันเราจึงมีบริการที่สามารถกำหนดเป็นชุดพ็อดเชิงตรรกะได้ เป็นเลเยอร์นามธรรมที่ด้านบนของพ็อดซึ่งมีชื่อ IP และ DNS เดียวที่สามารถเข้าถึงพ็อดได้ บริการช่วยในการจัดการการกำหนดค่าการจัดสรรภาระงานและปรับขนาดพ็อดได้อย่างง่ายดาย ใน OpenShift เซอร์วิสคืออ็อบเจ็กต์ REST ซึ่งสามารถโพสต์ deification ไปยัง apiService บน OpenShift master เพื่อสร้างอินสแตนซ์ใหม่

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

สร้างและสตรีม

สร้าง

ใน OpenShift บิลด์เป็นกระบวนการเปลี่ยนรูปภาพเป็นคอนเทนเนอร์ เป็นการประมวลผลที่แปลงซอร์สโค้ดเป็นรูปภาพ กระบวนการสร้างนี้ทำงานบนกลยุทธ์ที่กำหนดไว้ล่วงหน้าในการสร้างซอร์สโค้ดเป็นรูปภาพ

การสร้างประมวลผลกลยุทธ์และแหล่งที่มาต่างๆ

สร้างกลยุทธ์

  • Source to Image- โดยพื้นฐานแล้วเป็นเครื่องมือที่ช่วยในการสร้างภาพที่ทำซ้ำได้ อิมเมจเหล่านี้อยู่ในขั้นตอนที่พร้อมสำหรับการรันโดยใช้คำสั่ง Docker run เสมอ

  • Docker Build - นี่คือกระบวนการที่สร้างภาพโดยใช้ไฟล์ Docker โดยเรียกใช้คำสั่ง Docker build แบบง่าย

  • Custom Build - นี่คืองานสร้างที่ใช้สำหรับสร้างอิมเมจ Docker พื้นฐาน

สร้างแหล่งที่มา

Git- แหล่งที่มานี้ถูกใช้เมื่อใช้ที่เก็บ git สำหรับการสร้างอิมเมจ Dockerfile เป็นทางเลือก การกำหนดค่าจากซอร์สโค้ดมีลักษณะดังต่อไปนี้

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - Dockerfile ใช้เป็นอินพุตในไฟล์กำหนดค่า

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

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

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

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

เส้นทางและเทมเพลต

เส้นทาง

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

ใน OpenShift เส้นทางถูกสร้างขึ้นโดยใช้เราเตอร์ที่ปรับใช้โดยผู้ดูแลระบบ OpenShift บนคลัสเตอร์ เราเตอร์ใช้เพื่อผูกพอร์ต HTTP (80) และ https (443) กับแอปพลิเคชันภายนอก

ต่อไปนี้เป็นโปรโตคอลประเภทต่างๆที่เส้นทางรองรับ -

  • HTTP
  • HTTPS
  • TSL และเว็บซ็อกเก็ต

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

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

จากนั้นรันคำสั่งต่อไปนี้และบริการจะถูกสร้างขึ้น

$ oc create -f ~/training/content/Openshift-Rservice.json

นี่คือลักษณะของบริการหลังการสร้าง

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

สร้างเส้นทางสำหรับบริการโดยใช้รหัสต่อไปนี้

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

เมื่อใช้คำสั่ง OC เพื่อสร้างเส้นทางระบบจะสร้างอินสแตนซ์ใหม่ของทรัพยากรเส้นทาง

เทมเพลต

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

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

การรับรองความถูกต้องและการอนุญาต

การรับรองความถูกต้อง

ใน OpenShift ในขณะที่กำหนดค่าโครงสร้างหลักและไคลเอ็นต์ต้นแบบจะมาพร้อมกับคุณสมบัติที่สร้างขึ้นของเซิร์ฟเวอร์ OAuth เซิร์ฟเวอร์ OAuth ใช้สำหรับสร้างโทเค็นซึ่งใช้สำหรับการตรวจสอบสิทธิ์กับ API เนื่องจาก OAuth มาเป็นการตั้งค่าเริ่มต้นสำหรับต้นแบบเราจึงมีการใช้ผู้ให้บริการข้อมูลประจำตัวอนุญาตทั้งหมดโดยค่าเริ่มต้น มีผู้ให้บริการข้อมูลประจำตัวที่แตกต่างกันซึ่งสามารถกำหนดค่าได้ที่/etc/openshift/master/master-config.yaml.

มีผู้ให้บริการข้อมูลประจำตัวประเภทต่างๆที่มีอยู่ใน OAuth

  • อนุญาตทั้งหมด
  • ปฏิเสธทั้งหมด
  • HTPasswd
  • LDAP
  • การรับรองความถูกต้องขั้นพื้นฐาน

อนุญาตทั้งหมด

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

ปฏิเสธทั้งหมด

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

ในการใช้ HTPasswd เราต้องตั้งค่า Httpd-tools บนเครื่องหลักก่อนจากนั้นกำหนดค่าในลักษณะเดียวกับที่เราทำกับผู้อื่น

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

การอนุญาต

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

นโยบายการอนุญาตถูกควบคุมโดยใช้ -

  • Rules
  • Roles
  • Bindings

การประเมินการอนุญาตทำได้โดยใช้ -

  • Identity
  • Action
  • Bindings

การใช้นโยบาย -

  • นโยบายคลัสเตอร์
  • นโยบายท้องถิ่น

OpenShift ประกอบด้วยค่ามัธยฐานสองประเภทในการสร้างและปรับใช้แอปพลิเคชันโดย GUI หรือ CLI ในบทนี้เราจะใช้ CLI เพื่อสร้างแอปพลิเคชันใหม่ เราจะใช้ไคลเอนต์ OC เพื่อสื่อสารกับสภาพแวดล้อม OpenShift

การสร้างแอปพลิเคชันใหม่

ใน OpenShift มีสามวิธีในการสร้างแอปพลิเคชันใหม่

  • จากซอร์สโค้ด
  • จากรูปภาพ
  • จากเทมเพลต

จากซอร์สโค้ด

เมื่อเราพยายามสร้างแอปพลิเคชันจากซอร์สโค้ด OpenShift จะค้นหาไฟล์ Docker ที่ควรอยู่ใน repo ซึ่งกำหนดขั้นตอนการสร้างแอปพลิเคชัน เราจะใช้ oc new-app เพื่อสร้างแอปพลิเคชัน

สิ่งแรกที่ควรคำนึงถึงในขณะที่ใช้ repo คือควรชี้ไปที่จุดเริ่มต้นใน repo จากที่ OpenShift จะดึงรหัสและสร้างขึ้น

หาก repo ถูกโคลนบนเครื่อง Docker ที่ติดตั้งไคลเอนต์ OC และผู้ใช้อยู่ในไดเร็กทอรีเดียวกันก็สามารถสร้างได้โดยใช้คำสั่งต่อไปนี้

$ oc new-app . <Hear. Denotes current working directory>

ต่อไปนี้เป็นตัวอย่างของการพยายามสร้างจาก repo ระยะไกลสำหรับสาขาเฉพาะ

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

ที่นี่ test1 เป็นสาขาที่เราพยายามสร้างแอปพลิเคชันใหม่ใน OpenShift

เมื่อระบุไฟล์ Docker ในที่เก็บเราจำเป็นต้องกำหนดกลยุทธ์การสร้างดังที่แสดงด้านล่าง

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

จากรูปภาพ

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

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

$ oc new-app - - docker-image tomcat

การใช้สตรีมรูปภาพ -

$ oc new-app tomcat:v1

จากเทมเพลต

สามารถใช้เทมเพลตสำหรับการสร้างแอปพลิเคชันใหม่ อาจเป็นเทมเพลตที่มีอยู่แล้วหรือสร้างเทมเพลตใหม่

ไฟล์ yaml ต่อไปนี้เป็นเทมเพลตที่สามารถใช้สำหรับการปรับใช้

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

พัฒนาและปรับใช้โปรแกรมประยุกต์บนเว็บ

การพัฒนาแอปพลิเคชันใหม่ใน OpenShift

ในการสร้างแอปพลิเคชันใหม่ใน OpenShift เราต้องเขียนโค้ดแอปพลิเคชันใหม่และสร้างโดยใช้คำสั่งสร้าง OpenShift OC ตามที่กล่าวไว้เรามีหลายวิธีในการสร้างภาพใหม่ ที่นี่เราจะใช้เทมเพลตเพื่อสร้างแอปพลิเคชัน เทมเพลตนี้จะสร้างแอปพลิเคชันใหม่เมื่อรันด้วยคำสั่ง oc new-app

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

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

เทมเพลต

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

คำจำกัดความของวัตถุ

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

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

เราต้องเรียกใช้คำสั่งต่อไปนี้เพื่อสร้างแอปพลิเคชัน

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

หากเราต้องการตรวจสอบบิลด์สามารถทำได้โดยใช้ -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

เราสามารถตรวจสอบแอปพลิเคชันที่ปรับใช้บน OpenShift โดยใช้ -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

เราสามารถตรวจสอบได้ว่ามีการสร้างบริการแอปพลิเคชันตามข้อกำหนดของบริการโดยใช้หรือไม่

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

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

ไฟล์ BuildConfig

ใน OpenShift BuildConfig เป็นอ็อบเจ็กต์ที่เหลือที่ใช้เพื่อเชื่อมต่อกับ API แล้วสร้างอินสแตนซ์ใหม่

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

ใน OpenShift มีกลยุทธ์การสร้างสี่ประเภท

  • กลยุทธ์ต้นทางสู่รูปภาพ
  • กลยุทธ์นักเทียบท่า
  • กลยุทธ์ที่กำหนดเอง
  • กลยุทธ์ท่อ

กลยุทธ์ที่มาสู่ภาพ

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

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

มีนโยบายกลยุทธ์หลายประการ

  • Forcepull
  • การสร้างที่เพิ่มขึ้น
  • งานสร้างภายนอก

กลยุทธ์นักเทียบท่า

ในขั้นตอนนี้ OpenShift ใช้ Dockerfile เพื่อสร้างภาพจากนั้นอัปโหลดภาพที่สร้างขึ้นไปยังรีจิสทรีของ Docker

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

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

  • จากรูปภาพ
  • เส้นทาง Dockerfile
  • ไม่มีแคช
  • แรงดึง

กลยุทธ์ที่กำหนดเอง

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

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

ประกอบด้วยกลยุทธ์การสร้างหลายแบบ

  • เปิดเผยซ็อกเก็ต Docker
  • Secrets
  • แรงดึง

กลยุทธ์ท่อส่ง

กลยุทธ์ไปป์ไลน์ใช้เพื่อสร้างท่อส่งแบบกำหนดเอง โดยทั่วไปจะใช้เพื่อนำเวิร์กโฟลว์ไปใช้ในท่อ ขั้นตอนการสร้างนี้ใช้ขั้นตอนการสร้างแบบกำหนดเองโดยใช้ภาษา Groovy DSL OpenShift จะสร้างงานไปป์ไลน์ใน Jenkins และดำเนินการ การไหลไปป์ไลน์นี้สามารถใช้ใน Jenkins ในกลยุทธ์นี้เราใช้ Jenkinsfile และต่อท้ายด้วยคำจำกัดความ buildconfig

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift CLI ใช้สำหรับจัดการแอปพลิเคชัน OpenShift จากบรรทัดคำสั่ง OpenShift CLI มีความสามารถในการจัดการวงจรชีวิตของแอปพลิเคชัน end-to-end โดยทั่วไปเราจะใช้ OC ซึ่งเป็นไคลเอนต์ OpenShift เพื่อสื่อสารกับ OpenShift

การตั้งค่า OpenShift CLI

ในการตั้งค่าไคลเอนต์ OC บนระบบปฏิบัติการอื่นเราจำเป็นต้องทำตามลำดับขั้นตอนต่างๆ

OC Client สำหรับ Windows

Step 1 - ดาวน์โหลด oc cli จากลิงค์ต่อไปนี้ https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - คลายซิปแพคเกจบนเส้นทางเป้าหมายบนเครื่อง

Step 3 - แก้ไขตัวแปรสภาพแวดล้อมเส้นทางของระบบ

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - ตรวจสอบการตั้งค่า OC บน Windows

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

OC Client สำหรับ Mac OS X

เราสามารถดาวน์โหลดไบนารีการตั้งค่า Mac OS สำหรับตำแหน่งเดียวกับ Windows และคลายซิปในภายหลังที่ตำแหน่งและกำหนดเส้นทางของการปฏิบัติการภายใต้ตัวแปร PATH สภาพแวดล้อม

Alternatively

เราสามารถใช้ Home brew และตั้งค่าได้โดยใช้คำสั่งต่อไปนี้

$ brew install openshift-cli

OC Client สำหรับ Linux

ในหน้าเดียวกันเรามีไฟล์ tar สำหรับการติดตั้ง Linux ที่สามารถใช้สำหรับการติดตั้ง ต่อมาสามารถตั้งค่าตัวแปรพา ธ โดยชี้ไปยังตำแหน่งปฏิบัติการนั้น ๆ

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

คลายไฟล์ tar โดยใช้คำสั่งต่อไปนี้

$ tar –xf < path to the OC setup tar file >

รันคำสั่งต่อไปนี้เพื่อตรวจสอบการพิสูจน์ตัวตน

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

ไฟล์คอนฟิกูเรชัน CLI

ไฟล์คอนฟิกูเรชัน OC CLI ใช้สำหรับจัดการการเชื่อมต่อเซิร์ฟเวอร์ OpenShift หลายตัวและกลไกการพิสูจน์ตัวตน ไฟล์คอนฟิกูเรชันนี้ยังใช้สำหรับจัดเก็บและจัดการหลายโปรไฟล์และเพื่อสลับระหว่างโปรไฟล์ ไฟล์คอนฟิกูเรชันปกติมีลักษณะดังต่อไปนี้

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

การตั้งค่าไคลเอนต์ CLI

สำหรับการตั้งค่าข้อมูลรับรองผู้ใช้

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

สำหรับการตั้งค่าคลัสเตอร์

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

ตัวอย่าง

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

สำหรับการตั้งค่าบริบท

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

โปรไฟล์ CLI

ในไฟล์คอนฟิกูเรชัน CLI ไฟล์เดียวเราสามารถมีได้หลายโปรไฟล์โดยแต่ละโปรไฟล์มีการกำหนดค่าเซิร์ฟเวอร์ OpenShift ที่แตกต่างกันซึ่งสามารถใช้ในภายหลังเพื่อสลับระหว่างโปรไฟล์ CLI ที่แตกต่างกัน

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

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

หากต้องการตรวจสอบโปรไฟล์ปัจจุบันที่ใช้งานสามารถทำได้โดยใช้ -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

หากเราต้องการเปลี่ยนไปใช้ CLI อื่นสามารถทำได้จากบรรทัดคำสั่งโดยใช้คำสั่งต่อไปนี้

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

ใช้คำสั่งด้านบนเราสามารถสลับระหว่างโปรไฟล์ เมื่อใดก็ตามที่เราต้องการดูการกำหนดค่าเราสามารถใช้คำสั่ง $ oc config view

OpenShift CLI สามารถดำเนินการกำหนดค่าพื้นฐานและขั้นสูงการจัดการการเพิ่มเติมและการปรับใช้แอปพลิเคชันทั้งหมด

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

คำสั่งพื้นฐาน

ตารางต่อไปนี้แสดงรายการคำสั่ง OC พื้นฐาน

ซีเนียร์ คำสั่งและคำอธิบาย
1

Types

บทนำเกี่ยวกับแนวคิดและประเภท
2

Login

ล็อกอินเข้าสู่เซิร์ฟเวอร์
3

new-project

ขอโครงการใหม่
4

new-app

สร้างแอปพลิเคชันใหม่
5

Status

แสดงภาพรวมของโครงการปัจจุบัน
6

Project

เปลี่ยนไปใช้โปรเจ็กต์อื่น
7

Projects

แสดงโครงการที่มีอยู่
8

Explain

เอกสารทรัพยากร
9

Cluster

เริ่มและหยุดคลัสเตอร์ OpenShift

เข้าสู่ระบบ

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

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

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

ตัวเลือก -

-p, --password = " - รหัสผ่านจะแจ้งหากไม่มีให้

-u, --username = " - ชื่อผู้ใช้จะแจ้งหากไม่ได้ระบุ

--certificate-authority = "- เส้นทางสู่ใบรับรอง ไฟล์สำหรับผู้ออกใบรับรอง

--insecure-skip-tls-verify = false- หากเป็นจริงใบรับรองของเซิร์ฟเวอร์จะไม่ถูกตรวจสอบความถูกต้อง ซึ่งจะทำให้การเชื่อมต่อ HTTPS ของคุณไม่ปลอดภัย

--token = " - โทเค็นผู้ถือสำหรับการรับรองความถูกต้องไปยังเซิร์ฟเวอร์ API

หากต้องการรับรายละเอียดทั้งหมดเกี่ยวกับคำสั่งใด ๆ ให้ใช้ไฟล์ oc <Command Name> --help คำสั่ง

สร้างและปรับใช้คำสั่ง

ตารางต่อไปนี้แสดงรายการคำสั่งสร้างและปรับใช้

ซีเนียร์ คำสั่งและคำอธิบาย
1

Rollout

จัดการการปรับใช้ Kubernetes หรือการปรับใช้ OpenShift
2

Deploy

ดูเริ่มต้นยกเลิกหรือลองปรับใช้อีกครั้ง
3

Rollback

เปลี่ยนบางส่วนของแอปพลิเคชันกลับสู่สถานะก่อนหน้า
4

new-build

สร้างคอนฟิกูเรชันบิลด์ใหม่
5

start-build

เริ่มงานสร้างใหม่
6

cancel-build

ยกเลิกการทำงานรอดำเนินการหรืองานสร้างใหม่
7

import-image

นำเข้าภาพจาก Docker Registry
8

Tag

แท็กรูปภาพที่มีอยู่ลงในสตรีมรูปภาพ

คำสั่งการจัดการแอปพลิเคชัน

ตารางต่อไปนี้แสดงรายการคำสั่งการจัดการแอปพลิเคชัน

ซีเนียร์ คำสั่งและคำอธิบาย
1

Get

แสดงทรัพยากรหนึ่งหรือหลายรายการ
2

Describe

แสดงรายละเอียดของทรัพยากรเฉพาะหรือกลุ่มของทรัพยากร
3

Edit

แก้ไขทรัพยากรบนเซิร์ฟเวอร์
4

Set

คำสั่งที่ช่วยตั้งค่าคุณลักษณะเฉพาะบนวัตถุ
5

Label

อัปเดตป้ายกำกับบนทรัพยากร
6

Annotate

อัปเดตคำอธิบายประกอบบนทรัพยากร
7

Expose

แสดงแอปพลิเคชันที่จำลองแบบเป็นบริการหรือเส้นทาง
8

Delete

ลบทรัพยากรอย่างน้อยหนึ่งรายการ
9

Scale

เปลี่ยนจำนวนพ็อดในการปรับใช้
10

Autoscale

ปรับขนาดการกำหนดค่าการปรับใช้การปรับใช้การจำลองตัวควบคุมหรือชุดแบบจำลองโดยอัตโนมัติ
11

Secrets

จัดการความลับ
12

Serviceaccounts

จัดการบัญชีบริการในโครงการของคุณ

คำสั่งการแก้ไขปัญหาและการดีบัก

ตารางต่อไปนี้แสดงรายการคำสั่งการแก้ไขปัญหาและการดีบัก

ซีเนียร์ คำสั่งและคำอธิบาย
1

logs

พิมพ์บันทึกสำหรับทรัพยากร
2

Rsh

เริ่มเซสชันเชลล์ในพ็อด
3

Rsync

คัดลอกไฟล์ระหว่างระบบไฟล์ภายในและพ็อด
4

port-forward

ส่งต่อพอร์ตภายในเครื่องอย่างน้อยหนึ่งพอร์ตไปยังพ็อด
5

Debug

เปิดอินสแตนซ์ใหม่ของพ็อดสำหรับการดีบัก
6

Exec

ดำเนินการคำสั่งในคอนเทนเนอร์
7

Procy

เรียกใช้พร็อกซีไปยังเซิร์ฟเวอร์ Kubernetes API
9

Attach

แนบกับคอนเทนเนอร์ที่กำลังทำงานอยู่
10

Run

เรียกใช้รูปภาพเฉพาะบนคลัสเตอร์
11

Cp

คัดลอกไฟล์และไดเรกทอรีไปยังและจากคอนเทนเนอร์

คำสั่งขั้นสูง

ตารางต่อไปนี้แสดงรายการคำสั่งขั้นสูง

ซีเนียร์ คำสั่งและคำอธิบาย
1

adm

เครื่องมือสำหรับจัดการคลัสเตอร์
2

create

สร้างทรัพยากรตามชื่อไฟล์หรือ stdin
3

replace

แทนที่ทรัพยากรด้วยชื่อไฟล์หรือ stdin
4

apply

ใช้การกำหนดค่ากับทรัพยากรโดยใช้ชื่อไฟล์หรือ stdin
5

patch

อัปเดตฟิลด์ของทรัพยากรโดยใช้แพตช์ผสานเชิงกลยุทธ์
6

process

ประมวลผลเทมเพลตลงในรายการทรัพยากร
7

export

ส่งออกทรัพยากรเพื่อให้สามารถใช้ที่อื่นได้
8

extract

แยกข้อมูลลับหรือกำหนดค่าแมปไปยังดิสก์
9

idle

ทรัพยากรที่ปรับขนาดได้ไม่ได้ใช้งาน
10

observe

สังเกตการเปลี่ยนแปลงของทรัพยากรและตอบสนองต่อสิ่งเหล่านี้ (ทดลอง)
11

policy

จัดการนโยบายการอนุญาต
12

auth

ตรวจสอบการอนุญาต
13

convert

แปลงไฟล์กำหนดค่าระหว่าง API เวอร์ชันต่างๆ
14

import

คำสั่งที่นำเข้าแอปพลิเคชัน

การตั้งค่าคำสั่ง

ตารางต่อไปนี้แสดงรายการคำสั่งการตั้งค่า

ซีเนียร์ คำสั่งและคำอธิบาย
1

Logout

สิ้นสุดเซสชันเซิร์ฟเวอร์ปัจจุบัน
2

Config

เปลี่ยนไฟล์คอนฟิกูเรชันสำหรับไคลเอนต์
3

Whoami

ส่งคืนข้อมูลเกี่ยวกับเซสชันปัจจุบัน
4

Completion

รหัสเสร็จสิ้นเชลล์เอาต์พุตสำหรับเชลล์ที่ระบุ (bash หรือ zsh)

OpenShift ใช้วิธีการติดตั้งสองวิธีในการตั้งค่าคลัสเตอร์ OpenShift

  • วิธีการติดตั้งอย่างรวดเร็ว
  • วิธีการกำหนดค่าขั้นสูง

การตั้งค่าคลัสเตอร์

วิธีการติดตั้งด่วน

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

Interactive method

$ atomic-openshift-installer install

สิ่งนี้มีประโยชน์เมื่อต้องการเรียกใช้การตั้งค่าแบบโต้ตอบ

Unattended installation method

วิธีนี้ใช้เมื่อต้องการตั้งค่าวิธีการติดตั้งโดยไม่ต้องใส่ข้อมูลโดยผู้ใช้สามารถกำหนดไฟล์ yaml การกำหนดค่าและวางไว้ใต้ ~/.config/openshift/ด้วยชื่อของ installer.cfg.yml จากนั้นสามารถรันคำสั่งต่อไปนี้เพื่อติดตั้งไฟล์–u tag.

$ atomic-openshift-installer –u install

โดยค่าเริ่มต้นจะใช้ไฟล์กำหนดค่าที่อยู่ภายใต้ ~/.config/openshift/. ในทางกลับกัน Ansible ใช้เป็นข้อมูลสำรองของการติดตั้ง

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

ที่นี่เรามีตัวแปรเฉพาะบทบาทซึ่งสามารถกำหนดได้หากต้องการตั้งค่าตัวแปรเฉพาะบางตัว

เมื่อเสร็จแล้วเราสามารถตรวจสอบการติดตั้งโดยใช้คำสั่งต่อไปนี้

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

การติดตั้งขั้นสูง

การติดตั้งขั้นสูงขึ้นอยู่กับการกำหนดค่า Ansible โดยสมบูรณ์ซึ่งมีการกำหนดค่าโฮสต์และนิยามตัวแปรที่เกี่ยวข้องกับการกำหนดค่าหลักและโหนด ซึ่งประกอบด้วยรายละเอียดทั้งหมดเกี่ยวกับการกำหนดค่า

เมื่อเรามีการตั้งค่าและ playbook พร้อมแล้วเราสามารถเรียกใช้คำสั่งต่อไปนี้เพื่อตั้งค่าคลัสเตอร์

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

การเพิ่มโฮสต์ในคลัสเตอร์

เราสามารถเพิ่มโฮสต์ในคลัสเตอร์โดยใช้ -

  • เครื่องมือติดตั้งด่วน
  • วิธีการกำหนดค่าขั้นสูง

Quick installation toolทำงานได้ทั้งในโหมดโต้ตอบและไม่โต้ตอบ ใช้คำสั่งต่อไปนี้

$ atomic-openshift-installer -u -c </path/to/file> scaleup

รูปแบบของการปรับขนาดรูปลักษณ์ของไฟล์คอนฟิกูเรชันแอ็พพลิเคชันสามารถใช้เพื่อเพิ่มทั้งมาสเตอร์และโหนด

วิธีการกำหนดค่าขั้นสูง

ด้วยวิธีนี้เราอัปเดตไฟล์โฮสต์ของ Ansible จากนั้นเพิ่มโหนดหรือรายละเอียดเซิร์ฟเวอร์ใหม่ในไฟล์นี้ ไฟล์คอนฟิกูเรชันมีลักษณะดังต่อไปนี้

[OSEv3:children]
masters
nodes
new_nodes
new_master

ในไฟล์โฮสต์ Ansible เดียวกันให้เพิ่มรายละเอียดตัวแปรเกี่ยวกับโหนดใหม่ดังที่แสดงด้านล่าง

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

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

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

การจัดการบันทึกคลัสเตอร์

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

มีเครื่องมือเพียงไม่กี่รายการตามที่ระบุไว้ซึ่งสามารถนำไปใช้ในการจัดการบันทึกได้

  • Fluentd
  • ELK
  • Kabna
  • Nagios
  • Splunk

ELK stack- สแต็กนี้มีประโยชน์ในขณะที่พยายามรวบรวมบันทึกจากโหนดทั้งหมดและนำเสนอในรูปแบบที่เป็นระบบ ELK stack แบ่งออกเป็นสามประเภทหลัก ๆ

ElasticSearch - ส่วนใหญ่ตอบสนองได้สำหรับการรวบรวมข้อมูลจากคอนเทนเนอร์ทั้งหมดและวางไว้ในตำแหน่งส่วนกลาง

Fluentd - ใช้สำหรับป้อนบันทึกที่รวบรวมไปยังเครื่องยนต์คอนเทนเนอร์ที่ยืดหยุ่น

Kibana - อินเทอร์เฟซแบบกราฟิกที่ใช้สำหรับการนำเสนอข้อมูลที่รวบรวมเป็นข้อมูลที่มีประโยชน์ในอินเทอร์เฟซแบบกราฟิก

ประเด็นสำคัญประการหนึ่งที่ควรทราบคือเมื่อระบบนี้ถูกปรับใช้บนคลัสเตอร์ระบบจะเริ่มรวบรวมบันทึกจากโหนดทั้งหมด

การวินิจฉัยบันทึก

OpenShift มี inbuilt oc adm dignosticsคำสั่งกับ OC ที่สามารถใช้สำหรับวิเคราะห์สถานการณ์ผิดพลาดหลาย ๆ เครื่องมือนี้สามารถใช้ได้จากต้นแบบในฐานะผู้ดูแลคลัสเตอร์ ยูทิลิตี้นี้มีประโยชน์มากคือการแก้ไขปัญหาและการให้เกียรติปัญหาที่ทราบ สิ่งนี้ทำงานบนไคลเอนต์หลักและโหนด

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

  • AggregatedLogging
  • AnalyzeLogs
  • ClusterRegistry
  • ClusterRoleBindings
  • ClusterRoles
  • ClusterRouter
  • ConfigContexts
  • DiagnosticPod
  • MasterConfigCheck
  • MasterNode
  • MetricsApiProxy
  • NetworkCheck
  • NodeConfigCheck
  • NodeDefinitions
  • ServiceExternalIPs
  • UnitStatus

เราสามารถเรียกใช้ด้วยคำสั่งต่อไปนี้

$ oc adm diagnostics <DiagnosticName>

การอัพเกรดคลัสเตอร์

การอัปเกรดคลัสเตอร์เกี่ยวข้องกับการอัปเกรดหลายสิ่งภายในคลัสเตอร์และการอัปเดตคลัสเตอร์ด้วยคอมโพเนนต์และการอัปเกรดใหม่ สิ่งนี้เกี่ยวข้องกับ -

  • การอัพเกรดส่วนประกอบหลัก
  • การอัพเกรดส่วนประกอบโหนด
  • การอัปเกรดนโยบาย
  • การอัพเกรดเส้นทาง
  • การอัปเกรดสตรีมรูปภาพ

ในการดำเนินการอัปเกรดทั้งหมดนี้เราจำเป็นต้องจัดเตรียมตัวติดตั้งหรือยูทิลิตีอย่างรวดเร็วก่อน เพื่อที่เราจะต้องอัปเดตยูทิลิตี้ต่อไปนี้ -

  • atomic-openshift-utils
  • atomic-openshift-excluder
  • atomic-openshift-docker-excluder
  • แพ็คเกจ etcd

ก่อนที่จะเริ่มการอัพเกรดเราต้องทำการสำรองข้อมูล etcd บนเครื่องหลักซึ่งสามารถทำได้โดยใช้คำสั่งต่อไปนี้

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

การอัพเกรดส่วนประกอบหลัก

ใน OpenShift master เราเริ่มการอัปเกรดโดยอัปเดตไฟล์ etcd จากนั้นย้ายไปที่ Docker สุดท้ายเราเรียกใช้ผู้บริหารอัตโนมัติเพื่อให้คลัสเตอร์อยู่ในตำแหน่งที่ต้องการ อย่างไรก็ตามก่อนที่จะเริ่มการอัปเกรดเราจำเป็นต้องเปิดใช้งานแพ็กเกจ atomic openshift บนมาสเตอร์แต่ละตัวก่อน ซึ่งสามารถทำได้โดยใช้คำสั่งต่อไปนี้

Step 1 - ลบแพ็คเกจ atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - อัพเกรด etcd กับปรมาจารย์ทั้งหมด

$ yum update etcd

Step 3 - เริ่มบริการของ etcd ใหม่และตรวจสอบว่าเริ่มต้นสำเร็จหรือไม่

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - อัปเกรดแพ็คเกจ Docker

$ yum update docker

Step 5 - เริ่มบริการ Docker ใหม่และตรวจสอบว่าขึ้นถูกต้องหรือไม่

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - เมื่อเสร็จแล้วให้รีบูตระบบด้วยคำสั่งต่อไปนี้

$ systemctl reboot $ journalctl -r -u docker

Step 7 - สุดท้ายเรียกใช้ atomic-executer เพื่อรับแพ็คเกจกลับไปที่รายการยำที่ไม่รวม

$ atomic-openshift-excluder exclude

ไม่มีการบังคับในการอัปเกรดนโยบายดังกล่าวจำเป็นต้องอัปเกรดหากมีการแนะนำเท่านั้นซึ่งสามารถตรวจสอบได้ด้วยคำสั่งต่อไปนี้

$ oadm policy reconcile-cluster-roles

ในกรณีส่วนใหญ่เราไม่จำเป็นต้องอัปเดตข้อกำหนดของนโยบาย

การอัพเกรดส่วนประกอบโหนด

เมื่อการอัปเดตหลักเสร็จสมบูรณ์เราสามารถเริ่มอัปเกรดโหนดได้ สิ่งหนึ่งที่ควรทราบคือระยะเวลาในการอัปเกรดควรสั้นเพื่อหลีกเลี่ยงปัญหาใด ๆ ในคลัสเตอร์

Step 1 - ลบแพ็คเกจ OpenShift atomic ทั้งหมดออกจากโหนดทั้งหมดที่คุณต้องการทำการอัพเกรด

$ atomic-openshift-excluder unexclude

Step 2 - ถัดไปปิดการใช้งานการตั้งเวลาโหนดก่อนอัปเกรด

$ oadm manage-node <node name> --schedulable = false

Step 3 - จำลองโหนดทั้งหมดจากโฮสต์ปัจจุบันไปยังโฮสต์อื่น

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - อัปเกรดการตั้งค่า Docker บนโฮสต์

$ yum update docker

Step 5 - เริ่มบริการ Docker ใหม่จากนั้นเริ่มโหนดบริการ Docker

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - ตรวจสอบว่าทั้งคู่เริ่มต้นอย่างถูกต้องหรือไม่

$ journalctl -r -u atomic-openshift-node

Step 7 - หลังจากอัปเกรดเสร็จสิ้นให้รีบูตเครื่องโหนด

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - เปิดใช้งานการตั้งเวลาบนโหนดอีกครั้ง

$ oadm manage-node <node> --schedulable.

Step 9 - เรียกใช้ atomic-openshift executer เพื่อรับแพ็คเกจ OpenShift กลับมาที่โหนด

$ atomic-openshift-excluder exclude

Step 10 - สุดท้ายตรวจสอบว่ามีโหนดทั้งหมดหรือไม่

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

การปรับขนาดอัตโนมัติเป็นคุณลักษณะใน OpenShift ที่แอปพลิเคชันที่ปรับใช้สามารถปรับขนาดและจมได้ตามและเมื่อต้องการตามข้อกำหนดบางประการ ในแอปพลิเคชัน OpenShift การปรับขนาดอัตโนมัติเรียกอีกอย่างว่าการปรับขนาดอัตโนมัติของพ็อด มีสองtypes of application scaling ดังต่อไปนี้.

มาตราส่วนแนวตั้ง

การปรับขนาดตามแนวตั้งเป็นเรื่องของการเพิ่มพลังงานให้กับเครื่องเดียวซึ่งหมายถึงการเพิ่ม CPU และฮาร์ดดิสก์มากขึ้น วิธีนี้เป็นวิธีเก่าของ OpenShift ซึ่งตอนนี้ OpenShift ไม่รองรับ

มาตราส่วนแนวนอน

การปรับขนาดประเภทนี้มีประโยชน์เมื่อมีความจำเป็นในการจัดการคำขอเพิ่มเติมโดยการเพิ่มจำนวนเครื่อง

ใน OpenShift มีไฟล์ two methods to enable the scaling feature.

  • การใช้ไฟล์คอนฟิกูเรชันการปรับใช้
  • ในขณะที่เรียกใช้ภาพ

การใช้ Deployment Configuration File

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

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

เมื่อเรามีไฟล์แล้วเราจำเป็นต้องบันทึกด้วยรูปแบบ yaml และรันคำสั่งต่อไปนี้สำหรับการปรับใช้

$ oc create –f <file name>.yaml

ขณะเรียกใช้รูปภาพ

คุณยังสามารถปรับขนาดอัตโนมัติโดยไม่มีไฟล์ yaml ได้โดยใช้สิ่งต่อไปนี้ oc autoscale คำสั่งในบรรทัดคำสั่ง oc

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

คำสั่งนี้จะสร้างไฟล์ประเภทเดียวกันที่สามารถใช้อ้างอิงได้ในภายหลัง

กลยุทธ์การปรับใช้ใน OpenShift

กลยุทธ์การปรับใช้ใน OpenShift กำหนดขั้นตอนการปรับใช้ด้วยวิธีการที่แตกต่างกัน ใน OpenShift ต่อไปนี้คือไฟล์important types of deployment strategies.

  • กลยุทธ์การหมุน
  • สร้างกลยุทธ์ใหม่
  • กลยุทธ์ที่กำหนดเอง

ต่อไปนี้เป็นตัวอย่างของไฟล์คอนฟิกูเรชันการปรับใช้ซึ่งส่วนใหญ่ใช้สำหรับการปรับใช้บนโหนด OpenShift

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

ในไฟล์ Deploymentconfig ด้านบนเรามีกลยุทธ์เป็น Rolling

เราสามารถใช้คำสั่ง OC ต่อไปนี้สำหรับการปรับใช้

$ oc deploy <deployment_config> --latest

กลยุทธ์กลิ้ง

กลยุทธ์การกลิ้งใช้สำหรับการอัปเดตหรือการปรับใช้งาน กระบวนการนี้ยังสนับสนุน life-cycle hooks ซึ่งใช้สำหรับการแทรกโค้ดลงในกระบวนการปรับใช้ใด ๆ

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

สร้างกลยุทธ์ใหม่

กลยุทธ์การปรับใช้นี้มีคุณสมบัติพื้นฐานบางประการของกลยุทธ์การปรับใช้แบบกลิ้งและยังรองรับการใช้งานตลอดอายุการใช้งาน

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

กลยุทธ์ที่กำหนดเอง

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

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

ในบทนี้เราจะพูดถึงหัวข้อต่างๆเช่นวิธีจัดการโหนดกำหนดค่าบัญชีบริการเป็นต้น

การกำหนดค่าหลักและโหนด

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

สำหรับไฟล์คอนฟิกูเรชันหลัก

$ openshift start master --write-config = /openshift.local.config/master

สำหรับไฟล์คอนฟิกูเรชันโหนด

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

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

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

ไฟล์คอนฟิกูเรชันโหนด

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

นี่คือลักษณะของไฟล์คอนฟิกูเรชันโหนด เมื่อเรามีไฟล์คอนฟิกูเรชันเหล่านี้แล้วเราสามารถรันคำสั่งต่อไปนี้เพื่อสร้างเซิร์ฟเวอร์หลักและโหนด

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

การจัดการโหนด

ใน OpenShift เรามียูทิลิตี้บรรทัดคำสั่ง OC ซึ่งส่วนใหญ่จะใช้สำหรับการดำเนินการทั้งหมดใน OpenShift เราสามารถใช้คำสั่งต่อไปนี้เพื่อจัดการกับโหนด

สำหรับการแสดงรายการโหนด

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

การอธิบายรายละเอียดเกี่ยวกับโหนด

$ oc describe node <node name>

การลบโหนด

$ oc delete node <node name>

รายการพ็อดบนโหนด

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

การประเมินพ็อดบนโหนด

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Configuration Authentication

ใน OpenShift master มีเซิร์ฟเวอร์ OAuth ในตัวซึ่งสามารถใช้สำหรับจัดการการพิสูจน์ตัวตน ผู้ใช้ OpenShift ทั้งหมดจะได้รับโทเค็นจากเซิร์ฟเวอร์นี้ซึ่งช่วยให้พวกเขาสื่อสารกับ OpenShift API

มีระดับการพิสูจน์ตัวตนที่แตกต่างกันใน OpenShift ซึ่งสามารถกำหนดค่าพร้อมกับไฟล์กำหนดค่าหลัก

  • อนุญาตทั้งหมด
  • ปฏิเสธทั้งหมด
  • HTPasswd
  • LDAP
  • การรับรองความถูกต้องขั้นพื้นฐาน
  • ขอส่วนหัว

ในขณะที่กำหนดการกำหนดค่าหลักเราสามารถกำหนดนโยบายการระบุตัวตนซึ่งเราสามารถกำหนดประเภทของนโยบายที่เราต้องการใช้

อนุญาตทั้งหมด

อนุญาตทั้งหมด

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

ปฏิเสธทั้งหมด

การดำเนินการนี้จะปฏิเสธการเข้าถึงชื่อผู้ใช้และรหัสผ่านทั้งหมด

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd ใช้เพื่อตรวจสอบชื่อผู้ใช้และรหัสผ่านกับรหัสผ่านของไฟล์ที่เข้ารหัส

สำหรับการสร้างไฟล์ที่เข้ารหัสคำสั่งต่อไปนี้

$ htpasswd </path/to/users.htpasswd> <user_name>

การใช้ไฟล์เข้ารหัส

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

ผู้ให้บริการข้อมูลประจำตัว LDAP

สิ่งนี้ใช้สำหรับการพิสูจน์ตัวตน LDAP โดยที่เซิร์ฟเวอร์ LDAP มีบทบาทสำคัญในการพิสูจน์ตัวตน

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

การรับรองความถูกต้องขั้นพื้นฐาน

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

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

การกำหนดค่าบัญชีบริการ

บัญชีบริการเป็นวิธีที่ยืดหยุ่นในการเข้าถึง OpenShift API โดยเปิดเผยชื่อผู้ใช้และรหัสผ่านสำหรับการตรวจสอบสิทธิ์

การเปิดใช้งานบัญชีบริการ

บัญชีบริการใช้คู่คีย์สาธารณะและคีย์ส่วนตัวสำหรับการตรวจสอบสิทธิ์ การพิสูจน์ตัวตนกับ API ทำได้โดยใช้คีย์ส่วนตัวและตรวจสอบความถูกต้องกับคีย์สาธารณะ

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

การสร้างบัญชีบริการ

ใช้คำสั่งต่อไปนี้เพื่อสร้างบัญชีบริการ

$ Openshift cli create service account <name of server account>

ทำงานกับ HTTP Proxy

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

สามารถทำได้โดยการเพิ่มนิยามพร็อกซีบนไฟล์หลักและไฟล์โหนดที่อยู่ภายใต้ /etc/sysconfig. สิ่งนี้คล้ายกับที่เราทำกับแอปพลิเคชันอื่น ๆ

มาสเตอร์แมชชีน

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

เครื่องโหนด

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

เมื่อเสร็จแล้วเราต้องรีสตาร์ทเครื่องต้นแบบและโหนด

สำหรับ Docker Pull

/ etc / sysconfig / นักเทียบท่า

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

ในการทำให้พ็อดทำงานในสภาพแวดล้อมพร็อกซีสามารถทำได้โดยใช้ -

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

คำสั่งสภาพแวดล้อม OC สามารถใช้เพื่ออัพเดต env ที่มีอยู่

OpenShift Storage พร้อม NFS

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

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

จากนั้นใช้คำสั่ง OC create create Persistent Volume

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

อ้างสิทธิ์ในไดรฟ์ข้อมูลที่สร้างขึ้น

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

สร้างการอ้างสิทธิ์

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

การจัดการผู้ใช้และบทบาท

การดูแลระบบผู้ใช้และบทบาทใช้ในการจัดการผู้ใช้การเข้าถึงและการควบคุมโครงการต่างๆ

การสร้างผู้ใช้

เทมเพลตที่กำหนดไว้ล่วงหน้าสามารถใช้เพื่อสร้างผู้ใช้ใหม่ใน OpenShift

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

ใช้ oc create –f <file name> เพื่อสร้างผู้ใช้

$ oc create –f vipin.yaml

ใช้คำสั่งต่อไปนี้เพื่อลบผู้ใช้ใน OpenShift

$ oc delete user <user name>

การ จำกัด การเข้าถึงของผู้ใช้

ResourceQuotas และ LimitRanges ใช้สำหรับ จำกัด ระดับการเข้าถึงของผู้ใช้ ใช้สำหรับ จำกัด พ็อดและคอนเทนเนอร์บนคลัสเตอร์

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

การสร้างใบเสนอราคาโดยใช้การกำหนดค่าข้างต้น

$ oc create -f resource-quota.yaml –n –Openshift-sample

การอธิบายอ้างทรัพยากร

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

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

ข้อ จำกัด โครงการของผู้ใช้

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

ก่อนอื่นเราต้องกำหนดวัตถุที่เก็บมูลค่าของโครงการประเภทบรอนซ์เงินและทองได้ สิ่งเหล่านี้ต้องทำในไฟล์ master-confif.yaml

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

รีสตาร์ทเซิร์ฟเวอร์หลัก

การกำหนดผู้ใช้ไปยังระดับใดระดับหนึ่ง

$ oc label user vipin level = gold

ย้ายผู้ใช้ออกจากป้ายกำกับหากจำเป็น

$ oc label user <user_name> level-

การเพิ่มบทบาทให้กับผู้ใช้

$ oadm policy add-role-to-user 
      
        <user_name>

การลบบทบาทออกจากผู้ใช้

$ oadm policy remove-role-from-user 
      
        <user_name>

การเพิ่มบทบาทคลัสเตอร์ให้กับผู้ใช้

$ oadm policy add-cluster-role-to-user 
      
        <user_name>

การลบบทบาทคลัสเตอร์ออกจากผู้ใช้

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

การเพิ่มบทบาทให้กับกลุ่ม

$ oadm policy add-role-to-user 
      
        <user_name>

การลบบทบาทออกจากกลุ่ม

$ oadm policy remove-cluster-role-from-user 
      
        <user_name>

การเพิ่มบทบาทคลัสเตอร์ให้กับกลุ่ม

$ oadm policy add-cluster-role-to-group 
      
        <groupname>

การลบบทบาทคลัสเตอร์ออกจากกลุ่ม

$ oadm policy remove-cluster-role-from-group <role> <groupname>

ผู้ใช้สำหรับการดูแลคลัสเตอร์

นี่เป็นหนึ่งในบทบาทที่ทรงพลังที่สุดที่ผู้ใช้มีความสามารถในการจัดการคลัสเตอร์ที่สมบูรณ์ตั้งแต่การสร้างจนถึงการลบคลัสเตอร์

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

ผู้ใช้ที่มีพลังสูงสุด

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift สร้างขึ้นบน Docker และ Kubernetes คอนเทนเนอร์ทั้งหมดสร้างขึ้นที่ด้านบนของคลัสเตอร์ Docker ซึ่งโดยพื้นฐานแล้วบริการ Kubernetes ที่อยู่ด้านบนของเครื่อง Linux โดยใช้คุณสมบัติ Kubernetes orchestrations

ในกระบวนการนี้เราสร้าง Kubernetes master ซึ่งควบคุมโหนดทั้งหมดและปรับใช้คอนเทนเนอร์ไปยังโหนดทั้งหมด หน้าที่หลักของ Kubernetes คือการควบคุมคลัสเตอร์ OpenShift และขั้นตอนการปรับใช้โดยใช้ไฟล์การกำหนดค่าประเภทอื่น เช่นเดียวกับใน Kubernetes เราใช้ kubctl ในลักษณะเดียวกับที่เราใช้ยูทิลิตี้บรรทัดคำสั่ง OC เพื่อสร้างและปรับใช้คอนเทนเนอร์บนโหนดคลัสเตอร์

ต่อไปนี้เป็นไฟล์กำหนดค่าประเภทต่างๆที่ใช้ในการสร้างอ็อบเจ็กต์ประเภทต่างๆในคลัสเตอร์

  • Images
  • POD
  • Service
  • ตัวควบคุมการจำลอง
  • ชุดจำลอง
  • Deployment

รูปภาพ

อิมเมจ Kubernetes (Docker) เป็นส่วนประกอบสำคัญของ Containerized Infrastructure ณ ตอนนี้ Kubernetes รองรับเฉพาะDockerภาพ คอนเทนเนอร์แต่ละอันในพ็อดจะมีอิมเมจ Docker ทำงานอยู่ข้างใน

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

POD

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

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

บริการ

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

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

ตัวควบคุมการจำลอง

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

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

ชุดจำลอง

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

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

การปรับใช้

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

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

ไฟล์กำหนดค่าทั้งหมดสามารถใช้เพื่อสร้างออบเจ็กต์ Kubernetes ตามลำดับ

$ Kubectl create –f <file name>.yaml

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

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

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

การรักษาความปลอดภัย OpenShift ส่วนใหญ่เป็นการรวมกันของสององค์ประกอบที่จัดการกับข้อ จำกัด ด้านความปลอดภัยเป็นหลัก

  • ข้อ จำกัด บริบทความปลอดภัย (SCC)
  • บัญชีบริการ

ข้อ จำกัด บริบทความปลอดภัย (SCC)

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

OpenShift จัดเตรียมชุดของ SCC ที่กำหนดไว้ล่วงหน้าซึ่งผู้ดูแลระบบสามารถใช้แก้ไขและขยายได้

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

หากต้องการใช้ scc ใด ๆ ที่กำหนดไว้ล่วงหน้าสามารถทำได้โดยเพียงเพิ่มผู้ใช้หรือกลุ่มลงในกลุ่ม scc

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

บัญชีบริการ

โดยทั่วไปแล้วบัญชีบริการจะใช้เพื่อควบคุมการเข้าถึง OpenShift master API ซึ่งจะถูกเรียกเมื่อคำสั่งหรือคำขอเริ่มทำงานจากเครื่องหลักหรือโหนดใด ๆ

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

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

ความปลอดภัยของตู้คอนเทนเนอร์

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

Image Provenance - มีการติดตั้งระบบการติดฉลากที่ปลอดภัยซึ่งระบุได้อย่างชัดเจนและไม่เปลี่ยนแปลงว่าคอนเทนเนอร์ที่ทำงานอยู่ในสภาพแวดล้อมการผลิตมาจากที่ใด

Security Scanning - เครื่องสแกนภาพจะตรวจสอบภาพทั้งหมดโดยอัตโนมัติเพื่อหาช่องโหว่ที่ทราบ

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

Isolation and Least Privilege- คอนเทนเนอร์ทำงานด้วยทรัพยากรและสิทธิ์ขั้นต่ำที่จำเป็นในการทำงานอย่างมีประสิทธิภาพ พวกเขาไม่สามารถรบกวนโฮสต์หรือคอนเทนเนอร์อื่น ๆ ได้มากเกินไป

Runtime Threat Detection - ความสามารถที่ตรวจจับภัยคุกคามที่ใช้งานอยู่กับแอปพลิเคชันคอนเทนเนอร์ในรันไทม์และตอบสนองโดยอัตโนมัติ

Access Controls - โมดูลความปลอดภัยของ Linux เช่น AppArmor หรือ SELinux ใช้เพื่อบังคับใช้การควบคุมการเข้าถึง

มีวิธีการหลักสองสามวิธีในการเก็บถาวรความปลอดภัยของคอนเทนเนอร์

  • การควบคุมการเข้าถึงผ่าน oAuth
  • ผ่านเว็บคอนโซลแบบบริการตนเอง
  • โดยใบรับรองของแพลตฟอร์ม

การควบคุมการเข้าถึงผ่าน OAuth

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

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์ OAuth โปรดดูบทที่ 5 ของบทช่วยสอนนี้

ผ่านเว็บคอนโซลแบบบริการตนเอง

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

  • เปิดใช้เลเยอร์ TCL แล้ว
  • ใช้ใบรับรอง x.509 สำหรับการตรวจสอบสิทธิ์
  • ยึดคอนฟิกูเรชัน etcd บนเครื่องหลัก

โดยใบรับรองของแพลตฟอร์ม

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

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีสร้างใบรับรองที่กำหนดเองโปรดไปที่ลิงค์ต่อไปนี้ -

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

ความปลอดภัยของเครือข่าย

ใน OpenShift จะใช้ Software Defined Networking (SDN) สำหรับการสื่อสาร เนมสเปซเครือข่ายใช้สำหรับแต่ละพ็อดในคลัสเตอร์โดยแต่ละพ็อดจะได้รับ IP ของตัวเองและช่วงของพอร์ตเพื่อรับทราฟฟิกเครือข่าย ด้วยวิธีนี้เราสามารถแยกพ็อดเนื่องจากไม่สามารถสื่อสารกับพ็อดในโครงการอื่นได้

การแยกโครงการ

ซึ่งสามารถทำได้โดยผู้ดูแลคลัสเตอร์โดยใช้สิ่งต่อไปนี้ oadm command จาก CLI

$ oadm pod-network isolate-projects <project name 1> <project name 2>

ซึ่งหมายความว่าโครงการที่กำหนดไว้ข้างต้นไม่สามารถสื่อสารกับโครงการอื่นในคลัสเตอร์ได้

Volume Security

การรักษาความปลอดภัยระดับเสียงหมายถึงการรักษาความปลอดภัยของ PV และ PVC ของโครงการในคลัสเตอร์ OpenShift ส่วนใหญ่มีสี่ส่วนในการควบคุมการเข้าถึงไดรฟ์ข้อมูลใน OpenShift

  • กลุ่มเสริม
  • fsGroup
  • runAsUser
  • seLinuxOptions

Supplemental Groups - กลุ่มเสริมคือกลุ่ม Linux ปกติ เมื่อกระบวนการทำงานในระบบจะรันด้วย ID ผู้ใช้และ ID กลุ่ม กลุ่มเหล่านี้ใช้สำหรับควบคุมการเข้าถึงพื้นที่เก็บข้อมูลที่แชร์

ตรวจสอบการเมาท์ NFS โดยใช้คำสั่งต่อไปนี้

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

ตรวจสอบรายละเอียด NFS บนเมาท์เซิร์ฟเวอร์โดยใช้คำสั่งต่อไปนี้

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/ opt / NFS /ส่งออกสามารถเข้าถึงได้โดยโพสต์454265 และกลุ่ม 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup ย่อมาจากกลุ่มระบบไฟล์ซึ่งใช้สำหรับการเพิ่มกลุ่มเสริมคอนเทนเนอร์ ID กลุ่มเสริมใช้สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ fsGroup ใช้สำหรับบล็อกที่เก็บข้อมูล

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser ใช้ ID ผู้ใช้สำหรับการสื่อสาร สิ่งนี้ใช้ในการกำหนดอิมเมจคอนเทนเนอร์ในนิยามพ็อด ผู้ใช้ ID เดียวสามารถใช้ได้ในทุกคอนเทนเนอร์หากจำเป็น

ในขณะที่เรียกใช้คอนเทนเนอร์รหัสที่กำหนดจะจับคู่กับ ID เจ้าของในการส่งออก ถ้า ID ที่ระบุถูกกำหนดไว้ภายนอก ID นั้นจะกลายเป็นโกลบอลสำหรับคอนเทนเนอร์ทั้งหมดในพ็อด หากมีการกำหนดด้วยพ็อดเฉพาะมันจะกลายเป็นเฉพาะสำหรับคอนเทนเนอร์เดียว

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265
ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved