หนังสือเกี่ยวกับ Docker ที่เขียนยังไม่เสร็จ Docker ก็เปลี่ยนใส้ในไปหลายอย่างจนผมตามไม่ทัน

1.
...ขาพเจาเฝารอวันที่ความรูของขาพเจาพรอมสรรพ
วันนั้นไมเคยเดินทางมาถึงเลย
ตอเมื่อขาพเจาหยุดที่จะรอ วันนั้นก็มาถึง
ขาพเจารูซึ้งวาวันนั้นไมมีทางมาถึงตราบที่ยังตามหา
แทจริงแลวมีแตวันนี้เทานั้นเอง…

2. “Docker​หนะหรอ? กอนจะกลาวถึง Docker นั้นตองคุยไปถึงเรื่อง Container
เสียกอนวามีความเกี่ยวของกันยังไง” ปรมาจารยอูเกวยกลาวพลางคํ้าไมเทา
“Container บางทีเราก็เรียกมันวา OS-Level Virtualization เพราะวามันใฃ Kernel
รวมกับตัวระบบปฏิบัติการหลักของเรา มีมานานมากแลวถาจะนับ Chroot เปน OS-Level Virtualization
แลวละก็ มันก็มีมาตั้งแต ค.ศ. 1982 พูนแหละ แตถาเปน Container รุนใหมๆ ก็มีมาราวสิบปมานี่แหละ
ไอพวก OpenVZ, Solaris Zone หรือพวก LInux Container (LXC) แมวามันจะไมปลอดภัยเทากับตัว
Hypervisor แตมันก็มีขอดีคือลดพื้นที่โจมตีเพราะมันไมตองมีพวก Guest OS
เรื่องซีเคียวนี่เถียงกันไดอีกนาน”
“แลว Kernel มันคืออะไรหละทานอาจารย” อาโปกลาวถาม ขณะที่ปรมาจารยอูเกวยหันหลังอยู
“Kernel คือโปรแกรมที่ทําหนาที่เปนแกนกลางของระบบปฏิบัติการของเรา
สวนนี้คือหัวใจในการติดตอกันระหวางฃิ้นสวนภายใน OS โดยปกติแลวโปรแกรมเราจะไมไดสามารถคุยกับ
RAM หรือ Harddisk หรืออุปกรณคอมพตาง ๆ ไดตรง แตจะคุยผาน Kernel ปองกันโปรแกรมกาก ๆ
ที่พวกเจาสรางจะเขาไปทําใหระบบไฟฟามันซอตหนะซิ”
“แลว Chroot หละทานอาจารย”
“Chroot เปนการขังโปรแกรมใหมองเห็นไดเรกทอรี่ (ที่เรียกจนติดปากวาโฟลเดอรนั่นแหละ)
ที่กําหนดใหเปนเปนรูทไดเรกทอรี่ของโปรแกรททําใหมันวิ่งไปที่ไดเรกทอรี่อื่นไมได เพราะในระบบ Unix
รูทไดเรกทอรี่มันอยูสูงสุดแลวไงหละ”
“เอาเทานี้กอนเดี๋ยวธาตุไฟเขาแทรก” ปรมาจารยอูเกวยกลาว พลางเลาตอ
“Docker เปนทั้งชื่อซอฟตแวรและก็ชื่อบริษัทดวย แตกอน Solomon Hykes เปนเจาของ dotCloud
บริษัททําเกี่ยวกับเรื่อง PaaS ทําไปทํามาทาทางจะไปไมรอดเพราะไมทําเงินใหนักลงทุนสักเทาไหร แต
Solomon ก็ไดทําโปรเจกโอเพนซอสภายใน dotCloud ไปดวยชื่อวา Docker เปดซอสเปน Apache 2.0
นักพัฒนายุคแรกๆก็พวก Andrea Luzzardi, Francois-Xavier Bourlet แลวก็ Jeff Lindsay
สามคนแรกเปนวิศวกรของ dotCloud สวน Jeff เปนนักพัฒนาภายนอก ทําไปทํามาโปรเจกนี้ชักรุง
ประกอบกับธุรกิจหลักของ dotCloud ไมคอยดี เลยเปลี่ยนชื่อบริษัทเปน Docker แลวให dotCloud
เปนหนวยธุรกิจของ Docker แทน ภายหลัง dotCloud ก็ถูกขายให CloudControl โดยไมเปดเผยเงื่อนไข
ประมาณวาไปอยูกับคนที่เขาดูแลเธอไดดีกวาฉันจะดีกวา แตไมมีพนักงาน Docker ยายไปอยูกับ
CloudControl เลย เมื่อตนป ค.ศ. 2016 dotCloud ก็ตองปดตัวลงเพราะบริการไปไมรอด
บอกแลวตลาดนี้มันเถื่อน ไมแนจริงอยูไมได”
“เทคโนโลยี Container ที่มีมานานนมแลวก็จริงแตมันใชงานยาก Docker เอามาทําใหมันสามารถไดงาย ๆ
และจุดยืนของ Docker จะชวยโฟลวการทํางานของ DevOps ซึ่งเปนวัฒนธรรมการทํางานที่ Developer กับ
Operation ประสานงานกันไดอยางดี ยาย App จากเครื่องไปอีกเครื่องได ไมมีดรามามันเวิรคบนเครื่องตู!

