cloud_computing

ภาพที่ 10.1 หนาจอการตดิ ตัง้ คณุ สมบตั ิระบบยอยลีนกุ ซสำหรบั วนิ โดวส หลังจากที่รีบูตเครื่องมาแลว ใหผูอานเปดหนาตาง Powershell โดยมีสิทธิ์ผูดูแลระบบ เพื่อตั้งคาใหใช ระบบยอ ยลนี กุ ซของวนิ โดวสเวอรช นั 2 เปน เวอรชันเรมิ่ ตน ดวยคำส่ัง # wsl --set-default-version 2 ในกรณีที่การตั้งคาไมถกู ตอง เชน ติดตั้งคุณสมบัตขิ องระบบปฏิบัติการไมครบ หรือไมไดเปด การทำงาน ของการทำเสมือนที่ไบออสจะแสดงขอความเหมือนภาพที่ 10.2 แตถาการตั้งคาถูกตองและครบถวนสมบูรณ หลงั พมิ พค ำส่ังจะแสดงขอความเหมอื นภาพที่ 10.3 ภาพท่ี 10.2 หนา จอขอผดิ พลาดเมื่อเปลี่ยนเวอรชันระบบยอ ยลีนกุ ซสำหรับวินโดวส 181

ภาพที่ 10.3 หนา จอการเปล่ียนเวอรช นั ระบบยอยลนี กุ ซสำหรบั วนิ โดวส ำเรจ็ ข้ันตอนถัดไป คอื การติดต้งั ดิสตริบวิ ชันของระบบปฏิบัติการลนี ุกซท ่ีถูกออกแบบมาพิเศษใหใชแกนของ ลีนุกซที่ระบบปฏิบัติการวินโดวส ซึ่งสามารถคนหาไดจาก Microsoft Store โดยทั่วไป และผูอานสามารถ เลือกดิสตริบิวชันอะไรก็ไดมาติดตั้งเปนแบ็กเอนดของด็อกเกอร (Microsoft Inc. 2020c) โดยทั่วไปลีนุกซ Ubuntu จะเปนที่นิยมสำหรับนักพัฒนาซอฟตแวรที่ใชงานระบบยอยของลีนุกซเนื่องจากมีเวอรชันของ แพ็คเกจซอฟตแวรท ีค่ อ นขางทนั สมยั และดว ยการทีล่ ีนกุ ซ Ubuntu ถูกพฒั นามาจาก Debian ทำใหต ัวจัดการ แพ็คเกจเปน apt ซึ่งมีขอดีอีกอยางหนึ่ง คือ มีแพ็คเกจซอฟตแวรเปนจำนวนมากที่สุดเมื่อเทียบกับตัวจัดการ แพ็คเกจอยาง yum ในลีนุกซตระกูล CentOS หรือ Red Hat แตเนื่องจากการใชงานลีนุกซดิสตริบิวชันอื่นท่ี ไมเหมือนเดิมอาจทำใหการพิมพคำสั่งของผูอานสะดุด ทางผูเขียนจึงแนะนำใหใช Fedora Remix ซึ่งเปน ดิสตริบิวชันที่พัฒนาจากลีนุกซ Fedora และมีตัวจัดการแพ็คเกจเปน yum และที่อยูการตั้งคาของโปรแกรม ตาง ๆ เหมือนกบั CentOS แทบทง้ั หมดทำใหผูอานไดมีประสบการณที่ตอเนื่องเม่ือพิมพคำส่ังสลับกันระหวาง CentOS กับ Fedora Remix ดิสตริบิวชัน Fedora Remix สามารถดาวนโหลดผาน Microsoft Store ไดแตมีคาใชจายอยูท่ี 349 บาท แตทางผูพัฒนาไดเผยแพรดิสตริบิวชัน Fedora Remix ฟรีผานเว็บไซต github.com ซึ่งถาผูอานดาวน โหลดจากเว็บไซต github.com จะสามารถติดตั้งไดโดยไมมีคาใชจายที่ https://github.com/ WhitewaterFoundry/Fedora-Remix-for-WSL เมื่อเขาไปแลวจะปรากฎหนาเว็บดังภาพที่ 10.4 ใหคลิกที่ Release ท่ีเมนูฝง ขวามอื 182

ภาพท่ี 10.4 สวนหน่ึงของหนาเว็บไซต Remix เวอรชันในปจจุบันคือ Fedora Remix 31.5.0 ซึ่งพัฒนามาจาก Fedora 31 และเปนเวอรชันที่มีความ ใกลเคียงกับ CentOS 8 มากที่สุด จากนั้นใหคลิกดาวนโหลดแฟมขอมูลประเภท appxbundle จากสวน Assets ตามภาพท่ี 10.5 ภาพท่ี 10.5 สวนหน่ึงของหนา เวบ็ ไซตดาวนโ หลด Fedora Remix เมื่อดาวนโหลดเสร็จแลว ผูอานสามารถดับเบิ้ลคลิกเพื่อทำการติดตั้งโปรแกรม Fedora Remix โดย หลงั จากท่ตี ิดตง้ั สำเร็จ ลนี กุ ซด ิสตรบิ วิ ชันจะถามใหผ ูอานสรา งผใู ชงานสำหรับปฏสิ ัมพนั ธกบั โปรแกรม Fedora Remix ดังภาพที่ 10.6 ผูอานสามารถตั้งชื่อบัญชีผูใชและรหัสผานไดตามตองการ โดยไมกระทบตอการตั้งคา หรือติดตั้งโปรแกรมด็อกเกอรสำหรับวินโดวส แตบัญชีผูใชนี้ถูกสรางเพื่อใหผูอานสามารถใชงานลีนุกซเพ่ือ ติดตัง้ และเรยี กโปรแกรมที่มอี ยใู นลนี ุกซไ ดในภายหลัง 183

ภาพที่ 10.6 หนาจอการตงั้ คา Fedora Remix หลังเปดการใชง านครั้งแรก จากนั้นกอนการติดตั้งโปรแกรมด็อกเกอร ผูอานควรตรวจสอบคุณสมบัติของดิสตริบิวชันที่ติดต้ังลงไป โดยเขา Powershell และพิมพค ำสงั่ # wsl -l -v คำสั่งนี้จะเปนคำสั่งแสดงรายการของดิสตริบิวชันลีนุกซที่ถูกติดตั้งพรอมทั้งสถานะ และเวอรชันของ ระบบยอยลีนุกซที่ใชงานอยูดังภาพที่ 10.7 โปรแกรม Fedora Remix จะตั้งชื่อเริ่มตนใหเปน fedoraremix หากมีเครื่องหมายดอกจันทนอยูหนา fedoraremix หมายถึงดิสตริบิวชันนีเ้ ปนดิสตริบิวชันเริม่ ตนที่ด็อกเกอร จะถูกติดตั้งลงไป ในกรณีที่ผูอานมีดิสตริบิวชันอื่นกอนหนา ผูอานสามารถตั้งคาให Fedora Remix เปน ดิสตรบิ ิวชันเริม่ ตน ดวยคำสง่ั # wsl --set-default fedoraremix แตห ากเวอรชันของระบบยอยลีนุกซท ใี่ ชง านไมใ ชเวอรชนั 2 ผอู านสามารถเปลี่ยนเวอรชันไดด ว ยคำสั่ง # wsl --set-version fedoraremix 2 หากแสดงผลไดถกู ตอ ง แสดงวา การติดตั้งระบบยอยลนี กุ ซสำหรบั วินโดวสเสร็จสมบูรณ ภาพท่ี 10.7 หนาจอแสดงชื่อดิสตริบวิ ชนั และเวอรช ันของลนี ุกซ 184

10.3 การตดิ ต้งั ดอ็ กเกอรสำหรบั ระบบปฏิบัติการวินโดวส เมื่อผูอานตั้งคาแบ็กเอนดใหกับโปรแกรมด็อกเกอรสำหรับวินโดวสแลว สามารถดาวนโหลด Docker Desktop for Windows ไดจากเว็บไซตด็อกเกอรฮับที่ https://hub.docker.com/editions/community /docker-ce-desktop-windows เมื่อเขาไปเว็บไซตแลวจะปรากฎหนาเว็บดังภาพที่ 10.8 โดยด็อกเกอรมีให เลือกสองรุน คอื Stable และ Edge ด็อกเกอรรุน Stable หรือรุนเสถียรเปนด็อกเกอรที่ถูกปลอยมาใหดาวนโหลดหลังจากการทดสอบ ซอฟตแวรเบื้องตนทำใหมั่นใจวาผูอานจะสามารถใชงานไดอยางไมมีปญหา โดยรุน Stable นี้จะมีการอัพเดท ใหมทุก 3 เดือน สวนด็อกเกอรรุน Edge หรือรุนใหมเปนด็อกเกอรที่มีคุณสมบัติใหมแตยังอยูในระหวางการ พัฒนา การทดสอบการใชงาน และมีรหัสตนฉบับที่สามารถคอมไพลผาน โดยรุน Edge นี้จะมีการอัพเดทใหม ทกุ สปั ดาห วิธีการเลือกใชงานรุนของด็อกเกอร คือ สำหรับผูอานที่กำลังศึกษาด็อกเกอรและผูอานที่ตองการนำ ด็อกเกอรไปใชงานในสภาพการใชงานจริง ผูเขียนแนะนำใหผูอานใชด็อกเกอรรุน Stable เพราะโอกาสเกิด ขอผิดพลาดท่เี กิดการจากพัฒนาและยังผานการทดสอบไมครบถวนจะมีนอย สวนผูอานท่ีมีด็อกเกอรใชงานอยู ในสภาพการใชงานจริงอยูแลว และตองการศึกษาคุณสมบัติใหมข องด็อกเกอรในเคร่ืองของตนเอง เพ่ือตองการ ทดสอบและนำคุณสมบัติใหมน้ันไปใชในสภาพการใชงานจริงเมื่อคุณสมบัตนิ ัน้ ถูกยา ยมาอยูใ นรุน Stable และ ผูอา นพรอ มอพั เดทโปรแกรมด็อกเกอรเปนประจำ ในกรณีน้ี รนุ Edge จะเหมาะสมกับผูอ านมากกวา ภาพท่ี 10.8 สวนหน่ึงของหนาเว็บไซตดาวนโ หลดดอ็ กเกอรส ำหรับวนิ โดวส เมื่อดาวนโหลดตัวติดตั้งมาแลว และดับเบิ้ลคลิกเพื่อเปดการทำงานของตัวติดตั้ง ผูอานจะพบกับ หนาตางดังภาพที่ 10.9 แสดงการตั้งคาสำหรับติดตั้งด็อกเกอรสำหรับวินโดวส ใหผูอานคลิกไมเลือก Enable WSL 2 Windows Features เพราะตัวติดตั้งในบางเวอรชันอาจทำใหการติดตั้งไมสำเร็จ อยางไรก็ตามกอน การดำเนินการตอ ผูอานควรมั่นใจวาไดเตรียมพรอมแบ็กเอนดสำหรับด็อกเกอรไวเรียบรอยแลว ไมวาจะ เลือกใช Hyper-V หรือระบบยอ ยลีนุกซสำหรบั วนิ โดวส อยา งใดอยางหน่ึง หรือทั้งสองอยาง ซง่ึ ถา ผูอานมีพรอม ทั้งสองอยาง ผูอานจะสามารถสลับแบ็กเอนดหลังการติดตั้งได แตผูเขียนไมแนะนำ เพราะเพียงแคแบ็กเอนด เดียวก็เพียงพอตอการทำงานไดอยางสมบูรณ อีกตวั เลือกหนึง่ หรือ Add shortcut to desktop เปน ตัวเลือกท่ี 185

ตวั ตดิ ตั้งด็อกเกอรจ ะสรา งทางลัดเพ่ือเปดการทำงานของด็อกเกอรไวทเี่ ดกสท็อป เมื่อเลอื กไดตามตองการแลว กด Ok เพื่อดำเนนิ การติดตัง้ ภาพท่ี 10.9 หนา ตางการตงั้ คาสำหรบั ตดิ ตัง้ ดอ็ กเกอร ในกรณีที่ผูอานเตรียมแบ็กเอนดเปนระบบยอยของลีนุกซเวอรชัน 2 เมื่อติดตั้งเสร็จ ตัวติดตั้งด็อกเกอร จะถามใหกด Close เพื่อปดตัวติดตั้ง แตถาผูอานเตรียมแบ็กเอนดเปน Hyper-V เมื่อติดตั้งเสร็จ ตัวติดต้ัง ด็อกเกอรจะถามใหกด Close and Logout ดังภาพที่ 10.10 ผูอานควรมั่นใจวาไมมีโปรแกรมอื่น ๆ ที่ยังไมได บนั ทกึ ขอมลู เปดคา งไวอ ยู เพราะตวั ติดต้งั จะลอ็ กเอาตแ ละลอ็ กเอาตบ ัญชีของผูอานในวนิ โดวสใหมอีกครง้ั ภาพท่ี 10.10 หนาตางเมื่อติดตง้ั ด็อกเกอรสำหรบั วนิ โดวสสำเร็จ เมือ่ ตดิ ตง้ั เสรจ็ แลว ผูอานสามารถส่ังใหด ็อกเกอรสำหรับระบบปฏบิ ัติการวนิ โดวสทำงานไดโดยการคลิก ไอคอนทางลัดที่เดกสท็อป หรือเขาจากปุมสตารท > Docker Desktop หากผูอานเตรียมระบบยอยลีนุกซ สำหรบั วนิ โดวสเปนแบ็กเอนด โปรแกรมด็อกเกอรจ ะเร่ิมการทำงานทนั ที แตถ า ผูอานเตรียม Hyper-V ไว และ 186

ยังไมไดติดต้ังระบบยอยลีนุกซของวินโดวส ด็อกเกอรจะแสดงหนาตางสอบถามผูอา นใหยืนยันใช Hyper-V ดัง ภาพท่ี 10.11 ใหผ ูอานคลกิ เลอื ก Use Hyper-V เพือ่ ดำเนินการตอ ภาพท่ี 10.11 หนาตางสอบถามใหย ืนยันใช Hyper-V หากเครื่องของผูอานเปนวินโดวส 10 เวอรชัน 2004 ซึ่งสามารถติดตั้งระบบยอยลีนุกซสำหรับวินโดวส เวอรช นั 2 ได โปรแกรมด็อกเกอรจะแสดงหนาตางสอบถามใหผูอา นสลับไปใชระบบยอยลีนุกซสำหรับวินโดวส แทนการใช Hyper-V หรือไม ดังภาพที่ 10.12 หากผูอานเลือกใช Hyper-V ใหคลิกที่ Not now จากนั้น โปรแกรมดอ็ กเกอรจ ะเริ่มการทำงาน ภาพที่ 10.12 หนา ตา งสอบถามใหสลับไปใชระบบยอยลีนกุ ซ ในกรณีที่ผูอานเลือกใช Hyper-V หากเปดเครื่องมือ Hyper-V Manager ที่เขาถึงจากปุมสตารทและ พิมพคน หาวา Hyper-V Manager ผูอานจะพบเครอ่ื งคอมพวิ เตอรเสมือนชื่อ DockerDesktopVM ถกู สรางข้ึน และทำงานโดยอตั โนมัติ ดังภาพท่ี 10.13 187

ภาพท่ี 10.13 หนาตา งแสดงเคร่ืองคอมพิวเตอรเ สมอื น หลงั จากทโ่ี ปรแกรมด็อกเกอรสำหรับวนิ โดวสไดถูกติดตงั้ และเปดการทำงานแลว ผูอานสามารถทดสอบ การทำงานของด็อกเกอรวาพรอมใชงานหรือไม ไดโดยการเปดหนาตาง Powershell หรือ Command Prompt และพมิ พค ำสัง่ # docker version ถาหากการติดตั้งและการเปดการทำงานสำเร็จ หลังจากพิมพคำสั่งจะแสดงผลลัพธดังภาพที่ 10.14 ที่ แสดงเวอรช ันของด็อกเกอรล ูกขา ย และด็อกเกอรแ มขาย หากการติดตัง้ สำเร็จและไมไดเ ปดการทำงาน ผลลพั ธ ที่แสดงจะแสดงเฉพาะเวอรชันของด็อกเกอรลูกขายเทานั้น ในกรณีนี้แสดงวาผูอานลืมคลิกไอคอน Docker Desktop เพ่ือเปด การทำงานของด็อกเกอรแมขาย ภาพที่ 10.14 หนาตา งแสดงเวอรชนั ของด็อกเกอรล ูกขา ยและด็อกเกอรแ มขา ย 188

