วิธีควบคุมโครงสร้างพื้นฐานเครือข่ายของคุณ บทที่สี่ ระบบอัตโนมัติ เทมเพลต

บทความนี้เป็นบทความที่หกในซีรีส์ “วิธีควบคุมโครงสร้างพื้นฐานเครือข่ายของคุณ” เนื้อหาบทความทั้งหมดในซีรีส์และลิงก์ต่างๆ สามารถพบได้ ที่นี่.

หลังจากทิ้งหัวข้อไว้มากมาย ฉันจึงตัดสินใจเริ่มต้นบทใหม่

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

DevOps สำหรับเครือข่าย

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

เมื่อกว่า 5 ปีที่แล้ว นักพัฒนาของเราซึ่งเป็นนักสร้างเครือข่ายมาหาเรา ด้วยข้อเสนอเหล่านี้ เราไม่รู้สึกยินดีเลย

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

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

หรือจะเข้าใจได้อย่างไรว่ามีการใช้คำสั่งการกำหนดค่าอย่างถูกต้องและต้องทำอย่างไรในกรณีที่เกิดข้อผิดพลาด?

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

แต่มีสถานการณ์หนึ่งที่ข้อบกพร่องได้รับการปรับระดับในทางปฏิบัติและเหลือเพียงข้อดีเท่านั้น ฉันกำลังพูดถึงงานออกแบบ

โครงการ

ในช่วงสองปีที่ผ่านมาฉันได้เข้าร่วมในโครงการสร้างศูนย์ข้อมูลสำหรับผู้ให้บริการรายใหญ่ ฉันรับผิดชอบ F5 และ Palo Alto ในโครงการนี้ จากมุมมองของ Cisco นี่คือ "อุปกรณ์ของบุคคลที่สาม"

สำหรับฉันโดยส่วนตัวแล้ว โปรเจ็กต์นี้มีสองขั้นตอนที่แตกต่างกัน

ขั้นตอนแรก

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

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

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

ตอนนี้เราสามารถมองไปรอบ ๆ เล็กน้อย
และนี่คือจุดเริ่มต้นของระยะที่สอง

ขั้นตอนที่สอง

ฉันตัดสินใจที่จะทำให้กระบวนการเป็นแบบอัตโนมัติ

สิ่งที่ฉันเข้าใจจากการสื่อสารกับนักพัฒนาในขณะนั้น (และเราต้องจ่ายส่วย เรามีทีมที่แข็งแกร่ง) คือรูปแบบข้อความ แม้ว่าเมื่อมองแวบแรกจะดูเหมือนเป็นสิ่งที่มาจากโลกของระบบปฏิบัติการ DOS แต่ก็มีตัวเลขอยู่ ของทรัพย์สินอันทรงคุณค่า
ตัวอย่างเช่น รูปแบบข้อความจะมีประโยชน์หากคุณต้องการใช้ประโยชน์จาก GIT และอนุพันธ์ทั้งหมดอย่างเต็มที่ และฉันก็อยากจะ

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

ดังนั้นเมื่อใช้ YAML และ Jinja2 ไฟล์ YAML ที่มีพารามิเตอร์การกำหนดค่าเช่นที่อยู่ IP หมายเลข BGP AS ... จะตอบสนองบทบาทของ NIP ได้อย่างสมบูรณ์แบบในขณะที่เทมเพลต Jinja2 มีไวยากรณ์ที่สอดคล้องกับการออกแบบ กล่าวคือ โดยพื้นฐานแล้ว ภาพสะท้อนของ LLD

ใช้เวลาสองวันในการเรียนรู้ YAML และ Jinja2 ตัวอย่างที่ดีบางส่วนก็เพียงพอที่จะเข้าใจวิธีการทำงานนี้ จากนั้นใช้เวลาประมาณสองสัปดาห์ในการสร้างเทมเพลตทั้งหมดที่ตรงกับการออกแบบของเรา: หนึ่งสัปดาห์สำหรับ Palo Alto และอีกหนึ่งสัปดาห์สำหรับ F5 ทั้งหมดนี้ถูกโพสต์บน Githab ขององค์กร

ตอนนี้กระบวนการเปลี่ยนแปลงมีลักษณะดังนี้:

• เปลี่ยนไฟล์ YAML
• สร้างไฟล์กำหนดค่าโดยใช้เทมเพลต (Jinja2)
• บันทึกไว้ในที่เก็บข้อมูลระยะไกล
• อัปโหลดการกำหนดค่าที่สร้างขึ้นไปยังอุปกรณ์
• ฉันเห็นข้อผิดพลาด
• เปลี่ยนไฟล์ YAML หรือเทมเพลต Jinja2
• สร้างไฟล์กำหนดค่าโดยใช้เทมเพลต (Jinja2)
• ...

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

การทดสอบที่ดีและโอกาสในการแก้ไขข้อบกพร่องทุกอย่างคือความปรารถนาของลูกค้าที่จะเปลี่ยนรูปแบบการตั้งชื่อ ผู้ที่ทำงานกับ F5 จะเข้าใจถึงความน่าสนใจของสถานการณ์ แต่สำหรับฉันมันค่อนข้างง่าย ฉันเปลี่ยนชื่อในไฟล์ YAML ลบการกำหนดค่าทั้งหมดออกจากอุปกรณ์ สร้างการกำหนดค่าใหม่และอัปโหลด ทุกอย่างรวมถึงการแก้ไขข้อบกพร่องใช้เวลา 4 วัน: สองวันสำหรับแต่ละเทคโนโลยี หลังจากนั้นฉันก็พร้อมสำหรับขั้นตอนต่อไป นั่นคือการสร้างศูนย์ข้อมูล DEV และ Staging

