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

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

โชคดีที่ เราอยู่ที่ไหน วันนี้.

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

Docker Swarm คืออะไร?

ก่อนที่เราจะดำดิ่งสู่การสร้างและปรับใช้กับฝูงแรกของเราคุณควรทราบว่า Docker Swarm คืออะไร Docker นั้นมีมานานหลายปีแล้วและคนส่วนใหญ่ในปัจจุบันคิดว่าเป็นคอนเทนเนอร์รันไทม์ ในความเป็นจริง Docker ประกอบด้วยชิ้นส่วนที่แตกต่างกันทั้งหมดทำงานร่วมกัน ตัวอย่างเช่นส่วนรันไทม์ของคอนเทนเนอร์นั้นถูกจัดการโดยคอมโพเนนต์ขนาดเล็กสองตัวที่เรียกว่า runC และ containerd . เนื่องจากนักเทียบท่าได้พัฒนาและตอบแทนชุมชนพวกเขาพบว่าการสร้างส่วนประกอบที่เล็กลงเหล่านี้เป็นวิธีที่ดีที่สุดในการเติบโตและเพิ่มคุณสมบัติอย่างรวดเร็ว ดังนั้นตอนนี้เราจึงมี SwarmKit และโหมด Swarm ซึ่งติดตั้งไว้ใน Docker โดยตรง

Docker Swarm เป็นเอนจินการจัดระเบียบคอนเทนเนอร์ ในระดับสูงต้องใช้ Docker Engines หลายตัวที่ทำงานบนโฮสต์ที่แตกต่างกันและให้คุณใช้ร่วมกันได้ การใช้งานนั้นง่ายมาก: ประกาศแอปพลิเคชันของคุณเป็นกองบริการและปล่อยให้ Docker จัดการส่วนที่เหลือ บริการสามารถเป็นอะไรก็ได้ตั้งแต่อินสแตนซ์แอปพลิเคชันไปจนถึงฐานข้อมูลหรือยูทิลิตี้เช่น Redis หรือ RabbitMQ สิ่งนี้น่าจะฟังดูคุ้นเคยหากคุณเคยทำงานกับนักเทียบเคียงในการพัฒนาเนื่องจากเป็นแนวคิดเดียวกัน ในความเป็นจริงการประกาศสแต็กเป็นเพียง docker-compose.yml ไฟล์ที่มีไวยากรณ์เวอร์ชัน 3.1 ซึ่งหมายความว่าคุณสามารถใช้การกำหนดค่าที่คล้ายกัน (และในหลาย ๆ กรณีก็เหมือนกัน) เพื่อสร้างการกำหนดค่าสำหรับการพัฒนาและการใช้งานฝูง แต่ฉันจะนำหน้าไปได้เล็กน้อยที่นี่ จะเกิดอะไรขึ้นเมื่อคุณมีอินสแตนซ์ของ Docker ในโหมด Swarm

อย่าตกแพ

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

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

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

สมมติว่าเรามีโหนดผู้จัดการสามโหนดชื่อ A, B และ C แน่นอนว่า A คือผู้นำที่กล้าหาญของเรา วันหนึ่งเกิดข้อผิดพลาดของเครือข่ายชั่วคราวทำให้ A ออฟไลน์ปล่อยให้ B และ C อยู่คนเดียว หลังจากไม่ได้รับการติดต่อจาก A มาเป็นเวลานาน (ไม่กี่ร้อยมิลลิวินาที) B และ C จะรอช่วงเวลาที่สุ่มสร้างขึ้นก่อนที่จะลงสมัครรับเลือกตั้งและแจ้งให้อีกฝ่ายทราบ แน่นอนคนแรกที่ลงสมัครรับเลือกตั้งในกรณีนี้จะได้รับการเลือกตั้ง ในตัวอย่างนี้ B กลายเป็นผู้นำคนใหม่และมีการคืนองค์ประชุม แต่แล้วพล็อตบิด: จะเกิดอะไรขึ้นเมื่อ A กลับมาออนไลน์? คิดว่ายังเป็นผู้นำอยู่ใช่ไหม? การเลือกตั้งแต่ละครั้งมีคำที่เกี่ยวข้องดังนั้น A จึงได้รับเลือกในระยะที่ 1 ทันทีที่ A กลับมาออนไลน์และเริ่มสั่งซื้อ B และ C พวกเขาจะแจ้งให้ทราบว่า B เป็นหัวหน้าของเทอม 2 และ A จะก้าวลงจากตำแหน่ง

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