10.4 การติดต้งั ด็อกเกอรสำหรับระบบปฏบิ ัตกิ ารลีนุกซ ตั้งแตเริ่มมีการพัฒนาโปรแกรมด็อกเกอร โปรแกรมด็อกเกอรไดถูกพัฒนาใหทำงานไดบน ระบบปฏิบัติการลีนุกซอยูแลว ดังนั้น การติดตั้งโปรแกรมด็อกเกอรในระบบปฏิบัติการลีนุกซสามารถ ดำเนนิ การไดท ันที และมีข้นั ตอนไมซ บั ซอ น ดังนี้ 1) เนื่องจากแพ็คเกจของด็อกเกอรไมไดอยูกับระบบปฏิบัติการ ผูอานจำเปนตองเพิ่มคลังแพ็คเกจ (Repository) ใหกับตวั จดั การแพค็ เกจของระบบปฏิบตั ิการกอน ดวยคำสั่ง # yum install -y yum-utils # yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo 2) หากเปนระบบปฏิบัติการ CentOS 7 หรือเกากวา เมื่อเพิ่มแหลงที่มาของแพ็คเกจจะสามารถตดิ ตง้ั Docker Community Edition ไดด วยคำส่ัง # yum install docker-ce หากเปนระบบปฏิบัติการ CentOS 8 หรือใหมกวา เมื่อเพิ่มแหลงที่มาของแพ็คเกจจะตองติดต้ัง แพ็คเกจ containerd.io กอน โดยผูอานสามารถหาเวอรชันลาสุดไดจากลิงก https:// download.docker.com/linux/centos/7/x86_64/stable/Packages/ ซึ่งเวอรชันที่ลาสุด ณ ชวงเวลาที่ผูเขียนเขียนตำราเลมนี้ คือ containerd.io-1.2.13-3.2.el7.x86_64.rpm ดังนั้น ผูอาน จะสามารถติดต้งั แพ็คเกจ containerd.io เวอรชนั ลาสดุ ไดด วยคำส่ัง # yum install https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ containerd.io-1.2.13-3.2.el7.x86_64.rpm หรือผูอา นสามารถใชส คริปตทีค่ น หาเวอรช ันสุดทา ยของแพ็คเกจ containerd.io ไดดวยคำสงั่ # latest=$(curl -s https://download.docker.com/linux/centos/7/ x86_64/stable/Packages/ | awk -F'\"' '/containerd.io/ {print $2}' | sort -V | tail -1) # yum install https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ $latest จากสามารถตดิ ตง้ั โปรแกรม Docker Community Edition ไดด วยคำส่งั # yum install docker-ce ในกรณีที่ไมต องการติดตัง้ containerd.io เวอรชนั ลาสุด ระบบปฏิบัตกิ าร CentOS 8 ยังมีแพ็คเกจ containerd.io เวอรชนั ท่ีมาพรอมกับระบบปฏิบัตกิ าร ซ่ึงสามารถติดต้ังอัตโนมัตไิ ดด วยคำส่งั 189

# yum install docker-ce --nobest พารามิเตอร nobest ใชเฉพาะกับระบบปฏิบัติการ CentOS หรือ RHEL เวอรชัน 8 เนื่องจาก ระบบปฏิบัติการ CentOS หรือ RHEL เวอรชัน 8 ไดพัฒนาแอปพลิเคชันบรรจุคอนเทนเนอรขึ้นมา ตางหาก ทำใหเกิดปญหาระหวางทีมผูพัฒนา ทำใหทีมผูพัฒนาด็อกเกอรไมคอมไพลแพ็คเกจบาง แพ็คเกจอยาง containerd.io ใหกับระบบปฏิบัติการ CentOS หรือ RHEL 8 หรือใหมกวา โดยเฉพาะ ในระหวางการติดตั้งโปรแกรม yum อาจสอบถามใหผูอานยืนยันการใชกุญแจสาธารณะของ คลังแพ็คเกจดอ็ กเกอรเพื่อตรวจสอบแพค็ เกจ ใหต อบ y เพื่อดำเนนิ การตอ 3) เม่ือติดตั้งเสรจ็ จะตองส่งั ใหโปรแกรมดอ็ กเกอรทำงานทนั ที และทำงานเมือ่ รบี ูตเครื่อง ดว ยคำสัง่ # systemctl start docker # systemctl enable docker 4) ผูอานสามารถตรวจสอบไดวาติดตั้งโปรแกรมด็อกเกอรเสร็จสมบูรณและด็อกเกอรโฮสตทำงานอยู หรอื ไม ดวยคำสงั่ # docker version หากปรากฎผลลัพธแสดงเวอรชันทั้ง Client และ Server ดังภาพที่ 10.15 แสดงวาโปรแกรม ดอ็ กเกอรพ รอ มใชงาน 5) เปดการทำงานของไฟรวอลลโดยอนุญาตใหคอนเทนเนอรที่สรางจากด็อกเกอรสามารถเชื่อมตอ อินเทอรเน็ตได โดยปกติด็อกเกอรจะเพิ่มอินเตอรเฟสเครือขายเริ่มตนไวที่โซนสาธารณะ (Public zone) อยูแ ลว สามารถอนุญาตใหแพกเกตวงิ่ ผาน โดยใชคำสง่ั # firewall-cmd --zone=public --add-masquerade --permanent # firewall-cmd --reload 190

ภาพที่ 10.15 หนาจอผลลพั ธค ำสง่ั แสดงเวอรช ันโปรแกรมดอ็ กเกอร 191

บทสรปุ ขัน้ ตอนการติดตง้ั โปรแกรมดอ็ กเกอรมีความแตกตา งกันระหวางระบบปฏบิ ัตกิ าร ในกรณีที่ระบบปฏิบัติการเปนวินโดวส 10 โปรแกรมด็อกเกอรจำเปนตองใชแบ็กเอนดเปน ระบบปฎิบัติการลีนุกซซ่ึงมวี ิธีการตดิ ตัง้ 3 แนวทาง คือ 1) ใชโ ปรแกรม Hyper-V เปน แบก็ เอนด เหมาะสำหรับ วินโดวส 10 ที่ไมไดอัพเดทเปนเวอรชัน 2004 แตเปนรุนที่สูงกวาโฮมอิดิชัน 2) ใชระบบยอยลีนุกซเปนแบ็ก เอนด เหมาะสำหรบั วินโดวส 10 ท่ไี ดอัพเดทเปนเวอรชัน 2004 หรอื เปนรุนโฮมอิดิชัน และมหี นวยประมวลผล กลางเปน AMD และการเลือกดสิ ตริบิวชันสามารถเลือกดสิ ตริบิวชนั ไดหลากหลายตามความถนัดของผูอาน 3) สรางเครื่องคอมพิวเตอรเสมือนดวยโปรแกรม Hyper-V หรือ VMWare Workstation Player แลวติดต้ัง โปรแกรมดอ็ กเกอรสำหรับระบบปฏบิ ตั กิ ารลีนกุ ซ ในกรณีที่ระบบปฏิบัติการเปนลีนุกซ ผูอานสามารถติดตั้งโปรแกรมด็อกเกอรไดโดยตรง โดยหากเปน ระบบปฏิบัติการ CentOS 8 หรือ Red Hat Enterprise Linux 8 หรือใหมกวา ผูอานควรติดตั้งแพ็คเกจ containerd.io ดวยตนเองกอ นการตดิ ตั้งด็อกเกอร 192

สรปุ คำส่งั ท่ีนาสนใจ เนื้อหา คำส่ังหรอื ช่ือคำส่งั ท่เี กี่ยวขอ ง คำส่ังตดิ ตั้งระบบยอยลีนุกซผาน cmd # dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart # dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart คำสั่งตดิ ต้ังระบบยอยลนี ุกซผาน # Enable-WindowsOptionalFeature -Online - Powershell FeatureName Microsoft-Windows-Subsystem-Linux -All -NoRestart # Enable-WindowsOptionalFeature -Online - FeatureName VirtualMachinePlatform -All -NoRestart เปลี่ยนเวอรช ันของระบบยอยลีนกุ ซเปน # wsl --set-default-version 2 เวอรชนั 2 แสดงรายการดสิ ตรบิ วิ ชนั ลนี กุ ซท่ถี ูก # wsl -l -v ตดิ ตัง้ ตั้งคา ดสิ ตรบิ ิวชนั เร่มิ ตน # wsl --set-default fedoraremix เปล่ียนเวอรช ันของดสิ ตริบวิ ชัน # wsl --set-version fedoraremix 2 ตรวจสอบการติดตั้งด็อกเกอร # docker version ดาวนโหลดด็อกเกอรสำหรับวินโดวส https://hub.docker.com/editions/community /docker- ce-desktop-windows ติดต้งั ดอ็ กเกอรสำหรบั ลีนุกซ # yum install -y yum-utils # yum-config-manager --add-repo https://download .docker.com/linux/centos/docker-ce.repo หากเปน CentOS 7 หรอื เกา กวา # yum install docker-ce หากเปน CentOS 8 หรอื ใหมกวา # latest=$(curl -s https://download.docker.com/ linux/centos/7/ x86_64/stable/Packages/ | awk -F'\"' '/containerd.io/ {print $2}' | sort -V | tail -1) # yum install https://download.docker.com/linux /centos/7/x86_64/stable/Packages/$latest หรือ # yum install docker-ce --nobest 193

เนอื้ หา คำสงั่ หรือช่ือคำสัง่ ท่เี ก่ียวขอ ง เปด การทำงานของด็อกเกอร # systemctl start docker ต้งั คาไฟรว อลลใหค อนเทนเนอรในด็อก # systemctl enable docker เกอรส ามารถเช่อื มตอ อินเทอรเนต็ ได # firewall-cmd --zone=public --add-masquerade -- permanent # firewall-cmd --reload 194

แบบฝกหดั บทท่ี 10 1. บอกแนวทางการติดต้ังด็อกเกอรส ำหรบั ระบบปฏบิ ตั ิการวินโดวส หากเครื่องของผอู านมีหนวย ประมวลผลกลางเปน AMD หรอื ใชวนิ โดวส รนุ โฮมอิดชิ นั 2. บอกช่อื คณุ สมบัติทีจ่ ำเปน สำหรบั การทำงานระบบยอยลีนกุ ซส ำหรับวินโดวส 3. ในกรณที ีเ่ วอรช นั ของระบบยอยลีนุกซท่ีใชงานเปนเวอรชัน 1 จะสามารถเปลี่ยนเปน เวอรช นั 2 โดยไมต อ ง ตดิ ต้ังดสิ ตรบิ วิ ชันของลนี ุกซใหมไดหรอื ไม อยา งไร 4. บอกความแตกตา งระหวา งดอ็ กเกอรสำหรับวนิ โดวส รนุ Stable และรนุ Edge 5. การตดิ ตั้งด็อกเกอรส ำหรับลนี ุกซในระบบปฏิบตั กิ าร CentOS 7 ตา งจาก CentOS 8 อยางไร 195

196

การใชงานเบอื้ งตนแอปพลิเคชนั เทคโนโลยบี รรจคุ อนเทนเนอร บทนำ หน่งึ ใหเ หตุผลหนง่ึ ทีท่ ำใหด อ็ กเกอรเ ปนโปรแกรมที่นา สนใจ คือ การท่ีดอ็ กเกอรเปน ระบบท่มี ีระบบนิเวศ ขนาดใหญ มีแอปพลิเคชันที่ถูกสรางเปนอิมเมจจำนวนมาก และอัพเดทใหทันสมัยอยูเสมอ ผูอานสามารถ เรียกใชอิมเมจที่ถกู สรางโดยผูพ ัฒนาโดยมาสรางเปนคอนเทนเนอรไดตามความตองการ โดยที่สามารถควบคุม การทำงานคอนเทนเนอรไ ดโดยไมสง ผลกระทบตอเครอ่ื งแมขาย 11.1 การคน หาและเรียกใชงานอิมเมจมาตรฐาน อิมเมจมาตรฐาน คือ อิมเมจของซอฟตแวรที่ผูพัฒนาซอฟตแวรเปนผูจัดทำขึ้นมาและดูแลรักษาดวย ตัวเอง ขอดีของอิมเมจมาตรฐานคืออิมเมจที่ใหใชงานจะเปนอิมเมจที่ทันสมัย เพราะเมื่อผูพัฒนาซอฟตแวร ปลอยซอฟตแวรในรูปแบบปกติหรือแฟมขอมูลไบนารีแลว ผูพัฒนาซอฟตแวรจะสามารถปลอยซอฟตแวรใน รูปแบบอิมเมจไปพรอมกันดวย เมื่อการตองการใชงานอิมเมจมาตรฐาน ผูอานสามารถคนหาอิมเมจมาตรฐาน ไดจากรจี ีสตรสี าธารณะของดอ็ กเกอรท ่เี ว็บไซต https://hub.docker.com (Docker Inc. 2020a) โดยมีชองท่ี สามารถคนหาอิมเมจมาตรฐานได ยกตัวอยางเชน หากตองการคนหาโปรแกรมเว็บเซิรฟเวอร apache (The Apache Software Foundation 2020) กพ็ ิมพคำคน วา apache เปน ตน ดังภาพท่ี 11.1 ภาพท่ี 11.1 สว นหนึ่งของหนาเวบ็ ไซตด อ็ กเกอร 197

ภาพท่ี 11.2 ผลลัพธก ารคนหาอิมเมจ จากภาพที่ 11.2 แสดงผลลัพธอิมเมจที่เกี่ยวของกับคำคน apache โดยอิมเมจมาตรฐานของโปรแกรม Apache มชี ื่อ httpd ปจ จุบันมยี อดดาวนโ หลดมากกวา 10 ลานคร้ัง เมอื่ คลกิ เขาไปจะแสดงรายละเอียดของ อิมเมจมาตรฐาน httpd ดังภาพที่ 11.3 ผูอานสามารถเลือกแพลตฟอรมทางฝงขวามือสำหรับเครื่อง คอมพวิ เตอรสว นบุคคลท่ีใชงานกันทว่ั ไปจะเลือกเปน Linux – x86-64 (latest) จะปรากฏชอื่ อิมเมจมาตรฐาน ทีเ่ หมาสมกบั แพลตฟอรมทเ่ี ลอื ก ภาพท่ี 11.3 สวนหนึ่งหนาเว็บแสดงรายละเอยี ดอิมเมจ httpd 198

ผูอานสามารถเรมิ่ ดาวนโหลดอิมเมจ httpd ท่ีเปนเวอรช ันลา สดุ มาเก็บไวในเครอื่ งได โดยใชคำส่งั # docker pull httpd ภาพที่ 11.4 หนาจอผลลพั ธคำสั่งดาวนโ หลดอิมเมจ เมื่อดาวนโหลดเสร็จสิ้น จะปรากฏขอความดังภาพที่ 10.4 วาอิมเมจไดถูกดาวนโหลดสำเร็จ ผูอาน สามารถตรวจสอบรายการอมิ เมจท่ถี ูกดาวนโ หลดมาไวในเครือ่ ง โดยใชค ำสง่ั # docker image ls ภาพท่ี 11.5 หนาจอผลลัพธคำสัง่ แสดงรายการอิมเมจ โปรแกรมด็อกเกอรจะแสดงชื่อของอิมเมจ ชอ่ื แท็ก รหสั อมิ เมจ วันท่ผี พู ัฒนาอิมเมจสรา ง และขนาดของ อิมเมจดังภาพที่ 10.5 โดยขนาดของอิมเมจเปนขนาดที่ไมถูกบีบอัด (Uncompressed) แตเมื่อถูกดาวนโหลด หรืออัพโหลดจากรีจีสตรี รีจีสตรีจะเก็บอิมเมจในรูปแบบที่บีบอัด (Compressed) และเก็บคาแฮชดวย อัลกอริทึม SHA-256 ของอิมเมจและแตละชั้นขอมูลเพื่อไวเปรียบเทียบหากมีอิมเมจหรือชั้นขอมูลซ้ำกันที่รีจี สตรี ชั้นขอมูลนั้นหรืออิมเมจนั้นจะไมถูกอัพโหลดหรือดาวนโหลดซ้ำ เพื่อลดปญหาการจราจรทางเครือขาย (Network Traffic) 11.2 การสรา งและเริ่มตน คอนเทนเนอร เมื่อผูอานดาวนโหลดอิมเมจมาแลว ดังที่ไดกลาวไวแลววาอิมเมจนั้นไมสามารถแกไขได (Immutable) แตห ากนำมาใชงาน โปรแกรมด็อกเกอรจะนำช้นั ขอมูลของอิมเมจมาเปนชน้ั ขอมูลฐาน และสรางช้ันขอมูลใหม ที่เก็บขอมูลเฉพาะแฟมที่มีความแตกตางจากชั้นขอมูลฐาน เรียกวา คอนเทนเนอร ดังนั้น อิมเมจหนึ่งอิมเมจ สามารถนำไปสรางคอนเทนเนอรไดหลายคอนเทนเนอรในเวลาเดียวกัน โดยเมื่ออางอิงแฟมขอมูลเดียวกัน โปรแกรมด็อกเกอรจ ะอานขอมูลจากดิสกท่ีบล็อกเดยี วกัน ทำใหร ะบบปฏบิ ัติการบางตัวสามารถทำแคชในบาง ดสิ กเ พ่ือเพิ่มประสทิ ธิภาพการทำงานได โดยปกติเมื่อสรางคอนเทนเนอร โปรแกรมด็อกเกอรจะเริ่มตนคอนเทนเทอรนั้นอันโนมัติ อยางไรก็ตาม คอนเทนเนอรนั้นถูกทำงานผานเครือขายเสมือนของด็อกเกอรไมสามารถติดตอกับด็อกเกอรโฮสตไดโดยตรง 199