3. ซะมากกวาเพราะทุกวันนี้เถียงกันหลือเกินวา VM หรือ Docker ดีกวา มันดีกันคนละอยาง ปดโถว!
เอาหละไหนๆ ก็พูดกันถึงเรื่อง VM ปะทะ Docker แลวก็ตองอธิบายสักหนอย” พูดพลางวาดรูปบนพื้น
“อาโป เจาเห็นรูปนี่ไหม ทางซายเปนชั้นของ VM จะตองมี Hipervisor หรือ Virtual Machine Manager
(VMM) เปนตัวกลางในการคุยกัน อยาเพิ่งเถียงเรื่องประเภทของ VM ที่แบงยอยไดหลากหลาย เอาเปนวา
VM ทั่วๆไปที่เราใชอยูมีลักษณะแบบนี้ จะมีตัวกลางในการคุยคือ Hipervisor นี่แหละ แลวก็ยังตองมี Guest
OS ซึ่งมันทําใหชา ในขณะที่ Docker ทางขวาเขาเจานั้นไมจําเปนตองใช Guest OS ไมตองมี Hypervisor
แตมี Docker Engine แทน งานวิจัยของ IBM บอกวา Container มันมีโอเวอรเฮดของการเริ่มตนใชอยูที่ < 1
วินาที แต VM ใชราว 11 วินาที อันที่จริง Docker มีนใชเวลาเริ่มราว ๆ 200-300 มิลลิวินาทีเอง งานวิจัยใหม
ๆ ตนป ค.ศ. 2016 บอกวาสามารถใชเทคนิคให Container เร็วกวา VM 91 เทา เร็วโพดโพ
เร็วจนตองรองขอชีวิต กลไกที่ทําใหมันเร็วไดขนาดนี้ก็เนื่องมาจากที่ไดอธิบายไป มันใชวิธีการวิ่งผาน Kernel
ของระบบปฏิบัติการหลักที่เราใชอยู เปนเหตุผลวาทําไมมันใช Windows ขางใน Container บน Linux ไมได
เพราะ Windows กับ Linux มันใช Kernel คนละตัวกันไง ชัดหรือยังวาตางมีแนวทางเปนของตัวเอง จะให
Container ไปตีตลาด VM คงจะไมงายซะทีเดียว”
“แลวกระบวนการขางใน Docker Engine ทํางานยังไงหละทานอาจารย” อาโปยิงคําถามตอ

4.
“กอนอื่นคงตองเลาคราวๆ ใหเจาฟงกอนเรื่องของชิ้นสวนหรือองคประกอบของที่เรียกวา Docker
ซะกอนวามีอะไรที่จําเปนตองรูบาง
● Docker Machine​ เปนตัวที่ใช Provision หรือเตรียมเครื่องปลายทางให ถาเรามีเครื่องคอมเปลา ๆ
หรือที่เรียกวา Bare Metal มันจะสรางคียแลวเอาคียไปเพิ่มที่เครื่องปลายทาง
จากนั้นจัดการลงโนนนี่ใหเสร็จสรรพ หรือถาเราใชอินฟราของพวก Amazon, DigitalOcean
เราก็จะเอาคียมาใส จากนั้นที่เหลือมันก็จะจัดการลง Image อะไรให สะดวกสบาย ถามวาไมใช Machine
ไดไหม กตอบวาได แตถามีเครื่องเปนรอยเครื่องนี่ลําบากแนนอน โดยเฉพาะตอนสรางคีย แลว Join Swarm
Cluster นะ บอกไดคําเดียววานรกแตกจะ
● Docker Swarm​ ตัวนี้เอาไวใชคุยกับ Docker หลายๆ ตัววางายๆ
มันก็คือตัวที่เอาไวจัดการคลัสเตอรของ Docker นั่นเอง ขอดีคือมันสามารถคุยกับ Docker
หลายตัวในโหมดซีเคียวได สั่งที่เดียวสามารถกําหนดใหมันเอา Container ไปวางที่ DigitalOcean หรือ
Amazon ก็ได สบั้ยมาก
Docker Compose เอาไวมัด Container หลายๆ ตัวเขาไวดวยกันไง เวลารันมันจะไดรันขึ้นมาเปนชุดๆ
เชนเว็บเซิฟเวอรกับฐานขอมูล มันก็จะมาเปนชุดๆ กันเราก็จะเขียนไฟลในรูปแบบ YML (อานวายาเมล)
รายละเอียดเดี๋ยวคอยวากัน
● Docker Engine​ พระเอกของเราที่จะไดคุยรายละเอียดกันตอไป แตตอนนี้เอาคราวๆ
มันคือตัวรันงานจริงๆ เปนตัวจัดการ Container สวนนี้คือหัวใจของ Docker เลยแหละ
ถาไมมีพสวนนี้พับคอมเก็บแลวไปปลูกเมลอนไดเลย
● Docker Registry​ สวนนี้เอาไวเก็บ Image ของ Docker เดี๋ยวเลาใหฟง วัยรุนอยาเพิ่งใจรอน“