การจัดกำหนดการงานและการกระทบยอด

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

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

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

การค้นหาบริการและการโหลดบาลานซ์

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

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

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

ไม่ได้หยุดอยู่แค่การเชื่อมต่อภายนอก บริการที่ทำงานบนสแต็กเดียวกันมีเครือข่ายซ้อนทับที่ช่วยให้พวกเขาสื่อสารกันได้ แทนที่จะเข้ารหัสที่อยู่ IP แบบยากในรหัสของคุณคุณสามารถใช้ชื่อบริการเป็นชื่อโฮสต์ที่คุณต้องการเชื่อมต่อได้ ตัวอย่างเช่นหากแอปของคุณต้องการสื่อสารกับบริการ Redis ชื่อ“ redis” ก็สามารถใช้“ redis” เป็นชื่อโฮสต์และ Swarm จะกำหนดเส้นทางคำขอไปยังคอนเทนเนอร์ที่เหมาะสม และเนื่องจากสิ่งนี้ทำงานได้อย่างราบรื่นในการพัฒนาด้วย Docker-compose และในการผลิตด้วย Docker Swarm จึงไม่ต้องกังวลอีกต่อไปเมื่อปรับใช้แอปของคุณ

การอัปเดตแบบโรลลิ่ง

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

เมื่ออัปเดตบริการคุณสามารถกำหนดจำนวนคอนเทนเนอร์ที่ควรอัปเดตในแต่ละครั้งและจะเกิดอะไรขึ้นหากคอนเทนเนอร์ใหม่เริ่มทำงานล้มเหลว หลังจากถึงเกณฑ์ที่กำหนด Swarm สามารถหยุดการอัปเดตหรือ (ณ Docker 17.04) ย้อนกลับคอนเทนเนอร์ไปยังรูปภาพและการตั้งค่าก่อนหน้า ไม่ต้องกังวลว่าพรุ่งนี้เช้าจะต้องพาเจ้านายมาดื่มกาแฟ

ความปลอดภัย

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

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

ดำน้ำเข้าไปในฝูง

ถ้าคุณเป็นเหมือนฉันล่ะก็คุณคงอยากจะเข้ามาใช้คุณสมบัติเหล่านี้ให้ได้! มาดำน้ำกันเถอะ!

แอพตัวอย่าง Docker Swarm

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

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

ซอร์สโค้ดทั้งหมดมีอยู่ใน GitHub หากคุณต้องการ 'ตรวจสอบ' สิ่งที่เกิดขึ้น

เล่นกับ Docker!

อย่าลังเลที่จะใช้เซิร์ฟเวอร์ของคุณเองเมื่อคุณอ่านบทช่วยสอนนี้ แต่ฉันขอแนะนำให้ใช้ play-with-docker.com หากคุณต้องการเพียงแค่กระโดดเข้ามาเป็นไซต์ที่ดำเนินการโดยนักพัฒนา Docker เพียงไม่กี่รายที่ให้คุณหมุนโหนดเครือข่ายหลายโหนดที่ติดตั้ง Docker ไว้ล่วงหน้า พวกเขาจะปิดตัวลงหลังจากสี่ชั่วโมง แต่นั่นก็มีมากมายสำหรับตัวอย่างนี้!

การสร้าง Swarm

เอาล่ะไปเลย! ดำเนินการต่อและสร้างสามอินสแตนซ์ใน PWD (play-with-docker) หรือหมุนเซิร์ฟเวอร์สามเครื่องในบริการ VPS (เซิร์ฟเวอร์ส่วนตัวเสมือน) ที่คุณชื่นชอบและติดตั้ง Docker engine ในทั้งหมด โปรดทราบว่าคุณสามารถสร้างรูปภาพและใช้ซ้ำได้ตลอดเวลาเมื่อเพิ่มโหนดในอนาคต ไม่มีซอฟต์แวร์ที่ชาญฉลาดแตกต่างกันระหว่างโหนดผู้จัดการและโหนดผู้ปฏิบัติงานดังนั้นคุณจึงไม่จำเป็นต้องดูแลรักษารูปภาพสองภาพที่ต่างกัน