ดังนั้น หากตองการกำหนดการเชื่อมตอคอนเทนเนอรกับด็อกเกอรโฮสตนั้น ผูอานจำเปนตองระบุคุณสมบัติ ดังกลาวตั้งแตสรางคอนเทนเนอร เพราะเมื่อสรางคอนเทนเนอรข ึ้นมาแลว พารามิเตอรสวนใหญจะไมส ามารถ เปล่ยี นแปลงได ทัง้ น้ี คอนเทนเนอรเ มื่อเชื่อมตอกับด็อกเกอรโฮสตและรักษาสถานะของขอมูลและเครือขายได แลว คอนเทนเนอรจะถูกหยดุ การทำงาน ลบแลว สรางใหมจ ากอิมเมจเดิม คอนเทนเนอรก็ยังสามารถทำงานได เหมอื นเดิม ตารางที่ 11.1 พารามเิ ตอรท่ีใชส รางคอนเทนเนอร ชอ่ื พารามเิ ตอร ความหมาย -i ทำงานในโหมดปฏิสัมพันธ -t สรางหนาจอเทียม -d ทำงานในโหมดพนื้ หลัง -e VAR=value กำหนดตัวแปรสภาพแวดลอมช่ือ VAR ใหมีคาเปน value -v /local/path:/container/path เชอ่ื มตอ ไดเรกทอรีบนเครื่องแมข า ย /local/path กับไดเรกทอรีใน คอนเทนเนอร /container/path -p host:port:containerPort เชอื่ มตอ พอรตบนเครื่องแมขา ยกบั ทอ่ี ยูไอพี host พอรต port กบั พอรตในเคร่ืองคอนเทนเนอร containerPort คาเรม่ิ ตน ของ host คอื 0.0.0.0 --name hostname กำหนดชอื่ ใหคอนเทนเนอรใ หเปน hostname --restart option กำหนดใหคอนเทนเนอรเ ปดคอนเทนอรเ องโดยอตั โนมตั ิ มตี ัวเลอื กเปน image_name no ไมร สี ตารท และเปด คอนเทนเนอรเองอัตโนมตั ิ command on-failure รสี ตารทและเปดคอนเทนเนอรเ องเม่ือการทำงานใน คอนเทนเนอรผิดพลาดจนคอนเทนเนอรปดตวั ลง always รสี ตารท และเปดคอนเทนเนอรเ องอัตโนมัติ unless-stopped รสี ตารทและเปด คอนเทนเนอรเองอตั โนมัติ จนกวาจะสั่งหยุดคอนเทนเนอร คา เร่มิ ตน คือ no กำหนดท่ีอยขู องอิมเมจด็อกเกอร ตำแหนงของพารามิเตอรน้จี ะตอง ไวห ลงั พารามเิ ตอรท ร่ี ะบคุ ุณสมบัติเทา น้ัน กำหนดคำสัง่ ท่ีทำงานเมื่อเริ่มตน คอนเทนเนอร ตำแหนง ของ พารามิเตอรน ต้ี องอยูถัดจาก image_name เทา นนั้ สำหรับการสรางคอนเทนเนอร โปรแกรมด็อกเกอรสนับสนุนพารามิเตอรหลายพารามิเตอรแสดงตาม ตารางที่ 11.1 และพารามิเตอรเหลานี้ควรกำหนดใหเสร็จกอนการสราง เนื่องจากคอนเทนเนอรนั้นถูกทำงาน ผานเครือขายเสมือนของด็อกเกอรไมสามารถติดตอกับด็อกเกอรโฮสตไดโดยตรง โดยเฉพาะใชจองพอรตไว 200

เชื่อมตอ กบั ด็อกเกอรโ ฮสต ดังนัน้ เวลาสรา งคอนเทนเนอร ผูอา นควรพิจารณาตามลำดบั เพื่อระบุพารามิเตอรท่ี จำเปนสำหรับการสรา งคอนเทนเนอร ดงั นี้ 1) คอนเทนเนอรนี้ทำงานดวยโหมดปฏิสัมพันธหรือโหมดพื้นหลัง หากเปนโหมดปฏิสัมพันธ ผูอานจะ สามารถเขาถึงเชลลและพิมพคำสั่งไดทันที แตหากเปนโหมดพื้นหลัง คอนเทนเนอรจะทำงานพ้ืน หลังโดยท่ไี มมกี ารปฏิสมั พันธก บั ผอู าน พารามิเตอร โหมดปฏิสัมพนั ธ คือ -it โหมดพ้ืนหลงั คอื -d และโหมดปฏสิ ัมพนั ธแตสั่งใหทำงานอยู พ้ืนหลงั คือ -dit พารามเิ ตอรนส้ี ามารถปรากฏไดเ พยี งคร้งั เดียวและจำเปนตองระบุ 2) คอนเทนเนอรนี้มีการสงตัวแปรสภาพแวดลอมหรือไม ตัวแปรสภาพแวดลอมที่สงไปยังคอนเทน เนอรมักเปนเงื่อนไขในการตัดสินใจการทำงานของอิมเมจ ผูอานสามารถศึกษาตัวแปร สภาพแวดลอมไดจากรีจสี ตรีอมิ เมจมาตรฐาน ซึ่งผูพฒั นาอมิ เมจจะกำหนดตัวแปรทสี่ ำคัญ เชน รหัส ผูใช รหสั ผา น ฐานขอ มูลเรม่ิ ตน เปน ตน พารามิเตอรของตัวแปรสภาพแวดลอม คือ -e <ชื่อตัวแปร>=<คาตัวแปร> หากตองการระบหุ ลาย ตวั แปร ใหใชพ ารามิเตอร -e หลายคร้ังตอ กนั เชน -e VAR1=value1 -e VAR2=value2 จากคำสั่ง น้ี เมอื่ echo $VAR1 $VAR2 ในเซลลของคอนเทนเนอรจ ะไดผลลัพธเปน value1 value2 พารามเิ ตอรน้ีไมจ ำเปน ตองระบุก็ได 3) คอนเทนเนอรน ี้มีการเชื่อมตอทเ่ี กบ็ ขอมูลใดกบั ไดเรกทอรีของด็อกเกอรโฮสตหรือไม การเช่ือมตอท่ี เก็บขอมลู กับไดเรกทอรีบนโฮสตจะชวยใหเ ม่ือลบคอนเทนเนอรขอมูลจะไมสูญหายไป การเชื่อมตอ ที่เก็บขอมูลของด็อกเกอรจะสนับสนุนการเชื่อมตอ แบบรายไดเรกทอรี (Per directory) เทานั้น ไม สามารถรายแฟม ขอมลู (Per file) ได พารามเิ ตอรข องการเชือ่ มที่เก็บขอมูล คอื -v <ไดเรกทอรีบนโฮสต>:<ไดเรกทอรีบนคอนเทนเนอร> หากตองการระบุหลายการเชื่อมที่เก็บขอมูล ใหใชพารามิเตอร -v หลายครั้งตอกัน เชน -v /root/database:/var/lib/postgresql -v /root/backup:/backup จากคำส่ังนี้ หากผอู า นบันทึก แฟมขอมูลหรือแกไขแฟมขอมูลในไดเรกทอรี /var/lib/postgresql และ /backup ในคอนเทน เนอร ขอ มูลจะถูกบันทึกลงบนโฮสตที่ไดเรกทอรี /root/database และ /root/backup ตามลำดับ ทำใหผ ูอา นสามารถเขาถงึ แฟมขอมลู ที่เชอ่ื มตอ ไวโ ดยท่ไี มไดเขาไปท่ีหนาจอของคอนเทนเนอร พารามิเตอรน้ีไมจำเปนตอ งระบุกไ็ ด 4) คอนเทนเนอรนี้มเี ปดพอรต และการเชื่อมตอกับพอรตบนเครื่องด็อกเกอรโฮสตหรือไม การเชื่อมตอ พอรตจะชวยใหซอฟตแวรที่ทำงานอยูในคอนเทนเนอรสามารถเชื่อมตอไปยังเครือขายภายนอกได เชน คอนเทนเนอรของเว็บเซิรฟเวอรเปดพอรต 80 เพื่อใหเขาถึงเว็บเซิรฟเวอรในคอนเทนเนอรได ผอู า นจำเปนตอ งเชือ่ มตอ พอรตของคอนเทนเนอรก บั พอรตของด็อกเกอรโ ฮสต พารามิเตอรของการเชื่อมตอพอรต คือ -p <ที่อยูไอพีของโฮสต:พอรตของโฮสต>:<พอรตของคอน เทนเนอร> ในกรณีที่ไมระบุที่อยูไอพีของโฮสต คาที่อยูไอพีของโฮสตที่จะเชื่อมตอคือ 0.0.0.0 หมายความวาเคร่ืองคอมพิวเตอรใดท่ีเชื่อมตอกบั ด็อกเกอรโ ฮสตจะสามารถเขา ถึงคอนเทนเนอรตาม 201

พอรตที่กำหนด ในบางกรณีเพื่อความมั่นคงปลอดภัย ผูอานอาจระบุใหที่อยูไอพีของโฮสตเปน 127.0.0.1 ทำใหบริการที่พอรตของคอนเทนเนอรนั้นไมสามารถเขาถึงจากเครื่องที่อยูในเครือขาย เดียวกับด็อกเกอรโฮสตได หากตองการระบุหลายการเชื่อมตอพอรต ใหใชพารามิเตอร -p หลาย ครั้งตอกัน เชน -p 127.0.0.1:5000:80 -p 443:443 จากคำสั่งนี้ เฉพาะเครื่องด็อกเกอรโฮสตเมื่อ เชื่อมตอกับพอรต 5000 ของตัวเองจะเทากับเชื่อมตอไปยังคอนเทนเนอรนั้นพอรต 80 และทุก เครื่องในเครือขายที่เชื่อมกับด็อกเกอรโฮสตเมื่อเชื่อมตอผานพอรต 443 ของด็อกเกอรโฮสต จะ เทากับเชื่อมตอ ไปยังคอนเทนเนอรน ัน้ พอรต 443 การเชื่อมตอดังกลาวโปรแกรมด็อกเกอรโฮสตจะ สรางคำสัง่ ไฟรวอลลเ พอื่ ยายแพกเกต (Packet) ไปเองโดยอัตโนมัติ พารามิเตอรน ไ้ี มจำเปนตอ งระบกุ ็ได 5) เมื่อรีสตารทเครื่องด็อกเกอรโฮสต คอนเทนเนอรนี้จะเปดการทำงานโดยอัตโนมัติหรือไม โดยปกติ เมื่อหยุดการทำงานของด็อกเกอรโฮสตและเริ่มการทำงานใหม คอนเทนเนอรทั้งหมดจะอยูใน สถานะหยุดการทำงานชัว่ คราว โดยผอู านสามารถสั่งเปดการทำงานตอได พารามิเตอรสงั่ ใหเริ่มการทำงานอตั โนมตั ิ --restart always พารามเิ ตอรน้ีไมจำเปนตอ งระบกุ ็ได 6) คอนเทนเนอรน ้ีใชอมิ เมจใดเพ่ือสรางช้นั ขอมูลฐาน ในกรณีทเี่ ปน อิมเมจมาตรฐาน ชื่อของอิมเมจมัก เปน คำเดียว เชน httpd แตห ากผอู า นสรางบัญชที รี่ จี ีสตรีและสงออกอมิ เมจของผูอา นเองชื่อจะเปน <รหสั ผูใช>/<ชอื่ อมิ เมจ> เชน utarn/httpd เปน ตน พารามิเตอรน จี้ ำเปนตองระบุ 7) ตอ งการกำหนดคำสั่งพเิ ศษท่ที ำงานเมื่อเริ่มตน คอนเทนเนอรห รอื ไม หากไมกำหนดคอนเทนเนอรจะ เริ่มตนการทำงานตามคำสั่งที่ระบุไวในอิมเมจ คำสั่งพิเศษอาจไมจำเปนหากผูอานใชอิมเมจ มาตรฐานหรืออิมเมจที่มีผูพัฒนาดูแลและเปนที่นิยม สวนใหญนิยมใชกำหนดคำสั่งเขาถึงเชลลเพือ่ ตรวจสอบการทำงานหรือตรวจสอบขอผิดพลาดของอิมเมจที่สรางขึ้นมาวาทำงานไดถกู ตองหรือไม ตวั อยา งคำส่งั พิเศษ เชน sh หรือ bash สำหรับการเขา ถึงเชลลในลีนุกซ พารามเิ ตอรนีไ้ มจำเปนตอ งระบุ จากพารามิเตอรสำหรับการสรางคอนเทนเนอร ผูอานสามารถสรางคอนเทนเนอรของเว็บเซิรฟเวอร Apache ท่ีตรงกับพารามิเตอรดังนี้ 1) ทำงานอยูในโหมดเบ้อื งหลัง ใชพ ารามเิ ตอร -d 2) เชื่อมตอไดเรกทอรี /usr/local/apache2/htdocs/ ของคอนเทนเนอรกับไดเรกทอรี /root/website ของโฮสต 3) เช่อื มตอตอ พอรต 80 ของคอนเทนเนอร กบั พอรต 80 ของโฮสต 4) ใชอมิ เมจมาตรฐาน ชอื่ httpd 202

จากเงื่อนไขดังกลาวจะสามารถสรางเปนคำสั่ง docker create หรือ docker run โดยคำสั่ง docker create จะสรางคอนเทนเนอรอยางเดียว แตคำสั่ง docker run จะสรางคอนเทนเนอรและเปดการทำงานไป พรอ มกัน ดงั น้ี # docker run -d -v /root/website:/usr/local/apache2/htdocs -p 80:80 httpd เม่ือพิมพค ำสั่งจะปรากฏผลลัพธด ังภาพที่ 11.6 แสดงรหสั ของคอนเทนเนอรท่ีสรางใหม หลังจากที่ส่ังให คอนเทนเนอรเวบ็ เซิรฟเวอรท ำงาน ผูอานสามารถตรวจสอบการทำงานของคอนเทนเนอรด ว ยคำส่งั # docker ps ภาพท่ี 11.6 หนาจอผลลพั ธคำสง่ั สรา งคอนเทนเนอรใ หม เมื่อพิมพคำสั่ง จะปรากฏผลลัพธดังภาพที่ 11.7 แสดงวาคอนเทนเนอรที่สรางขึ้นมามีรหัสเปน 1bba17d1cb3c และมีชอ่ื วา frosty_tereshkova ภาพท่ี 11.7 หนา จอผลลพั ธคำสัง่ แสดงรายการคอนเทนเนอร เนื่องจากคอนเทนเนอรไดเชื่อมตอพอรต 80 ของด็อกเกอรโฮสต ผูอานสามารถทดลองเขาเว็บของ คอนเทนเนอรเว็บเซิรฟเวอรนี้ไดจากเบราเซอรท่ี http://<ที่อยูไอพีของโฮสต> จะปรากฎผลลัพธดังภาพท่ี 10.8 ภาพท่ี 11.8 หนาจอผลลพั ธของเวบ็ เบราเซอรเ มอ่ื เขา ถึงเวบ็ ของคอนเทนเนอร เนื่องจากคอนเทนเนอรไดเชื่อมตอกับไดเรกทอรีของ /root/website ผูอานสามารถทดลองสรางหนา แรกของเว็บไซตอ ยา งงายๆ ดวยคำสง่ั 203

