รีวิว: Red Hat Docker เป็นวิธีที่ยาก

Project Atomic ของ Red Hat เป็นวิธีที่ได้รับความเห็นชอบในการเรียกใช้คอนเทนเนอร์ Linux ระบบปฏิบัติการ Atomic Host มาพร้อมกับ Docker (คอนเทนเนอร์), Flannel (ระบบเครือข่าย), OSTree (การจัดการโฮสต์), Etcd (ที่เก็บคีย์ - ค่าแบบกระจาย) และ Kubernetes (orchestration) ที่ติดตั้งไว้แล้ว 

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

Kubernetes ประสานการสร้าง "พ็อด" ในโฮสต์ของอะตอมหลายตัว พ็อดคือกลุ่มของคอนเทนเนอร์ Docker ที่แยกบริการในแอปพลิเคชันอย่างมีเหตุผล คอนเทนเนอร์ในพ็อดแชร์ที่อยู่ IP และสื่อสารผ่าน localhost

Flannel จัดเตรียมเครือข่ายซ้อนทับสำหรับโฮสต์ของ Atomic ทำให้ทุกพ็อดในคลัสเตอร์สื่อสารกับพ็อดหรือบริการอื่น ๆ ภายในคลัสเตอร์ เครือข่ายซ้อนทับนี้ใช้สำหรับเครือข่ายคอนเทนเนอร์เท่านั้น บริการพร็อกซี Kubernetes ให้การเข้าถึงพื้นที่ IP ของโฮสต์

Etcd ใช้เพื่อจัดเก็บการกำหนดค่าสำหรับทั้ง Kubernetes และ Flannel ในโฮสต์ทั้งหมดในคลัสเตอร์

กลุ่มภาชนะบรรจุปรมาณูตั้งสมมติฐานบางอย่างเนื่องจาก Kubernetes ผู้ดูแลระบบไม่มีทางเลือกกับ Atomic จริงๆ: ให้ใช้ Kubernetes หรือค้นหาระบบปฏิบัติการคอนเทนเนอร์อื่น 

หากคุณชื่นชอบ“ การออกแบบตามแบบแผน” และคุณต้องการอิสระและความยืดหยุ่นมากขึ้นในโฮสต์คอนเทนเนอร์คุณอาจพิจารณา RancherOS หรือ VMware Photon หากเป้าหมายสูงสุดของคุณคือการเรียกใช้คอนเทนเนอร์จำนวนมากในหลายโฮสต์ Atomic Host, Kubernetes และเพื่อน ๆ อาจเป็นเพียงสิ่งที่คุณต้องการ  

การดูแลระบบ Atomic Host

Atomic Host ใช้dockerคำสั่งเวอร์ชันของตัวเองatomicแม้ว่าdockerคำสั่งจริง  จะพร้อมใช้งานใน / bin / docker ตำแหน่งใน / bin บ่งบอกถึงการทำงานซ้ำบางส่วนที่ทำกับ RHEL / CentOS / Fedora เพื่อให้ Atomic OS สร้างขึ้นโดยเฉพาะสำหรับคอนเทนเนอร์ โดยปกติเฉพาะไบนารีระบบที่สำคัญเท่านั้นที่อยู่ใน / bin

คุณจัดการ Atomic Host ผ่านสองระบบย่อย RPM-OSTree จัดการการปรับใช้และการอัพเดตของระบบโฮสต์ในขณะที่ Docker จะจัดการการจัดเตรียมคอนเทนเนอร์สำหรับการรันเซอร์วิสและแอพพลิเคชั่น ระบบย่อยทั้งสองนี้ถูกจัดการโดยatomicคำสั่งที่อยู่ใน / usr / bin /

RPM-OSTree ทำให้ระบบไฟล์ Atomic ไม่เปลี่ยนรูป กล่าวคือระบบไฟล์เป็นแบบอ่านอย่างเดียวยกเว้น / var และ / etc ไดเร็กทอรี / var / lib / docker คือที่เก็บไฟล์และรูปภาพที่เกี่ยวข้องกับ Docker ทั้งหมดในขณะที่ / etc มีไฟล์คอนฟิกูเรชันทั้งหมด ดังที่เราจะเห็นในภายหลังสิ่งนี้ทำให้การอัปเกรดและการดาวน์เกรดของโฮสต์ง่ายขึ้นและปลอดภัยขึ้นซึ่งเป็นข้อกำหนดที่จำเป็นเมื่อจัดการโฮสต์คอนเทนเนอร์หลายพันโฮสต์ในคลัสเตอร์

atomicคำสั่งมีวัตถุประสงค์เพื่อเป็นจุดเริ่มต้นที่เดียวที่จะคอนเทนเนอร์ระบบย่อยคำสั่งร่มสำหรับทุกสิ่งภาชนะรวมทั้งการดำเนินโฮสต์atomicคำสั่งดูและรู้สึกเหมือนdockerคำสั่ง แต่อยู่ปัญหาพื้นฐานที่ใช้ร่วมกันโดยทุกระบบปฏิบัติการโฮสต์ภาชนะ: เริ่มต้นการให้บริการระดับระบบในภาชนะในเวลาบูตในวิธีที่เชื่อถือได้และมีความโปร่งใสโดยใช้ไฟล์หน่วย Systemd