5. “โอเค ตอนนี้เราก็รูถึงองคประกอบของ Docker บางสวนที่จําเปน แลวก็มีการพูดถึงบอย ๆ ไปแลว
ทีนี้เรามาเจาะลึกรายละเอียดเริ่มที่ Docker Engine พระเอกของเรากันกอนเลย Docker รีลีสครั้งแรก 13
มีนา 2013 (มันมีโจกอยูวา HR บองตื้นของบริษัทไหนจําไมไดระบุวาผูสมัครตองมีประสบการณใช Docker
ไมนอยกวา 3 ป ทั้งๆ ที่ตอนนั้น Docker อายุ 2 ป เอง) เวลาพูดถึง Docker ก็จะหมายถึง Docker Engine
นี่แหละ ตัว Engine ใชคุณสมบัติของ Linux Kernel เชน CGroups, Namespaces และ Union Mounting
(เชนพวก AUFS) ทําใหมันสามารถเปน OS-Level Virtualization ได และแยก Container
ที่ทํางานอยูบนเครื่องเดียวกันออกจากกันไดอยางสวยงาม ระบบจะมอง Engine
ทั้งตัวเปนแคโปรเซสของระบบ Container จะเปนโปรเซสยอยของ Engine อีกทีถา Docker Engine
หรือแมมันตาย Container ตัวลูกนี่ก็เดดซะมอเรตามไปดวย เวอรชั่นแรก ๆ Engine ใช LXC แตรุน 0.9
มาก็เปลี่ยนไปใชคาเริ่มตนเปน libcontainer ที่เขียนขึ้นมาเองจากภาษา Go”
“แลวพวก CGroups, เนมสเต็ก นี่คืออะไรหรอครับทานอาจารย”
“ Namespace ตะหากเฟย เอาหละ ในเมื่อเจาไมเขาจะก็จะเลาใหฟง
● CGroups​ หรือ Control Group
เปนตัวที่ใชแยกและจํากัดการเขาถึงทรัพยากรของเครื่องคอมพิวเตอรที่ใช Linux เชนพวก Disk I/O, RAM,
CPU, Network จํากัดการใชงานไดเชน ใช CPU ไดไมเกินเทาไหร ใช RAM ไมไมเกินเทาไหร
ใชสูงสุดแคทรัพยากรที่ตัวเองไดรับจัดสรรเทานั้น พัฒนาโดยวิศวกรจาก Google แลวรวมโคดเขามาใน Linux
Kernel Mainline ในรุน 2.6.24 (Linux Kernel มีคนแกใหเปนรุนยอยจนนับไมถวยแตตัวหลักที่ Linus
Torvald คนสราง Linux เปนคน Maintain เราเรียกวา Mainline)
● Namespaces​ ใชแบงทรัพยากรของ Linux ออกการกัน การทํางานจะคลายกับ Chroot
ระบบจะเห็นสภาพแวดลอมเฉพาะของ Container ตัวเอง ไมสามารถไปใชทรัพยาการของ Container อื่นได
โดยจัดวางอยูในลักษณะของไดเรกทอรี่ยอย ๆ เปนลําดับ Namespaces นี่เองที่ทําให Container มี IP,
Hostname หรืออุปกรณเครื่อขายเปนของตัวเอง
● Union Mount​ เปนการเมาทไฟลที่เดียว แตเห็นไฟลจากหลายที่ งงปะ? คือใน Linux
เราสามารถสรางรูหนอนจากไดเรกทอรี่หนึ่งหรือไดวรหนึ่ง ๆ ไปอีกที่หนึ่งได แตมันดันเปนแบบชี้ไดทีละที่
สมมุติ /mnt ของเรามีไฟล A อยู ทีนี้เราเมาท Disk0 ที่มีไฟล B ไปที่ /mnt ถาเราเปดดูจะเห็นแคไฟล B ตัว
Union Mount เลยเขามาแกปญหาสวนนี้ ซึ่งมันจะทําใหเห็นทั้งไฟล A และ B ในเมาทพอยตเดียวกัน”
“เดี๋ยวกอนยังไมหมด สิ่งที่ควรรูอีกอยางก็คือ Docker ใชกลไกที่เรียกวา Copy-on-Write (COW)
ที่อยูใน File System เชน BTRFS หลักการทํางานของมันก็คือมันจะ Copy ตัวที่มันจะ Write เอา
งงรับประทานอีก วากันงาย ๆ สมมุติวามี App 2 ตัวชื่อ App-1 กับ App-2 ใชงานไฟลเดียวกัน ชื่อไฟล A
ก็แลวกัน ระบบไฟลปกติเชน Ext4 ถา App-1 แกไฟล A ใหเปน A’ แลวความบรรลัยจักเกิดแก App-2
ที่เรียกใชงานไฟลเดียวกัน แตไฟลเจากรรมดันถูกแกไขไปแลว แตถาระบบเปนแบบ COW แลวหละก็ไฟลที่

