คอนเทนเนอร์ใน Windows Server 2016: สิ่งที่คุณต้องรู้

ในเรื่องราวที่ฉันเขียนสำหรับComputerworldในเดือนมกราคมซึ่งเป็นบทวิจารณ์ของ Windows Server 2016 Technical Preview 4 ฉันได้กล่าวถึงการสนับสนุนใหม่ของ Windows Server สำหรับคอนเทนเนอร์ Hyper-V ที่เพิ่มเข้ามาเพื่อรองรับคอนเทนเนอร์สไตล์ Docker (ปัจจุบันอยู่ในเบต้า ผลิตภัณฑ์นับตั้งแต่การเปิดตัวเป้าหมายเบต้าก่อนหน้านี้)

อย่างไรก็ตามการมีคอนเทนเนอร์สองตัวเลือกทำให้เกิดคำถามมากมาย อะไรคือความแตกต่างระหว่าง Docker container และ Hyper-V container ใหม่? ในสถานการณ์ใดที่คุณต้องการใช้โซลูชันคอนเทนเนอร์หนึ่งกับอีกโซลูชัน มีวิธีการแยกต่างหากในการปรับใช้แต่ละวิธีเหล่านี้หรือไม่?

Microsoft ไม่ได้ทำงานที่ยอดเยี่ยมในการจัดทำเอกสารตัวเลือกคอนเทนเนอร์ทั้งสองนี้และตัวคอนเทนเนอร์เองก็ยังใหม่สำหรับแพลตฟอร์ม Windows Server ด้วยปัจจัยทั้งสองนี้ฉันต้องการอุทิศเรื่องราวทั้งหมดให้กับโซลูชันคอนเทนเนอร์เฉพาะที่ Windows Server 2016 มีให้ในตอนนี้ในรูปแบบการแสดงตัวอย่างในรุ่นที่มีอยู่หรือสัญญาว่าจะให้ก่อนวันที่ซอฟต์แวร์ออกสู่การผลิต (RTM) ซึ่งส่วนใหญ่อาจอยู่ใน ครึ่งหลังของปี 2559

ภาพรวม

มีคอนเทนเนอร์สองประเภทใน Windows Server 2016 ในขณะนี้: คอนเทนเนอร์ Windows Server และคอนเทนเนอร์ Hyper-V ทั้งสองรองรับ Windows Server เท่านั้น ไม่สามารถผสมและจับคู่ Linux และ / หรือ Unix ได้เช่นกัน

สำหรับผู้ดูแลระบบที่ขี้เกียจอย่างฉันขอให้เราถามคำถามที่สำคัญออกไปก่อน: คอนเทนเนอร์หนึ่งในสองประเภทใช้งานได้ยากกว่าประเภทอื่นหรือไม่? คำตอบคือไม่เน้น

[อ่านเพิ่มเติม: รูปลักษณ์แรก: เรียกใช้ VM ใน VM ด้วยคอนเทนเนอร์ Hyper-V]

ประเภทคอนเทนเนอร์ดำเนินการแตกต่างกันและมีระดับการแยกและความไว้วางใจในไฮเปอร์ไวเซอร์ที่แตกต่างกัน แต่หลัก ๆ แล้วนี่คือการตัดสินใจในการปรับใช้งานโดยเจ้าของเครื่องทางกายภาพ - เจ้าของโฮสต์ - เกี่ยวกับประเภทของคอนเทนเนอร์ที่จะใช้และทำได้ง่ายเพียงแค่ตรวจสอบปุ่มตัวเลือกที่ถูกต้องในตัวช่วยสร้าง . คุณเพียงแค่เลือกระหว่างสองอย่างในเวลาสร้าง การตัดสินใจมีผลต่อวิธีการที่ Windows Server 2016 - ระบบปฏิบัติการ (ไฮเปอร์ไวเซอร์นั่งอยู่ที่ด้านล่างของสิ่งเหล่านี้ทั้งหมดทำงานบนซิลิกอนและเหล็กทางกายภาพ) - แยกและดำเนินการปริมาณงานภายในแต่ละคอนเทนเนอร์

ตอนนี้คุณรู้แล้วว่าอ็อพชันคอนเทนเนอร์ใดเป็นจำนวนงานที่เท่ากันสำหรับคุณคุณจะตัดสินใจอย่างชาญฉลาดระหว่างทั้งสองได้อย่างไร? โดยพื้นฐานแล้วมันขึ้นอยู่กับความไว้วางใจ: หากคุณเชื่อถือโค้ดที่ทำงานภายในคอนเทนเนอร์คุณจะต้องเลือกคอนเทนเนอร์ Windows Server (อ่าน: แบบดั้งเดิมสไตล์ Docker) หากคุณไม่เชื่อถือโค้ดหรือไม่สามารถตรวจสอบได้หรือไม่ได้มาจากนักพัฒนาภายในของคุณภายในองค์กรของคุณเองคอนเทนเนอร์ Hyper-V ก็เป็นหนทางที่จะไป มาดูรายละเอียดแต่ละตัวเลือกกัน