# echo \"Hello my first docker container\" > /root/website/index.html จากนั้นเมื่อกด F5 เพื่อรีเฟรชเบราเซอรใหม ผูอานจะไดผลลัพธดังภาพที่ 11.9 วาหนาแรกที่ทดลอง สรางปรากฎบนเว็บเซริ ฟเวอร ภาพที่ 11.9 หนา จอผลลัพธของเว็บเบราเซอรเมอ่ื เพิ่มหนาเว็บหนาแรก 11.3 อธิบายการกำหนดการทำงานของคอนเทนเนอร เมื่อสรางคอนเทนเนอรขึ้นมาแลว การแกไขการทำงานของคอนเทนเนอรจะสามารถทำไดอยางจำกัด กลาวคือ ไมใชทุกการตั้งคาเมื่อสรางคอนเทนเนอรดวยคำสั่ง docker run จะสามารถแกไขไดในภายหลัง ดังนัน้ ทางท่ีดีทสี่ ดุ ของการกำหนดการทำงานของคอนเทนเนอรคือใหกำหนดคุณสมบัตติ าง ๆ ใหเ รียบรอ ยกอน การสรางคอนเทนเนอรขึ้นมา หนึ่งในพารามิเตอรที่นิยมแกไขหลังการสรางคอนเทนเนอร คือ การกำหนดการ เปดการทำงานของคอนเทนเนอรเมื่อเริ่มตนบริการของด็อกเกอร ซึ่งบริการของด็อกเกอรนั้นสามารถตั้งคาให เริ่มการทำงานเม่ือรบี ูตเคร่ืองโฮสตได แตโ ดยเร่มิ ตน หากคอนเทนเนอรอยูในสถานะเปดการทำงานกอนการปด หรือรีสตารทบริการด็อกเกอร เมื่อบริการของด็อกเกอรในด็อกเกอรโฮสตเริ่มตนการทำงานอีกครั้ง คอนเทน เนอรจ ะอยูในสถานะออกการทำงาน (Exited) คำสั่งกำหนดการทำงานของคอนเทนเนอรทุกคำสั่งในโปรแกรมด็อกเกอรจะตองใชขอมูลอยางใดอยาง หนึ่ง คือ รหัสของคอนเทนเนอรหรือชื่อของคอนเทนเนอร ในกรณีที่เปนรหสั คอนเทนเนอรผูอ านสามารถพิมพ แคบ างสว นที่ไมซ้ำกับรหัสคอนเทนเนอรของคอนเทนเนอรอ่ืน เชน หากคอนเทนเนอรมรี หสั คอนเทนเนอรเปน 1bba17d1cb3c และมีชื่อวา frosty_tereshkova ผูอานสามารถใชคำสั่งตอไปนี้เพือ่ กำหนดใหคอนเทนเนอร อยใู นสถานะเร่มิ การทำงานพรอมกบั บรกิ ารของด็อกเกอรได # docker update --restart always 1bba17d1cb3c # docker update --restart always 1b (ในกรณที ีไ่ มม ีคอนเทนเนอรอ่นื ทม่ี รี หัสคอนเทนเนอรขึ้นตน ดว ย 1b) # docker update --restart always 1 (ในกรณที ไี่ มม ีคอนเทนเนอรอื่นท่ีมีรหสั คอนเทนเนอรขน้ึ ตน ดว ย 1) # docker update --restart always frosty_tereshkova 204

(ไมสามารถพมิ พช่อื เพยี งบางสวนได) นอกจารคำสั่ง docker update แลว เวลาพิมพคำสั่งอื่นที่อางอิงคอนเทนเนอร ผูอานสามารถใช หลกั การพิมพรหสั คอนเทนเนอรบ างสว นเพือ่ ความสะดวกรวดเรว็ ย่ิงขึ้นได 11.4 การหยดุ และบงั คบั หยุดการทำงานของคอนเทนเนอร วิธีการหยุดการทำงานของคอนเทนเนอรนั้นขึ้นอยูกับโหมดการทำงานของคอนเทนเนอรวาทำงานใน โหมดการทำงานใด ในกรณีที่ทำงานดวยโหมดปฏิสัมพันธ หนาผูอานปดหนาจอการเขาถึงระยะไกล เชน โปรแกรม Putty หรือกด CTRL + C ก็จะหยดุ การทำงานของคอนเทนเนอรนั้นทันที ในกรณีทที่ ำงานดว ยโหมด พ้นื หลงั หรือผูอานเปดการเขาถึงระยะไกลหรือคอนโซลอีกหนาตางหนึ่ง ผูอา นสามารถใชคำส่ังตอไปนี้หยุดการ ทำงานของคอนเทนเนอรได # docker stop frosty_tereshkova ผูอานสามารถใชค ำส่ังตอไปนีเ้ พ่ือบงั คบั หยุดการทำงานของคอนเทนเนอรไ ด # docker kill frosty_tereshkova ในกรณีท่คี อนเทนเนอรหยุดการทำงานไปแตยังไมถูกลบ ผอู านสามารถตรวจสอบสถานะการทำงานของ คอนเทนเนอรท่ีหยุดการทำงานไปดวยคำสง่ั # docker ps -a หากตองการเริ่มการทำงานใหม ผูอานสามารถใชคำสั่งตอไปนี้เพื่อเริ่มการทำงานของคอนเทนเนอรอีก คร้งั ได # docker start frosty_tereshkova การสัง่ หยดุ การทำงานตา งจากการสั่งบังคับหยดุ ตรงท่ี เมื่อผอู านส่งั หยุดการทำงาน ด็อกเกอรโฮสตจะสง สัญญาณ Signal Hang up (SIGHUP) ไปยังคอนเทนเนอร สัญญาณ SIGHUP เปนคำสั่งหยุดที่สามารถรอได ในซอฟตแ วรสวนใหญจ ะเขยี นโคดรองรบั ใหบ ันทึกการทำงานครัง้ สดุ ทายกอ นหยุดการทำงาน สว นการสง่ั บังคับ หยดุ การทำงาน ด็อกเกอรโ ฮสตจะสง สญั ญาณ Signal Termination (SIGTERM) ไปยงั คอนเทนเนอร คอนเทน เนอรจะรีบออกจากการทำงานใหเร็วที่สุดทันทีซึ่งอาจสงผลตอขอมูลที่กำลังประมวลผลอยู โดยมากมักใชใน กรณีที่โพรเซสในคอนเทนเนอรแฮงค อยางไรก็ตาม แมซอฟตแวรสวนใหญจะเขียนโปรแกรมมาจัดการกับ SIGHUP แตยังมีโอกาสที่ขอมูลสูญหายได ดังนั้น วิธีการออกคอนเทนเนอรที่ดีที่สุดคือ การสงคำสั่งหยุดการ ทำงานของซอฟตแ วรใ นคอนเทนเนอรน ้นั ซึ่งคำส่ังดงั กลาวขึ้นอยกู บั ผพู ฒั นาและสรางอิมเมจกำหนดขน้ึ มา 205

11.5 การหยุดการทำงานของคอนเทนเนอรชว่ั คราว การหยุดการทำงานของคอนเทนเนอรชั่วคราวจะเปนการหยุดการทำงานของโพรเซสในคอนเทนเนอร ทำใหโ พสเซสในคอนเทนเนอรไมใ ชทรัพยากรจากหนวยประมวลผลกลาง แตค อนเทนเนอรยงั คงอยใู นสถานะที่ ทำงานและยังจองพื้นที่หนวยความจำหลักอยู การหยุดการทำงานของคอนเทนเนอรชั่วคราวมักใชในกรณีที่ ตองการใหคอนเทนเนอรอื่นใชทรัพยากรประมวลผลงานกอน แตก็ไมตองการปดการทำงานของคอนเทนเนอร ไป ผอู า นสามารถใชคำสัง่ นีเ้ พ่ือหยดุ การทำงานของคอนเทนเนอรช ่วั คราวได # docker pause frosty_tereshkova เมื่อพรอมใหคอนเทนเนอรที่หยุดการทำงานชวยคราวสามารถทำงานไดตอ ผูอานสามารถใชคำสั่ง ตอ ไปนีเ้ พ่อื ดำเนนิ การทำงานของคอนเทนเนอรตอ ได # docker unpause frosty_tereshkova 11.6 การลบคอนเทนเนอรแ ละอมิ เมจ เมื่อสรางและสั่งใหคอนเทนเนอรทำงานแลว โปรแกรมด็อกเกอรจะสรางชั้นขอมูลสำหรับคอนเทนเนอร ข้ึนมาอีกช้นั ในช้นั ขอ มูลนน้ั บางสว นอาจเชื่อมตอไปยังไดเรกทอรีของด็อกเกอรโ ฮสตทำใหคอนเทนเนอรนั้นใช พน้ื ท่เี ก็บขอมลู บนดิสก เมือ่ หยดุ การทำงานแลว โปรแกรมด็อกเกอรจ ะไมลบคอนเทนเนอรน นั้ ออก เพราะคอน เทนเนอรเมื่อหยุดการทำงานไปแลว ยังสามารถเปดการทำงานใหมอีกครั้งได ดังนั้น ผูใชจึงควรลบคอนเทน เนอรทีไ่ มไดใชงานออกอยูเ สมอ ผูอ านสามารถใชค ำส่ังตอไปนเ้ี พื่อลบของคอนเทนเนอรตอได # docker rm frosty_tereshkova ในกรณีที่มีคอนเทนเนอรจำนวนมากทีต่ องการลบ ผูอานสามารถลบคอนเทนเนอรท่ีไมไดทำงาน โดยใช คำส่ัง # docker container prune -f พารามิเตอร -f ของคำส่ังมไี วเ พ่อื ลบคอนเทนเนอรท ันทีทุกคอนเทนเนอร สำหรับอิมเมจ เมื่อดาวนโหลดหรือถูกสรางขึ้นมา แมโปรแกรมด็อกเกอรจะดาวนโหลดหรือเก็บขอมูล เฉพาะชั้นขอมูลท่ีไมซ้ำกัน แตเมื่อเวลาผานไป ผูอานอาจมีอิมเมจที่ไมไดใชงานหรือจะไมไดใชสราง คอนเทนเนอรอีก ซึ่งอิมเมจเหลานี้ใชพื้นที่เก็บขอมูลบนดิสก การลบอิมเมจออกจำเปนตองใชรหัสของอิมเมจ เทา นัน้ เชน หากอมิ เมจ httpd มรี หัสอมิ เมจดังภาพท่ี 11.5 เปน b2c2ab6dcf2e สามารถใชค ำสง่ั # docker image rm b2c2ab6dcf2e ในกรณที ี่ตองการลบอิมเมจทไ่ี มไดใ ชง านทั้งหมด ผูอา นสามารถใชคำสงั่ # docker image prune 206

แตอิมเมจที่จะลบไดนั้นจะตองไมถูกอางอิงจากคอนเทนเนอรใด ๆ เลยแมคอนเทนเนอรนั้นจะหยุดการ ทำงานไปก็ตาม หากตองการลบอิมเมจที่ไมถูกอางอิงจากคอนเทนเนอรที่กำลังทำงานอยูเทานั้น สามารถเพ่ิม พารามเิ ตอร -a ไดเปนคำสงั่ # docker image prune -a อยางไรก็ตาม แมคำสั่งลบคอนเทนเนอรและลบอิมเมจจะมีคำสั่งที่สามารถลบขอมูลทั้งหมดไดโดยไม สอบถามการยนื ยนั จากผูใชงาน แตการกระทำดงั กลาวไมถือวาเปนการกระทำที่อันตราย เพราะสำหรับอิมเมจ แลว สามารถดาวนโหลดไดใหมจากรีจีสตรี และสำหรับคอนเทนเนอร หากเช่อื มตอไดเรกทอรีท่ีเก็บขอมูลไวกับ ไดเรกทอรีบนด็อกเกอรโฮสต การลบคอนเทนเนอรจะไมสงผลตอไดเรกทอรีที่เก็บขอมูลบนด็อกเกอรโฮสตแต อยา งใด 207

บทสรุป อิมเมจมาตรฐาน คือ อิมเมจของซอฟตแวรที่ผูพัฒนาซอฟตแวรเปนผูจัดทำขึ้นมาและดูแลรักษาดวย ตัวเอง ขอดีของอิมเมจมาตรฐานคืออิมเมจท่ีใหใชงานจะเปนอิมเมจที่ทันสมัย เพราะเมื่อผูพัฒนาซอฟตแวร ปลอยซอฟตแวรในรูปแบบปกติหรือแฟมขอมูลไบนารีแลว ผูพัฒนาซอฟตแวรจะสามารถปลอยซอฟตแวรใน รูปแบบอิมเมจไปพรอมกนั ดวย อิมเมจของด็อกเกอรมกี ารจัดการขอ มูลเปนชั้นและเก็บคา แฮชดว ยอัลกอริทมึ SHA-256 เพื่อตรวจสอบ ไมใหชั้นขอมูลของอิมเมจถูกอัพโหลดซ้ำหรือดาวนโหลดซ้ำ เพื่อลดปญหาการจราจรทางเครือขาย (Network Traffic) คุณลักษณะเดนของอิมเมจ คือ ไมสามารถแกไขได ดังนั้น ในการใชงาน ด็อกเกอรจึงสราง คอนเทนเนอรจ ากอิมเมจ และบันทกึ การเปลีย่ นแปลงไวในคอนเทนเนอรแ ทน ในขั้นตอนการสรางคอนเทนเนอรนน้ั มีหลายพารามิเตอรท่ีไมสามารถเปลี่ยนแปลงไดหลังจากการสราง ดังนั้น ในการสรางผูอานควรระบุพารามิเตอรที่จำเปนใหครบถวน เหตุผลหลักที่พารามิเตอรไมสามารถ เปลี่ยนแปลงไดภายหลังเพราะผูอานสามารถสรางคอนเทนเนอรจากอิมเมจไดใหมตลอดเวลา คอนเทนเนอร เปรียบเสมอื นศูนยรวมการต้ังคา ความเช่ือมโยงวา จะใหเครอื ขา ยไหน เกบ็ ขอ มูลไวท ีไ่ หน หรอื เชอื่ มตอกับพอรต อะไร ดังนั้น กระบวนการสวนใหญของการลบและสรางคอนเทนเนอรใหมจากอิมเมจเดิมไมเกิดการสูญเสีย ขอมูล 208

สรปุ คำส่งั ทน่ี าสนใจ คำส่ังหรือชื่อคำสงั่ ท่เี ก่ียวของ เนือ้ หา https://hub.docker.com # docker pull รจี ีสตรีสาธารณะของด็อกเกอร # docker image ls คำส่งั ดาวนโ หลดอมิ เมจ # docker run -d -v ตรวจสอบรายการอิมเมจท่ีถกู ดาวนโหลดมาไวใ น /root/website:/usr/local/apache2/htdocs -p เคร่ือง 80:80 httpd ตัวอยางคำสั่งสรางคอนเทนเนอรจ ากอิมเมจ # docker ps ตรวจสอบการทำงานของคอนเทนเนอร 1. รหสั ของคอนเทนเนอรโ ดยพิมพเ ฉพาะบางสวนท่ี หลักการอา งองิ ช่ือคอนเทนเนอร ไมซ้ำกบั รหสั คอนเทนเนอรอื่น กำหนดใหคอนเทนเนอรอยูในสถานะเร่มิ การทำงาน 2. ชือ่ คอนเทนเนอรเ ต็ม พรอ มกบั บรกิ ารของด็อกเกอร # docker update --restart always หยุดการทำงานของคอนเทนเนอร frosty_tereshkova บังคับหยดุ การทำงานของคอนเทนเนอร # docker stop frosty_tereshkova เร่ิมการทำงานของคอนเทนเนอร # docker kill frosty_tereshkova หยดุ การทำงานของคอนเทนเนอรชั่วคราว # docker start frosty_tereshkova ดำเนินการทำงานของคอนเทนเนอรต อ # docker pause frosty_tereshkova ลบของคอนเทนเนอร # docker unpause frosty_tereshkova ลบคอนเทนเนอรท ่ีไมไดท ำงาน # docker rm frosty_tereshkova ลบอิมเมจ # docker container prune -f ลบอิมเมจที่ไมไดใ ชงานท้ังหมด # docker image rm รหสั อมิ เมจ ลบอิมเมจที่ไมถกู อา งอิงจากคอนเทนเนอรท ่ีกำลงั # docker image prune ทำงานอยูเทา นน้ั # docker image prune -a 209

แบบฝก หัดบทที่ 11 1. บอกท่ีอยูของรจี ีสตรมี าตรฐานท่ีสามารถคน หาอิมเมจมาตรฐานได 2. บอกพารามเิ ตอร และความหมายของพารามิเตอรสำหรับใชส รา งคอนเทนเนอรมาอยา งนอ ย 5 พารามิเตอร 3. คำสง่ั docker stop แตกตางจากคำสั่ง docker kill อยา งไร 4. บอกหลักการการอางองิ ชอ่ื และรหัสคอนเทนเนอรเ พ่ือใชใ นคำสงั่ เครื่องมือดอ็ กเกอรล ูกขาย 5. บอกคำสงั่ ท่ีใชล บอิมเมจทั้งหมดท่ไี มถ ูกใชใ นเคร่ืองด็อกเกอรโ ฮสต 210