6. App-1 แกจะไมกระทบกับ App-2 มันจะมองเปนคนละไฟลกันแลว แนวคิดนี้ชวยให Docker
ลดการใชพื้นที่ไปไดเยอะเลยเพราะมันเก็บเฉพาะสวนที่เพิ่มขึ้นมาเอาไวแกไฟลนิดเดียวก็ไมตองเก็บทั้ง HDD”
“อนาคตของ Docker ไปไดสวย และคิดวานาจะไปไดสวยเรื่อยตอนนี้นอกจาก Linux แลวยังมี Windows
เขามาแจมดวย อยากจะรูเหลือเกินวาอะไรดลใจ Satya Nadella CEO ของ Microsoft ใหยอมแก Kernel
ของ Windows ใหซับพอรต Docker ยิ่งชวงหลัง ๆ Microsoft ดู เอาจริงเอาจังกับ Linux มาก ๆ
แถมยังยอมใส Bash Shell เขามาเอาใจ System Admin ที่ใช Linux อีก เขามีแผนอะไรกันแนนะ”
“วันนีเลิกคลาสได เราจะเจอกันวันพรุงนี้ เมื่อวันพรุงนี้มาถึงเจาจะตองพรอมแลว”
ปรมาจารยอูเกวยหันหลังแลวหายตัวไป
วันคืนลวงไป ๆ บัดนี้เราทําอะไรอยู
- พระพุทธเจา -
“อาโป ตึ่งไดลาวว ลือสายแลวนะ เดี๋ยวไปเรียนไมทัน”
“ครับเตี่ยยยย”
กระบวนทาที่ 1 : เปดโลกยุทธจักร
“เอาหละวันนี้เจาจะไดเรียนรูโลกของ Docker และวิชายุทธเบื้องตนกันใหพอสมควร Docker
นั้นมีคียเวิรดที่นาสนใจอยูหลายตัว
● Docker Image​ เปนลักษณะตนแบบของ Container
ซึ่งมันประกอบไปดวย OS แลวก็ App ที่ติดตั้งเพิ่มไปเปนชั้นๆเหมือนขนมชั้นเลย
ที่มันทําเปนชั้น ๆ แบบนี้ไดก็เพราะมีคุณสมบัติของ COW นี่แหละที่สนับสนุน
มันจะเก็บ Layer ตอซอนกันขึ้นไปเรื่อย ๆ ไดตามขอมูลหรือโปรแกรมที่เพิ่มขึ้นมา
รูปขวามือเปน Image ชื่อ Mem_Nginx
จะเห็นวามันมีชั้นหลายอันเรียงกันเปนขนมชั้น ชั้นที่ตํ่าที่สุดคือ Ubuntu 16.10
ซึ่งเปนระบบปฏิบัติการ Image ที่ไมมีแมแบบนี้เราเรียกมันวา Base Image
จากนั้นก็มีการติดตั้ง Nginx​ ตามดวย Memcache​ ในลําดับถัดมา
สมมุติอีกวาถาเรามี Image ตัวที่ 2 ชื่อ MApache แตใช Ubuntu 16.10​ ซึ่งเปน
Base Image รวมกันแบบนี้ Layer ของ Ubuntu 16.10
ก็จะสามารถใชรวมกันไดไมตองเปลืองเนื้อที่เก็บ 2 เทา แตมันชี้มา Layer เดียวกันไดเลย (ตามคํานิยามในเว็บ

7. https://docs.docker.com​ Base Image คือ Image ที่ไมมี Parent แตในเอกสารหลาย ๆ ตัวก็ใชคําวา
Base Image สําหรับ Image ที่คิดวาเปนฐานของงานตัวเองเลย เชน ตัวอยางขางบนถาเราสนใจการติดตั้ง
Web Server ก็สามารถเรียกตัว Image ของ Ubuntu เปน Base Image ไดเชนเดียวกัน ถึงแมวา Ubuntu
จะมีหลาย Layer ก็ตาม บางเจาปรับกลไกพวก Init system ที่ใชกับ Docker ไมเหมาะแลวคอยทํา Base
Image ดังนั้นไมตองซีเรียสเรื่องการเรียกมาก)
● Docker Container​ คลายกับ Container ที่เอาไวขนสงสิ่งของทางเครื่องบินหรือทางเรือ แต
Docker ใฃกับการขนสงชิ้นสวนซอฟตแวร การขนสงสินคาไมสนใจวาของใน Container
เปนอะไรขอแคมันอยูในนั้นได บริษัทสงสินคารับรองวาจะสงไดอยางมีมาตรฐาน Docker ก็ขนสงซอฟตแวรใน
Container โดยไมสนใจ เหมือนกันวามันเปนซอฟตแวรอะไร
แตรับประกันวามันจะทํางานไดอยางมีมาตรฐานเดียวกัน ในทุก ๆ ที่
ทําใหมันสามารถรันที่ไหนก็ไดและใหผลลัพธเหมือนเดิม ตัว Docker Container ใช Image
เปนตัวตั้งตนเพื่อสราง Container ขยายความอีกหนอย Container คือ โปรเซสของ Image
ที่สามารถมีหลายโปรเซสหรือ Container ทํางานโดยตั้งตนจาก Image เดียวกันได ถา Container
ไหนมีการแกไขคอยใช COW เพิ่ม Layer ขนมชั้นไปเรื่อยๆ เห็นไหมหละวาคอนเซ็บ COW ถูกเอามาใชแลว
Conatainer
● Docker Engine​ อยางที่เคยบอกไปวาตัว Engine นี้คือพระเอกของเรา ซึ่งภายในตัว Engine
เองก็แบงออกเปน 2 สวน คือ Docker Server บางที่เราก็เรียกมันวา Daemon ตัวนี้เปนตัวทํางานใหเราจริง
ๆ ระบบการทํางานจะอยูสวนนี้ อีกสวนคือ Docker Client เปนตัวเรียกสั่งงานผาน RESTful API ชื่อเทห ๆ
คือ Docker Remote API ไปที่ตัว Daemon จากนั้น Daemon จะเปนตัวจัดการ Container ให
ขอควรระวังคือเวอรชัน API ใน Server กับ Client ควรจะเปนเวอรชันตรงกันจะดีที่สุด
มีหลายกรณีที่เวอรชันตางกันแลวทํางานไมได
แตไมตองเปนกังวลถาติดตั้งพรอมกันปกติก็ไดรุนเดียวกันมาอยูแลว ทาพิศดารแบบนั้นเกงแลวคอยใช“
“ถาเครื่องเรามีโปแกรมครบทุกอยาง แลวเราสามารถทํา Base Image ของเราเองไดไหมทานอาจารย”
“ไดซิลองถามอากูดูวา ทํายังไงนะ เอาเปนวาตอนนี้เจาพรอมที่จะใชงาน Docker กอนแลวก็แลวกัน
ตามธรรมเนียมเราจะเริ่มที่การติดตั้งกันเลย (ใครเกงแลวก็ขาม ๆ ไปได)
Windows

