หากโครงสร้างพื้นฐานด้านไอทีของคุณเติบโตเร็วเกินไป ไม่ช้าก็เร็วคุณจะพบกับทางเลือก: เพิ่มทรัพยากรมนุษย์เชิงเส้นเพื่อรองรับโครงสร้างพื้นฐานหรือเริ่มระบบอัตโนมัติ จนถึงจุดหนึ่ง เราอาศัยอยู่ในกระบวนทัศน์แรก และจากนั้นเส้นทางอันยาวไกลสู่ Infrastructure-as-Code ก็เริ่มต้นขึ้น
แน่นอนว่า NSPK ไม่ใช่สตาร์ทอัพ แต่บรรยากาศดังกล่าวครอบงำบริษัทในช่วงปีแรกของการดำรงอยู่ และนั่นเป็นปีที่น่าสนใจมาก ชื่อของฉันคือ ฉันสนับสนุนโครงสร้างพื้นฐาน Linux ที่มีข้อกำหนดความพร้อมใช้งานสูงมานานกว่า 10 ปี เขาเข้าร่วมทีม NSPK ในเดือนมกราคม 2016 และน่าเสียดายที่เขาไม่เห็นจุดเริ่มต้นของการดำรงอยู่ของบริษัท แต่มาถึงขั้นตอนของการเปลี่ยนแปลงครั้งใหญ่
โดยทั่วไปเราสามารถพูดได้ว่าทีมงานของเราจัดหาผลิตภัณฑ์ให้กับบริษัท 2 รายการ ประการแรกคือโครงสร้างพื้นฐาน เมลควรใช้งานได้ DNS ควรใช้งานได้ และตัวควบคุมโดเมนควรให้คุณเข้าสู่เซิร์ฟเวอร์ที่ไม่ควรขัดข้อง ภูมิทัศน์ด้านไอทีของบริษัทมีขนาดใหญ่มาก! นี่คือระบบที่สำคัญต่อธุรกิจและภารกิจ ข้อกำหนดด้านความพร้อมใช้งานสำหรับบางรุ่นคือ 99,999 ผลิตภัณฑ์ที่สองคือเซิร์ฟเวอร์ทั้งแบบกายภาพและเสมือน ที่มีอยู่แล้วจำเป็นต้องได้รับการตรวจสอบ และจะต้องส่งมอบสิ่งใหม่ให้กับลูกค้าจากหลายแผนกอย่างสม่ำเสมอ ในบทความนี้ ฉันต้องการมุ่งเน้นไปที่วิธีที่เราพัฒนาโครงสร้างพื้นฐานที่รับผิดชอบต่อวงจรชีวิตของเซิร์ฟเวอร์
จุดเริ่มต้นของการเดินทาง
ในช่วงเริ่มต้นของการเดินทาง กลุ่มเทคโนโลยีของเรามีลักษณะดังนี้:
ระบบปฏิบัติการ CentOS 7
ตัวควบคุมโดเมน FreeIPA
ระบบอัตโนมัติ - Ansible(+Tower), Cobbler
ทั้งหมดนี้อยู่ใน 3 โดเมน ซึ่งกระจายอยู่ในศูนย์ข้อมูลหลายแห่ง ในศูนย์ข้อมูลแห่งหนึ่ง มีระบบสำนักงานและไซต์ทดสอบ ส่วนที่เหลือมี PROD
การสร้างเซิร์ฟเวอร์ ณ จุดหนึ่งมีลักษณะดังนี้:
ในเทมเพลต VM นั้น CentOS มีค่าน้อยที่สุดและค่าขั้นต่ำที่ต้องการนั้นเหมือนกับ /etc/resolv.conf ที่ถูกต้อง ส่วนที่เหลือจะมาจาก Ansible
ซีเอ็มดีบี - Excel
หากเซิร์ฟเวอร์เป็นแบบฟิสิคัล แทนที่จะคัดลอกเครื่องเสมือน ระบบปฏิบัติการได้รับการติดตั้งโดยใช้ Cobbler - ที่อยู่ MAC ของเซิร์ฟเวอร์เป้าหมายจะถูกเพิ่มในการกำหนดค่า Cobbler เซิร์ฟเวอร์จะได้รับที่อยู่ IP ผ่าน DHCP จากนั้นระบบปฏิบัติการ ถูกเพิ่ม
ในตอนแรกเรายังพยายามจัดการการกำหนดค่าบางอย่างใน Cobbler ด้วยซ้ำ แต่เมื่อเวลาผ่านไป สิ่งนี้เริ่มนำมาซึ่งปัญหาเกี่ยวกับการพกพาการกำหนดค่าทั้งไปยังศูนย์ข้อมูลอื่นและโค้ด Ansible สำหรับการเตรียม VM
ในเวลานั้น พวกเราหลายคนมองว่า Ansible เป็นส่วนเสริมที่สะดวกของ Bash และไม่ได้ละทิ้งการออกแบบโดยใช้เชลล์และ sed โดยรวม Bashsible สิ่งนี้นำไปสู่ความจริงที่ว่าหาก Playbook ไม่ทำงานบนเซิร์ฟเวอร์ด้วยเหตุผลบางประการ มันจะง่ายกว่าที่จะลบเซิร์ฟเวอร์ แก้ไข Playbook และเรียกใช้อีกครั้ง โดยพื้นฐานแล้วไม่มีการกำหนดเวอร์ชันของสคริปต์ ไม่มีความสามารถในการพกพาการกำหนดค่า
ตัวอย่างเช่น เราต้องการเปลี่ยนการกำหนดค่าบางอย่างบนเซิร์ฟเวอร์ทั้งหมด:
- เราเปลี่ยนการกำหนดค่าบนเซิร์ฟเวอร์ที่มีอยู่ในเซ็กเมนต์เชิงตรรกะ/ศูนย์ข้อมูล บางครั้งก็ไม่ได้อยู่ในวันเดียว - ข้อกำหนดในการเข้าถึงและกฎหมายจำนวนมากไม่อนุญาตให้ใช้การเปลี่ยนแปลงทั้งหมดในคราวเดียว และการเปลี่ยนแปลงบางอย่างอาจเป็นอันตรายได้และจำเป็นต้องรีสตาร์ทบางอย่าง ตั้งแต่บริการไปจนถึงระบบปฏิบัติการเอง
- แก้ไขมันใน Ansible
- เราแก้ไขมันใน Cobbler
- ทำซ้ำ N ครั้งสำหรับแต่ละเซ็กเมนต์เชิงตรรกะ/ศูนย์ข้อมูล
เพื่อให้การเปลี่ยนแปลงทั้งหมดเป็นไปอย่างราบรื่น จำเป็นต้องคำนึงถึงปัจจัยหลายประการ และการเปลี่ยนแปลงเกิดขึ้นอย่างต่อเนื่อง
- การรีแฟคเตอร์โค้ด ansible ไฟล์คอนฟิกูเรชัน
- การเปลี่ยนแปลงแนวทางปฏิบัติที่ดีที่สุดภายใน
- การเปลี่ยนแปลงขึ้นอยู่กับผลการวิเคราะห์เหตุการณ์/อุบัติเหตุ
- การเปลี่ยนแปลงมาตรฐานความปลอดภัยทั้งภายในและภายนอก ตัวอย่างเช่น PCI DSS ได้รับการอัปเดตตามข้อกำหนดใหม่ทุกปี
การเติบโตของโครงสร้างพื้นฐานและจุดเริ่มต้นของการเดินทาง
จำนวนเซิร์ฟเวอร์/โดเมนลอจิคัล/ศูนย์ข้อมูลเพิ่มขึ้น และจำนวนข้อผิดพลาดในการกำหนดค่าก็เพิ่มขึ้นด้วย เมื่อถึงจุดหนึ่ง เราได้มาถึงแนวทางสามประการที่ต้องพัฒนาการจัดการการกำหนดค่า:
- ระบบอัตโนมัติ ควรหลีกเลี่ยงข้อผิดพลาดของมนุษย์ในการดำเนินการซ้ำๆ ให้มากที่สุด
- การทำซ้ำ การจัดการโครงสร้างพื้นฐานจะง่ายกว่ามากเมื่อสามารถคาดการณ์ได้ การกำหนดค่าเซิร์ฟเวอร์และเครื่องมือสำหรับการจัดเตรียมควรเหมือนกันทุกที่ นี่เป็นสิ่งสำคัญสำหรับทีมผลิตภัณฑ์ด้วย หลังจากการทดสอบแล้ว แอปพลิเคชันจะต้องได้รับการรับรองว่าจะสิ้นสุดในสภาพแวดล้อมการใช้งานจริงที่กำหนดค่าคล้ายกับสภาพแวดล้อมการทดสอบ
- ความเรียบง่ายและความโปร่งใสในการเปลี่ยนแปลงการจัดการการกำหนดค่า
ยังคงต้องเพิ่มเครื่องมือสองสามอย่าง
เราเลือก GitLab CE เป็นที่เก็บโค้ดของเรา อย่างน้อยก็สำหรับโมดูล CI/CD ในตัว
ห้องนิรภัยแห่งความลับ - Hashicorp Vault รวม สำหรับ API ที่ยอดเยี่ยม
การทดสอบการกำหนดค่าและบทบาทที่รับได้ – โมเลกุล+เทสตินฟรา การทดสอบจะเร็วขึ้นมากหากคุณเชื่อมต่อกับไมโทเจนที่รับแสงได้ ในเวลาเดียวกันเราเริ่มเขียน CMDB และ orchestrator ของเราเองสำหรับการปรับใช้อัตโนมัติ (ในภาพด้านบน Cobbler) แต่นี่เป็นเรื่องราวที่แตกต่างไปจากเดิมอย่างสิ้นเชิงซึ่งเพื่อนร่วมงานของฉันและผู้พัฒนาหลักของระบบเหล่านี้จะเล่าให้ฟังในอนาคต
ทางเลือกของเรา:
โมเลกุล + เทสตินฟรา
Ansible + ทาวเวอร์ + AWX
World of Servers + DITNET (การพัฒนาของตัวเอง)
พายผลไม้
Gitlab + นักวิ่ง GitLab
ห้องนิรภัย Hashicorp
โดยวิธีการเกี่ยวกับบทบาทที่สามารถเข้าใจได้ ในตอนแรกมีเพียงบทบาทเดียว แต่หลังจากการปรับโครงสร้างใหม่หลายครั้ง มี 17 บทบาท ฉันขอแนะนำอย่างยิ่งให้แบ่งบทบาทใหญ่โตออกเป็นบทบาท idempotent ซึ่งสามารถเปิดใช้แยกกันได้ นอกจากนี้ คุณยังสามารถเพิ่มแท็กได้อีกด้วย เราแบ่งบทบาทตามฟังก์ชันการทำงาน - เครือข่าย การบันทึก แพ็คเกจ ฮาร์ดแวร์ โมเลกุล ฯลฯ โดยทั่วไปเราปฏิบัติตามกลยุทธ์ด้านล่างนี้ ฉันไม่ยืนยันว่านี่เป็นความจริงเพียงอย่างเดียว แต่มันใช้ได้ผลสำหรับเรา
- การคัดลอกเซิร์ฟเวอร์จาก “ภาพสีทอง” นั้นชั่วร้าย!ข้อเสียเปรียบหลักคือคุณไม่ทราบแน่ชัดว่ารูปภาพอยู่ในสถานะใด และการเปลี่ยนแปลงทั้งหมดจะเกิดขึ้นกับรูปภาพทั้งหมดในฟาร์มเสมือนจริงทั้งหมด
- ใช้ไฟล์การกำหนดค่าเริ่มต้นให้น้อยที่สุดและตกลงกับแผนกอื่นๆ ว่าคุณเป็นผู้รับผิดชอบไฟล์ระบบหลักตัวอย่างเช่น:
- ปล่อย /etc/sysctl.conf ว่างไว้ การตั้งค่าควรอยู่ใน /etc/sysctl.d/ เท่านั้น ค่าเริ่มต้นของคุณในไฟล์เดียว กำหนดเองสำหรับแอปพลิเคชันในอีกไฟล์หนึ่ง
- ใช้ไฟล์แทนที่เพื่อแก้ไขหน่วย systemd
- สร้างเทมเพลตการกำหนดค่าทั้งหมดและรวมไว้ทั้งหมด หากเป็นไปได้ ห้ามใช้ sed หรือแอนะล็อกใน Playbook
- การรีแฟคเตอร์โค้ดระบบการจัดการคอนฟิกูเรชัน:
- แบ่งงานออกเป็นเอนทิตีเชิงตรรกะและเขียนใหม่เป็นบทบาท
- ใช้ลินเตอร์! Ansible-lint, yaml-lint ฯลฯ
- เปลี่ยนแนวทางของคุณ! ไม่มีการทุบตี จำเป็นต้องอธิบายสถานะของระบบ
- สำหรับบทบาท Ansible ทั้งหมด คุณต้องเขียนการทดสอบในระดับโมเลกุลและสร้างรายงานวันละครั้ง
- ในกรณีของเรา หลังจากเตรียมการทดสอบ (ซึ่งมีมากกว่า 100 รายการ) พบข้อผิดพลาดประมาณ 70000 รายการ ใช้เวลาหลายเดือนในการแก้ไข
การดำเนินการของเรา
ดังนั้น บทบาทที่สามารถวิเคราะห์ได้จึงพร้อม สร้างเทมเพลต และตรวจสอบโดยลินเตอร์ และแม้แต่คอมไพล์ก็ยังถูกยกขึ้นทุกหนทุกแห่ง แต่คำถามเกี่ยวกับการส่งมอบโค้ดที่เชื่อถือได้ไปยังส่วนต่างๆ ยังคงเปิดอยู่ เราตัดสินใจซิงโครไนซ์กับสคริปต์ ดูเหมือนว่า:
หลังจากการเปลี่ยนแปลงมาถึง CI จะถูกเปิดใช้งาน เซิร์ฟเวอร์ทดสอบจะถูกสร้างขึ้น บทบาทจะถูกเผยแพร่ และทดสอบโดยโมเลกุล หากทุกอย่างเรียบร้อยดี โค้ดจะไปที่สาขาผลิตภัณฑ์ แต่เราไม่ได้ใช้รหัสใหม่กับเซิร์ฟเวอร์ที่มีอยู่ในเครื่อง นี่เป็นตัวหยุดชนิดหนึ่งที่จำเป็นสำหรับความพร้อมใช้งานสูงของระบบของเรา และเมื่อโครงสร้างพื้นฐานมีขนาดใหญ่ขึ้น กฎของคนจำนวนมากก็เข้ามามีบทบาท แม้ว่าคุณจะแน่ใจว่าการเปลี่ยนแปลงนั้นไม่เป็นอันตราย แต่ก็สามารถนำไปสู่ผลลัพธ์ที่เลวร้ายได้
นอกจากนี้ยังมีตัวเลือกมากมายสำหรับการสร้างเซิร์ฟเวอร์ ในที่สุดเราก็เลือกสคริปต์ Python แบบกำหนดเอง และสำหรับ CI ที่สามารถอ่านได้:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"นี่คือสิ่งที่เราได้มา ระบบยังคงมีชีวิต และพัฒนาต่อไป
- 17 บทบาท Ansible สำหรับการตั้งค่าเซิร์ฟเวอร์ แต่ละบทบาทได้รับการออกแบบมาเพื่อแก้ปัญหางานลอจิคัลที่แยกจากกัน (การบันทึก การตรวจสอบ การให้สิทธิ์ผู้ใช้ การตรวจสอบ ฯลฯ)
- การทดสอบบทบาท โมเลกุล + การทดสอบอินฟรา
- การพัฒนาของตัวเอง: CMDB + Orchestrator
- เวลาในการสร้างเซิร์ฟเวอร์คือ ~30 นาที เป็นอัตโนมัติและไม่ขึ้นอยู่กับคิวงาน
- สถานะ/การตั้งชื่อเดียวกันของโครงสร้างพื้นฐานในทุกเซ็กเมนต์ - เพลย์บุ๊ก พื้นที่เก็บข้อมูล องค์ประกอบการจำลองเสมือน
- ตรวจสอบสถานะเซิร์ฟเวอร์รายวันพร้อมสร้างรายงานความคลาดเคลื่อนกับมาตรฐาน
ฉันหวังว่าเรื่องราวของฉันจะเป็นประโยชน์กับผู้ที่อยู่ในช่วงเริ่มต้นการเดินทาง คุณใช้สแต็กอัตโนมัติแบบใด
ที่มา: will.com