การบริหารจัดการอิมเมจและคอนเทนเนอร บทนำ เนื่องจากการทำงานของคอนเทนเนอรใชหลังการอางอิงและสรางจากอิมเมจ และคอนเทนเนอรเปน แหลงรวมการตั้งคาและเก็บบันทึกเฉพาะการเปลี่ยนแปลงจากอิมเมจ ดังนั้น การบริหารจัดการอิมเมจที่ดีจะ ชวยใหผูอานสามารถบริหารจัดการเวอรชันของซอฟตแวรไดอยางสะดวกสบาย นอกจากนี้ ด็อกเกอรยัง สนับสนุนการควบคุมการทำงานและตรวจสอบการทำงานของคอนเทนเนอรใหเปนไปตามที่ผูอานตองการได อยางถูกตองและมีประสทิ ธิภาพ 12.1 การจดั การอมิ เมจหลายเวอรชนั ลักษณะหนึ่งที่สำคัญของอิมเมจคือ อิมเมจหนึ่งอิมเมจประกอบดวยแท็ก (Tag) ตั้งแต 1 แท็กเปนตนไป หากเวลาสรางหรือเรียกใชงานอิมเมจไมระบุชื่อแท็ก ชื่อแท็กเริ่มตนจะเปน latest เสมอ โดยหากอิมเมจมีช่ือ แทก็ ทแ่ี ตกตา งกันจะมีขอมลู ที่บันทึกอยูในชั้นขอมลู แตกตา งกันออกไป การต้งั ชื่อแท็กมปี ระโยชนสำหรับผูดูแล รักษาอิมเมจโดยเฉพาะกรณีที่ซอฟตแวรที่เผยแพรนั้นมีหลายเวอรชัน หรือหลายระบบปฏิบัติการ อิมเมจหนึ่ง อิมเมจอาจมีแท็กหลายแท็กที่ชี้ไปยังอิมเมจที่มีชั้นขอมูลเดียวกัน เชน อิมเมจของ httpd มีแท็ก 2.4.43 แท็ก 2.4 แท็ก 2 และแทก็ latest หมายถงึ อิมเมจท่มี ีช้นั ขอมลู เดยี วกนั แตมวี ิธีการใชงานตางบริบทกัน เชน ในกรณี ที่ผูใชงานตองการเรยี กเฉพาะเวอรชัน 2.4.43 สามารถอางอิงแท็ก 2.4.43 ได แตเม่ือผูพัฒนาปลอยซอฟตแวร เวอรชัน 2.5.1 ผูใ ชง านท่อี างองิ แท็ก 2.4.43 จะไมม กี ารอัพเดทอิมเมจ แตผ ูทอี่ า งอิงแท็ก 2.5 แท็ก 2 และแท็ก latest จะไดรับการอัพเดทซอฟตแวร ดังนั้น ประโยชนของแท็กจะทำใหผูอานสามารถควบคุมขอบเขตของ เวอรช นั ที่ตองการเรียกใชได เมื่อทราบขอบเขตของเวอรชันซอฟตแวรที่ตอ งการเรียกใชงาน ผูอานสามารถดาวนโหลดอิมเมจ httpd ทเี่ ปนเวอรช ัน 2 ท่ลี า สุดเสมอ มาเกบ็ ไวใ นเครอ่ื งได โดยใชคำส่ัง # docker pull httpd:2 แตห ากตองการเวอรช นั ลาสุดเสมอ สามารถใชคำสง่ั # docker pull httpd เมอ่ื แสดงรายการของอิมเมจจะมีคอลัมนระบุช่ือแท็กของอิมเมจ โดยอิมเมจชอ่ื เดียวกันแตมีแท็กตางกัน จะแสดงคนละรายการ ตัวอยางการบริหารจดั การเวอรช ันของอิมเมจฐานขอมูลท่ีเทคโนโลยบี รรจุคอนเทนเนอรชวยใหสามารถ อัพเดทระบบฐานขอมูลไดสะดวกและปลอดภัย คือ ระบบฐานขอมูล Postgresql ที่เชื่อมตอเครือขายผาน โพรโตคอล TCP พอรต 5432 และเก็บขอมูลไวท่ี /root/database เมื่อเริ่มสรางคอนเทนเนอรจากอิมเมจ postgresql:12 ในวันนี้ Postgresql 12 อาจเปนเวอรชัน 12.0 ถัดมาอีก 3 เดือน Postgresql 12.1 ไดถูก ปลอยออกมา แตเนื่องจากเวอรชันหลักยังคงเปน 12 อยู ตัวอิมเมจของด็อกเกอรของผูพัฒนาก็ยังคงเปน postgresql:12 เหมือนเดิม แตเมื่อผูอานลบและสรางคอนเทนเนอรใหม ผูอานจะได Postgresql เวอรชัน 211

12.1 โดยที่ยังคงมีระบบฐานขอมูล และเครือขายที่เชื่อมตอที่โพรโตคอลเดิมพอรดเดิม นับไดวาเปนวิธีการ อัพเดทซอฟตแวรใหมที่มีการบริหารจัดการที่งายมากเพียงเปลี่ยนอิมเมจของซอฟตแวรเวอรชันใหม ใน ขณะเดียวกันวิธีการน้ีมีความเสย่ี งนอยมาก เพราะถาหาก Postgresql 12.1 ยงั ไมเสถียร ผอู านก็สามารถสราง คอนเทนเนอรแตคราวนี้ระบุเวอรชันกอนหนาดวยการระบุในแท็กวา postgresql:12.0 แทน เพียงเทาน้ัน ผูอา นก็สามารถยอ นกลับไปซอฟตแ วรเวอรชนั เดมิ ไดทันที 12.2 การตรวจสอบการทำงานของคอนเทนเนอร เมื่อคอนเทนเนอรถูกสรางคอนเทนเนอรจ ะมีสถานะเปดการทำงาน (Active) อยางไรก็ตาม หากการต้ัง คา จากคำสัง่ docker run ผดิ พลาดไมส อดคลองกับทีผ่ ูพัฒนาอมิ เมจกำหนด คอนเทนเนอรอ าจออกการทำงาน (Exited) ได ในกรณีที่คำสั่งสรางคอนเทนเนอรระบุใหรีสตารท คอนเทนเนอร (พารามิเตอร --restart always) ด็อกเกอรโฮสตจะหยดุ รอเปน ระยะเวลาแบบสุมเพื่อทดลองเปดการทำงานคอนเทนเนอรใ หม (Restarting) อีก ครง้ั โดยระยะเวลาสุมน้จี ะคอย ๆ หา งขึ้นเร่อื ย ๆ อยา งไรกต็ าม ผอู า นสามารถตรวจสอบสถานะการทำงานของ คอนเทนเนอรวายงั ทำงานอยูหรอื ไม ดว ยคำส่ัง # docker ps -a พารามิเตอร -a จะแสดงรายการของคอนเทนเนอรทั้งหมดที่เคยถูกสราง แตยังไมถูกลบออกจากเครื่อง ทำใหผูอานสามารถตรวจสอบสถานะของคอนเทนเนอร แตหากตองการตรวจสอบวาภายในคอนโซลของคอน เทนเนอรน น้ั มีการแสดงผลวาอยา งไร เพือ่ ตรวจสอบการทำงานโดยละเอยี ด และหากคอนเทนเนอรท ำงานไดไม ถูกตองหนาจอคอนซอลอาจแสดงขอผิดพลาดวาทำไมคอนเทนเนอรทำงานผิดพลาด เพื่อความสะดวกแกผูใช การอา งอิงช่ือของคอนเทนเนอรใ นด็อกเกอรจะตองใชข อมูลเพียงอยางใดอยางหนงึ่ คอื รหัสของคอนเทนเนอร หรอื ช่ือของคอนเทนเนอร จากตัวอยางคอนเทนเนอรช ่ือ frosty_tereshkova ผอู า นสามารถใชค ำสัง่ ดังน้ี # docker logs frosty_tereshkova ในกรณีที่คอนเทนเนอรยังคงทำงานอยู และคอนโซลอาจแสดงผลขอความที่ตองการตรวจสอบเพิ่มเติม ผูอ านสามารถเพ่ิมพารามิเตอร -f เพ่อื ใหคำสงั่ ยงั ไมก ลับมาสูเ ชลลแตยังรอผลลพั ธข องคอนโชล เชน # docker logs -f frosty_tereshkova หรือหากคอนเทนเนอรถูกตองการตรวจสอบทำงานไดถูกเปดการทำงานมานาน ผูอานสามารถ ตรวจสอบผลลัพธข องคอนโซลตามชว งระยะเวลาไดด วย 2 พารามเิ ตอร คือ 1) พารามิเตอร --since ใชระบุชวงเวลาที่ตองการแสดงรายการหลังจากเวลานี้ โดยอาจระบุวา 40m หมายถึง รายการที่แสดงตองเกิดขึ้นภายใน 40 นาที หรือ 1h หมายถึง รายการที่แสดงตองเกิดขึ้น ภายใน 1 ชั่วโมงกอนหนา หรือระบุวันที่ในรูปแบบ YYYY-MM-DDTHH:mm:ss เชน 2020-02- 02T15:00:00 หมายถึงรายการท่ีแสดงตองเกิดข้ึนหลังวันท่ี 2 กมุ ภาพนั ธ พ.ศ. 2563 เวลา 15.00น. 212

2) พารามิเตอร --until ใชระบุชวงเวลาที่ตองการแสดงรายการกอนเวลานี้ มีรูปแบบการระบุเวลา เหมือนพารามิเตอร --since แตใชในความหมายตรงขาม เชน 40m หมายถึง รายการที่แสดงตอง เกิดขึ้นนานกวา 40 นาที หากตองการแสดงขอมูลถึงปจจุบันใหระบุ 0m หมายถึง รายการที่แสดง ตองเกิดขึ้นตองนานกวา 0 นาที หรือระบุวันที่ในรูปแบบ YYYY-MM-DDTHH:mm:ss เชน 2020- 02-02T15:00:00 หมายถึงรายการที่แสดงตองเกิดขึ้นกอนวันท่ี 2 กุมภาพันธ พ.ศ. 2563 เวลา 15.00น. พารามิเตอร --since และพารามเิ ตอร --until เปนเพยี งพารามิเตอรเสรมิ สามารถไมร ะบุ ระบุเพยี งหนึ่ง พารามิเตอร หรอื ระบุท้งั สองพารามิเตอรรวมกัน เชน # docker logs --since 1h frosty_tereshkova เมื่อพิมพคำสั่ง ด็อกเกอรโฮสตจะแสดงขอความที่แสดงในคอนโซลของคอนเทนเนอร frosty_ tereshkova ภายใน 1 ชวั่ โมง 12.3 การเขาถึงและการออกคอนโซลของคอนเทนเนอร หลังจากท่ตี รวจสอบการทำงานของคอนเทนเนอร ในบางคร้ัง ผูอานอาจตองการเขาไปในคอนเทนเนอร เพอื่ พิมพคำสง่ั หรือแกไขการตั้งคาบางประการ ด็อกเกอรโ ฮสตมวี ิธีการท่ีทำใหส ามารถเขาถงึ คอนโซลของคอน เทนเนอรได 2 วธิ ี คอื 1) เขาถึงคอนโซลของคอนเทนเนอรโดยตรง วิธีการนี้นิยมใชกับคอนเทนเนอรที่ทำงานอยูเบื้องหลัง และมีเชลลใ หผ ูอ านเขาถงึ ได หรือเมอื่ ตอนสรา งคอนเทนเนอรไดมีการระบเุ ชลลลงไป เชน การสั่งให คอนเทนเนอรข องระบบปฏิบัติการ CentOS 7 เวอรช นั กอนหนา ทำงาน โดยใชค ำส่ัง # docker run -dit centos:7 bash เมื่อพิมพคำสั่ง ด็อกเกอรโฮสตจะสรางคอนเทนเนอรของระบบปฏิบัติการ CentOS เวอรชัน 7 ที่มี เชลล bash ใหผ ูอานพมิ พคำส่ังได ในกรณนี ้ี หากคอนเทนเนอรม ีชื่อวา frosty_tereshkova ผูอาน สามารถเขา ถงึ คอนโซลของคอนเทนเนอรน ไี้ ดดว ยคำสั่ง # docker attach frosty_tereshkova เมอื่ พิมพคำสง่ั จะปรากฏเชลลใหผอู า นสามารถเขาถึงภายในคอนเทนเนอรได วธิ ีการออกคอนโซลของคอนเทนเนอรจากวิธกี ารน้จี ะตองออกดว ยการกดปมุ คยี ลดั CTRL + P + Q เทาน้นั หากกด CTRL + C จะเปนการสง สญั ญา SIGHUP ไปใหค อนเทนเนอรน้ปี ดตวั ลง 2) เขาถึงคอนโซลของคอนเทนเนอรดวยการสรางเชลลใหม วิธีการนี้นยิ มใชกับคอนเทนเนอรที่มีคำส่ัง เร่ิมตนการทำงานเฉพาะ และไมไดสรางเชลลไวใหผูอานเขาถึงได เมื่อพิมพคำสั่ง docker attach กลับขน้ึ ผลลพั ธของการทำงานของซอฟตแวรภ ายใน ไมม ีเชลลใหผอู านสามารถพิมพคำสงั่ ได วิธีการ นี้ผูอานจะสัง่ ใหเ ชลลทำงานเพิม่ อีกโพรเซสหนึ่งในคอนเทนเนอรนั้น ในกรณีนี้ หากคอนเทนเนอรมี 213

ชื่อวา frosty_tereshkova ผูอานสามารถสรางเชลลเพื่อเขาถึงคอนโซลของคอนเทนเนอรนี้ไดดว ย คำสั่ง # docker exec -it frosty_tereshkova bash เมื่อพิมพคำสั่ง ด็อกเกอรโฮสตจะสรางโพรเซสของ Bash shell และผูอานใหเขาถึงเชลลนั้น Bash shell เปนเชลลที่สนับสนุนคำสั่งในการโปรแกรมสมบูรณที่สุด แตไมใชทุกอิมเมจจะมี Bash shell ในกรณที ผี่ ูพฒั นาอมิ เมจไมไ ดติดตงั้ Bash shell มาดว ย ผอู านสามารถใชอกี ทางเลือกหน่ึง คอื # docker exec -it frosty_tereshkova sh เม่อื พมิ พคำสัง่ ดอ็ กเกอรโ ฮสตจ ะสรางโพรเซสของ Bourne shell แทน วิธีการออกคอนโซลของคอนเทนเนอรจากวิธีการนี้จะตองออกดวยการพิมพ exit หรือกด CTRL + C เพื่อปดการทำงานของโพรเซสเชลลท่ีผูอา นสรางขึน้ มาใหม มิเชนน้ัน คอนเทนเนอรจะมี โพรเซสเชลลทส่ี รางขึ้นใหมทำงานคา งไวอ ยเู พมิ่ ทุกครั้งทผ่ี อู านเขา ถึงคอนโซลดว ยวิธีการน้ี การเขาถึงคอนโซลจะมีประโยชนมากในกรณีที่ผูอานตองการตรวจสอบแฟมการตั้งคา หรือคัดลอก แฟมขอมูลจากคอนเทนเนอรออกมาทั้งนี้ หากแฟมขอมูลนั้นไมไดเชื่อมตอกับไดเรกทอรีของด็อกเกอรโฮสต การเขาถึงแฟมขอมูลจากภายนอกคอนเทนเนอรจึงเปนเรื่องยาก ดังนั้น วิธีการที่สะดวกที่สุดคือการคัดลอก แฟมขอมูลนั้นไปยังไดเรกทอรีที่เชื่อมตอกับด็อกเกอรโฮสต อนึ่งการเขาถึงคอนเทนเนอรจะสามารถทำไดก็ ตอ เมอ่ื คอนเทนเนอรอ ยใู นสถานะเปดการทำงานเทานนั้ 12.4 การตรวจสอบประวัติการทำงานของคอนเทนเนอร เมื่ออิมเมจถูกใชในการสรางคอนเทนเนอร ในบางกรณีคอนเทนเนอรอาจทำงานผิดปกติ เชน ออกการ ทำงานเอง หรือรีสตารทคอนเทนเนอรเอง หรืออิมเมจที่ใชมีการอัพเดทแท็กใหม การตรวจสอบรายการของ คอนเทนเนอรและอิมเมจดวยคำสั่ง docker image ls และ docker ps จะแสดงเฉพาะสถานะสุดทายของ อิมเมจหรือคอนเทนเนอรนัน้ อยางไรก็ตาม โปรแกรมด็อกเกอรลูกขายมคี ำสั่งที่สามารถตรวจสอบเหตุการณที่ เกิดขึ้น พรอมทั้งแสดงวันที่ และเวลาที่เกิดเหตุการณนั้น ในกรณีนี้ หากผูอานสรางคอนเทนเนอรมีชื่อวา frosty_tereshkova จากอิมเมจ httpd ผูอ า นสามารถตรวจสอบเหตุการณด ว ยคำสง่ั docker events แตห าก พิมพคำสั่งนี้โดยที่ไมมีพารามิเตอรใด ๆ จะไมปรากฏผลลัพธใด ๆ แตจะเปนการรอการแสดงผล และจะแสดง รายการของเหตุการณก็ตอเมื่อเกิดเหตุการณขึ้นหลังจากที่พิมพคำสั่งเทานั้น ซึ่งโดยปกติผูอานนิยมตรวจสอบ เหตุการณยอ นหลังมากกวาตรวจสอบเหตุการณทกี่ ำลังจะเกิด ดงั นน้ั คำสง่ั นี้ ตองมกี ารระบพุ ารามเิ ตอร ดงั นี้ 1) พารามิเตอร --filter ใชร ะบุเงอื่ นไขการแสดงผล โดยทว่ั ไปนยิ มระบุเงอื่ นไขตามอิมเมจหรือคอนเทน เนอร หากตองการระบุเงื่อนไขการแสดงผลตามอิมเมจ โครงสรางของพารามิเตอรนี้จะเปน --filter image=<ชื่ออิมเมจ> เชน --filter image=httpd แตหากตองการระบุเงื่อนไขการแสดงผลตาม คอนเทนเนอร โครงสรางของพารามิเตอรนี้จะเปน --filter container=<รหัสคอนเทนเนอร> หรือ 214