8. 1) ไปที่เว็บไซต https://www.docker.com/products/docker-toolbox
2) กด Download ฝงที่มีโลโก Windows
3) ขั้นตอนติดตั้งก็ไมยาก เหมือนที่เราคุนเคยกันดี Next ๆ Yes ๆ OK ๆ

10.
4) หลังจากติดตั้งเสร็จแลวเราจะได icon มาสองตัว เราจะเลือกใช Terminal
เพราะมันจะรับคําสั่งทาง Command Line Interface (CLI) (สวนตัว Kitematic เปนแบบ GUI คลิ๊ก ๆ
สั่งงานไดเหมือนกัน)
Mac OS X
คลาย ๆ กับของ Windows เลยครับ แตเปนการติดตั้งจาก Source นอก App Store ของ Apple
ดังนั้นถาเกิดกดจะติดตั้งแลวติดตั้งไมได ใหเขาไปเปลี่ยนโหมดตัวปองกันการติดตั้งกอน ใหมันรองรับ
Indentified Developers
ไปที่ System Preferences > Security & Privacy > แลวเลือกตัวกลางตามภาพ
1) ไปที่เว็บไซต https://www.docker.com/products/docker-toolbox
2) เลือกโหลดฝง Mac

11.
กด Keep (บอกละเอียดไปปาวเนี่ย)
3) Next ๆ Yes ๆ OK ๆ

12.
Ubuntu (และ Debian ก็คลายกัน)
ตัวอยางสั่งจาก Shell Super User ของ Root พอทุกสถาบัน (ถาอยากสั่งให User
ของเราไปอยูในกลุม Docker ที่ Docker แอบสรางไวใหเพื่อใชสั่งรัน Docker ได ก็สั่ง $ sudo usermod -aG
docker your-use​r ซึ่งก็ใชสิทธิ์ Super User อยูดีแตใชแคครั้งแรกไงหละ)
1) เปด Terminal แลวสั่ง $ sudo su
2) สั่ง # curl -sSL https://get.docker.com/ | sh
(เครื่องหมาย $ ไมตองพิมพนะ เอาไวบอกระดับของ Shell วาเปน Shell ระดับ User ธรรมดา สวน
# บอกวาเปนระดับ Super User เขียนเอาไวเผื่อมีคนงง มันเคยมีไง)

13. 3) สั่ง # docker version​ ดู ถามันขึ้นทั้ง Client กับ Server แบบนี้เปนอันเรียบรอย
พิเศษหนอยสําหรับใครที่อยูในกลุม Private Beta ของ Docker ก็สามารถโหลด Docker for Mac หรือ
Docker for Windows มาใชได (คาดวาอีกสักพักกวาผูใชทั่วไปจะไดใช) ตัว Docker
Toolbox ที่บอกวิธีติดตั้งไปแลวนั้นจะใช Linux Disto ที่ชื่อ boot2docker บน
VirtualBox ทั้งใน Mac และ Windows แตตัว Docker ที่เปน Private Beta จะใช
Alpine Linux บน xhyve ใน Mac หรือบน Hyper-V ใน Windows ซึ่งเปน
Hypervisor ที่เปน Native ของแตละ OS หลักการของ Toolbox จะใช Machine
Provision ไปที่ VirtualBox จากนั้นเรียก API ไปสั่งงาน (โดยใช Environment) สวน Docker for Mac/Win
ไมตองใช Machine แตจะใชผาน API ไปเรียกใช Hypervisor เลย (ไมตองตั้ง Environment
มันจะใชคาเริ่มตนคือ /var/tmp/docker.sock ซึ่งเปนไฟลที่ระบบปฏิบัติการตระกูล UNIX
ใชติดตอกันระหวางโปรเซสลักษณะคลาย TCP/IP สวนตัว Docker for Win จะคุยผาน Named Pipe)
ใครที่สนใจก็สามารถเขาไปโหลดไดที่ https://docs.docker.com/docker-for-mac/​ สําหรับ Mac หรือ
https://docs.docker.com/docker-for-windows/​ สําหรับ Windows การทํางานหลัก ๆ ก็ยังเหมือนเดิม”
----------------------------------------------------------ขอควรรู--------------------------------------------------------------
ตัวอยางการใชงานตอจากนี้ไปจะใช Docker Toolbox ที่ติดตั้งใน Mac OS X เปนหลัก

