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

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

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

ให้ฉันอธิบายให้ชัดเจน: เรื่องราวของฉันสะท้อนถึงเครื่องมือและกระบวนการจัดการการกำหนดค่าที่ทีมของเราใช้

คอมเพล็กซ์การจัดการการกำหนดค่าประกอบด้วยหลายระดับ องค์ประกอบสำคัญคือระบบ CMS ในการดำเนินอุตสาหกรรม การไม่มีระดับใดระดับหนึ่งย่อมนำไปสู่ปาฏิหาริย์อันไม่พึงประสงค์อย่างหลีกเลี่ยงไม่ได้

การจัดการการติดตั้งระบบปฏิบัติการ

ระดับแรกคือระบบสำหรับจัดการการติดตั้งระบบปฏิบัติการบนเซิร์ฟเวอร์จริงและเซิร์ฟเวอร์เสมือน สร้างการกำหนดค่าระบบปฏิบัติการพื้นฐาน ขจัดปัจจัยด้านมนุษย์

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

งาน "สูงสุด" สำหรับระบบจัดการการติดตั้งคือการกำหนดค่าเซิร์ฟเวอร์โดยอัตโนมัติจากระดับ BIOS/เฟิร์มแวร์ไปยังระบบปฏิบัติการ ส่วนใหญ่ขึ้นอยู่กับอุปกรณ์และงานการตั้งค่า สำหรับอุปกรณ์ที่แตกต่างกันคุณสามารถพิจารณาได้ API เรดฟิช. หากฮาร์ดแวร์ทั้งหมดมาจากผู้จำหน่ายรายเดียว การใช้เครื่องมือการจัดการสำเร็จรูปมักจะสะดวกกว่า (เช่น HP ILO Amplifier, DELL OpenManage เป็นต้น)

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

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

ข้าว. 1. การจัดการการติดตั้งระบบปฏิบัติการ

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

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

หากคุณไม่ได้กำหนดตั้งแต่ต้นว่าจะจัดเก็บความลับเหล่านี้ที่ไหนและอย่างไร ดังนั้นขึ้นอยู่กับความรุนแรงของข้อกำหนดด้านความปลอดภัยของข้อมูล วิธีการจัดเก็บต่อไปนี้น่าจะเป็นไปได้:

• โดยตรงในรหัสควบคุมการกำหนดค่าหรือในไฟล์ในพื้นที่เก็บข้อมูล
• ในเครื่องมือการจัดการการกำหนดค่าพิเศษ (เช่น Ansible Vault)
• ในระบบ CI/CD (Jenkins/TeamCity/GitLab/ฯลฯ) หรือในระบบการจัดการการกำหนดค่า (Ansible Tower/Ansible AWX)
• ข้อมูลลับสามารถถ่ายโอนได้ "ด้วยตนเอง" ตัวอย่างเช่น พวกมันถูกวางในตำแหน่งที่ระบุ จากนั้นจะถูกใช้โดยระบบการจัดการการกำหนดค่า
• การผสมผสานต่าง ๆ ข้างต้น

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

เราใช้พื้นที่เก็บข้อมูลลับแบบรวมศูนย์ HashiCorp Vault สิ่งนี้ทำให้เรา:

• เก็บความลับให้ปลอดภัย ข้อมูลเหล่านี้ได้รับการเข้ารหัส และแม้ว่าบางคนจะสามารถเข้าถึงฐานข้อมูลห้องนิรภัยได้ (เช่น โดยการกู้คืนจากข้อมูลสำรอง) พวกเขาก็จะไม่สามารถอ่านความลับที่เก็บไว้ที่นั่นได้
• จัดทำนโยบายการเข้าถึงความลับ เฉพาะความลับที่ "จัดสรร" เท่านั้นที่มีให้สำหรับผู้ใช้และแอปพลิเคชัน
• ตรวจสอบการเข้าถึงความลับ การดำเนินการใดๆ ที่เป็นความลับจะถูกบันทึกไว้ในบันทึกการตรวจสอบของห้องนิรภัย
• จัด “วงจรชีวิต” เต็มรูปแบบของการทำงานกับความลับ สามารถสร้าง เพิกถอน กำหนดวันหมดอายุ ฯลฯ
• ง่ายต่อการรวมเข้ากับระบบอื่น ๆ ที่ต้องการเข้าถึงความลับ
• และยังใช้การเข้ารหัสจากต้นทางถึงปลายทาง รหัสผ่านแบบใช้ครั้งเดียวสำหรับระบบปฏิบัติการและฐานข้อมูล ใบรับรองของศูนย์ที่ได้รับอนุญาต ฯลฯ

ตอนนี้เรามาดูระบบการรับรองความถูกต้องและการอนุญาตจากส่วนกลางกัน คุณสามารถทำได้โดยไม่ต้องใช้มัน แต่การดูแลระบบผู้ใช้ในระบบที่เกี่ยวข้องหลายๆ ระบบนั้นไม่ใช่เรื่องเล็กน้อยเกินไป เราได้กำหนดค่าการรับรองความถูกต้องและการอนุญาตผ่านบริการ LDAP มิฉะนั้น ห้องนิรภัยจะต้องออกและติดตามโทเค็นการตรวจสอบสิทธิ์สำหรับผู้ใช้อย่างต่อเนื่อง และการลบและเพิ่มผู้ใช้จะกลายเป็นภารกิจ “ฉันสร้าง/ลบบัญชีผู้ใช้นี้ทุกที่หรือไม่?”