การพัฒนาและการจัดเตรียม

จริงๆ แล้วการจัดเตรียมจะจำลองการผลิตโดยสมบูรณ์ Dev เป็นสำเนาที่ถูกแยกส่วนอย่างหนักซึ่งสร้างจากฮาร์ดแวร์เสมือนเป็นหลัก สถานการณ์ในอุดมคติสำหรับแนวทางใหม่ ถ้าฉันแยกเวลาที่ใช้ออกจากกระบวนการโดยรวม ฉันคิดว่างานใช้เวลาไม่เกิน 2 สัปดาห์ เวลาหลักรออีกฝ่ายค้นหาปัญหาร่วมกัน การใช้งานของบุคคลที่สามแทบจะไม่มีใครสังเกตเห็นจากผู้อื่น มีเวลาเรียนรู้บางสิ่งบางอย่างและเขียนบทความเกี่ยวกับHabré :)

เพื่อสรุปผล

แล้วฉันมีอะไรอยู่ในบรรทัดล่าง?

• สิ่งที่ฉันต้องทำเพื่อเปลี่ยนการกำหนดค่าคือเปลี่ยนไฟล์ YAML ที่เรียบง่ายและมีโครงสร้างชัดเจนพร้อมพารามิเตอร์การกำหนดค่า ฉันไม่เคยเปลี่ยนสคริปต์ python และน้อยมาก (เฉพาะในกรณีที่มีข้อผิดพลาด) ฉันเปลี่ยน Jinja2 heatlate
• จากมุมมองของเอกสาร นี่เป็นสถานการณ์ที่เกือบจะสมบูรณ์แบบ คุณเปลี่ยนเอกสารประกอบ (ไฟล์ YAML ทำหน้าที่เป็น NIP) และอัปโหลดการกำหนดค่านี้ไปยังอุปกรณ์ วิธีนี้จะทำให้เอกสารของคุณเป็นข้อมูลล่าสุดอยู่เสมอ

ทั้งหมดนี้นำไปสู่ความจริงที่ว่า

• อัตราข้อผิดพลาดลดลงเหลือเกือบ 0
• 90 เปอร์เซ็นต์ของกิจวัตรประจำวันหายไป
• ความเร็วของการดำเนินการเพิ่มขึ้นอย่างมาก

จ่าย F5Y เอซีวาย

ฉันบอกว่าตัวอย่างบางส่วนก็เพียงพอที่จะเข้าใจวิธีการทำงาน
นี่คือเวอร์ชันสั้นๆ (และแน่นอนว่ามีการแก้ไข) ของสิ่งที่สร้างขึ้นระหว่างการทำงานของฉัน

จ่าย = การใช้งาน Pสวัสดี Aมาจาก Yaml = พาโลอัลโตจาก Yaml
เอฟทูวาย = การใช้งาน F5 ราคาเริ่มต้นที่ Yแอมแอล = F5 ราคาเริ่มต้นที่ Yแอม (เร็วๆ นี้)
เอซี = การใช้งาน ACฉันมาจาก Yแอมแอล = F5 ราคาเริ่มต้นที่ Yจูเนียร์

ฉันจะเพิ่มคำสองสามคำเกี่ยวกับ ACY (เพื่อไม่ให้สับสนกับ ACI)

ผู้ที่เคยร่วมงานกับ ACI รู้ดีว่าปาฏิหาริย์นี้ (และในทางที่ดีด้วย) ไม่ได้ถูกสร้างขึ้นโดยเครือข่ายอย่างแน่นอน :) ลืมทุกสิ่งที่คุณรู้เกี่ยวกับเครือข่ายไปได้เลย - มันจะไม่เป็นประโยชน์กับคุณ!
มันเกินจริงนิดหน่อยแต่คร่าวๆ ก็สื่อถึงความรู้สึกที่ฉันได้สัมผัสมาโดยตลอดตลอด 3 ปีที่ผ่านมาที่ได้ร่วมงานกับ ACI

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

วิศวกรในโครงการนี้ใช้ Excel เพื่อกำหนดค่า ACI แทน YAML เพื่อจุดประสงค์เดียวกันทุกประการ แน่นอนว่ามีข้อดีในการใช้ Excel:

• NIP ของคุณในไฟล์เดียว
• ป้ายสวยๆ ให้ลูกค้าได้ชมครับ
• คุณสามารถใช้เครื่องมือ Excel บางอย่างได้

แต่มีข้อเสียอยู่อย่างหนึ่งและในความคิดของฉันมันมีค่ามากกว่าข้อดี การควบคุมการเปลี่ยนแปลงและการประสานงานการทำงานเป็นทีมกลายเป็นเรื่องยากมากขึ้น

จริงๆ แล้ว ACY เป็นแอปพลิเคชันที่มีแนวทางเดียวกับที่ฉันใช้กับบุคคลที่สามเพื่อกำหนดค่า ACI

ที่มา: will.com