ยังปั่นไหวไหม ไม่ต้องกังวลฉันจะรอ เอาล่ะตอนนี้เรากำลังจะสร้างผู้จัดการแรกและโหนดผู้นำ ในกรณีแรกของคุณเริ่มต้นฝูง:

docker swarm init --advertise-addr

แทนที่ด้วยที่อยู่ IP ของโหนดของคุณ ใน PWD ที่อยู่ IP จะแสดงที่ด้านบนและหากคุณใช้ VPS ของคุณเองอย่าลังเลที่จะใช้ที่อยู่ IP ส่วนตัวของเซิร์ฟเวอร์ของคุณตราบใดที่สามารถเข้าถึงได้จากโหนดอื่น ๆ ในเครือข่ายของคุณ

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

docker swarm join-token manager

คัดลอกคำสั่งผลลัพธ์และรันบนโหนดที่สองและสามของคุณ ดูเถิดสามโหนดรุม! มาตรวจสอบกันว่าโหนดทั้งหมดของเรามีอยู่จริง docker node ls คำสั่งจะแสดงรายการโหนดทั้งหมดในกลุ่มของเรา คุณควรเห็นสิ่งนี้:

$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

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

ใช้เวลาสักครู่เพื่อชื่นชมความง่ายและมาทำให้แอปแรกของเราใช้งานได้

จัดส่ง!

ทีมพัฒนาธุรกิจได้สัญญากับลูกค้าว่าแอปใหม่ของพวกเขาจะถูกใช้งานและพร้อมใช้งานภายในหนึ่งชั่วโมง! โดยทั่วไปฉันรู้ แต่อย่ากลัวไปเลยว่าเราไม่ต้องใช้เวลามากขนาดนั้นเพราะมันถูกสร้างขึ้นโดยใช้ Docker! นักพัฒนาใจดีพอที่จะให้เรา docker-compose ไฟล์:

version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

เราจะทำลายมันลงในอีกสักครู่ แต่ยังไม่มีเวลาสำหรับเรื่องนั้น มาติดตั้งใช้งานกันเลย! ไปข้างหน้าและสร้างไฟล์บนโหนดแรกของคุณชื่อ docker-compose.yml และเติมข้อมูลด้วยการกำหนดค่าด้านบนคุณสามารถทำได้อย่างง่ายดายด้วย echo '' > docker-compose.yml

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

echo 'supersecretpassword' | docker secret create db_password -

เยี่ยมมาก! ตอนนี้สิ่งที่เราต้องทำคือบอก Docker ให้ใช้การกำหนดค่าของเรา:

docker stack deploy -c docker-compose.yml demo

เมื่อคุณเรียกใช้คำสั่งนี้คุณจะเห็น Docker สร้างบริการสามอย่างที่เรากำหนดไว้: web, nginx และ redis อย่างไรก็ตามเนื่องจากเราตั้งชื่อการสาธิตสแต็กบริการของเราจึงมีชื่อว่า demo_web, demo_nginx และ demo_redis เราสามารถดูบริการของเราได้โดยเรียกใช้ docker service ls คำสั่งซึ่งควรแสดงสิ่งนี้:

$ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

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

การเห็นคือความเชื่อ

อย่าเอาคำของฉัน (หรือคำของนักเทียบท่า) มาใช้ มาลองเชื่อมต่อกับแอปของเรา การกำหนดค่าบริการของเราบอกให้ Docker แสดง NGINX บนพอร์ต 8000 หากคุณใช้ PWD ควรมีลิงก์สีน้ำเงินที่ด้านบนของหน้าซึ่งระบุว่า“ 8000” PWD ตรวจพบโดยอัตโนมัติว่าเรามีบริการที่ทำงานบนพอร์ตนั้น! คลิกที่นั่นและจะนำคุณไปยังโหนดที่เลือกบนพอร์ต 8000 หากคุณรีดเซิร์ฟเวอร์ของคุณเองเพียงแค่ไปที่ IP ของเซิร์ฟเวอร์ตัวใดตัวหนึ่งบนพอร์ต 8000

คุณจะได้รับการต้อนรับด้วยหน้าจอสไตล์สวยงามที่ให้ข้อมูลพื้นฐานแก่คุณ:

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