ในปรมาณูสิ่งนี้ทำด้วยสิ่งที่เรียกว่าคอนเทนเนอร์ที่มีสิทธิพิเศษซึ่งมีความสามารถในการมองเห็นและจัดการกับโฮสต์เอง ดังนั้นแม้ว่าจะatomicดูเหมือนคำสั่ง Docker มาตรฐาน แต่ก็เป็นการเติมเต็มช่องว่างระหว่าง Docker และ RPM-OSTree นั่นคือการกำหนดค่าสคริปต์การติดตั้งการตั้งค่าบริการการกำหนดสิทธิ์ที่เหมาะสมและอื่น ๆ ที่คล้ายกันเพื่อให้สามารถใช้งานแอปพลิเคชันที่ใช้คอนเทนเนอร์ได้อย่างน่าเชื่อถือ .

พูดง่ายๆคือ  atomic คำสั่งอนุญาตให้คุณจัดการโครงสร้างพื้นฐานของโฮสต์พื้นฐาน (cgroups, namespaces, SELinux ฯลฯ ) เพื่อเรียกใช้แอปพลิเคชันของคุณ ตัวอย่างเช่นสมมติว่าคุณสร้างแอปพลิเคชันคอนเทนเนอร์ Network Time Protocol (ntpd) ที่ต้องการความสามารถ SYS_TIME เพื่อปรับเปลี่ยนเวลาระบบของโฮสต์ คุณสามารถกำหนดค่าได้โดยเพิ่มข้อมูลเมตาลงในอิมเมจคอนเทนเนอร์ของคุณโดยใช้คำสั่ง:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

จากนั้นเมื่อคุณรัน container ( atomic run ntpd) ระบบจะอ่านข้อมูลเมตานั้นและกำหนดค่าความสามารถ SYS_TIME และทรัพยากรอื่น ๆ สำหรับคอนเทนเนอร์ 

การติดตั้งและการกำหนดค่า Atomic Host

การติดตั้งเป็นเรื่องยากส่วนใหญ่เป็นเพราะฉันพบว่าเอกสารไม่เป็นระเบียบและสับสน เอกสารนี้ถือว่ามีความรู้ระดับสูงเกี่ยวกับระบบนิเวศของ Red Hat ซึ่งไม่ใช่ผู้อ่านทุกคนจะมี หลังจากเริ่มต้นผิดพลาดเล็กน้อยในที่สุดฉันก็สามารถติดตั้งจาก ISO โลหะเปลือยได้ การสนับสนุนการติดตั้งเครื่องเสมือนด้วยสิ่งอื่นนอกเหนือจากการจัดการที่ดีเป็นเรื่องที่เจ็บปวด Atomic Host ไม่ใช่ Windows หรือ Mac อย่างแน่นอนในเรื่องนี้

สำหรับใครก็ตามที่คุ้นเคยกับการติดตั้ง CentOS ขั้นตอนการเปลือยโลหะจะเป็นเรื่องง่าย ความแตกต่างที่เห็นได้ชัดเจนเพียงอย่างเดียวคือในเค้าโครงดิสก์โดยมีการสงวนพื้นที่ไว้โดยอัตโนมัติสำหรับ Docker และคอนเทนเนอร์พร้อมกับการเมาท์สำหรับ SELinux, cgroups และอื่น ๆ ที่มาพร้อมกับการติดตั้งระบบปฏิบัติการคอนเทนเนอร์

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

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

หลังจากกำหนดค่าต้นแบบด้วย Kubernetes ใบรับรองบริการและเครือข่ายซ้อนทับ Flannel จากนั้นติดตั้ง Flannel (ผ้าสักหลาด), Kubernetes (kubelet) และ Etcd ในแต่ละโหนดในที่สุดฉันก็มีคลัสเตอร์คอนเทนเนอร์ห้าโหนดที่ทำงานอยู่ น่าเสียดายที่สิ่งนี้ใช้หน่วยความจำค่อนข้างน้อยและฉันไม่สามารถหาวิธีทดสอบโดยใช้โหนดเดียวได้เหมือนที่ฉันทำเมื่อทดสอบ RancherOS และ VMware Photon

ณ จุดนี้สามารถใช้ Kubernetes เพื่อเปิดและจัดการพ็อดซึ่งเป็นกลุ่มคอนเทนเนอร์ที่ห่อหุ้มบริการและแอปพลิเคชัน

การจัดเก็บ Atomic Host และระบบเครือข่าย

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

ใน Docker โดยทั่วไปรูปภาพและไฟล์ที่เกี่ยวข้องจะถูกเก็บไว้ใน / var / lib / docker และในระบบปฏิบัติการมาตรฐานส่วนใหญ่คุณเพียงแค่ติดตั้งอุปกรณ์ที่จุดนั้นในระบบไฟล์เพื่อเพิ่มที่จัดเก็บข้อมูล อย่างไรก็ตาม Atomic ใช้ไดรฟ์ข้อมูล LVM โดยตรง (Linux Volume Manager) ผ่านทางด้านหลัง Device Mapper เพื่อจัดเก็บอิมเมจ Docker และข้อมูลเมตา: / dev / atomicos / docker-data และ / dev / atomicos / docker-meta นั่นหมายความว่าคุณจะต้องเรียนรู้บางอย่างเกี่ยวกับ LVM และไดรฟ์ข้อมูลเพื่อเพิ่มพื้นที่ให้กับโฮสต์อะตอม

