‫ดังนั้นเวทมนตร์เล็กน้อยนั้นไม่ใช่เวทมนตร์จริงๆ มันเป็นตาข่ายการกำหนดเส้นทาง
‫The Routing Mesh
‫เป็นเครือข่ายขาเข้าหรือทางเข้าที่กระจายแพ็คเก็ตสำหรับบริการของเราไปยังงานสำหรับบริการนั้นเพราะเราสามารถมีมากกว่าหนึ่งงาน
‫สิ่งนี้ครอบคลุมทุกโหนดและใช้เคอร์เนลแบบดั้งเดิมที่เรียกว่า IPVS
‫ดังนั้นเราไม่ได้พูดถึงบริการใหม่ที่แปลกใหม่
‫เราแค่พูดถึงคุณสมบัติหลักของเคอร์เนล Linux สิ่งที่มันทำที่นี่จริง
‫ๆ คือการทำโหลดบาลานซ์ให้กับโหนดทั้งหมดและรับฟังโหนดทั้งหมดเพื่อรับส่งข้อมูล
‫มีสองวิธีที่เราสามารถพูดคุยเกี่ยวกับวิธีการทำงาน
‫ตัวอย่างแรกคือจากภาชนะหนึ่งไปอีกภาชนะหนึ่ง
‫หากระบบแบ็กเอนด์ของเราเช่นพูดว่าฐานข้อมูลเพิ่มขึ้นเป็นสองซ้ำส่วนหน้าพูดคุยกับแบ็กเอนด์จะไม่พูดคุยโดยตรงกับที่อยู่ IP
‫ของพวกเขา
‫พวกเขาจะพูดกับสิ่งที่เรียกว่าวีไอพีหรือ IP เสมือนจริงที่ Swarm นำเสนอต่อการบริการทั้งหมด
‫นี่คือ IP ส่วนตัวภายในเครือข่ายเสมือนจริงของ Swarm
‫และช่วยให้มั่นใจได้ว่าโหลดจะถูกกระจายไปพร้อมกับงานทั้งหมดสำหรับบริการ
‫ดังนั้นหากคุณสามารถจินตนาการได้ว่าคุณมีบทบาทของผู้ปฏิบัติงานในแอปพลิเคชันของคุณและมี 10 คอนเทนเนอร์ที่แตกต่างกันคุณไม่จำเป็นต้องใส่บาลานเซอร์โหลดไว้หน้านั้น
‫สิ่งนี้ทำเพื่อคุณ
‫เมื่อคุณพูดถึงปริมาณข้อมูลจากบริการหนึ่งในเครือข่ายเสมือนของคุณพูดคุยกับบริการอื่นภายในเครือข่ายเสมือนของคุณ
‫และตัวอย่างที่สองของการทำงานของ routing mesh คือการรับส่งข้อมูลภายนอกที่เข้ามาในฝูงของคุณสามารถเลือกที่จะกดปุ่มใด
‫ๆ ในกลุ่มของคุณ
‫โหนดผู้ปฏิบัติงานใด ๆ
‫จะเปิดพอร์ตที่เผยแพร่แล้วและรับฟังทราฟฟิกของคอนเทนเนอร์นั้นจากนั้นจะเปลี่ยนเส้นทางทราฟฟิกนั้นไปยังคอนเทนเนอร์ที่เหมาะสมโดยพิจารณาจากการทำโหลดบาลานซ์
‫สิ่งนี้หมายความว่าเมื่อคุณปรับใช้คอนเทนเนอร์ในฝูงคุณไม่ควรที่จะดูแลเกี่ยวกับเซิร์ฟเวอร์ใดเพราะมันอาจจะย้ายใช่มั้ย
‫หากคอนเทนเนอร์ล้มเหลวและภารกิจถูกสร้างขึ้นใหม่โดย swarm มันอาจวางไว้บนโหนดอื่น และแน่นอนคุณไม่ต้องการเปลี่ยนไฟร์วอลล์หรือตั้งค่า
‫DNS ของคุณเพื่อให้คอนเทนเนอร์นั้นทำงานอีกครั้ง
‫The mesh mesh แก้ปัญหาเหล่านั้นได้มากมายด้วยการอนุญาตให้เว็บไซต์ Drupal ของเราที่พอร์ต 80
‫สามารถเข้าถึงได้จากโหนดใด ๆ ในฝูง และในพื้นหลังก็นำแพ็คเก็ตเหล่านั้นจากเซิร์ฟเวอร์นั้นแล้วกำหนดเส้นทางไปยังคอนเทนเนอร์
‫ถ้ามันอยู่บนโหนดอื่นมันจะทำการส่งผ่านเครือข่ายเสมือน
‫ถ้ามันอยู่บนโหนดเดียวกันมันจะเปลี่ยนเส้นทางไปยังพอร์ตของคอนเทนเนอร์นั้น
‫และเราไม่ต้องทำอะไรเพื่อเปิดใช้งานสิ่งนี้
‫ทั้งหมดนี้อยู่นอกกรอบ
‫ลองดูไดอะแกรมว่ามันทำงานอย่างไร
‫ถ้าฉันสร้างบริการข่าวและฉันบอกว่ามันมีสามแบบจำลอง
‫และมันสร้างสามงานด้วยสามคอนเทนเนอร์บนสามโหนด ภายในเครือข่ายโอเวอร์เลย์นั้นมันเป็นการสร้าง IP เสมือนที่แมปกับชื่อ
‫DNS ของบริการใช่ไหม และบริการตามค่าเริ่มต้นคือชื่อ DNS คือชื่อของบริการ
‫ในกรณีนี้ฉันสร้างบริการที่เรียกว่าเว็บของฉันและตู้คอนเทนเนอร์อื่น ๆ ที่ฉันมีในเครือข่ายโอเวอร์เลย์ของฉันที่ต้องพูดคุยกับบริการนั้นในฝูงพวกเขาต้องกังวลเกี่ยวกับการใช้
‫DNS เว็บของฉัน
‫IP เสมือนโหลดการรับส่งข้อมูลระหว่างงานทั้งหมดในบริการนั้นอย่างถูกต้อง
‫นี่ไม่ใช่ DNS Round Robin จริง ๆ ที่จริงแล้วการกำหนดค่าที่แตกต่างกันเล็กน้อย
‫เราสามารถเปิดใช้งานได้ถ้าเราต้องการ จริงๆแล้วมีตัวเลือกให้ใช้ DNS Round Robin
‫ประโยชน์ของวีไอพีมากกว่า Round Robin คือหลายครั้งที่แคช DNS
‫ของเราในแอพของเราทำให้เราไม่สามารถกระจายโหลดได้อย่างเหมาะสม
‫แทนที่จะต่อสู้กับไคลเอนต์ DNS ของเราในการกำหนดค่า
‫DNS เราแค่พึ่งใช้วีไอพีซึ่งเป็นสิ่งที่คุณจะได้รับหากคุณซื้อบาลานเซอร์โหลดฮาร์ดแวร์โดยเฉพาะ
‫ในตัวอย่างที่สองนี่แสดงให้เห็นจริง ๆ ว่ามันจะเป็นอย่างไรเมื่อมีการจราจรจากภายนอกเข้ามา
‫นี่คล้ายกับสิ่งที่เราเพิ่งทำกับ Drupal ซึ่งเมื่อฉันสร้างกล่องสีเหลืองเหล่านั้นโดยการสร้างบริการหนึ่งที่เรียกว่าเว็บของฉันและมันสร้างสองงานและนำไปใช้กับสองโหนดที่แตกต่างกันแต่ละโหนดเหล่านั้นมีการสร้าง
‫-in load balancer บน IP
‫แอดเดรสภายนอก สำหรับฉันเพราะฉันใช้ DigitalOcean ที่อยู่ IP
‫นั้นคือที่ DigitalOcean ให้ฉัน เมื่อฉันใช้
‫-p และเผยแพร่บนพอร์ตในตัวอย่างนี้มันใช้พอร์ต 80:80 การรับส่งข้อมูลใด
‫ๆ ที่เข้ามาในโหนดทั้งสามเหล่านี้จะพบการโหลดบาลานซ์ที่พอร์ต 80:80
‫ตัวโหลดบาลานซ์ตัดสินใจว่าคอนเทนเนอร์ใดควรรับทราฟฟิกและทราฟฟิกนั้นอยู่บนโลคัลโหนดหรือต้องการส่งทราฟฟิกผ่านเครือข่ายไปยังโหนดอื่น
‫อีกครั้งสิ่งนี้เกิดขึ้นจริงในพื้นหลังโดยไม่มีความพยายามเป็นพิเศษในส่วนของเรา
‫เอาล่ะ เรามาดูการทำงานของเราติ้งเมช
‫เราได้เห็นตัวอย่างกับ Drupal แล้วและมันฟังบนโหนดทั้งสามนี้ได้อย่างไร
‫แต่ถ้าเรามีหลายงานที่เห็นว่าโหลดบาลานเซอร์ทำงาน
‫ถ้าเราสร้างบริการนักเทียบท่าสิ่งที่เราจะทำคือเราจะใช้คอนเทนเนอร์ Elasticsearch
‫เราจะเรียกมันว่าค้นหาและให้แบบจำลองสามอัน และต้องการเผยแพร่บนพอร์ต 9200 ซึ่งเป็นพอร์ตเริ่มต้น
‫ในกรณีนี้เราต้องการ: 2 ในนั้นเพราะเป็นรุ่นที่ง่ายที่สุดในการปรับใช้ตอนนี้
‫ในขณะที่กำลังสร้างฉันจะพูดถึงว่า Elasticsearch เป็นจริงฐานข้อมูลการค้นหาที่สามารถเข้าถึงได้ผ่านทาง JSON เว็บ API
‫ดังนั้นจึงเป็นเรื่องง่ายที่จะตีด้วยม้วนงอและให้ตัวอย่างที่ดีเกี่ยวกับวิธีการทำงาน
‫ฉันค้นหาบริการนักเทียบท่า ps เราจะเห็นว่ามันสร้างงานแต่ละอย่างบนโหนดที่แตกต่างกันอย่างชาญฉลาด
‫ถ้าฉันทำ curl บน localhost ของฉันบนโหนดหนึ่งบนพอร์ต 9200 เพราะฉันเผยแพร่พอร์ตนั้นฉันจะได้รับข้อมูลพื้นฐานของ
‫Elasticsearch กลับมา ส่วนหนึ่งของมันคือมันจะสร้างชื่อสุ่ม
‫นั่นเป็นเพียงคุณลักษณะจาก Elasticsearch
‫ถ้าฉันขดหลายครั้งคุณจะเห็นว่ามันเป็น Patch เซิร์ฟเวอร์ Patch จากนั้นเป็นครั้งที่สาม
‫Jane Foster และจากนั้นมันจะเริ่มซ้ำตัวเองเช่นนี้
‫นั่นคือ IP เสมือนจริงที่ทำหน้าที่เป็น load balancer และกระจายภาระของฉันในสามภารกิจ
‫หมายเหตุเพิ่มเติมอีกเล็กน้อยบนเส้นทางสายงานการผลิต ในวันที่ 17 03, ซึ่งเป็นรีลีสที่ฉันแสดงให้คุณเห็นบนนี้, ส่วนของ routing
‫routing และ load balancing ปัจจุบันเป็น load balancer แบบไร้รัฐ
‫หากคุณเคยจัดการกับ State ภายในบางทีอาจเป็น load balancer แบบคลาสสิกของ Amazon หรือเทคโนโลยี load balancer
‫อื่น ๆ คุณรู้ว่ามันคืออะไร
‫นี่เป็นการบอกว่าถ้าคุณต้องใช้คุกกี้เซสชันในแอปพลิเคชันของคุณหรือคาดว่าคอนเทนเนอร์ที่สอดคล้องกันจะต้องพูดคุยกับลูกค้าที่สอดคล้องกันคุณอาจต้องเพิ่มสิ่งอื่น
‫ๆ เพื่อช่วยแก้ปัญหานั้น
‫ทุกครั้งที่คุณใช้บริการกับงานหลาย ๆ งานคุณจะได้ผลลัพธ์ที่แตกต่างออกไป
‫นอกจากนี้หากคุณได้รับรายละเอียดสิ่งนี้จริง ๆ แล้วมันคือ load balancer ของเลเยอร์ -3 และที่ทำงานที่
‫IP และเลเยอร์พอร์ต
‫มันไม่ได้ทำงานที่เลเยอร์ DNS
‫หากคุณเคยเรียกใช้หลายเว็บไซต์ในพอร์ตเดียวกันบนเซิร์ฟเวอร์เดียวกันสิ่งนี้จะยังไม่เกิดขึ้น
‫คุณยังคงต้องใช้จิ๊กซอว์อีกชิ้นหนึ่งนอกเหนือจากนั้นหากคุณต้องการใช้งานเว็บไซต์หลาย
‫ๆ แห่งในพอร์ตเดียวกันในกลุ่มเดียวกัน
‫โชคดีที่เป็นคำขอทั่วไปและมีหลายตัวเลือกที่คุณสามารถทำได้เพื่อแก้ไขปัญหาทั้งสองนี้
‫หนึ่งในนั้นคือการใช้ Nginx หรือ HAProxy
‫ซึ่งมีตัวอย่างที่ดีออกมาจากตู้คอนเทนเนอร์ที่จะนั่งข้างหน้ากับสายงานการผลิตของคุณและทำหน้าที่เป็นตัวปรับสมดุลโหลดหรือเลเยอร์สำหรับโหลดบาลานเซอร์ และสิ่งอื่น ๆ
‫มากมาย
‫หากคุณต้องการคุณอาจต้องการตรวจสอบบางส่วนจากแหล่งข้อมูลของส่วนนี้
‫ฉันควรจะพูดถึงว่าถ้าคุณต้องจ่ายค่าสมัครสมาชิกของ Docker Enterprise edition ด้วยบางสิ่งที่เรียกว่า UCP
‫หรือศูนย์ข้อมูล Docker ซึ่งเป็นเว็บอินเตอร์เฟส แต่ฉันควรพูดถึงว่า Docker
‫Enterprise edition ถ้าคุณได้รับการบอกรับเป็นสมาชิกสำหรับ swarm
‫nodes ของคุณจริง ๆ แล้วมันมาพร้อมกับเลเยอร์ในตัวสำหรับเว็บพร็อกซี่ที่ช่วยให้คุณเพียงแค่โยนชื่อ DNS ในการกำหนดค่าเว็บ
‫ทุกอย่างใช้งานได้