อย่าลังเลที่จะลองกดพอร์ต 8000 จากโหนดใด ๆ คุณจะยังคงถูกกำหนดเส้นทางไปยังแอป

ทำให้เข้าใจเวทมนตร์

ณ จุดนี้ทุกอย่างใช้งานได้และหวังว่าคุณจะพบว่ากระบวนการนี้ไม่เจ็บปวด! มาดูกันดีกว่าว่า docker-compose.yml ไฟล์และดูสิ่งที่เราบอกกับ Docker ในระดับสูงเราได้กำหนดบริการไว้ 3 อย่าง ได้แก่ web, nginx และ redis เช่นเดียวกับไฟล์เขียนทั่วไปเราได้จัดเตรียมอิมเมจของ Docker เพื่อใช้สำหรับแต่ละบริการรวมถึงคำสั่งในการเรียกใช้ ในกรณีของ nginx เราได้ระบุด้วยว่าพอร์ต 8000 บนโฮสต์ควรแมปกับพอร์ต 80 ในคอนเทนเนอร์ ทั้งหมดนี้เป็นไวยากรณ์การเขียนมาตรฐานจนถึงตอนนี้

มีอะไรใหม่ที่นี่คือคีย์การปรับใช้และความลับ คีย์เหล่านี้จะถูกละเว้นโดย docker-compose ดังนั้นจึงไม่ส่งผลกระทบต่อสภาพแวดล้อมการพัฒนาของคุณ แต่จะใช้โดย docker stack มาดูบริการบนเว็บกัน ง่ายพอเรากำลังบอก Docker ว่าเราต้องการเรียกใช้แอป Flask ของเราสองตัวจำลอง นอกจากนี้เรายังแจ้งให้ Docker ทราบว่าบริการบนเว็บต้องใช้ db_password ความลับ. นี่คือสิ่งที่ทำให้มั่นใจได้ว่าคอนเทนเนอร์จะมีไฟล์ชื่อ /run/secrets/db_password มีค่าของความลับ

เมื่อเลื่อนลงไปที่ Nginx เราจะเห็นว่าโหมดปรับใช้ถูกตั้งค่าเป็น global ค่าเริ่มต้น (ซึ่งใช้โดยปริยายในเว็บ) คือ replicated ซึ่งหมายความว่าเราจะระบุจำนวนตัวจำลองที่เราต้องการ เมื่อเราระบุ global มันจะบอกนักเทียบท่าว่าทุกโหนดในฝูงควรเรียกใช้บริการหนึ่งอินสแตนซ์ เรียกใช้ docker service ls อีกครั้งคุณจะสังเกตเห็นว่า nginx มีสามแบบจำลองหนึ่งรายการสำหรับแต่ละโหนดในฝูงของเรา

สุดท้ายนี้เราได้สั่งให้ Docker เรียกใช้ Redis อินสแตนซ์เดียวในฝูง ไม่สำคัญว่าเว็บคอนเทนเนอร์ของเราจะถูกส่งไปยังที่ใดโดยอัตโนมัติเมื่อขอโฮสต์ Redis

ใช้ Swarm วันต่อวัน

ขอแสดงความยินดีกับการปรับใช้แอปแรกของคุณกับ Docker Swarm! ลองใช้เวลาสักครู่เพื่อตรวจสอบคำสั่งทั่วไปบางคำที่คุณจะใช้

ตรวจสอบฝูงของคุณ

ต้องการตรวจสอบบริการของคุณหรือไม่? ลอง docker service ls และ docker service ps . ก่อนหน้านี้จะแสดงภาพรวมระดับสูงของแต่ละบริการและส่วนหลังจะให้ข้อมูลเกี่ยวกับคอนเทนเนอร์แต่ละรายการที่เรียกใช้บริการที่ระบุ สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อคุณต้องการดูว่าโหนดใดกำลังเรียกใช้บริการ

การอัปเดตแบบโรลลิ่ง

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

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

docker service update --image lsapan/docker-swarm-demo-web:latest demo_web

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

docker service update --image lsapan/docker-swarm-demo-web:latest --update-parallelism 1 --update-delay 30s demo_web