14. และการใชงานคําสั่งจะไมไดลงรายละเอียดการตั้งคายิบยอย แตทานสามารถหาเอกสารอานเพิ่มหรือสั่ง
$ ​docker --help​ เพื่อดูการตั้งคา หรือ $ docker ​คําสั่งยอย --help​ เพื่อดูการใชงานได
----------------------------------------------------------------------------------------------------------------------------------
“เอาหละทีนี้เรามาเริ่มใชงานกันเลย เปด Docker Quickstart Terminal
ขึ้นมา จากนั้นตัว App จะสั่ง Machine ให Provision โดยใช Driver ของ
VirtualBox ขึ้นมา Provision ให ซึ่งกระบวนการคราว ๆ ก็มี
1) เริ่มกระบวนการสรางเครื่อง (ปกติชื่อวา default)
2) กอปไฟล boot2docker.img ซึ่งเปน Linux Disto พิเศษที่
Docker ทํามาเขาไปขางใน VM”
3) สรางตัว VM ใน VirtualBox
4) สรางคีย SSH เอาไวใชเครื่องแบบไมตองใสรหัสผาน มันจะเอาคียไปถอดรหัสกันเอง
5) สตารท VM จากนั้นเอาคียไปวางใหถูกที่ถูกทาง
ซึ่งกระบวนการที่วาจะทําแครอบแรกที่ Provision เทานั้น
ใชเวลาพอสมควรแตถาเห็นวาฬเหมือนในรูปก็เปนอันใชได (รอบตอไปก็เปดแลวโซโลไดเลย)

15.
ลองเช็ค Environment ดู
DOCKER_HOST​ จะเห็นวามันเซ็ตชี้ไปที่ IP : 192.168.99.100 ซึ่งเปน IP ของ VM ที่ลง boot2docker
ใชพอรต 2376 ซึ่งเปนซีเคียวพอรตของ Docker Engine (ถาใชพอรต 2375 แสดงวาไมใชโหมดซีเคียวเดอ)
DOCKER_MACHINE_NAME​ ชื่อโฮสของ VM ชื่อ default (โฮสกับ VM ใชชื่อเดียวกัน)
DOCKER_TLS_VERIFY​ ใชโหมดซีเคียว
DOCKER_CERT_PATH​ ที่เก็บใบรับรอง (ตอนที่ Machine มันสรางคีย SSH จะไดใบรับรองออกมาดวย)”
“แลว Driver ที่ใชใน Machine นี่คืออะไรหรอทานอาจารย” อาโปถามขึ้นหลังจากที่เงียบฟงอยูนาน
“ใน Machine นั้น Driver คือตัวที่บอกวามันจะมีกลไกการ Provision อยางไร แตละ Driver
ก็มีความแตกตางกันออกไป เชน DigitalOcean Driver ของมันก็จะบอกวามันตองไปจะเรียก API

