นี่คือบันทึกของสุนทรพจน์ и .
นี่คือเรื่องราวของโปรเจ็กต์ที่ใช้ระบบการจัดการการกำหนดค่าที่เขียนขึ้นเอง และเหตุใดการย้ายไปยัง Ansible จึงใช้เวลา 18 เดือน
วันที่ -XXXXX: ก่อนเริ่มต้น
ในตอนแรก โครงสร้างพื้นฐานประกอบด้วยโฮสต์จำนวนมากที่ทำงานแยกจากกันซึ่งใช้ Hyper-V การสร้างเครื่องเสมือนต้องใช้หลายขั้นตอน เช่น วางดิสก์ในตำแหน่งที่ถูกต้อง ลงทะเบียน DNS จอง DHCP วางการกำหนดค่า VM ในพื้นที่เก็บข้อมูล git กระบวนการนี้มีการใช้เครื่องจักรบางส่วน แต่ตัวอย่างเช่น VM ถูกกระจายระหว่างโฮสต์ด้วยมือ ตัวอย่างเช่น นักพัฒนาสามารถแก้ไขการกำหนดค่า VM ใน git และนำไปใช้ได้โดยการรีบูต VM
โซลูชันการจัดการการกำหนดค่าแบบกำหนดเอง
ฉันสงสัยว่าแนวคิดดั้งเดิมนั้นถูกมองว่าเป็น IaC: VM ไร้สัญชาติจำนวนมากที่รีเซ็ตสถานะเป็นศูนย์เมื่อรีบูต การจัดการการกำหนดค่า VM คืออะไร ตามแผนผังมันดูง่าย:
- MAC แบบคงที่ถูกจับลงสำหรับ VM
- ISO พร้อม CoreOS และดิสก์สำหรับบูตเชื่อมต่อกับ VM
- CoreOS เปิดตัวสคริปต์การปรับแต่งโดยการดาวน์โหลดจากเว็บเซิร์ฟเวอร์ตาม IP
- สคริปต์ดาวน์โหลดการกำหนดค่า VM ผ่าน SCP ตามที่อยู่ IP
- footcloth ของไฟล์ systemd unit และ footcloth ของสคริปต์ทุบตีถูกเปิดใช้งาน
โซลูชันนี้มีปัญหาที่ชัดเจนหลายประการ:
- CoreOS ISO เลิกใช้งานแล้ว
- การดำเนินการอัตโนมัติที่ซับซ้อนและเวทมนตร์มากมายเมื่อทำการโยกย้าย/สร้าง VM
- ความยากในการอัปเดตและเมื่อจำเป็นต้องใช้ซอฟต์แวร์เวอร์ชันใดเวอร์ชันหนึ่ง สนุกยิ่งขึ้นด้วยโมดูลเคอร์เนล
- ไม่ได้รับ VM โดยไม่มีข้อมูลเช่น VM ปรากฏขึ้นพร้อมกับดิสก์ที่มีการติดตั้งข้อมูลผู้ใช้เพิ่มเติม
- มีคนทำให้การพึ่งพาหน่วย systemd เสียหายอย่างต่อเนื่องและ CoreOS จะหยุดทำงานเมื่อรีบูตเครื่อง เป็นเรื่องยากที่จะจับสิ่งนี้โดยใช้เครื่องมือที่มีอยู่ใน CoreOS
- การจัดการความลับ
- ไม่มีซีเอ็ม มีการกำหนดค่า bash และ YML สำหรับ CoreOS
หากต้องการใช้การกำหนดค่า VM คุณต้องรีบูตเครื่อง แต่อาจไม่สามารถรีบูตได้ ดูเหมือนว่าจะเป็นปัญหาที่ชัดเจน แต่ไม่มีดิสก์ถาวร - ไม่มีที่ไหนที่จะบันทึกบันทึกได้ โอเค เรามาลองเพิ่มตัวเลือกการโหลดเคอร์เนลเพื่อที่บันทึกจะถูกส่งไป แต่ไม่เลย มันซับซ้อนขนาดไหน
วันที่ 0: รับรู้ปัญหา
มันเป็นโครงสร้างพื้นฐานการพัฒนาตามปกติ: เจนกินส์ สภาพแวดล้อมการทดสอบ การตรวจสอบ การลงทะเบียน CoreOS ได้รับการออกแบบมาเพื่อโฮสต์คลัสเตอร์ k8s เช่น ปัญหาคือวิธีใช้ CoreOS ขั้นตอนแรกคือการเลือกสแต็ก เราตัดสินเมื่อ:
- CentOS เป็นการกระจายฐานเพราะว่า นี่คือการกระจายไปยังสภาพแวดล้อมการใช้งานจริงที่ใกล้เคียงที่สุด
- เบิ้ล สำหรับการจัดการการกำหนดค่าเพราะว่า มีการตรวจสอบอย่างละเอียดเกี่ยวกับเรื่องนี้
- เจนกิ้นส์ เป็นกรอบการทำงานสำหรับกระบวนการที่มีอยู่โดยอัตโนมัติเพราะว่า มันถูกนำไปใช้อย่างแข็งขันสำหรับกระบวนการพัฒนาแล้ว
- Hyper-V เป็นแพลตฟอร์มเสมือนจริง มีเหตุผลหลายประการที่อยู่นอกเหนือขอบเขตของเรื่องราว แต่สรุปคือ เราไม่สามารถใช้คลาวด์ได้ เราต้องใช้ฮาร์ดแวร์ของเราเอง
วันที่ 30: แก้ไขข้อตกลงที่มีอยู่ - ข้อตกลงเป็นรหัส
เมื่อกองชัดเจนแล้ว การเตรียมการสำหรับการเคลื่อนย้ายก็เริ่มขึ้น การแก้ไขข้อตกลงที่มีอยู่ในรูปแบบของรหัส (ข้อตกลงเป็นรหัส!). การเปลี่ยนแปลง ใช้แรงงาน -> การใช้เครื่องจักร -> อัตโนมัติ.
1. กำหนดค่า VM
Ansible ทำงานได้ดีมากในเรื่องนี้ ด้วยการเคลื่อนไหวร่างกายขั้นต่ำ คุณสามารถควบคุมการกำหนดค่า VM ได้:
- สร้างที่เก็บคอมไพล์
- เราใส่รายการ VM ไว้ในรายการ การกำหนดค่าใน Playbook และบทบาท
- เรากำลังตั้งค่าทาสเจนกินส์พิเศษซึ่งคุณสามารถเรียกใช้ Ansible ได้
- เราสร้างงานและกำหนดค่าเจนกินส์
กระบวนการแรกพร้อมแล้ว ข้อตกลงได้รับการแก้ไขแล้ว
2. สร้าง VM ใหม่
ทุกอย่างที่นี่ไม่สะดวกมาก การสร้าง VM บน Hyper-V จาก Linux ไม่สะดวกนัก หนึ่งในความพยายามในการใช้เครื่องจักรกระบวนการนี้คือ:
- Ansbile เชื่อมต่อผ่าน WinRM ไปยังโฮสต์ windows
- Ansible รันสคริปต์ PowerShell
- สคริปต์ Powershell สร้าง VM ใหม่
- การใช้ Hyper-V/ScVMM เมื่อสร้าง VM ใน guest OS ชื่อโฮสต์จะได้รับการกำหนดค่า
- เมื่ออัปเดตการเช่า DHCP VM จะส่งชื่อโฮสต์
- การรวม ddns & dhcp มาตรฐานบนฝั่ง Domain Controller จะกำหนดค่าบันทึก DNS
- คุณสามารถเพิ่ม VM ลงในสินค้าคงคลังของคุณและกำหนดค่าด้วย Ansible
3.สร้างเทมเพลต VM
พวกเขาไม่ได้ประดิษฐ์อะไรเลยที่นี่ - พวกเขาเอาคนบรรจุหีบห่อ
- เพิ่มแพ็คเกอร์ เริ่มต้นการตั้งค่าไปยังที่เก็บ git
- การตั้งค่าทาสเจนกินส์พิเศษด้วย Hyper-v และ Packer
- เราสร้างงานและกำหนดค่าเจนกินส์
ลิงค์นี้ทำงานอย่างไร:
- Packer สร้าง VM เปล่าและรับ ISO
- เมื่อ VM บูท Packer จะป้อนคำสั่งลงใน bootloader เพื่อใช้ไฟล์ kickstart ของเราจากฟล็อปปี้ดิสก์หรือ http
- Anaconda เปิดตัวด้วยการกำหนดค่าของเรา และการกำหนดค่าระบบปฏิบัติการเริ่มต้นเสร็จสิ้นแล้ว
- Packer รอให้ VM พร้อมใช้งาน
- Packer ภายใน VM ทำงานในโหมดโลคัล
- Ansible ใช้บทบาทเดียวกันกับที่ใช้ในขั้นตอนที่ 1 ทุกประการ
- Packer ส่งออกเทมเพลต VM
วันที่ #75: ปรับโครงสร้างข้อตกลงใหม่โดยไม่ทำลาย = ทดสอบได้ + ครัวทดสอบ
การจับภาพแบบแผนในโค้ดอาจไม่เพียงพอ ท้ายที่สุดแล้ว หากคุณต้องการเปลี่ยนแปลงบางสิ่งบางอย่างทั้งภายในและภายนอกของกระบวนการ คุณสามารถทำลายบางสิ่งบางอย่างได้ ดังนั้นในกรณีของโครงสร้างพื้นฐาน การทดสอบโครงสร้างพื้นฐานนี้จึงปรากฏขึ้น เพื่อประสานความรู้ภายในทีม เราได้เริ่มทดสอบบทบาท Ansible ฉันจะไม่ลงลึกเพราะว่า... มีบทความบรรยายเหตุการณ์ ณ ขณะนั้นด้วย (สปอยล์นี่ไม่ใช่เวอร์ชันสุดท้ายและต่อมาทุกอย่างก็ซับซ้อนมากขึ้น ).
วันที่ #130: อาจไม่จำเป็นต้องใช้ CentOS+ansible ใช่ไหม อาจจะ openshift เหรอ?
เราต้องเข้าใจว่ากระบวนการแนะนำโครงสร้างพื้นฐานไม่ใช่กระบวนการเดียวเท่านั้นและยังมีโครงการย่อยย่อยอีกด้วย ตัวอย่างเช่น มีคำขอมาเพื่อเปิดใช้แอปพลิเคชันของเราใน openshift และส่งผลให้มีการวิจัยมานานกว่าหนึ่งสัปดาห์ ซึ่งทำให้กระบวนการเคลื่อนย้ายช้าลง ผลลัพธ์ปรากฏว่า openshift ไม่ครอบคลุมทุกความต้องการ คุณต้องมีฮาร์ดแวร์จริง หรืออย่างน้อยก็ความสามารถในการเล่นกับเคอร์เนล
วันที่ #170: Openshift ไม่เหมาะ ลองใช้ Windows Azure Pack ไหม
Hyper-V ไม่เป็นมิตรมากนัก SCVMM ไม่ได้ทำให้ดีขึ้นมากนัก แต่มีบางอย่างเช่น Windows Azure Pack ซึ่งเป็นส่วนเสริมของ SCVMM และเลียนแบบ Azure แต่ในความเป็นจริงแล้ว ผลิตภัณฑ์ดูเหมือนถูกทิ้งร้าง: เอกสารมีลิงก์เสียและกระจัดกระจายมาก แต่ในฐานะที่เป็นส่วนหนึ่งของการศึกษาตัวเลือกในการทำให้ชีวิตระบบคลาวด์ของเราง่ายขึ้น พวกเขาก็พิจารณาเรื่องนี้เช่นกัน
วันที่ #250: Windows Azure Pack ไม่ค่อยดีนัก เรายังคงอยู่ใน SCVMM
Windows Azure Pack ดูมีแนวโน้มดี แต่ก็มีการตัดสินใจว่าจะไม่นำ WAP ที่มีความซับซ้อนเข้าสู่ระบบเพื่อประโยชน์ของคุณสมบัติที่ไม่จำเป็น และยังคงอยู่กับ SCVMM
วันที่ 360: กินช้างทีละชิ้น
เพียงหนึ่งปีต่อมา แพลตฟอร์มสำหรับการย้ายไปก็พร้อม และเริ่มกระบวนการขนย้าย เพื่อจุดประสงค์นี้ งาน SMART จึงถูกตั้งค่าไว้ เราตรวจสอบ VM ทั้งหมดและเริ่มค้นหาการกำหนดค่าทีละรายการ อธิบายใน Ansible และครอบคลุมด้วยการทดสอบ
วันที่ #450: คุณได้ระบบแบบไหนมา?
กระบวนการนี้ไม่น่าสนใจ เป็นเรื่องปกติ โดยสังเกตได้ว่าการกำหนดค่าส่วนใหญ่ค่อนข้างง่ายหรือมีลักษณะสมมาตร และตามหลักการ Pareto 80% ของการกำหนดค่า VM ต้องการ 20% ของเวลา ตามหลักการเดียวกัน ใช้เวลา 80% ในการเตรียมการเคลื่อนไหว และเพียง 20% ในการเคลื่อนไหวเท่านั้น
วันที่ #540: รอบชิงชนะเลิศ
เกิดอะไรขึ้นใน 18 เดือน?
- ข้อตกลงกลายเป็นรหัส
- การใช้แรงงานคน -> การใช้เครื่องจักร -> อัตโนมัติ.
การเชื่อมโยง
ที่มา: will.com