ซึ่งจะอัปเดตทีละคอนเทนเนอร์โดยรอ 30 วินาทีระหว่างการอัปเดต

บริการปรับขนาดขึ้นหรือลง

การมีคอนเทนเนอร์สองเว็บนั้นยอดเยี่ยม แต่คุณรู้หรือไม่ว่าอะไรดีกว่ากัน? มีสิบ! บริการปรับขนาดขึ้นและลงเป็นฝูงทำได้ง่ายเหมือน:

docker service scale demo_web=10

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

การลบกองและบริการ

สแต็คและบริการของคุณถูกปรับใช้และปรับขนาดได้ยอดเยี่ยม! แต่ตอนนี้คุณต้องการที่จะออฟไลน์ ซึ่งสามารถทำได้ด้วย rm ตามลำดับ คำสั่ง ในการลบ Demo stack ให้รันคำสั่ง:

docker stack rm demo

หรือหากคุณต้องการเพียงแค่ลบบริการเดียวให้ใช้:

docker service rm demo_web

โหนดการระบายน้ำ

จำไว้ว่าเมื่อเราวิ่ง docker node ls ก่อนหน้านี้เพื่อตรวจสอบโหนดในฝูงของเรา? มันให้ข้อมูลมากมายในแต่ละโหนดรวมถึงโหนด ความพร้อมใช้งาน . โดยค่าเริ่มต้นโหนดคือ คล่องแคล่ว ซึ่งหมายความว่าพวกเขาเป็นเกมที่ยุติธรรมในการเรียกใช้คอนเทนเนอร์ อย่างไรก็ตามมีหลายครั้งที่คุณอาจจำเป็นต้องออฟไลน์ชั่วคราวเพื่อทำการบำรุงรักษา แน่นอนว่าคุณสามารถปิดมันได้และฝูงก็จะฟื้นตัว แต่มันเป็นการดีที่จะแจ้งให้ Moby (วาฬนักเทียบท่า) ทราบสักนิด

นี่คือที่มาของโหนดระบายน้ำเมื่อคุณทำเครื่องหมายโหนดเป็น ท่อระบายน้ำ Docker Swarm จะมอบหมายคอนเทนเนอร์ใด ๆ ที่ทำงานบนโหนดนั้นไปยังโหนดอื่น ๆ และจะไม่เริ่มคอนเทนเนอร์ใด ๆ บนโหนดจนกว่าคุณจะเปลี่ยนความพร้อมใช้งานกลับเป็น คล่องแคล่ว .

สมมติว่าเราต้องการระบาย node1 เราสามารถเรียกใช้:

docker node update --availability drain node1

ง่าย! เมื่อคุณพร้อมที่จะนำกลับมาใช้งานได้:

docker node update --availability active node1

ห่อ

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

ทำความเข้าใจพื้นฐาน

Docker Swarm คืออะไร?

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

ทำไมคุณถึงใช้ Docker Swarm?

แทนที่จะจัดการโครงสร้างพื้นฐานของคุณด้วยตนเอง Docker Swarm ช่วยให้คุณสามารถระบุได้อย่างชัดเจนว่าจะปรับใช้และปรับขนาดแอปของคุณอย่างไร เมื่อติดตั้งแล้วจะช่วยให้มั่นใจได้ว่าตรงตามข้อกำหนดของคุณอย่างต่อเนื่อง

ต้องใช้อะไรบ้างในการทำให้ Docker Swarm ทำงาน

ไม่มาก! เพียงติดตั้ง Docker บนโฮสต์ของคุณและให้หนึ่งในนั้นเริ่มต้นฝูง เมื่อเสร็จแล้วโฮสต์อื่น ๆ ก็สามารถเข้าร่วมได้อย่างรวดเร็ว

Docker Swarm เชื่อมช่องว่างระหว่างการพัฒนาและการดำเนินงานอย่างไร

ต้องขอบคุณ Docker stacks ที่ใช้ไวยากรณ์เดียวกันกับ docker-compose นักพัฒนาของคุณจะทำงานส่วนใหญ่ในการเขียนการกำหนดค่า stack ของคุณได้แล้ว! ซึ่งหมายความว่าจะมีเซอร์ไพรส์น้อยลงเมื่อถ่ายทอดสดและนั่นก็เป็นสิ่งที่ดีเสมอ