16. ไปที่ไหนเพื่อสรางเครื่องใน DigitalOcean ถาจะระบุที่ตั้งของโหนดที่จะเปดตองทําอยางไร, Amazon EC2
ก็คลายกันนะ, สวนพวกที่เปน VM หนะหรอ อืมม~ม ถาเปน VirtualBox มันก็จะมีมีบอกวารันคอมมานยังไง
กําหนดพารามิเตอรยังไง ถาจะเอา RAM เทาไหร ประมาณนี้ เดี๋ยวมีเวลาจะเลาใหฟงนะ”
“แตตอนนี้เจาลอง Whalesay ซึ่งเปนเบสิกของ Docker คลายๆ Hello, world ของการเขียนโปรแกรมกอน
สั่ง $ docker run docker/whalesay cowsay "Hi,I'm user"
เมื่อเราสั่งคําสั่งไปแลว Docker Engine จะไปดึง (Pull) Image ซึ่งเปนขนมชั้น (จะเห็นวามันโหลดมาเปน
Layer ๆ จาก Registry ซึ่ง Registry เองก็มี 2 สวนคือ Public คือ https://hub.docker.com
สวนนี้เอาไวเก็บ Official Image หรือ Image ที่ผูใชเปดสาธารณะ อีกสวนคือ Private เปน Registry
ที่เอาไวเก็บ Image ใน Datacenter ของผูใชเอง หรือจะใช https://hub.docker.com​ ก็ไดเหมือนกัน
แตถาจะเก็บเกิน 1 Private Image ตองจายเงิน สวนนี้จะเห็นเฉพาะผูไดรับอนุญาต เมื่อดึง Image
ลงมาไดครบทุก Layer ระบบก็จะหา Digest เพื่อรับประกันวาขอมูลที่ดึงมาครบถวน sha256 เปนชื่อ
Algorithms ที่ใชหา Digest จากนั้น Docker ก็จะสั่งให Container ทํางานโดยผานพารามิเตอร ​cowsay
"Hi,I'm user" ไปให cowsay เปนชื่อโปรแกรมปกติเปนวัวพูด แตใน Image นี้แกใหเปนวาฬพูด "Hi,I'm user"
เปนพารามิเตอรของ cowsay อีกทีบอกวาใหวาฬพูดวา "Hi,I'm user"
ถาเห็นวาฬพูดคํานั้นออกมาก็เปนอันใชได”

17.
ปรมาจารยอูเกวยกลาวพรอมเสียงไอ คอก แคก “กระบวนทาที่ 1 คงตองหยุดไวเทานี้เสียกอน”
เชื้อเพลิง ออกซิเจน และความรอนเปนเหตุใหเกิดไฟ
ขาพเจาและแมใคร ๆ มิอาจสั่งใหไฟนั้นกอติดได
การอาน การฟง และคิดวิเคราะหเปนเหตุของความรู
ขาพเจาและแมใคร ๆ มิอาจสั่งใหความรูนั้นกอเกิดได
ทั้งไฟและความรูเกิดจากเหตุของมัน ไมไดเกิดจากพระเจาอยากใหเปน
- เซอร จอหน ดราวนตัน -
กระบวนทาที่ 2 : ครอบครอง Dockerfile
แดดวันนี้รอนเกินที่จะจิบกาแฟหรือเลนกอกองทราย เด็ก ๆ ในสํานักนี้ลวนมีหนาที่แตกตางกันไป
บางเปนเบ บางเปนใบ บางเปนพี่ บางเปนนอง ทุกคนมุงหวังจะฝกวรยุทธเพื่อเอาไวชวยเหลือบานเมืองตน
แตไมใชทุกคนที่ประสบความสําเร็จแตทุกคนก็ไดวิชาติดเนื้อติดตัวกันไปพอไดใชรักษาชีวิตเปนครั้งคราว
“อาโป เก็บของวันนี้ขาจะพาเจาเขาเมือง” ปรมาจารยอูเกวยกลาวพลางหันไปซุปซิปกับปรมาจารยชิฟู
“ไดเลยครับทานอาจารย” อาโปรับคําพลันเก็บของลงยามสะพายหลัง
เวลาบายแก ๆ ของวัน แมจะไมเหมาะนักกับการเดินทางแตก็เปนเวลาที่ถูกกําหนดไวจากอูเกวย
แสดงวามันตองเปนธุรสําคัญแน ๆ ถึงตองเดินทางกันในเวลานี้
“วันนี้ขาจะสอนเจาเรื่อง Dockerfile” อูเกวยเอยขึ้นหลังจากที่เราเดินทางออกจากสํานักไดสัก 15 ลี้แลว
อาโปสงกระบอกไมใผบรรจุนํ้าใหอูเกวยที่นั่งพักไดดื่ม หลังจากดื่มนํ้าสองอึกใหญ ๆ
ไปแลวอาโปก็หยิบมาดื่มบาง พรอม ๆ กับตั้งใจฟง
“การจะสราง Docker Image มานั้นสามารถไดจาก 2 ทาง ทางแรกคือสรางโดยการคอมมิท Container
จากคําสั่ง $ docker commit วิธีนี้ประมาจารยหลายทานไมชอบพอนักเพราะทานเห็นวา Track
ดูรายการคําสั่งอะไรบางก็ลําบาก ไมมีชั้นมีตอน ตางจากการสรางจากสั่ง $ docker build จาก Dockerfile

18. ที่เปนขั้นตอน แกงาย สามารถเก็บไวใน Version Control เชนพวก Git ไดดีกวาการเก็บไบนารี่ของ Docker
Image ทั้งกอน บางทานก็วาใชมันทั้งคูนั่นแหละ”
“เอา เดี๋ยวทําทั้งสองวิธีใหดูกอนแลวเราคอยมาลงลึกกับ Dockerfile
● Docker Commit​ จะใชกรณีที่มี Container อยูแลว แลวตองการทําให Container
นั้นกลายเปนพื้นฐานใหกับ Container ตัวอื่นหรือจิวางาย ๆ ก็คือ Image ใหตัวอื่นเอาไปใชนั้นเอง
เอาหละสมมุติวามี Image ของ Busybox (Linux Distro ไซสเล็กขนาดไมกี่เม็ก) ที่ดึงลงมาจาก Docker Hub
อยู (Image มีชั้น 8ddc19f16526 อยูชั้นเดียวแบบนี้ Base Image ตัวจริงเสียงจริงแนนอน)
สั่งใหรัน
ดูสถานะหนอยวารันไดยัง
เขาไปใช Shell ของ Container
ลองสรางไฟลขึ้นมาสักไฟลหนึ่ง แลวลิสตดู จากนั้นก็ออกจาก Shell
จากนั้นจะ Commit ใหเปน Image ตัวใหม
ลองลิสต Images ดูวาได Image ออกมาจริง ๆ ไหม ก็จะเห็นวามี Image ตามชื่อที่ใหเรากําหนดโผลขึ้นมา

19. ● Docker Build​ จะสั่งคําสั่งนี้ไดเราก็ตองมี Dockerfile ซะกอน
วิธีการที่ทําใหดูนี้จะเอาไฟลยัดเขาไปในตัว Image ดวย
เอาหละเมื่อไฟลพรอมแลวก็จะสั่ง Build ถาสังเกตมันจะมีรายการคําสั่งที่อยูใน Dockerfile โชวขึ้นมาเปน
Step ๆ และระหวางทางมันก็จะมีการสราง Intermediate Container ขึ้นมาแลวก็ลบทิ้งไป
เนื่องจากบางคําสั่งตองการทํางานใน Container เชนพวก RUN apt-get update อะไรทํานองนั้นไง
โอเค เสร็จแลวลองลิสตดูวามี Image ชื่อ busybox_hello โผลมาหรือเปลา (ใชเครื่องหมาย Dash -
ในนี้ไมไดนะ)
สั่ง Run Container ดูวามันจะทํางานตาม Script ที่เราเขียนไวหรือเปลา
เอาหละเก็บเราจะเดินทางตอกันแลว ไวจะเลารายละเอียดใหฟงตอนที่เรากําลังเดินทางกันดีกวา
เดียวจะสายเกินไป” ปรมาจารยอูเกวยเก็บขาวของเดินนําหนาออกไป
….
เดินทางออกมาไดสักพักอูเกวยก็พูดขึ้นเพื่อทําลายความเงียบ “Dockerfile เจาก็ไดรูวิธีทําไปแลว
ทีนี้จะไดมาลงรายละเอียดกันซะที เอาเปนวาเริ่มเรียนรูคําสั่งที่ใชใน Dockerfile กันกอน
คําสั่ง คําอธิบาย

20. FROM เปนคําสั่งที่ใชบอกถึง Image ตั้งตนที่จะเอามาใชงานดวยลักษณะการของ Docker
Image คือจะมี Image ฐานของมันซึ่งจะเปน Image
ตัวไหนก็ไดแลวก็มีลักษณะขนมชั้นที่เพิ่มไปเรื่อย ๆ อยางถาอยากได Ubuntu
14.04 แลวจะสั่งติดตั้ง Nginx ฐานของเราก็คือ Ubuntu 14.04
แลวเราก็จะใชคําสั่งติดตั้ง Nginx ทีหลัง เนอ~อ แลวก็ FROM
นี่จะเปนคําสั่งเริ่มตนของทุก Dockerfile (ไมตองทอง ไมออกสอบ)
วิธีใช
FROM [ชื่อ Image ไหนก็ได]
ตัวอยาง
FROM Ubuntu:14.04
คําแนะนํา
ควรใชกับ Image ที่มีขนาดเล็ก หากตองการ Full Distribution
ที่มีของทุกอยางใหครบควรใช Image ของ Debian นะจะ ๆ
MAINTAINER คําสั่งนี้เอาไวบอกวาใครเปนคนสราง Image นี้ขึ้นมา เวลาดาจะไดดาถูกตัว
(วึ่งเวลาจะทําอะไรเกรียน ๆ เราก็จะใสชื่อเพื่อนลงไป)
วิธีใช
MAINTAINER [ชื่อคนสราง] “ใส Email ดวยก็ได”
ตัวอยาง
MAINTAINER AorJoa “bhuridech@gmail.com”
คําแนะนํา
การกําหนดคานี้จะไมมีผลกับกระบวนการ Build Image (ยกเวนใสชื่อ เจี๊ยบ
เลียบดวน ลงไป เครื่องทานอาจจะพังได
และทางเราปฏิเสธความรับผิดชอบในทุกกรณี)
RUN ใชสําหรับทํางานคําสั่งกับ Container อะ อยาเพิ่งงงนะ จําไดไมเรื่อง
Intermediate Container หนะมันก็คือ Container ที่ถูกสรางขึ้นมาระหวางการ
Build แลวมันก็ลบทิ้งไง อธิบายละเอียดอีกหนอยก็คือคําสั่ง Docker Build
มันไปสั่งใหสราง Container ขึ้นมาใชจาก Image ที่กําหนดไวในคําสั่ง FROM
แลวเอาคําสั่งที่อยูใน RUN ไปรันใน Contianer นั้น เมื่อรันเสร็จมันก็จะ Commit
เก็บไวใชในคําสั่งตอ ๆ ไปของ Dockerfile
วิธีใช
RUN คําสั่ง <======== แบบ shell
RUN [คําสั่ง] <======== แบบ exec
ตัวอยาง
RUN apt-get install -y nginx

21. คําแนะนํา
หลีกเลี่ยงคําสั่งที่ตองมีการโตตอบกับผูใชงาน ถาจะใช apt-get install ให update
กอนนะ และถามีหลายบรรทัดใหใชเครื่องหมาย คั่น เชน
RUN apt-get update && apt-get install -y
nginx
CMD อาการของคําสั่งนี้จะคลายกับ RUN แตวาการทํางานคําสั่งนี้จะเกิดขึ้นตอนที่สั่งให
Container เริ่มทํางาน สวนคําสั่ง RUN จะทํางานตอนที่สราง Image อยางถาสั่ง
CMD echo "I'm handsome." อยางนี้ หลังจาก Container
เริ่มทํางานไมวาจะเริ่มจากคําสั่ง Run หรือ Start ก็ตาม
แตเนื่องจากจุดประสงคของการสรางคําสั่งนี้มาเขาสรางมาเพื่อเปน คําสั่งเริ่มตน
นั่นหมายความวามันสามารถถูก Override
หรือทับคําสั่งดวยการใชคําสั่งในระดับอื่น เชน กรณีที่กําหนดใหใช echo “TEST”
ใน Dockerfile แตถามีการ Override คําสั่งก็จะเปลี่ยนไปตามคําสั่งที่ Override
คือเปลี่ยนเปน echo “Override” แทน
วิธีใช
CMD “คําสั่ง” “Parameter1” “Parameter2” <==== แบบ shell
CMD [“Parameter1”,“Parameter2”] <==== แบบ Default Parameter
CMD [“คําสั่ง”,“Parameter1”,“Parameter2”] <=== แบบ exec *แนะนํา
ตัวอยาง
CMD [“/usr/bin/curl”,”www.google.com”]
คําแนะนํา
(1) ถามีคําสั่ง CMD หลายอันมันจะทําแคอันสุดทาย
(2) มีขอแตกตางระหวางเครื่องหมาย ‘ กับ “ ขอแนะนําใหใช “
(3) ควรจะใช Full Path กับคําสั่งเชน /usr/bin/curl
(4) ตัวคําสั่งที่ Override มีความสําคัญกวา ดังนั้นถามีการ Override
มันจะทําเฉพาะ Override
ENTRYPOINT