คอนเทนเนอร์ Windows Server

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

การแชร์นี้ยังคงแยกคอนเทนเนอร์ออกจากแอปพลิเคชันใด ๆ ที่อาจทำงานบนโฮสต์ แต่ยังช่วยลดค่าใช้จ่ายและทำให้คอนเทนเนอร์มีน้ำหนักเบามากขึ้น คุณมีเฮดรูมมากขึ้นต่อเซิร์ฟเวอร์ที่ใช้งานคอนเทนเนอร์เนื่องจากการแชร์นี้ซึ่งต่างจากการใช้เครื่องเสมือนแบบเดิมซึ่งแยกได้มากกว่าและไม่แชร์อะไรเลย - จึงมีแนวโน้มที่จะมีการทำซ้ำมากขึ้น โดยทั่วไปคุณจะใช้คอนเทนเนอร์ของ Windows Server เมื่อโฮสต์และแขกของคุณใช้ระบบปฏิบัติการเดียวกันทั้งหมดเพื่อใช้ประโยชน์จากการแบ่งปันนี้ เป็นผลให้คุณไม่สามารถเรียกใช้คอนเทนเนอร์ที่มีเซิร์ฟเวอร์ Ubuntu ที่ทำงานบนโฮสต์ Windows Server 2016 (สำหรับเวิร์กโหลดประเภทนั้นคุณจะใช้เครื่องเสมือนแบบเดิมคอนเทนเนอร์จะไม่เหมาะสมสำหรับสิ่งนี้คุณแค่ใช้ VM ซึ่งได้รับการสนับสนุนใน Windows ตั้งแต่ปี 2008)

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

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

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

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

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

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

คอนเทนเนอร์ Hyper-V

นั่นคือเมื่อคุณเริ่มมองหาคอนเทนเนอร์ Hyper-V ซึ่งแต่งงานกับโมเดลของการแยกและนามธรรมจากเครื่องเสมือนแบบเดิมด้วยความยืดหยุ่นรูปภาพและรูปแบบการปรับใช้ใหม่ที่ง่ายของคอนเทนเนอร์ Windows Server แบบ Docker พร้อมกับ Docker API และเครื่องมือการจัดการที่ ฉันได้พูดคุยในหัวข้อก่อนหน้านี้

Mark Russinovich, CTO ของ Microsoft Azure กล่าวไว้ในรายการบล็อกเมื่อปีที่แล้ว: คอนเทนเนอร์ Hyper-V "แยกแอปพลิเคชันด้วยการรับประกันที่เกี่ยวข้องกับการจำลองเสมือนแบบเดิม แต่ด้วยความสะดวกรูปแบบภาพและรูปแบบการจัดการของ Windows Server Containers รวมถึง การสนับสนุน Docker Engine " ความแตกต่างคือระดับของการแยก: คอนเทนเนอร์ Hyper-V ไม่แชร์ไฟล์ระบบปฏิบัติการกระบวนการและบริการกับโฮสต์โดยตรง แต่ Windows Server จะรวมอิมเมจคอนเทนเนอร์ขนาดเล็กแต่ละอิมเมจไว้ในเครื่องเสมือนที่มีค่าใช้จ่ายต่ำมากซึ่งบรรลุขอบเขตที่เป็นนามธรรมและเชื่อถือได้ว่าคอนเทนเนอร์ Windows Server แบบ Docker ไม่มี

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

ข้อเสียของแนวทางนี้: มีค่าใช้จ่ายมากขึ้น เนื่องจากการแยกเพิ่มเติมโค้ดและกระบวนการเพิ่มเติมจึงซ้ำกัน นอกจากนี้ยังมีความจริงที่ว่าแม้ว่ากระดาษห่อหุ้มเครื่องเสมือนน้ำหนักเบาสำหรับคอนเทนเนอร์ Hyper-V จะมีขนาดเล็ก แต่ก็เพิ่ม "ภาษี" ให้กับค่าใช้จ่ายในการเรียกใช้อิมเมจคอนเทนเนอร์ ดังนั้นในขณะที่คุณสามารถบรรจุโฮสต์ที่มีประสิทธิภาพซึ่งเต็มไปด้วยคอนเทนเนอร์ Windows Server แบบ Docker ได้ แต่คอนเทนเนอร์ Hyper-V จะถูก จำกัด ไว้ที่คอนเทนเนอร์จำนวนน้อยกว่า แต่อย่างอื่นทั้งหมดก็คือฮาร์ดแวร์ที่ชาญฉลาดเท่ากัน