เราเพิ่มระดับอื่นให้กับระบบของเรา: การจัดการความลับและการรับรองความถูกต้อง/การอนุญาตจากส่วนกลาง:

ข้าว. 2. การจัดการความลับ

การจัดการการตั้งค่า

เรามาถึงแกนกลางแล้ว - ระบบ CMS ในกรณีของเรา นี่คือการผสมผสานระหว่าง Ansible และ Red Hat Ansible AWX

แทนที่จะใช้ Ansible สามารถใช้ Chef, Puppet, SaltStack ได้ เราเลือก Ansible ตามเกณฑ์หลายประการ

• ประการแรกคือความเก่งกาจ ชุดโมดูลสำเร็จรูปสำหรับการควบคุม มันน่าประทับใจ. และหากคุณมีไม่เพียงพอ คุณสามารถค้นหาบน GitHub และ Galaxy
• ประการที่สอง ไม่จำเป็นต้องติดตั้งและสนับสนุนตัวแทนบนอุปกรณ์ที่ได้รับการจัดการ พิสูจน์ว่าตัวแทนไม่รบกวนการโหลด และยืนยันว่าไม่มี "บุ๊กมาร์ก"
• ประการที่สาม Ansible มีอุปสรรคในการเข้าต่ำ วิศวกรที่มีความสามารถจะเขียน Playbook ในการทำงานในวันแรกที่ทำงานกับผลิตภัณฑ์

แต่ Ansible เพียงอย่างเดียวในสภาพแวดล้อมการใช้งานจริงนั้นไม่เพียงพอสำหรับเรา มิฉะนั้นอาจเกิดปัญหามากมายในการจำกัดการเข้าถึงและตรวจสอบการดำเนินการของผู้ดูแลระบบ จะจำกัดการเข้าถึงได้อย่างไร? ท้ายที่สุดแล้ว แต่ละแผนกจำเป็นต้องจัดการ (อ่าน: เรียกใช้ Playbook ของ Ansible) ชุดเซิร์ฟเวอร์ “ของตัวเอง” จะอนุญาตให้พนักงานบางคนเรียกใช้ Playbooks ของ Ansible ได้อย่างไร หรือจะติดตามผู้ที่เปิดตัว Playbook โดยไม่ต้องตั้งค่าความรู้ท้องถิ่นมากมายเกี่ยวกับเซิร์ฟเวอร์และอุปกรณ์ที่ใช้ Ansible ได้อย่างไร

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

และอีกหนึ่งสัมผัสที่ภาพเหมือนของระบบ CMS ของเรา Playbook ที่เข้าใจได้ควรจัดเก็บไว้ในระบบการจัดการที่เก็บโค้ด เรามีมัน GitLab ซีอี.

ดังนั้น การกำหนดค่าเองได้รับการจัดการโดยใช้ Ansible/Ansible AWX/GitLab ร่วมกัน (ดูรูปที่ 3) แน่นอนว่า AWX/GitLab ถูกรวมเข้ากับระบบการตรวจสอบสิทธิ์เดียว และ Playbook ของ Ansible ก็รวมเข้ากับ HashiCorp Vault การกำหนดค่าจะเข้าสู่สภาพแวดล้อมการใช้งานจริงผ่าน Ansible AWX เท่านั้น ซึ่งมีการระบุ "กฎของเกม" ทั้งหมด: ใครสามารถกำหนดค่าอะไร จะรับรหัสการจัดการการกำหนดค่าสำหรับ CMS ได้ที่ไหน ฯลฯ

ข้าว. 3. การจัดการการกำหนดค่า

การจัดการทดสอบ

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

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

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

การพัฒนาโค้ดและการจัดการการกำหนดค่ามีความสงบและคาดเดาได้มากขึ้น เพื่อจัดการการทดสอบอย่างต่อเนื่อง เราใช้ชุดเครื่องมือ GitLab CI/CD และดำเนินการ โมเลกุลแอนซิเบิ้ล.

เมื่อใดก็ตามที่มีการเปลี่ยนแปลงในรหัสการจัดการการกำหนดค่า GitLab CI/CD จะเรียก Molecule:

• มันจะตรวจสอบไวยากรณ์ของโค้ด
• ยกคอนเทนเนอร์ Docker ขึ้น
• ใช้รหัสที่แก้ไขกับคอนเทนเนอร์ที่สร้างขึ้น
• ตรวจสอบบทบาทสำหรับ idempotency และรันการทดสอบสำหรับโค้ดนี้ (รายละเอียดที่นี่อยู่ที่ระดับบทบาทที่สามารถวิเคราะห์ได้ ดูรูปที่ 4)