--filter container=<ชื่อคอนเทนเนอร> ในกรณีที่เปนรหัสคอนเทนเนอรผูอานสามารถพิมพแค บางสวนที่ไมซ้ำกับรหัสคอนเทนเนอรของคอนเทนเนอรอื่นได เชน หากคอนเทนเนอรมีรหัสคอน เทนเนอรเปน 1bba17d1cb3c และมีชื่อวา frosty_tereshkova ตัวอยางการใชพารามิเตอรนี้จะ เปน --filter container=1 หรือ --filter container=1b หรอื --filter container=1bba17d1cb3c หรือ --filter container=frosty_tereshkova อยา งใดอยางหน่งึ 2) พารามิเตอร --since ใชระบุชวงเวลาที่ตองการแสดงรายการหลังจากเวลานี้ โดยอาจระบุวา 40m หมายถึง รายการที่แสดงตองเกิดขึ้นภายใน 40 นาที หรือ 1h หมายถึง รายการที่แสดงตองเกิดขึ้น ภายใน 1 ชั่วโมงกอนหนา หรือระบุวันที่ในรูปแบบ YYYY-MM-DDTHH:mm:ss เชน 2020-02- 02T15:00:00 หมายถงึ รายการท่แี สดงตอ งเกิดขึ้นหลังวันที่ 2 กุมภาพันธ พ.ศ. 2563 เวลา 15.00น. 3) พารามิเตอร --until ใชระบุชวงเวลาที่ตองการแสดงรายการกอนเวลานี้ มีรูปแบบการระบุเวลา เหมือนพารามิเตอร --since แตใชในความหมายตรงขาม เชน 40m หมายถึง รายการที่แสดงตอง เกิดขึ้นนานกวา 40 นาที หากตองการแสดงขอมูลถึงปจจุบันใหระบุ 0m หมายถึง รายการที่แสดง ตองเกิดขึ้นตองนานกวา 0 นาที หรือระบุวันที่ในรูปแบบ YYYY-MM-DDTHH:mm:ss เชน 2020- 02-02T15:00:00 หมายถึงรายการที่แสดงตองเกิดขึ้นกอนวันที่ 2 กุมภาพันธ พ.ศ. 2563 เวลา 15.00น. พารามเิ ตอร --since และพารามเิ ตอร --until เปนเพยี งพารามเิ ตอรเสริม สามารถไมระบุ ระบเุ พยี งหน่ึง พารามิเตอร หรือระบุทั้งสองพารามิเตอรรวมกัน แตพารามิเตอร --filter เปนพารามิเตอรที่จำเปนตองระบุ ยกตัวอยางเชน หากตองการตรวจสอบเหตุการณของคอนเทนเนอรรหัส 1bba17d1cb3c ภายในชวง ระยะเวลา 1 ชัว่ โมง สามารถใชค ำสงั่ # docker events --filter container=1bba17d1cb3c –since=1h --until=0 หากตอ งการตรวจสอบเหตุการณของอิมเมจชือ่ httpd ทีเ่ กิดขึน้ นานกวา 4 ชั่วโมง สามารถใชค ำสั่ง # docker events --filter image=httpd --until=4h ภาพที่ 12.1 แสดงบางสวนของรายการการตรวจสอบเหตุการณของอิมเมจ httpd ที่เกิดขึ้นนานกวา 4 ชว่ั โมง ภาพที่ 12.1 หนา จอผลลัพธคำสั่งแสดงรายการการตวรจสอบเหตกุ ารณข องอิมเมจ 215

12.5 การตรวจสอบทรพั ยากรทคี่ อนเทนเนอรใช เนื่องจากคอนเทนเนอรเปนเสมือนหนึ่งเครื่องคอมพิวเตอรเสมือนอีกเครื่อง แตตางกันที่ไมมี ไฮเปอรไวเซอรจำลองฮารดแวร มขี อ ดคี อื การใชทรพั ยากรของโพรเซสในคอนเทนเนอรจ ะมปี ริมาณท่เี ทียบเทา การสั่งใหโพรเซสทำงานนอกคอนเทนเนอรจึงทำใหผูอานสามารถใชคำสั่งทั่วไปสำหรับตรวจสอบทรัพยากรที่ โพรเซสในคอนเทนเนอรใชไดโดยตรง อยางไรก็ตาม โปรแกรมด็อกเกอรมีเครื่องมือที่สามารถสอบถามการใช ทรัพยากรองครวมของทั้งคอนเทนเนอรนั้นไปยงั ด็อกเกอรโฮสต โดยทรัพยากรหลักที่สามารถตรวจสอบได คือ การใชงานหนวยประมวลผลกลาง (CPU time) หนวยความจำหลักที่ใช (RAM used) และพื้นที่เก็บขอมูลท่ี คอนเทนเนอรใชย กเวน ไดเรกทอรีที่เช่อื มตอกับไดเรกทอรีของด็อกเกอรโ ฮสต การใชงานหนวยประมวลผลกลาง โดยปกติในระบบปฏิบัติการลีนุกซผูอานสามารถใชคำสั่ง ps เพ่ือ ตรวจสอบการใชงานหนวยประมวลผลกลางตามโพรเซสที่ทำงานอยู สำหรับการตรวจสอบเฉพาะในคอนเทน เนอร สามารถใชพารามเิ ตอรเปนรหัสคอนเทนเนอรหรือชื่อคอนเทนเนอรอยา งใดอยางหน่ึง ในกรณีที่เปนรหัส คอนเทนเนอรผูอานสามารถพิมพแคบางสวนที่ไมซ้ำกับรหัสคอนเทนเนอรของคอนเทนเนอรอื่นได เชน หาก คอนเทนเนอรม ชี ือ่ วา frosty_tereshkova การตรวจสอบการใชงานหนว ยประมวลผลกลางสามารถใชค ำส่งั # docker top frosty_tereshkova โดยผลลัพธท แ่ี สดงจะมีทั้งหมด 8 คอลัมน แตล ะคอลมั นมคี วามหมายดงั นี้ 1) UID หมายถึงรหสั ผใู ชท ีเ่ ปนเจาของโพรเซสน้นั เชน หากเปน 0 คือบญั ชผี ูใช เปน ตน 2) PID หมายถงึ รหัสของโพสเซส 3) PPID หมายถงึ รหัสของโพสเซสท่สี รางโพรเซสนีม้ าอีกทหี น่งึ 4) C หมายถงึ เปอรเ ซน็ ของหนวยประมวลผลกลางทีใ่ ช ณ ขณะนั้น 5) STIME หมายถึง เวลาที่เริ่มตนโพรเซสนี้ เชน 9:00 หมายถึงเริ่มตนโพรเซสนี้ตอนเกานาิกา คอลมั นนไี้ มไดร ะบุวนั ที่ 6) TTY หมายถึง หมายเลขหนา จอคอนโซลทก่ี ำลงั ใชง านอยู หากทำงานอยเู บ้ืองหลงั จากแสดงเปน ? 7) TIME หมายถึง เวลาของหนวยประมวลผลกลางที่ถูกใชไป เชน หากโพสเซสนี้ใชเปอรเซ็นตของ หนว ยประมวลผลกลาง 50% เปนเวลา 10 นาที คอลมั น TIME จะแสดงผลเปน 50% x 10 นาที = 5 นาที 8) CMD หมายถึง คำสั่งทสี่ รา งโพสเซส ผูอานสามารถเลือกแสดงบางคอลัมนได เชน หากตองการแสดงเฉพาะคอลัมน UID PIDTIME และ CMD โดยเพิ่มพารามเิ ตอร o และระบุคอลัมนท ตี่ อ งการถดั จากพารามิเตอร ดงั น้ี # docker top frosty_tereshkova o uid,pid,time,cmd 216

เม่ือพมิ พค ำสั่งจะปรากฎผลลัพธดงั ภาพท่ี 12.2 วา มโี พรเซส httpd กำลังทำงานอยู ภาพท่ี 12.2 หนาจอผลลัพธคำสงั่ ตรวจสอบการใชง านหนว ยประมวลผลกลาง สำหรบั การตรวจสอบการใชงานทั้งหนว ยประมวลผลกลางและหนว ยความจำท่ีใชงานอยูในปจจบุ ัน โดย ปกติในระบบปฏิบัติการลีนุกซสามารถใชคำสั่ง free เพื่อตรวจสอบหนวยความจำที่ใชและคงเหลือ แตจะเปน การตรวจสอบของท้งั เครือ่ ง ไมใ ชร ายคอนเทนเนอร สำหรับโปรแกรมดอ็ กเกอรสามารถใชค ำส่ัง # docker stats เมื่อพิมพคำสั่งจะปรากฏหนาจอแสดงขอมูลสถานะการใชทรัพยากรและอัพเดททุก 2 วินาที แตหาก ตองการใหแสดงผลขอมลู ณ เวลานนั้ จากนน้ั กลับมาที่เชลลส ามารถใชค ำสัง่ # docker stats --no-stream จะปรากฏผลลัพธดังภาพที่ 12.3 ที่แสดงขอมูลตอไปนี้ รหัสคอนเทนเนอร (Container ID) ชื่อ คอนเทนเนอร (Name) เปอรเซ็นตที่หนวยประมวลผลกลางใช (CPU %) หนวยความจำหลักที่ใชและที่จำกัด (Mem usage / limit) เปอรเซน็ ตข องหนวยความจำหลักที่ใช (Mem %) ปริมาณการเขียนและอา นดิสก (Net I/O) จำนวนบล็อกของดิสกท่เี ขียนและอาน (Block I/O) รหสั โพรเซสทค่ี วบคุมคอนเทนเนอรน ี้อยู (PIDs) ภาพที่ 12.3 หนา จอผลลพั ธคำส่งั แสดงขอมูลสถานะการใชท รพั ยากรของคอนเทนเนอร สำหรับการตรวจสอบพื้นที่เก็บขอมูลที่คอนเทนเนอรใชยกเวนไดเรกทอรีที่เชื่อมตอกับไดเรกทอรีของ ด็อกเกอรโฮสตนั้น สามารถตรวจสอบไดจากชั้นขอมูลที่คอนเทนเนอรนั้นใชงานอยู เพราะเมื่อสราง คอนเทนเนอรใหม โปรแกรมด็อกเกอรจะสรางชั้นขอมูลของคอนเทนเนอรที่อางอิงอิมเมจและจะเก็บเฉพาะ ขอ มลู ทีแ่ ตกตางไปจากเดิมเทาน้ัน โดยทว่ั ไปชัน้ ขอมูลทสี่ รางข้ึนจะถกู เกบ็ ไวเ ปนไดเรกทอรีหน่ึงบนเคร่ืองของด็ อกเกอรโฮสตซึ่งไดเรกทอรีถูกตั้งชื่อตามรหัสคอนเทนเนอรเต็ม การตรวจสอบสามารถใชพารามิเตอรเปนรหัส คอนเทนเนอรหรือชื่อคอนเทนเนอรอยางใดอยางหนึ่ง ในกรณีที่เปนรหัสคอนเทนเนอรผูอานสามารถพิมพแค บางสวนที่ไมซ้ำกับรหัสคอนเทนเนอรของคอนเทนเนอรอื่นได เชน หากคอนเทนเนอรมีชื่อวา frosty_tereshkova การตรวจสอบรายละเอียดของคอนเทนเนอรส ามารถใชค ำสง่ั # docker inspect frosty_tereshkova 217

เมื่อพิมพคำสั่ง จะปรากฏขอมูลภายในของคอนเทนเนอร frosty_tereshkova ในรูปแบบ JavaScript Object Notation (JSON) ซึ่งประกอบดวยขอมูลที่ยาวมาก ผูอานสามารถตั้งคารูปแบบการแสดงผลดวย พารามเิ ตอร -f โดยพารามิเตอรน จี้ ะสามารถสอบถามแคบางสวนของขอมูล JSON ไดใ นท่ีนผ่ี อู านตองการเพียง ทีอ่ ยูที่ของชนั้ ขอ มูลที่ถกู สรา งใหม จงึ ใชค ำสงั่ # docker inspect frosty_tereshkova -f '{{.GraphDriver.Data.UpperDir}}' เมื่อพิมพคำส่ังเสร็จ จะไดที่อยูของไดเรกทอรที ี่เก็บขอมูลไวเ พิ่มเติม โดยผูอา นสามารถเขา ถึงไดเรกทอรี น้ันไดโ ดยใชค ำสงั่ cd แตวาหากพิมพใ นคอนโซลท่ีไมส ามารถคัดลอกขอความจะเกิดความลำบากเน่ืองจากที่อยู ไดเรกทอรีคอนขา งยาว ผอู านสามารถแกไขปญหาโดยเกบ็ ทอี่ ยูไดเรกทอรีไวในชอ่ื ตัวแปร จากนน้ั ใชค ำสั่ง cd กับชือ่ ตัวแปร ดงั นี้ # upperlayer=$( docker inspect frosty_tereshkova -f '{{.GraphDriver.Data.UpperDir}}' ) # cd $upperlayer เมื่อเขาถึงไดเรกทอรีดังกลาว ผูอานจะสามารถตรวจทุกแฟมขอมูลและทุกไดเรกทอรีที่เกิดการแกไขใน คอนเทนเนอรและเปนเฉพาะรายการแฟมขอมูลที่ตางจากที่มีอยูในอิมเมจเทานั้น การตรวจสอบนี้มีประโยชน เพราะสามารถใชคนหาแฟมขอมูลที่ตองการได และตรวจสอบไดวาคอนเทนเนอรไดสรางความเปลี่ยนแปลง ขอมูลอะไรบา งหลังการทำงาน โดยผูอา นสามารถตรวจสอบพ้ืนทที่ งั้ หมดทใี่ ชงานไดโ ดยใชคำสัง่ # du -sh $upperlayer เมื่อพิมพคำสั่งเสร็จ จะปรากฏผลลัพธดังภาพที่ 12.4 แสดงวาคอนเทนเนอร frosty_tereshkova ใช พื้นท่ีชั้นขอ มลู ที่ไมรวมไดเรกทอรีท่ีเชื่อมตอกับด็อกเกอรโ ฮสตจ ำนวน 4 กโิ ลไบต ภาพท่ี 12.4 หนา จอผลลพั ธคำสง่ั แสดงพ้ืนท่ีท่ีคอนเทนเนอรใชง าน 218

บทสรุป ลักษณะหนึ่งทสี่ ำคญั ของอิมเมจ คอื อิมเมจหน่งึ อมิ เมจประกอบดวยแท็ก (Tag) ต้ังแต 1 แท็กเปนตนไป หากเวลาสรางหรือเรียกใชงานอิมเมจไมระบุชื่อแท็ก ชื่อแท็กเริ่มตนจะเปน latest เสมอ โดยหากอิมเมจมีชื่อ แทก็ ทแ่ี ตกตางกันจะมีขอมลู ท่ีบันทึกอยูในช้ันขอมลู แตกตางกันออกไป การตัง้ ชือ่ แท็กมีประโยชนสำหรับผูดูแล รักษาอิมเมจโดยเฉพาะกรณีที่ซอฟตแวรที่เผยแพรนั้นมีหลายเวอรชัน หรือหลายระบบปฏิบัติการ และชวยให ผูอ า นสามารถควบคุมขอบเขตของเวอรชันทต่ี องการเรยี กใชได เมื่อคอนเทนเนอรถูกสรางคอนเทนเนอรจะมีสถานะเปดการทำงาน เมื่อคอนเทนเนอรทำงานผิดพลาด คอนเทนเนอรอาจออกการทำงานได ในกรณีที่คำสั่งสรางคอนเทนเนอรระบุใหรีสตารทคอนเทนเนอร (พารามิเตอร --restart always) ด็อกเกอรโฮสตจะหยุดรอเปนระยะเวลาแบบสุมเพื่อทดลองเปดการทำงาน คอนเทนเนอรใ หมอ กี ครงั้ การเขาถึงคอนเทนเนอรสามารถทำไดเมื่อคอนเทนเนอรมีสถานะเปดการทำงานเทานั้น ผูอานสามารถ เลือกใชการเขาถึงคอนโซลหรือสรางเชลลใหม แตถาคอนเทนเนอรออกการทำงาน ผูอานสามารถใชการ ตรวจสอบคอนโซลและประวตั ิการทำงานของคอนเทนเนอรเ พ่ือใชวเิ คราะหความผิดพลาดได เนื่องจากคอนเทนเนอรเปนเสมือนหนึ่งเครื่องคอมพิวเตอรเสมือนอีกเครื่อง แตตางกันที่ไมมีไฮเปอรไว เซอรจำลองฮารด แวร มีขอดี คอื การใชทรพั ยากรของโพรเซสในคอนเทนเนอรจะมปี ริมาณท่เี ทยี บเทาการส่ังให โพรเซสทำงานนอกคอนเทนเนอรจึงทำใหผูอานสามารถใชคำสั่งทัว่ ไปสำหรบั ตรวจสอบทรพั ยากรที่โพรเซสใน คอนเทนเนอรใ ชไ ดโดยตรง 219

