ด้วยแอพ 'การปฏิวัติ' ของคอนเทนเนอร์ได้เติบโตขึ้นมากกว่าแค่ฐานข้อมูลและส่วนหน้า แอปพลิเคชันถูกแบ่งออกเป็นไมโครเซอร์วิสต่างๆ และโดยทั่วไปจะสื่อสารระหว่างกันผ่าน REST API (โดยทั่วไปแล้วจะเป็นเพย์โหลดที่จัดรูปแบบ JSON ผ่าน HTTP) คอนเทนเนอร์ Docker เหมาะสำหรับสถาปัตยกรรมประเภทนี้ คุณสามารถจัดแพ็คเกจ 'microservice' ฟรอนต์เอนด์ของคุณลงในคอนเทนเนอร์ Docker ฐานข้อมูลจะไปที่อื่น และอื่น ๆ แต่ละบริการพูดคุยกับบริการอื่นผ่าน REST API ที่กำหนดไว้ล่วงหน้า แทนที่จะเป็นเสาหินที่เขียนเป็นซอฟต์แวร์ชิ้นเดียว
หากคุณต้องการใช้ฟังก์ชันหรือคุณลักษณะใหม่ เช่น เครื่องมือวิเคราะห์ คุณสามารถเขียนไมโครเซอร์วิสใหม่สำหรับสิ่งนั้น และจะใช้ข้อมูลผ่าน REST API ที่เปิดเผยโดยไมโครเซอร์วิสต่างๆ ของเว็บแอปของคุณ และเมื่อฟังก์ชันของคุณเติบโตขึ้นเรื่อยๆ รายการไมโครเซอร์วิสนี้ก็จะเติบโตขึ้นตามไปด้วย
คุณไม่ต้องการปรับใช้แต่ละคอนเทนเนอร์ กำหนดค่าแล้วกำหนดค่าทุกอย่างอื่นเพื่อพูดคุยกับมันเช่นกัน นั่นจะน่าเบื่อแม้กับสามตู้คอนเทนเนอร์ Docker-Compose ช่วยให้คุณสามารถปรับใช้คอนเทนเนอร์หลายรายการได้โดยอัตโนมัติ
Docker-Compose เป็นหนึ่งในเครื่องมือที่ง่ายที่สุดที่ช่วยให้คุณเปลี่ยนแนวคิดนามธรรมของไมโครเซอร์วิสเป็นชุดที่ใช้งานได้ของคอนเทนเนอร์ Docker
ระบบกระจาย
ตอนนี้เราได้แยกการเปิดเว็บแอปออกเป็นหลายคอนเทนเนอร์แล้ว มันไม่สมเหตุสมผลเลยที่จะเก็บไว้ทั้งหมดบนเซิร์ฟเวอร์เดียว (ที่แย่กว่านั้นคือบนเครื่องเสมือนเครื่องเดียว!) ซึ่งเป็นที่ที่บริการต่างๆ เช่น Docker Swarm และ Kubernetes เข้ามามีบทบาท
Docker Swarm อนุญาตให้คุณเรียกใช้แอปพลิเคชันจำลองหลายตัวในเซิร์ฟเวอร์หลายเครื่อง หากไมโครเซอร์วิสของคุณเขียนในลักษณะที่สามารถปรับขนาด 'ในแนวนอน' ได้ คุณสามารถใช้ Docker Swarm เพื่อปรับใช้เว็บแอปของคุณในศูนย์ข้อมูลหลายแห่งและหลายภูมิภาคได้ สิ่งนี้ให้ความยืดหยุ่นต่อความล้มเหลวของศูนย์ข้อมูลหรือลิงค์เครือข่ายอย่างน้อยหนึ่งแห่ง โดยทั่วไปจะทำโดยใช้คำสั่งย่อยใน Docker นั่นคือ Docker Stack
NS Docker Stack คำสั่งย่อยทำงานเหมือนกับคำสั่ง Docker-Compose มากกว่า และอาจนำไปสู่ความเข้าใจผิดต่อผู้ที่ใช้เทคโนโลยีอย่างใดอย่างหนึ่ง
ที่มาของความสับสน
ในแง่ของการใช้งานและเวิร์กโฟลว์ เทคโนโลยีทั้งสองทำงานคล้ายกันมาก และทำให้เกิดความสับสน วิธีที่คุณปรับใช้แอปของคุณโดยใช้ Docker Swarm หรือ Docker-Compose นั้นคล้ายกันมาก คุณกำหนดแอปพลิเคชันของคุณในไฟล์ YAML ไฟล์นี้จะมีชื่อรูปภาพ การกำหนดค่าสำหรับแต่ละรูปภาพ และขนาด (จำนวนแบบจำลอง) ที่แต่ละไมโครเซอร์วิสจะต้องตรงตามในการปรับใช้
ความแตกต่างส่วนใหญ่อยู่ในแบ็กเอนด์ โดยที่ docker-compose ปรับใช้คอนเทนเนอร์บนโฮสต์ Docker เดียว Docker Swarm จะปรับใช้ในหลายโหนด พูดอย่างหลวมๆ ก็ยังสามารถทำสิ่งต่างๆ ส่วนใหญ่ที่นักเทียบท่าเขียนได้ แต่ขยายขนาดข้ามโฮสต์ Docker หลายตัว
ความคล้ายคลึงกัน
ทั้ง Docker Swarm และ Docker-Compose มีความคล้ายคลึงกันดังต่อไปนี้:
- ทั้งคู่ใช้คำจำกัดความการจัดรูปแบบ YAML ของสแต็กแอปพลิเคชันของคุณ
- ทั้งสองมีไว้เพื่อจัดการกับแอปพลิเคชันหลายคอนเทนเนอร์ (microservices)
- ทั้งคู่มีพารามิเตอร์สเกลที่ให้คุณเรียกใช้คอนเทนเนอร์หลายตัวของอิมเมจเดียวกันได้ ทำให้ไมโครเซอร์วิสของคุณปรับขนาดในแนวนอนได้
- พวกเขาทั้งสองได้รับการดูแลโดยบริษัทเดียวกัน นั่นคือ Docker, Inc.
ความแตกต่าง
ข้อแตกต่างเล็กน้อยระหว่าง Docker Swarm และ Docker-Compose:
- Docker Swarm ใช้เพื่อปรับขนาดเว็บแอปของคุณในเซิร์ฟเวอร์ตั้งแต่หนึ่งเครื่องขึ้นไป โดยที่ Docker-compose จะเรียกใช้เว็บแอปของคุณบนโฮสต์ Docker เดียว
- การปรับขนาดเว็บแอปของคุณ Docker Swarm ให้ความพร้อมใช้งานสูงและความทนทานต่อข้อผิดพลาดอย่างร้ายแรง การปรับขนาดเว็บแอปโดยใช้ Docker-Compose บนโฮสต์เดียวมีประโยชน์สำหรับการทดสอบและการพัฒนาเท่านั้น
- Docker Swarm และคำสั่งย่อยที่เกี่ยวข้อง เช่น Docker Swarm และ Docker Stack ถูกสร้างใน Docker CLI ทั้งหมดนี้เป็นส่วนหนึ่งของไบนารีของ Docker ที่คุณโทรผ่านเทอร์มินัลของคุณ Docker-Compose เป็นไบนารีแบบสแตนด์อโลนในตัวของมันเอง
กรณีการใช้งานสำหรับ Docker-Compose
ตามที่อธิบายไว้ข้างต้น ทั้งสองเป็นเครื่องมือที่แตกต่างกันโดยสิ้นเชิง และแต่ละอันก็แก้ปัญหาที่แตกต่างกันโดยสิ้นเชิง ดังนั้นจึงไม่เหมือนกับว่าตัวใดตัวหนึ่งเป็นทางเลือกสำหรับอีกทางหนึ่ง อย่างไรก็ตาม เพื่อให้ผู้ใช้ใหม่เข้าใจถึงสิ่งที่ฉันกำลังพูดถึง นี่คือกรณีการใช้งานสำหรับ Docker Compose
สมมติว่าคุณต้องการโฮสต์บล็อก WordPress ด้วยตนเองบนเซิร์ฟเวอร์เดียว การตั้งค่าหรือบำรุงรักษาไม่ใช่สิ่งที่คุณต้องการทำด้วยตนเอง ดังนั้นสิ่งที่คุณจะทำแทนคือติดตั้ง Docker และ Docker-compose บน VPS ของคุณ สร้างไฟล์ YAML ง่ายๆ ที่กำหนดแง่มุมต่างๆ ของสแต็ก WordPress ของคุณ เช่นด้านล่าง :
หมายเหตุ: หากคุณกำลังใช้ข้อมูลด้านล่างเพื่อปรับใช้ไซต์ WordPress โปรดเปลี่ยนรหัสผ่านทั้งหมดเป็นสิ่งที่ปลอดภัย ยังดีกว่า ใช้ Docker Secrets เพื่อจัดเก็บข้อมูลที่สำคัญ เช่น รหัสผ่าน แทนที่จะเก็บไว้ในไฟล์ข้อความธรรมดา
รุ่น:'3'บริการ:
ฐานข้อมูล:
ภาพ: mysql:5.7
ปริมาณ:
- db_data:/ที่ไหน/lib/mysql
รีสตาร์ท: เสมอ
สิ่งแวดล้อม:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
เวิร์ดเพรส:
ขึ้นอยู่กับ:
- db
ภาพ: wordpress:ล่าสุด
พอร์ต:
-'8000: 80'
รีสตาร์ท: เสมอ
สิ่งแวดล้อม:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpressPassword
WORDPRESS_DB_NAME: wordpress
ปริมาณ:
db_data:{}
เมื่อไฟล์ถูกสร้างขึ้นและติดตั้งทั้ง Docker และ Docker-compose สิ่งที่คุณต้องทำคือเรียกใช้:
$นักเทียบท่า-เขียนขึ้น-NSและเว็บไซต์ของคุณจะพร้อมใช้งาน หากมีการอัปเดตให้เรียกใช้:
$นักเทียบท่า-เขียนลงจากนั้นทิ้งภาพ Docker เก่าและเรียกใช้คำสั่ง docker-compose up -d แล้วภาพใหม่จะถูกดึงเข้ามาโดยอัตโนมัติ เนื่องจากคุณมีข้อมูลถาวรที่จัดเก็บไว้ใน Docker Volume เนื้อหาของเว็บไซต์ของคุณจะไม่สูญหาย
เมื่อใดควรใช้ Docker Swarm
ในขณะที่ Docker-compose เป็นเครื่องมืออัตโนมัติมากกว่า แต่ Docker Swarm นั้นมีไว้สำหรับแอปพลิเคชันที่มีความต้องการมากขึ้น เว็บแอปที่มีผู้ใช้หรือปริมาณงานนับร้อยหรือหลายพันที่ต้องปรับขนาดควบคู่กัน บริษัทที่มีฐานผู้ใช้ขนาดใหญ่และข้อกำหนด SLA ที่เข้มงวดต้องการใช้ระบบแบบกระจาย เช่น Docker Swarm หากแอปของคุณทำงานบนเซิร์ฟเวอร์หลายเครื่องและศูนย์ข้อมูลหลายแห่ง โอกาสในการหยุดทำงานเนื่องจาก DC หรือลิงก์เครือข่ายที่ได้รับผลกระทบจะลดลงอย่างมาก
ที่กล่าวว่าฉันลังเลที่จะแนะนำ Docker Swarm สำหรับกรณีการใช้งานจริงเนื่องจากเทคโนโลยีที่แข่งขันกันอย่าง Kubernetes นั้นเหมาะสมกว่าสำหรับงานนี้ Kubernetes ได้รับการสนับสนุนโดยกำเนิดจากผู้ให้บริการระบบคลาวด์หลายราย และใช้งานได้ดีกับ Docker Containers ดังนั้นคุณจึงไม่ต้องสร้างแอปใหม่เพื่อใช้ประโยชน์จาก Kubernetes
บทสรุป
ฉันหวังว่าการเดินเตร่บน Docker และโครงการดาวเทียมนั้นเป็นข้อมูล และคุณพร้อมสำหรับระบบนิเวศของนักเทียบท่ามากขึ้น