เราส่งมอบการกำหนดค่าไปยังสภาพแวดล้อมการใช้งานจริงโดยใช้ Ansible AWX วิศวกรฝ่ายปฏิบัติการใช้การเปลี่ยนแปลงการกำหนดค่าผ่านเทมเพลตที่กำหนดไว้ล่วงหน้า AWX “ขอ” โค้ดเวอร์ชันล่าสุดอย่างอิสระจากสาขาหลัก GitLab ทุกครั้งที่ใช้งาน วิธีนี้ทำให้เรายกเว้นการใช้โค้ดที่ยังไม่ทดสอบหรือล้าสมัยในสภาพแวดล้อมการใช้งานจริง โดยปกติแล้ว รหัสจะเข้าสู่สาขาหลักหลังจากการทดสอบ ตรวจสอบ และอนุมัติเท่านั้น

ข้าว. 4. การทดสอบบทบาทอัตโนมัติใน GitLab CI/CD

นอกจากนี้ยังมีปัญหาที่เกี่ยวข้องกับการทำงานของระบบการผลิตอีกด้วย ในชีวิตจริง การเปลี่ยนแปลงการกำหนดค่าผ่านโค้ด CMS เพียงอย่างเดียวเป็นเรื่องยากมาก สถานการณ์ฉุกเฉินเกิดขึ้นเมื่อวิศวกรต้องเปลี่ยนการกำหนดค่า “ที่นี่และเดี๋ยวนี้” โดยไม่ต้องรอการแก้ไขโค้ด การทดสอบ การอนุมัติ ฯลฯ

ด้วยเหตุนี้ เนื่องจากการเปลี่ยนแปลงด้วยตนเอง ความคลาดเคลื่อนจึงปรากฏในการกำหนดค่าบนอุปกรณ์ประเภทเดียวกัน (เช่น การตั้งค่า sysctl ได้รับการกำหนดค่าแตกต่างกันบนโหนดคลัสเตอร์ HA) หรือการกำหนดค่าจริงบนอุปกรณ์แตกต่างจากที่ระบุไว้ในรหัส CMS

ดังนั้น นอกเหนือจากการทดสอบอย่างต่อเนื่องแล้ว เรายังตรวจสอบสภาพแวดล้อมการใช้งานจริงเพื่อดูความคลาดเคลื่อนในการกำหนดค่าอีกด้วย เราเลือกตัวเลือกที่ง่ายที่สุด: การรันโค้ดการกำหนดค่า CMS ในโหมด "ทดลองรัน" นั่นคือโดยไม่ต้องใช้การเปลี่ยนแปลง แต่จะมีการแจ้งให้ทราบถึงความแตกต่างทั้งหมดระหว่างการกำหนดค่าที่วางแผนไว้และการกำหนดค่าจริง เราปรับใช้สิ่งนี้โดยการรัน Playbooks Ansible ทั้งหมดเป็นระยะๆ ด้วยตัวเลือก “—ตรวจสอบ” บนเซิร์ฟเวอร์ที่ใช้งานจริง เช่นเคย Ansible AWX มีหน้าที่รับผิดชอบในการเปิดตัวและอัปเดต Playbook ให้ทันสมัยอยู่เสมอ (ดูรูปที่ 5):

ข้าว. 5. ตรวจสอบความคลาดเคลื่อนของการกำหนดค่าใน Ansible AWX

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

ตอนนี้เรามีเลเยอร์การทดสอบที่สำคัญซึ่งประกอบด้วย Ansible AWX/GitLab/Molecule (รูปที่ 6)

ข้าว. 6. การจัดการทดสอบ

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

ไม่มี "ความรู้ลับ" ในการตั้งค่าเซิร์ฟเวอร์และสภาพแวดล้อมในปัจจุบัน คุณสมบัติที่จำเป็นทั้งหมดจะแสดงอยู่ใน Playbook ไม่มีความคิดสร้างสรรค์และคำแนะนำที่คลุมเครืออีกต่อไป: “ติดตั้งเหมือน Oracle ทั่วไป แต่คุณต้องระบุการตั้งค่า sysctl สองสามรายการและเพิ่มผู้ใช้ด้วย UID ที่จำเป็น ถามคนปฏิบัติการสิ พวกเขารู้'

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

และแน่นอนว่า เราได้เร่งการเปิดตัวเซิร์ฟเวอร์ให้ใช้งานได้จากหลายวันเป็นชั่วโมง

ในวันส่งท้ายปีเก่า เมื่อเด็กๆ แกะของขวัญอย่างสนุกสนาน และผู้ใหญ่ต่างขอพรเมื่อมีเสียงระฆังดังขึ้น วิศวกรของเราได้ย้ายระบบ SAP ไปยังเซิร์ฟเวอร์ใหม่ แม้แต่ซานตาคลอสก็ยังบอกว่าปาฏิหาริย์ที่ดีที่สุดคือปาฏิหาริย์ที่เตรียมไว้อย่างดี

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

ผู้แต่ง: Sergey Artemov สถาปนิกแผนก โซลูชัน DevOps "เจ็ทอินโฟซิสเต็มส์"

ที่มา: will.com