จุดเริ่มต้นสำหรับการจัดการหน่วยเก็บข้อมูลใน Atomic คือสคริปต์การตั้งค่า / etc / sysconfig / docker-storage-setup Atomic Host มีพูลหน่วยเก็บข้อมูลสำหรับ Docker (และโฮสต์) ดังนั้นเคล็ดลับที่นี่คือการเพิ่มอุปกรณ์ใหม่ลงในพูลนี้ คุณสามารถทำได้โดยเพิ่มลงในรายการอุปกรณ์ในไฟล์ดังนี้:

DEVS="/dev/vdb /dev/vdc"

จากนั้นคุณรันสคริปต์ตัวช่วย / usr / bin / docker-storage-setup หากทุกอย่างเป็นไปด้วยดีดิสก์ของคุณจะถูกเพิ่มลงในพูลและโฮสต์ Atomic ของคุณมีพื้นที่สำหรับ Docker ฉันคิดว่า LVM จะได้รับการจัดการในการผลิตด้วยเครื่องมือการดูแลระบบที่มีอยู่หรือด้วยสคริปต์ Ansible / Salt / Chef / Puppet ดังนั้นอาจเป็นมาตรฐานมากกว่าสำหรับผู้ดูแลระบบที่ทำงานในสภาพแวดล้อมดาต้าเซ็นเตอร์ขนาดใหญ่

Project Atomic ใช้ Flannel เพื่อจัดหาเครือข่ายการซ้อนทับคอนเทนเนอร์ผ่าน Etcd คุณกำหนดค่าได้โดยการพุชไฟล์คอนฟิกูเรชัน JSON ลงในที่เก็บคีย์ - ค่า Etcd โดยใช้เครื่องมือเช่น Curl ในการกำหนดค่าซับเน็ตสำหรับคอนเทนเนอร์เราอาจสร้างไฟล์ JSON ที่มีลักษณะดังนี้:

   “ เครือข่าย”:“ 172.16.0.0/12”,

   “ SubnetLen”: 24,

   “ แบ็กเอนด์”: {

      “ ประเภท”:“ vxlan”

   }

}

และเพื่อให้สิ่งนี้เข้าสู่ Etcd master เราจะกดเข้าไปในคีย์การกำหนดค่าเครือข่าย:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

แม้ว่าจะค่อนข้างยุ่งยาก แต่ก็สามารถจัดการได้ ฉันชอบที่จะเห็นเสื้อคลุมสำหรับคำสั่งกำหนดค่าเหล่านี้ที่ทำให้มันง่ายขึ้นสำหรับผู้ดูแลระบบยูนิกซ์บางทีสิ่งที่ชอบatomic ifconfig…, atomic route…ฯลฯ

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

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

Atomic Host อัพเกรดและดาวน์เกรด

Atomic Host ใช้ตัวจัดการแพ็คเกจที่เรียกว่า RPM-OSTree ซึ่งรวมคุณสมบัติของ RPM และ OSTree แบบดั้งเดิม RPM-OSTree ช่วยให้เราสามารถหมุนไปข้างหน้าและถอยหลังได้อย่างน่าเชื่อถือเนื่องจากกระบวนการนี้เป็น "ปรมาณู" (ในฐานข้อมูลของคำ) RPM-OSTree ให้ธุรกรรมที่เชื่อถือได้สำหรับการอัปเดตซึ่งหมายความว่าไม่น่าจะทำให้ระบบปฏิบัติการเสียหาย เช่นเดียวกับคำสั่งสำหรับคอนเทนเนอร์การอัปเกรดโฮสต์และการย้อนกลับจะถูกนำหน้าโดยatomicระบบการจัดการ:

atomic host upgrade

atomic host rollback

โปรดทราบว่าฉันไม่ได้ทดสอบการย้อนกลับเพราะฉันไม่มีอะไรจะย้อนกลับไป

Red Hat Atomic Host เหมาะที่สุดสำหรับองค์กรที่มีการลงทุนจำนวนมากในทักษะและโครงสร้างพื้นฐานของ Red Hat บริษัท ที่เริ่มต้นจากมุมมองที่แตกต่างกันอาจต้องการพิจารณาตัวเลือกอื่น ๆ การรวม Kubernetes และประวัติของ Red Hat ในสภาพแวดล้อมการผลิตขนาดใหญ่หมายความว่า Atomic Host แทบจะเป็น "ดรอปอิน" สำหรับการเรียกใช้ปริมาณงานที่มีคอนเทนเนอร์ในองค์กร แต่ฉันไม่เห็นนักพัฒนาเลือกใช้เป็นแพลตฟอร์ม Docker ที่พวกเขาเลือก