สรปุ คำสั่งทน่ี า สนใจ คำสง่ั หรอื ชื่อคำส่ังทเี่ ก่ียวของ เน้ือหา # docker pull httpd:2 # docker pull httpd ดาวนโ หลดอิมเมจ # docker logs frosty_tereshkova ตรวจสอบหนา จอคอนโซลของคอนเทนเนอร # docker logs --since 1h frosty_tereshkova ขอ ความท่แี สดงในคอนโซลของคอนเทนเนอร frosty_ # docker attach frosty_tereshkova tereshkova ภายใน 1 ชวั่ โมง # docker exec -it frosty_tereshkova bash เขาถึงคอนโซลของคอนเทนเนอร # docker exec -it frosty_tereshkova sh สรา งเชลลเ พ่อื เขา ถึงคอนโซลของคอนเทนเนอร # docker events --filter container= ตรวจสอบเหตกุ ารณของคอนเทนเนอร frosty_tereshkova --since=1h --until=0 # docker events --filter image=httpd ตรวจสอบการใชง านหนวยประมวลผลกลาง --until=4h ตรวจสอบการใชง านท้ังหนวยประมวลผลกลางและ # docker top frosty_tereshkova หนวยความจำทใ่ี ชงานอยูในปจจุบนั # docker stats ตรวจสอบรายละเอียดของคอนเทนเนอร # docker inspect frosty_tereshkova ที่อยไู ดเรกทอรีเก็บขอมูลของคอนเทนเนอร # docker inspect frosty_tereshkova -f '{{.GraphDriver.Data.UpperDir}}' 220

แบบฝก หัดบทที่ 12 1. อธบิ ายความสมั พนั ธร ะหวา งอิมเมจและแทก็ 2. บอกคำสง่ั ทใ่ี ชแ สดงผลคอนโซลของคอนเทนเนอรชือ่ mycontainer ภายใน 1 ช่วั โมงลา สดุ 3. อธิบายความแตกตา งระหวางคำสัง่ docker attach และ docker exec 4. บอกคำสัง่ ทใี่ ชต รวจสอบเหตุการณท ั้งหมดของอิมเมจ httpd 5. อธิบายวิธกี ารหาชนั้ ขอ มูลของคอนเทนเนอร และพ้ืนทีท่ ีค่ อนเทนเนอรใชง าน 221

222

การปฏิสมั พนั ธร ะหวางคอนเทนเนอร บทนำ แมเทคโนโลยีบรรจุคอนเทนเนอรไมไดจำลองทุกฮารดแวรเหมือนเทคโนโลยีเสมือนจึงไมจำเปนตองมี ไฮเปอรไวเซอรและระบบปฏิบัตกิ ารเปนตวั คั่นกลาง แตเทคโนโลยบี รรจคุ อนเทนเนอร เชน โปรแกรมด็อกเกอร สามารถจำลองเครือขายเสมือน โดยใหคอนเทนเนอรที่ทำงานอยูสามารถเชื่อมตอหากันได และยังสามารถ เชื่อมตอหาบริการหรือการทำงานของระบบที่ไมไดอยูในคอนเทนเนอรได โดยที่บริการเหลานั้นไมสามารถ ทราบไดว า ซอฟตแ วรท กี่ ำลงั เชอ่ื มตออยนู น้ั ถูกปรับใชงานในคอนเทนเนอรอ ยหู รือไม 13.1 หลักการทำงานของเครือขา ยเสมือน เครือขายเสมือนในด็อกเกอรถูกสรางและจัดการไดดว ยการสรา งกฎของไฟรวอลลเพื่อตัดสินใจวาขอ มลู จะถกู สง ไปยังคอนเทนเนอรไหนหรือภายนอกคอนเทนเนอร ดังนนั้ เครอื ขายเสมือนทส่ี รา งข้ึนจะถูกสั่งงานโดย ซอฟตแวรทำใหคอนเทนเนอรไมสามารถไดที่อยูไอพีวงเดียวกันกับที่ด็อกเกอรโฮสตได เวนแตจะสรางกฎของ ไฟรว อลลข้ึนมาเฉพาะ โดยใหอนิ เตอรเฟสเครือขา ยของด็อกเกอรโ ฮสตจ องที่อยไู อพีเพ่ิม และยา ยเสนทางของท่ี อยูไอพีนั้นไปยังที่อยูไอพีของด็อกเกอรในเครือขายเสมือน อยางไรก็ตาม วิธีการดังกลาวไมเปนที่นิยม เพราะ โดยปกติที่อยูไอพีของคอนเทนเนอรจ ะถูกจัดสรรโดยด็อกเกอรโฮสตโดยอัตโนมัตผิ านโพรโตคอล DHCP ทำให แมลบคอนเทนเนอรและสรางคอนเทนเนอรใหมที่มีอิมเมจ การเชื่อมตอที่เก็บขอมูล และพอรตเหมือนเดิมแต ที่อยูไอพีของคอนเทนเนอรนั้นอาจจะไมเหมือนเดิม ดังนั้น การเชื่อมตอเฉพาะบางพอรตกับคอนเทนเนอรจึง เปนที่นิยมมากกวาโดยอาศัยวาคอนเทนเนอรหนึ่งคอนเทนเนอรควรมีบริการที่ทำงานอยูเพียงบริการเดียว เทา นนั้ เครือขายเสมือนในด็อกเกอรทำงานโดยใชไดรเวอร หรือซอฟตแวรเปนตัวขับเคล่ือนลักษณะการทำงาน โดยคาเรมิ่ ตนมีอยู 5 ประเภท คอื 1) บริดจ (Bridge) เปนไดรเวอรเครือขายเริ่มตน หากไมไดระบุตอนสรางเครือขายเสมือน เครือขาย บริดจของดอ็ กเกอรมีไวสำหรบั แอปพลเิ คชันที่ในคอนเทนเนอรเ ดี่ยวสามารถเชอ่ื มตอกนั ได ไดรเวอร น้เี หมาะสมหากตอ งการใหคอนเทนเนอรสามารถเช่ือมตอเคร่ืองภายนอกหรืออนิ เทอรเ น็ต 2) โฮสต (Host) เปนไดรเ วอรเครือขา ยท่ีเชื่อมตอเฉพาะคอนเทนเนอรกับโฮสตเทาน้ัน ทำใหคอนเทน เนอรไ มส ามารถเช่ือมตอกับเครื่องภายนอก หรืออนิ เทอรเนต็ ไดโ ดยตรง หากตอ งการเชอื่ มตอเคร่ือง ภายนอก หรืออินเทอรเน็ต คอนเทนเนอรที่มีอินเตอรเฟสเครือขายท่ใี ชไดรเวอรนจ้ี ะไดเชื่อมตอผาน คอนเทนเนอรอ ืน่ ท่ีมไี ดรเวอรอินเตอรเ ฟสเครือขายเปนบริดจ 3) โอเวอรเลย (Overlay) เปนไดรเวอรที่เช่ือมเครื่องคอมพิวเตอรทีต่ ิดต้ังด็อกเกอรโ ฮสตหลายเครื่อง เขาดวยกัน ทำใหในการเชื่อมตอผานไดรเวอรนี้ ด็อกเกอรโฮสตในคอมพิวเตอรทุกเครื่องทำงาน เสมือนหนึ่งเปนเครื่องเดียวกัน ดังนั้น คอนเทนเนอรที่ทำงานอยูบนตางด็อกเกอรโฮสตจะสามารถ เชอ่ื มตอกันไดเ สมอื นหนึ่งวาคอนเทนเนอรน้นั ทำงานอยบู นเคร่ืองด็อกเกอรโ ฮสตเดยี วกัน ไดรเวอรน้ี 223

จะถูกสรางโดยอัตโนมัติเพื่อด็อกเกอรโฮสตหลายเครื่องสรางด็อกเกอรสวอรม (Docker Swarm) (Docker Inc. 2020c) รวมกันเทาน้นั 4) แมควีแลน (Macvlan) เปนไดรเวอรที่อนุญาตใหระบุท่ีอยูทางกายภาพของอินเตอรเฟสเครือขาย (MAC address) ใหกับอินเตอรเฟสเครือขายของคอนเทนเนอรได ทำใหคอนเทนเนอรใชที่อยูไอพี เดียววงเดียวกันกับด็อกเกอรโฮสตได ดวยการสรางเครือขายบริดจ (Bridge network) กับ อินเตอรเฟสเครือขายของด็อกเกอรโฮสต แตการสงขามขอมูลระหวางเครื่องภายนอกกับคอนเทน เนอรทั้งหมดที่ใชไดรเวอรนีจ้ ะเชือ่ มตอกันดวยที่อยูทางกายภาพของอินเตอรเฟสเครือขายของด็อก เกอรโฮสตเดียวกัน ดังนั้น อุปกรณเครือขายหรือสวิตซจำเปนตองสนับสนุนการทำงานแบบ Promiscuous mode ดว ย 5) ไมมี (None) เปนการระบุวายกเลิกการทำงานของไดรเวอรเครือขายเพื่อไมใหคอนเทนเนอรนั้น สามารถเชอื่ มตอ กับคอนเทนเนอรอ นื่ ได แมจ ะมไี ดรเวอรหลายรูปแบบในด็อกเกอรใหเลือกใช อยา งไรกต็ าม ไดรเ วอรทีน่ ิยมถูกใชงานและเหมาะ ในสถานการณสวนใหญคือการใชไดรเวอรบริดจ เพราะด็อกเกอรจะสรางเครือขายอีกวงหนึ่งขึ้นมาให คอนเทนเนอรไดปฏิสัมพันธกันโดยขอมูลสามารถวิ่งผานด็อกเกอรโฮสตไปยังเครือขายภายนอกทันที และ เครื่องคอมพิวเตอรภายนอกสามารถเชื่อมตอผานพอรตของด็อกเกอรโฮสต โดยที่ประสิทธิภาพของเครือขาย แบบบริดจมีประสิทธิภาพใกลเคียงกับการเชื่อมตอกับแอปพลิเคชันที่ทำงานโดยไมไดผานด็อกเกอรโฮสต (Zeng et al. 2017) 13.2 คำส่ังท่ใี ชสรา งเครอื ขา ยเสมือน โปรแกรมดอ็ กเกอรล ูกขายสามารถสอบถามรายการเครอื ขายเสมือนจากด็อกเกอรโ ฮสตไดดว ยคำสง่ั # docker network ls เมื่อพิมพคำสั่งจะแสดงผลลัพธ ดังภาพที่ 13.1 แสดงรายการของเครือขายเสมือน พรอมคุณสมบัติ รหัสเครือขาย ชื่อเครือขาย ไดรเวอรที่ใช และขอบเขต โดยคาตั้งตนขอบหากด็อกเกอรโฮสตไมไดเขารวม ด็อกเกอรสวอรมจะมีเครือขายเสมือนมาท่ีตดิ ตั้งมาพรอ มกัน 3 เครือขาย คือ เครือขายชื่อ bridge ใชไดรเวอร บริดจ เครอื ขา ยช่ือ host ใชไ ดรเ วอรโฮสต และเครือขา ย none ไมม ไี ดรเวอร สวนรหัสของเครือขายน้ันจะถูก สรางโดยสุม เมื่อตอนตดิ ตงั้ แตล ะเครอื่ งจะมรี หสั เครือขายทไี่ มเ หมือนกนั ภาพที่ 13.1 หนา จอผลลัพธคำสง่ั แสดงรายการเครือขายเสมือน 224

นอกจากน้ีผูอานยังสามารถตรวจสอบอินเตอรเฟสเสมือนที่ถูกสรางขึ้นจากด็อกเกอรโฮสตโดยอัตโนมัติ ดวยคำส่ัง # ip link เมื่อพมิ พค ำสงั่ โปรแกรม ip จะแสดงรายการของการเชอ่ื มตอท่ีมอี ยูในเครื่องคอมพิวเตอร โดยเครือขาย ที่ด็อกเกอรโฮสตสรางขึ้นมานั้นจะเปนเครือขาย docker0 แตเมื่อสรางเครือขายเสมือนขึ้นตามมาในภายหลัง ชื่อของเครือขายที่ใชในระบบปฏิบัติการลีนุกซจะเปน br-<รหัสเครืองขาย> เชน หากเครือขายที่สรางใหมมี รหสั เครอื ขา ยเปน 3f03e2826368 ชือ่ ของเครอื ขายจะเปน br-3f03e2826368 ทุกครั้งที่สรางคอนเทนเนอรโดยที่ไมระบุเครือขาย คอนเทนเนอรที่สรางจะมีเครือขายอัตโนมัติอยูท่ี เครือขาย bridge แมจะทำใหเกิดความสะดวกสบาย คอนเทนเนอรสามารถเชื่อมตอระหวางกันไดทันที และ คอนเทนเนอรสามารถเชื่อมตอกับอินเทอรเ น็ตไดทันที แตหากตองมีการปรับใชค อนเทนเนอรมากกวา 1 คอน เทนเนอร และคอนเทนเนอรเหลานั้นมีการเช่ือมตอกันอยางมีขอบเขต เชน คอนเทนเนอร ก. สามารถเช่ือมตอ กับคอนเทนเนอร ข. และคอนเทนเนอร ค. สามารถเชื่อมตอกับคอนเทนเนอร ง. แตวาคอนเทนเนอร ก. ไม สามารถเชื่อมตอกับคอนเทนเนอร ค. ได ทั้งนี้ เพื่อทำใหการบริหารจัดการเครือขายเสมือนมีความมั่นคง ปลอดภัย ผูอานจึงควรสรางเครือขายเสมือนประเภทบริดจขึ้นมาเอง เชน หากตองการสรางเครือขายเสมือน ประเภทบรดิ จชื่อ alpine-net สามารถใชคำส่ัง # docker network create --driver bridge alpine-net แตเนอื่ งจากหรอื ไดรเ วอรบรดิ จเปน คาเริ่มตน ผูอา นสามารถใชค ำสั่ง # docker network create alpine-net แทนไดเชนกัน เมื่อพิมพคำสั่ง ด็อกเกอรโฮสตจะคนหาชวงของที่อยูไ อพีที่ถกู จดั วาเปนเครือขายสว นตวั และจะไมซ้ำกับที่อยูไอพีสาธารณะ และจัดสรรที่อยูไอพีใหโดยอัตโนมัติ โดยหากตรวจสอบดวยคำสั่ง docker network ls จะแสดงผลลัพธด งั ภาพที่ 13.2 ภาพที่ 13.2 หนาจอผลลัพธคำสัง่ แสดงรายการเครอื ขายเสมือนทส่ี รา งขึน้ ใหม แมการสรางเครือขา ยแบบโดยท่ีไมกำหนดชวงของซบั เน็ตจะเปน ที่นิยม หากตอ งการระบซุ ับเน็ตหรือชวง ของที่อยูไอพสี ำหรับเครือขาย สามารถใชพารามิเตอร --subnet --ip-range และ --gateway เพอ่ื ระบุชวงของ 225

ที่อยไู อพขี องซับเนต็ ชวงของท่อี ยูไ อพีที่ไวจดั สรรผา นโพรโตคอล DHCP และที่อยไู อพีของเกตเวยหรือของด็อก เกอรโฮสตตามลำดบั เชน # docker network create --driver bridge --subnet 192.168.100.0/24 --ip-range 192.168.100.0/24 --gateway 192.168.100.1 alpine-custom-net เมื่อพิมพคำสั่ง ด็อกเกอรโฮสตจะสรางเครือขาย alpine-custom-net และเมื่อตรวจสอบรายการ เครือขายเสมอื น จะปรากฏผลลัพธ ดงั ภาพท่ี 13.3 ภาพท่ี 13.3 หนา จอผลลพั ธคำส่ังแสดงรายการเครือขายเสมือนท่ีสรางขึ้นใหม หนึ่งในสาเหตุของการสรางเครือขายเสมือนที่ใหระบุซับเน็ต และชวงของที่อยูไอพีแยกออกจากกัน เพราะวาผูอานสามารถสรางเครือขายที่มีซับเน็ตกวางกวาชวงของที่อยูไอพีได เพราะเมื่อสรางคอนเทนเนอรท่ี เชื่อมตอกับเครือขายเสมือนนี้ คอนเทนเนอรจะมีไอพีที่จัดสรรโดยชวงของที่อยูไอพีที่ระบุเทานั้น แตผูอาน สามารถกำหนดท่ีอยไู อพคี งท่ีใหกบั คอนเทนเนอรใ นชว งทไ่ี มไดอยชู วงของท่ีอยไู อพีทีร่ ะบุ เชน # docker network create --driver bridge --subnet 192.168.101.0/24 --ip-range 192.168.101.208/28 --gateway 192.168.101.1 alpine-custom-net2 เปนคำสั่งสรางเครือขายเสมือนชื่อ alpine-custom-net2 ที่มีซับเน็ตเปน 192.168.101.0/24 หมายความวา ชวงของที่อยูไอพีที่ถูกตองของคอนเทนเนอรในเครือขายนี้สามารถเปน 192.168.101.1 ถึง 192.168.101.254 แตการระบุชวงของที่อยูไอพีในพารามิเตอร 192.168.101.208/28 หมายความวา หาก ผูอานสรางคอนเทนเนอรในเครือขายนี้โดยไมกำหนดที่อยูไอพีคงที่ ด็อกเกอรโฮสตจะกำหนดที่อยูไอพีใหอยู ในชวง 192.168.101.208/28 ซึ่งกค็ อื ตง้ั แต 192.168.101.208 ถงึ 192.168.101.223 เทานน้ั ประโยชนของการกำหนดซับเน็ตใหกวางกวาชวงของไอพีจะทำใหผูอานมีชวงของไอพีที่สามารถ กำหนดใหเปนที่อยูไอพีคงที่ได โดยที่ที่อยูไอพีคงที่นั้นจะไมถูกจัดสรรไปใหคอนเทนเนอรอื่นผานโพรโตคอล DHCP ในระหวางที่คอนเทนเนอรท ีก่ ำหนดที่อยูไ อพีคงท่ีนน้ั หยดุ การทำงานไปชว งหนึ่ง 13.3 การตรวจสอบสถานะของเครือขายเสมอื นของระบบ เมื่อสรางเครือขายเสมือน เครือขายเสมือนจะอยูในสถานะเปดการทำงานตลอดเวลา อยางไรก็ตาม มี ขอมูลหลายประการที่ด็อกเกอรโ ฮสตสรางขึ้นใหอตั โนมัติ ผูอานสามารถตรวจสอบสถานะของเครอื ขายไดจาก 226