อีกครั้งอิมเมจคอนเทนเนอร์เหล่านี้จะรองรับเฉพาะ Windows Server แม้ว่าจะมีการแยกกัน แต่ก็ยังมีการใช้ร่วมกันระหว่างอิมเมจคอนเทนเนอร์และระบบปฏิบัติการโฮสต์ ดังนั้นหากอิมเมจคอนเทนเนอร์ของคุณใช้ Linux, Unix, BSD หรือระบบปฏิบัติการทางเลือกอื่น ๆ คุณลักษณะใหม่ของ Windows Server 2016 เหล่านี้จะไม่สำคัญสำหรับคุณ

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

คอนเทนเนอร์ Docker

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

ตู้คอนเทนเนอร์หางเป็นสิ่งที่เฉพาะของตัวเองและในขณะที่ภาชนะที่ใช้ Windows Server ทำหน้าที่เหมือนภาชนะเทียบท่าในความสามารถของพวกเขาไปใช้ร่วมกัน แต่แยก - ซึ่งเป็นเหตุผลที่ฉันได้เรียกพวกเขาเป็น Docker- รูปแบบภาชนะบรรจุที่ใช้ Windows Server - พวกเขาไม่ได้เป็นภาชนะหางต่อ se . สิ่งนี้อาจเปลี่ยนแปลงได้ในอนาคตโดยเฉพาะอย่างยิ่งใน Service Pack หรือ Windows Server รุ่นถัดไป แต่สำหรับตอนนี้คอนเทนเนอร์ทั้งสามประเภทนี้แม้ว่าจะคล้ายกันทั้งหมด แต่ยังคงเป็นแนวคิดที่แตกต่างกัน Windows Server รองรับเพียงสองเครื่องเท่านั้น

ปัจจุบันเทคโนโลยีอยู่ที่ไหน

ตอนนี้การสนับสนุนคอนเทนเนอร์ใน Windows Server 2016 อยู่ระหว่างดำเนินการ มีหลายส่วนที่เคลื่อนไหวไปยังคอนเทนเนอร์: การลบการอ้างอิงบนไฟล์โฮสต์และระบบปฏิบัติการและเวอร์ชันเฉพาะและระดับแพตช์ บรรลุการแยกที่ถูกต้องและทำให้มั่นใจว่าไม่มีรหัสใดสามารถละเมิดขอบเขตความปลอดภัยและความไว้วางใจได้ ทำให้เรื่องราวของนักพัฒนาซอฟต์แวร์ถูกต้องด้วยเครื่องมือและระบบอัตโนมัติที่อนุญาตให้นักพัฒนาทำงานกับคอนเทนเนอร์ในสภาพแวดล้อมการพัฒนาแบบรวม (IDE) ที่ต้องการและ "ส่งออก" แอปพลิเคชันของตนไปยังคอนเทนเนอร์โดยตรง ตรวจสอบให้แน่ใจว่าตู้คอนเทนเนอร์สามารถเลื่อนขึ้นและลงสู่ระบบคลาวด์สาธารณะได้อย่างราบรื่น และอื่น ๆ.

ในทุกกรณีเหล่านี้ยังคงมีข้อผิดพลาดและข้อบกพร่องร้ายแรงที่ต้องดำเนินการ หากคอนเทนเนอร์มีความสำคัญต่อแผนงานการให้บริการภายในร้านของคุณคุณอาจต้องการเริ่มทดสอบความสามารถของคอนเทนเนอร์ Windows Server และคอนเทนเนอร์ Hyper-V ในตอนนี้และโดยเฉพาะอย่างยิ่งตรวจสอบคำสั่ง PowerShell ที่พร้อมใช้งานเพื่อเปิดใช้งานคอนเทนเนอร์และเพื่อจัดการ บนโฮสต์ Windows Server 2016

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

การสนับสนุนคอนเทนเนอร์จะเป็นส่วนเสริมที่น่าตื่นเต้นสำหรับแพลตฟอร์ม Windows ยังมีเรื่องราวอีกมากมายที่จะต้องเขียนและบอกเล่า

เรื่องนี้ "คอนเทนเนอร์ใน Windows Server 2016: สิ่งที่คุณต้องรู้" เผยแพร่ครั้งแรกโดย Computerworld