คงไม่ผิดที่จะบอกว่าผู้ชายที่ดีที่สุด
พบความสุขผ่านความทุกข์
ลุดวิกฟานเบโทเฟน
ฉันชื่อ Sergey ฉันทำงานที่ Yandex.Money ในทีมวิจัยประสิทธิภาพ ฉันอยากจะเล่าถึงจุดเริ่มต้นของเรื่องราวเกี่ยวกับเส้นทางสู่การใช้ออร์เคสตราของเรา - วิธีที่เราเลือกเครื่องดนตรีและสิ่งที่เราคำนึงถึง เหตุการณ์ทั้งหมดจากบทความเกิดขึ้นแบบเรียลไทม์ ดังนั้นคุณผู้อ่านที่รักกำลังติดตามการพัฒนาของสถานการณ์เกือบจะมีชีวิตอยู่
ทำไมเราต้องมีวาทยากรในทีมของเรา?
ใครคือผู้ควบคุมวง? จากศ. diriger - เพื่อจัดการ, กำกับ, เป็นผู้นำ - ในโลกแห่งดนตรี - นี่คือบุคคลที่เป็นผู้นำด้านการเรียนรู้และการแสดงดนตรีทั้งมวล ในกรณีของเรา สถานที่นี้ถูกครอบครองโดยระบบประสานและอัตโนมัติ
บทบาทของพวกเขาไม่แตกต่างจากบทบาทของวาทยากรในดนตรี - พวกเขาจำเป็นต้องช่วยเหลือทีม ชี้แนะ และจัดระเบียบการเล่น
ตามกฎแล้ว ทีมมีชุดความสามารถที่แน่นอน (หรือเรียกว่าเซิร์ฟเวอร์) ที่พวกเขาใช้โปรเจ็กต์ของตน
วิธีการรับและใช้งานเซิร์ฟเวอร์เหล่านี้แตกต่างกันไป ตัวอย่างบางส่วน:
- ทีมงานส่งคำขอ เช่น ไปยังกลุ่มปฏิบัติการ เพื่อจัดหาทรัพยากรพร้อมพารามิเตอร์บางอย่างให้พวกเขา
- ทีมปฏิบัติการจัดเตรียมปริมาณที่ต้องการ - คลาวด์หรือโลหะเปลือย - และดำเนินการบำรุงรักษาให้อยู่ในสภาพที่เหมาะสมตาม SLA การตั้งค่ายังดำเนินการโดยทีมปฏิบัติการอีกด้วย
- ทีมได้รับเฉพาะทรัพยากรคลาวด์หรือ Bare Metal จากกลุ่มปฏิบัติการ และกำหนดค่าได้ด้วยตัวเอง
- ทีมงานเอง "ซื้อ" ทรัพยากรและบำรุงรักษา/ตั้งค่าทรัพยากรเหล่านั้นอย่างอิสระโดยสมบูรณ์
ทีมงานของเราใช้เซิร์ฟเวอร์ที่ต้องได้รับการสนับสนุน - อัปเดตระบบปฏิบัติการ ติดตั้งแพ็คเกจใหม่ ฯลฯ
สำหรับตัวเราเองเราแบ่งพวกมันออกเป็นสองประเภทหลัก:
- กลุ่มรถถัง,
- กลุ่มบริการ
กลุ่มรถถังประกอบด้วยโฮสต์ที่มี Yandex.Tank
กลุ่มบริการรวมทุกอย่างที่เกี่ยวข้องกับการบำรุงรักษา ซึ่งเป็นบริการต่างๆ ที่ให้การสนับสนุนรอบการเปิดตัว สร้างรายงานอัตโนมัติ ฯลฯ
จนถึงจุดหนึ่ง ทั้งหมดนี้ไม่สะดวกในการจัดการด้วยตนเอง และเราคิดถึงการทำให้กระบวนการทั้งหมดเป็นแบบอัตโนมัติ โดยเริ่มจากเซิร์ฟเวอร์ "โหลด" และสิ้นสุดด้วยการพัฒนา การเปิดตัว และการเปิดตัวบริการภายในของเรา
เหตุใดจึงจำเป็นต้องมีวาทยากร แม้ว่าวงออเคสตราจะเล่นได้ก็ตาม
ขั้นแรก เราเชี่ยวชาญ Ansible และเริ่ม "เท" เซิร์ฟเวอร์ Bare Metal ของเราเพื่อลดการพึ่งพาผู้ดูแลระบบ - ทุกคนชนะที่นี่ เราได้รับทักษะใหม่ ๆ และบรรเทาผู้ดูแลระบบของงานบางอย่างที่พวกเขามีเพียงพอโดยไม่มีเรา . เรามุ่งมั่นที่จะพัฒนาเกินกว่าความสามารถพิเศษและความเป็นอิสระของทีมให้มากที่สุดเท่าที่จะเป็นไปได้
ในบริษัท การทำงานร่วมกับ Ansible ได้รับการกำหนดค่าและควบคุมมาเป็นเวลานาน ดังนั้นเราจึงรวมโซลูชันของเราเข้ากับกระบวนการนี้ได้อย่างง่ายดาย
ปัจจุบัน พูลโฮสต์ประกอบด้วยบทบาท Ansible สามบทบาท:
- บทบาทแรกจะติดตั้งระบบปฏิบัติการ
- ส่วนที่สองรันการตั้งค่าพื้นฐานสำหรับโฮสต์ การอนุญาต LDAP เช่น
- และอันที่สามจะติดตั้ง Yandex.Tank และการพึ่งพาที่เกี่ยวข้องในคอนเทนเนอร์นักเทียบท่า
มาดูบริการที่เราใช้ภายในทีมกันดีกว่า
สำหรับงานของเรา เราใช้ Kotlin และ Python เท่าๆ กัน และใช้ Golang มากกว่าเล็กน้อย เพื่อรวมการพัฒนาและการปรับใช้บริการของเราเข้าด้วยกัน เราจึงตัดสินใจจัดแพ็คเกจไว้ในคอนเทนเนอร์ Docker สิ่งนี้ให้อิสระแก่คุณในการเลือกภาษาการเขียนโปรแกรมและในขณะเดียวกันก็ควบคุมรูปแบบการจัดส่งที่เหมือนกันสำหรับแอปพลิเคชันของคุณ
หมายเหตุเล็ก ๆ เกี่ยวกับ ipv6 ใน Docker
บริการบางอย่างที่เราโต้ตอบด้วยนั้นมีให้ใช้งานผ่าน ipv6 เท่านั้น ดังนั้นเราจึงต้องหาวิธีสร้าง ipv6 สำหรับคอนเทนเนอร์
ตามเอกสาร ipv6 บนเว็บไซต์ Docker อย่างเป็นทางการ ipv6 ถูกเปิดใช้งานโดยการเพิ่มพารามิเตอร์ใน daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}ในกรณีนี้ ผู้ให้บริการจะต้องออกซับเน็ต ipv6 ซึ่งคุณจะต้องลงทะเบียน fixed-cidr-v6.
อย่างไรก็ตาม เราเลือกตัวเลือกอื่น - ipv6 NAT และนี่คือเหตุผล:
- ตอนนี้นักเทียบท่า ด้วย ipv6 เท่านั้น
- การมีที่อยู่ที่สามารถกำหนดเส้นทางได้ทั่วโลกในแต่ละคอนเทนเนอร์หมายความว่าพอร์ตทั้งหมด (แม้แต่พอร์ตที่ยังไม่ได้เผยแพร่) จะถูกเปิดเผยต่อทุกคน เว้นแต่จะมีการกรองเพิ่มเติม
- พร็อกซี userland สำหรับการเผยแพร่พอร์ต .
ipv6 NAT คือ ซึ่งจัดการกฎใน ip6tables และแก้ไขกฎเหล่านั้นเมื่อเพิ่มคอนเทนเนอร์ใหม่
เพื่อให้โซลูชันนี้ทำงานได้อย่างถูกต้อง จำเป็นต้องดำเนินการจัดการอื่นๆ อีกหลายประการ อย่าลืมเริ่มต้น ip6table_nat บนระบบ การมีอยู่ของโมดูลที่ติดตั้งบนระบบไม่ได้รับประกันว่าโมดูลจะถูกโหลดเข้าสู่เคอร์เนลเมื่อเริ่มต้นระบบ เราพบสิ่งนี้เมื่อได้รับข้อผิดพลาดนี้เมื่อเรียกใช้คอนเทนเนอร์ด้วย NAT บนโฮสต์ใหม่:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)ปัญหาได้รับการแก้ไขหลังจากเพิ่มการเริ่มต้นให้กับบทบาท Ansible โดยใช้โมดูล modprobe และโหลดเมื่อเริ่มต้นระบบปฏิบัติการโดยใช้ lineinfile:
- name: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'ยังไงก็ตามมีอันที่ดีอยู่ที่ฮับ ซึ่งอธิบายข้อดีและข้อเสียของวิธีการเรียกใช้ ipv6 ใน docker อย่างสั้นและชัดเจนอย่างชัดเจน
แต่กลับมาที่คำถามของเราที่ถามตอนต้น:
เหตุใดจึงจำเป็นต้องมีวาทยากร แม้ว่าวงออเคสตราจะเล่นได้ก็ตาม
ตอนนี้ทุกคนจินตนาการว่าจะเล่นในทีมของเราอย่างไร:
- กระบวนการ "เท" เซิร์ฟเวอร์ได้ถูกสร้างขึ้น
- การพัฒนาและการใช้บริการเป็นหนึ่งเดียว
มีคำถามที่สมเหตุสมผลเกิดขึ้น - วิธีการปรับใช้ อัปเดต และควบคุมบริการของเราในคอนเทนเนอร์ Docker อย่างมีประสิทธิภาพและอัตโนมัติที่สุดเท่าที่จะเป็นไปได้
แม้ว่าสมาชิกวงออเคสตราแต่ละคนจะรู้บทบาทของตนเอง แต่เขาอาจสับสนและเบี่ยงเบนไปจากแนวคิดดั้งเดิมได้ เรามาถึงข้อสรุปว่าหากไม่มีวาทยกร วงออเคสตราของเราจะไม่ซ้อมอย่างมีประสิทธิผลและเล่นได้อย่างสอดคล้องกัน ตัวนำมีหน้าที่รับผิดชอบในพารามิเตอร์ทั้งหมดของการแสดง เพื่อให้แน่ใจว่าทุกอย่างจะรวมเป็นหนึ่งเดียวด้วยจังหวะและอารมณ์เดียว
จะหาตัวนำที่ดีโดยลงทุนน้อยที่สุดได้อย่างไร?
หัวข้อของการเรียบเรียงได้รับการพัฒนาค่อนข้างดีในตลาด แต่ก่อนอื่นเรามาพูดถึงเครื่องมือเสริมที่สามารถช่วยผู้ควบคุมวงได้
- ระบบที่ให้ฟังก์ชันหลัก 2 ประการ:
- การค้นพบบริการ
- การจัดเก็บคีย์-ค่าแบบกระจาย
ในวงออเคสตราของเรา กงสุลจะรับผิดชอบในการลงทะเบียนบริการและจัดเก็บการกำหนดค่า มีสองตัวเลือกในการลงทะเบียน:
- ใช้งานอยู่คือเมื่อบริการลงทะเบียนตัวเองโดยใช้ HTTP API
- Passive - ต้องลงทะเบียนบริการด้วยตนเอง
ห้องนิรภัยเป็นพื้นที่เก็บข้อมูลที่สร้างมาตรฐานและรวมพื้นที่จัดเก็บข้อมูลที่ปลอดภัยและการจัดการความลับ - รหัสผ่าน ใบรับรอง
นี่คือประโยชน์ที่เราจะได้รับจากการใช้เครื่องมือนี้:
- ศูนย์รวมแห่งเดียวสำหรับการสร้างและจัดเก็บความลับและจัดการวงจรชีวิตโดยใช้ HTTP API
- Transit Secrets Engine - การเข้ารหัสและถอดรหัสข้อมูลโดยไม่ต้องบันทึก ความสามารถในการส่งข้อมูลในรูปแบบที่เข้ารหัสผ่านช่องทางการสื่อสารที่ไม่ปลอดภัย
- นโยบายการเข้าถึงที่กำหนดค่าได้ง่าย
- การตรวจสอบการเข้าถึงความลับ
- ความสามารถในการสร้าง CA (ผู้ออกใบรับรอง) ของคุณเองเพื่อจัดการใบรับรองที่ลงนามด้วยตนเองภายในโครงสร้างพื้นฐานของคุณ
เมื่อพิจารณาถึงข้อกำหนดทั้งหมดของเราแล้ว มีสองตัวเลือกที่เหมาะสมสำหรับบทบาทของตัวนำ - Kubernetes และ Nomad
Kubernetes
มีการเขียนบทความและหนังสือเกี่ยวกับเขากี่เล่มแล้ว (ที่นี่ ตัวอย่างเช่น) มีรายงานที่ฉันจะเขียนสั้น ๆ - นี่คือเครื่องเก็บเกี่ยวแบบสากลที่สามารถทำได้เกือบทุกอย่าง ราคาสำหรับสิ่งนี้คือการตั้งค่าและบำรุงรักษาคลัสเตอร์บน Kubernetes ไม่ใช่เรื่องง่ายเสมอไป
พเนจร
จาก HashiCorp บริษัทที่มีชื่อเสียงด้านกงสุลและห้องนิรภัยดังที่กล่าวข้างต้น
เราพบว่า Nomad ติดตั้งและกำหนดค่าได้ง่ายกว่า Kubernetes ไฟล์ไบนารีหนึ่งไฟล์ทำงานได้ทั้งในโหมดเซิร์ฟเวอร์และไคลเอนต์ ในเวลาเดียวกัน Nomad ครอบคลุมรายการงานทั้งหมดที่เราต้องการแก้ไข: การจัดการคลัสเตอร์ ตัวกำหนดเวลาที่รวดเร็ว การสนับสนุน multidatacenter นอกจากนี้ เมื่อใช้กงสุลและห้องนิรภัย เราได้รับการบูรณาการที่เข้มงวดมากขึ้นเพื่อจัดเตรียมบริการของเรา
สิ่งที่กำลังดำเนินการอยู่:
- เซิร์ฟเวอร์ที่เตรียมไว้สำหรับการปรับใช้กงสุล
- การกำหนดค่าคลัสเตอร์ Nomad จะถูกป้อนเข้าสู่กงสุล ด้วยความช่วยเหลือซึ่ง Nomad ควรปรับใช้โดยอัตโนมัติ
- ในขณะเดียวกัน เราจะติดตั้งห้องนิรภัยเพื่อเก็บความลับ
คำถามสำหรับผู้ชม: มันคุ้มไหมที่จะจ้างวาทยากรสำหรับงานดังกล่าวหรือวงออเคสตราจะทำได้ดีหากไม่มีเขา? บอกเราในความคิดเห็นว่าคุณคิดอย่างไรเกี่ยวกับเรื่องนี้
สมัครสมาชิกบล็อกของเราและติดตามข่าวสาร - เราจะแจ้งให้คุณทราบเร็วๆ นี้ว่าเกิดอะไรขึ้นในท้ายที่สุด และไม่ว่าเราจะกำหนดค่าคลัสเตอร์ Nomad ตามที่เราต้องการหรือไม่
มาที่แสนสบายของเรา ซึ่งคุณสามารถขอคำแนะนำ ช่วยเหลือเพื่อนร่วมงาน และพูดคุยเกี่ยวกับการวิจัยด้านประสิทธิภาพการทำงาน และอื่นๆ ได้ตลอดเวลา
ที่มา: will.com