รหัสเครือขายหรือชื่อของเครือขาย ในกรณีที่เปนรหัสเครือขายผูอานสามารถพิมพแคบางสวนที่ไมซ้ำกับ เครือขายอื่นได แตหากเปนชือ่ เครือขายจะตองพิมพชือ่ เต็มของเครือขายเชน หากตองการตรวจสอบเครือขาย alpine-net ที่มีรหสั เครอื ขา ยเปน 3f03e2826368 สามารถพมิ พค ำสัง่ # docker network inspect alpine-net เนื่องจากคำสั่ง inspect ของด็อกเกอรนั้น แมจะสงผลลัพธกับมาใหผูอานเห็นในรูปแบบ JSON แต โครงสรางของการประมวลผลเปนแมแบบภาษา Go ทั้งนี้เพราะโปรแกรมด็อกเกอรถูกเขียนขึ้นมาดวยภาษา Go ดังนั้น ผูอานจึงควรติดตั้งโปรแกรม jq ซึ่งเปนโปรแกรมตัวประมวลผลแฟม JSON (JSON Parser) เพื่อให การแสดงผลสวยงามและเขา ใจงาย ดว ยคำสัง่ # yum install jq ผูอานสามารถใชพารามิเตอร -f เพื่อจัดรูปแบบการแสดงผลของคำสั่งในด็อกเกอรได เชน คำสั่งที่ เกยี่ วของกับเครือขา ย alpine-net ดังน้ี 1) ซับเนต็ ของเครอื ขายและเกตเวยของเครอื ขา ย alpine-net ใชค ำสั่ง # docker network inspect alpine-net -f \"{{json .IPAM.Config}}\" | jq 2) คอนเทนเนอรท ่ถี กู สรางในเครอื ขา ยและท่ีอยูไอพีทไี่ ดร บั ใชค ำส่งั # docker network inspect alpine-net -f \"{{json .Containers}}\" | jq คำสั่งนี้จะแสดงผลลัพธก็ตอเมื่อมีคอนเทนเนอรที่กำลังเปดการทำงานอยู หากไมมีคอนเทนเนอรที่เปด การทำงานในเครือขายนี้ คำสั่งนจี้ ะไมแสดงผลลพั ธ 13.4 การสรา งคอนเทนเนอรพรอ มเครือขายเสมือน คอนเทนเนอรเมื่อถูกสรางขึ้นมาจะตองอยูในเครือขายใดเครือขายหนึ่งหากไมตองการใหคอนเทนเนอร น้ันสามารถเชื่อมตอกบั คอนเทนเนอรอนื่ ได คอนเทนเนอรน ้ันจะตองอยูในเครือขาย none เพราะไมมีไดรเวอร เครือขาย อยางไรก็ตาม เมื่อสรางคอนเทนเนอรโดยไมระบุเครือขาย คอนเทนเนอรนั้นจะอยูในเครือขาย bridge เสมอ และท่อี ยไู อพจี ะไดรับการจัดสรรผานโพรโตคอล DHCP ท่ที ำงานอยใู นดอ็ กเกอรโ ฮสต เพื่อใหด็อกเกอรไดสรางเครือขายใหกับคอนเทนเนอร และสามารถสอบถามดูสถานะของเครือขาย เสมือนคอนเทนเนอร ผูอานจะทดลองสรางคอนเทนเนอรขึ้นมาจำนวน 2 คอนเทนเนอร โดยใชอิมเมจของ Alpine Linux ซึ่งเปนอิมเมจของลีนุกซที่มีขนาดเล็กที่สุด และกำหนดใหทั้งคูอยูในเครือขาย alpine-net ใน กรณที ีต่ อ งการระบุชอื่ ของคอนเทนเนอร ผูอานสามารถใชพารามเิ ตอร --name เพื่อระบุช่อื คอนเทนเนอรได # docker run -dit --name alpine1 --network alpine-net alpine sh 227

จากคำสั่งดานบน จากคำสั่งดานบนจะเปนการคอนเทนเนอร alpine1 ถูกสรางจากอิมเมจ alpine ให ทำงานอยูเบื้องหลังบนเครือขายเสมือน alpine-net แตที่อยูไอพีที่คอนเทนเนอร alpine1 ไดรับนั้นจะไดรับ การจัดสรรอัตโนมัติผานโพรโตคอล DHCP โดยมีด็อกเกอรโฮสตเปนตัวบริหารจัดการที่อยูไอพี แตการสราง คอนเทนเนอรดวยวิธีนี้ หากผูอานหยุดการทำงานคอนเทนเนอรไป คอนเทนเนอรนี้จะปลอยที่อยูไอพีที่ไดรับ จัดสรรมาทำมาด็อกเกอรโฮสตมีที่อยูไอพีเหลือเพิ่มขึ้นสำหรบั จัดสรรใหกับคอนเทนเนอรอื่นในอนาคต ขอเสีย คือ เม่อื เรม่ิ ตนเปดการทำงานคอนเทนเนอรน ี้ใหมอีกคร้ัง ทีอ่ ยไู อพีของคอนเทนเนอรนี้จะเปลี่ยนแปลงไปทำให หากคอนเทนเนอรสองคอนเทนเนอรเชื่อมตอกันดวยที่อยูไอพี ทำใหถาคอนเทนเนอรทั้งสองคอนเทนเนอร เชื่อมตอกันโดยอางอิงท่ีอยูไอพีอาจทำใหเ กิดปญหาเวลาปรับใชงานในสภาพการใชงานจรงิ ได เพราะเครือขาย เสมือนที่ชื่อเดียวกนั ในด็อกเกอรโฮสตสองเครื่องอาจมีที่อยูไอพีคนละวงก็ได วิธีการที่แนะนำคือ ใหตั้งชื่อคอน เทนเนอรดวยพารามิเตอร --name เมื่อตอนสรางคอนเทนเนอร เมื่อสรางคอนเทนเนอรในเครือขายใด ด็อก เกอรโ ฮสตมรี ะบบ DNS โดยสรางชอื่ เครอ่ื งจากชอื่ คอนเทเนอรและเช่ือมโยงกบั ทีอ่ ยูไอพี เวลาเชือ่ มตอคอนเทน เนอรส องคอนเทนเนอรจ ะสามารถใชช่ือของคอนเทนเนอรเ พ่ืออางองิ ได อยางไรก็ตาม คอนเทนเนอรทั้งคูอาจจะไมสามารถเชื่อมกันไดอีก หากมีคอนเทนเนอรใดคอนเทนเนอร หนึ่งหยุดการทำงานและเปดการทำงานใหม ดังนั้น ผูอานสามารถสรางคอนเทนเนอรโดยตั้งคาที่อยูไอพีคงท่ี ใหกับคอนเทนเนอรนั้น โดยเงื่อนไขการกำหนดที่อยูไอพีนั้นจะตองเปนที่อยูไอพีที่ถูกตองและอยูในชวง เครือขายและซับเน็ตดวย และเครือขายที่จะสามารถระบุที่อยูไอพีไดนั้น ตองถูกสรางดวยคำสั่งที่ระบุซับเน็ต ชวงของไอพี และเกตเวยเอง เชน ผูอานสามารถระบุที่อยูไอพีคงที่ในเครือขาย alpine-customer-net ได แต จะไมสามารถระบุที่อยูไอพีคงที่ใหกับเครือขาย alpine-net ที่ด็อกเกอรโฮสตเปนตัวดำเนินการจัดหาซับเน็ต ชว งของทอี่ ยูไอพี และเกยเวยโดยอัตโนมัติ สำหรับเครือขาย alpine-customer-net มีซับเน็ตเปน 192.168.100.0/24 หมายความวา ชวงของท่ี อยูไอพีที่สามารถระบุไดคือ 192.168.100.1 ถึง 192.168.100.254 อยางไรก็ตาม หากผูอานระบุที่อยูไอพีผดิ ไป เชน ระบุเปน 192.168.120.10 ดังคำสงั่ ตอ ไปน้ี # docker run -dit --name alpine2 --network alpine-custom-net --ip 192.168.120.10 alpine sh # docker ps -a ด็อกเกอรโฮสตสรางคอนเทนเนอรนั้นได แตจะแสดงขอความผิดพลาดไมสามารถเปดการทำงานคอน เทนเนอรได ดังภาพที่ 13.4 เพราะที่อยูไ อพีไมถูกตอ ง ดัง วิธีการแกไ ขที่เหมาะสมคอื การลบคอนเทนเนอรน ้นั และสรางใหมโ ดยระบชุ วงของท่อี ยูไอพีที่ถูกตอง ภาพท่ี 13.4 หนา จอผลลพั ธขอ ผิดพลาดของคำสง่ั สรางคอนเทนเนอร 228

ลำดับถัดไป ผูอานจะลบคอนเทนเนอร alpine2 ออกไป และใชคำสั่งสรางคอนเทนเนอร alpine2 จาก อิมเมจ alpine ที่ทำงานอยูเบื้องหลังและเชื่อมตอกับเครือขาย alpine-custom-net มีที่อยูไอพีคงที่เปน 192.168.100.10 ซงึ่ เปน ทอ่ี ยไู อพที ีถ่ กู ตอง # docker rm alpine2 # docker run -dit --name alpine2 --network alpine-custom-net --ip 192.168.100.10 alpine sh ภาพที่ 13.5 หนา จอผลลัพธคำสงั่ สรางคอนเทนเนอร เมื่อพิมพคำสั่ง จะปรากฏผลลัพธดังภาพที่ 13.5 วาสามารถสรางคอนเทนเนอรและเปดการทำงานได ตามปกติ อยางไรก็ตาม แมจะระบุซับเน็ต ชวงของที่อยูไอพี และเกตเวยใหกับเครอื ขาย alpine-custom-net แตการสรางคอนเทนเนอรในเครือขายนี้ไมจำเปนตองกำหนดที่อยูไอพีคงที่เสมอไป เพราะด็อกเกอรโฮสต สามารถจดั สรรท่ีอยไู อพที ีว่ าง ณ ขณะนั้นใหกับคอนเทนเนอรไ ด เชน # docker run -dit --name alpine3 --network alpine-custom-net2 alpine sh เปนคำสั่งสรางคอนเทนเนอร alpine3 จากอิมเมจ alpine ที่ทำงานเบื้องหลังและเชื่อมตอกับเครือขาย alpine-custom-net2 ที่มชี วงของท่อี ยูไอพเี ปน 192.168.101.208 ถงึ 192.168.101.223 โดยดอ็ กเกอรโฮสต จะหาที่อยไู อพีท่ยี งั ไมไ ดจดั สรรตามชว งทกี่ ำหนดใหโ ดยอตั โนมตั ิ 13.5 การตรวจสอบสถานะของเครือขายเสมอื นของคอนเทนเนอร หากมคี อนเทนเนอรช่ือ alpine1 และ alpine2 หากตองการตรวจสอบคุณสมบตั ิเครือขา ยของคอนเทน เนอรท ีละคอนเทนเนอร เชน ตรวจสอบคอนเทนเนอร alpine1 สามารถใชคำสั่ง # docker inspect -f '{{json .NetworkSettings.Networks}}' alpine1 | jq แตหากตอ งการตรวจสอบทงั้ สองคอนเทนเนอรจ ากมุมมองของเครอื ขาย alpine-net โดยใชคำสัง่ # docker network inspect alpine-net -f \"{{json .Containers}}\" | jq จะปรากฏรายการแสดงตามรหัสคอนเทนเนอรท่ีมขี อมลู ชื่อคอนเทนเนอรพรอมทั้งที่อยูไอพีและเกตเวย ของคอนเทนเนอรนน้ั 229

13.6 การเชอื่ มตอคอนเนอรก บั เครือขายเสมอื น เงื่อนไขหนึ่งของการสรางและเปดการทำงานของคอนเทนเนอรคือคอนเทนเนอรจะตองเชื่อมตอ เครือขายอยางนอย 1 เครื่องขาย ในกรณีที่ตองการใหคอนเทนเนอรสามารถเชื่อมตอเครือขายมากกวา 1 เครอื ขาย หรือตองการยายเครือขายจากเครอื ขายหนึง่ เปนอีกเครือขายหนึ่ง ผูอ านสามารถเชอ่ื มตอเครือขายอื่น ใหกับคอนเทนเนอร เชน คอนเทนเนอร alpine1 ถูกสรางและกำหนดใหเชื่อมตอเครือขาย alpine-net อยู แลว หากตองการใหเชื่อมตอเครือขาย alpine-custom-net อีกหนึ่งเครือขายเพิม่ ขึ้นมาและยังคงเชื่อมตออยู เครือขาย alpine-net อยเู หมอื นเดิม สามารถใชค ำสั่ง # docker network connect alpine-custom-net alpine1 การบริหารจัดการ DNS เพื่อใหคอนเทนเนอรสามารถเชื่อมตอกันผา นชื่อของคอนเทนเนอรแทนท่ีอยูไอ พีไดนั้นถูกทำโดยอัตโนมัติผานด็อกเกอรโฮสต ในบางกรณี คอนเทนเนอรหนึ่งสามารถมีไดหลายชื่อแตกตาง ตามเครือขา ยทเ่ี ชื่อมตอ เชน คอนเทนเนอร alpine1 เดมิ มีช่ือวา alpine1 ในเครอื ขา ย alpine-net และชื่อวา alpine1 ในเครือขาย alpine-custom-net หากตองการใหคอนเทนเนอรนี้มีชื่อเพิ่มเติมวา a1 ในเครือขาย alpine-net และ ac1 ในเครอื่ งขาย alpine-custom-net สามารถดำเนินการไดโ ดยใหคอนเทนเนอร alpine1 ทยอยยกเลกิ การเช่อื มตอ คอนเทนเนอรกับเครอื ขายเสมือนกอน ดวยคำสั่งในหวั ขอ ถัดไป เมื่อยกเลิกการเชื่อมตอจาก alpine-net หรือยังไมไดเชื่อมตอกับเครือขาย alpine-net สามารถพิมพ คำส่งั # docker network connect --alias a1 alpine-net alpine1 เมื่อยกเลิกการเชื่อมตอจาก alpine-custom-net หรือยังไมไดเชื่อมตอกับเครือขาย alpine-custom- net สามารถพิมพค ำส่ัง # docker network connect --alias ac1 alpine-custom-net alpine1 เมอื่ พิมพครบทง้ั สองคำสง่ั DNS ของด็อกเกอรโ ฮสตจ ะเก็บขอมลู ชื่อโฮสต alpine1 และ a1 ในเครือขาย alpine-net และชอ่ื โฮต alpine1 และ ac1 ในเครอื ขา ย alpine-custom-net ใหชีไ้ ปยงั ทอี่ ยูไอพขี องคอนเทน เนอร alpine1 โดยอัตโนมัติ นอกจากการต้งั ช่อื โฮสต ผูอานยงั สามารถเปลยี่ นทอ่ี ยูไ อพที ่ีกำหนดทอี่ ยูไอพใี หคงที่ เชน หากตอ งการทำ หนดที่อยูไอพีของคอนเทนเนอร alpine1 ในเครือขาย alpine-custom-net เปน 192.168.100.20 โดย ยกเลิกการเชอื่ มตอจาก alpine-custom-net กอนหากมีการเชื่อมตออยกู อ นหนา และสามารถใชคำส่ัง # docker network connect --ip 192.168.100.20 alpine-custom-net alpine1 ขอควรระวังคือ การตั้งคาดวยคำสั่ง docker network connect ในแตละครั้งจะเปนการตั้งคาทับการ ตั้งคาเดิมสงผลใหการตั้งคาเดิมหายไป จากตัวอยางของคอนเทนเนอร alpine1 ที่เชื่อมตอเครือขาย alpine- custom-net เมือ่ พมิ พคำสั่งตง้ั ชื่อโฮสตเพ่ิม การต้ังคาท่ีอยูไอพีคงที่จะหายไป และเม่ือพิมพคำสั่งตั้งคาที่อยูไอ 230