ได้เวลาสำรวจความมหัศจรรย์ของ Docker แล้ว เรามีบทช่วยสอน 2 บท บทหนึ่งเน้นบทแนะนำอย่างละเอียด ซึ่งเราได้เรียนรู้ทั้งหมดเกี่ยวกับเทคโนโลยี วิธีเรียกใช้บริการและเปิดเผยพอร์ต วิธีคอมมิตและสร้างอิมเมจด้วย Dockerfiles และเทคนิคอื่นๆ อีกเล็กน้อย จากนั้นเราใช้ Supervisord แทนสคริปต์เริ่มต้นและ systemd
วันนี้มาเรียนเรื่อง Networking กัน เราจะเชื่อมต่อกับคอนเทนเนอร์ของเราได้อย่างไร เราสามารถเข้าถึงโฮสต์จากภายในอินสแตนซ์ที่เกิดขึ้นได้อย่างไร และที่สำคัญที่สุดคือ วิธีเชื่อมต่อจากคอนเทนเนอร์หนึ่งไปยังอีกคอนเทนเนอร์หนึ่งโดยไม่ต้องรู้อะไรเกี่ยวกับโทโพโลยีล่วงหน้า สิ่งนี้น่าจะน่าสนใจ เช่นเดียวกับคำแนะนำสองข้อก่อนหน้า เราจะอธิบายทีละขั้นตอนและอธิบายทุกอย่างโดยละเอียด หลังจากฉัน.
สารบัญ
- ตั้งค่า
- โฮสต์ไปยังเครือข่ายคอนเทนเนอร์
- สรุป
- คอนเทนเนอร์โฮสต์เครือข่าย
- เครือข่ายคอนเทนเนอร์ต่อคอนเทนเนอร์
- คอนเทนเนอร์ลิงก์!
- ไฟล์โฮสต์
- เชื่อมต่อกับเซิร์ฟเวอร์โดยใช้ชื่อ
- อ่านเพิ่มเติม
- สรุป
ตั้งค่า
ก่อนอื่นมาสร้างคอนเทนเนอร์หลาย ๆ อัน เรามีภาพของเราจากการทดสอบครั้งล่าสุดแล้ว ดังนั้นจึงไม่จำเป็นต้องเริ่มต้นใหม่ทั้งหมด เราจะรันสามคอนเทนเนอร์ แต่ละคอนเทนเนอร์มีบริการ SSH และ Apache ของตัวเอง ไม่ต้องสนใจด้านความปลอดภัยของมัน เพราะเรากำลังพยายามโฟกัสที่ส่วนเครือข่าย
สิ่งหนึ่งที่เราจะทำที่นี่ซึ่งเราไม่ได้ทำในครั้งที่แล้วคือ เราจะตั้งชื่อคอนเทนเนอร์ของเรา เพื่อให้ระบุได้ง่ายขึ้น สิ่งนี้ทำได้โดยใช้ตัวเลือก --name ตัวอย่างเช่น:
นักเทียบท่ารัน -d -ti -p 22 -p 80 --name net3 image-4:latest
มาดูกันว่าที่อยู่ IP ทั้งสามอินสแตนซ์ของเรามีที่อยู่ IP ใดบ้าง:
[root@localhost ~]# นักเทียบท่าตรวจสอบ net1 | grep -i ipaddr
"ที่อยู่ IP":"172.17.0.5",
[root@localhost ~]# นักเทียบท่าตรวจสอบ net2 | grep -i ipaddr
"ที่อยู่ IP":"172.17.0.6",
[root@localhost ~]# นักเทียบท่าตรวจสอบ net3 | grep -i ipaddr
"ที่อยู่ IP":"172.17.0.7",
นี่คือการกำหนดค่าเริ่มต้นของเราสำหรับการทดสอบ เรามีคอนเทนเนอร์สามคอนเทนเนอร์ ซึ่งทั้งหมดทำงานบนโฮสต์เดียวกัน พร้อมบริการและพอร์ตบริการที่เปิดเผย ตอนนี้เราสามารถเริ่มทำสิ่งที่น่าสนใจได้แล้ว
โฮสต์ไปยังเครือข่ายคอนเทนเนอร์
นี่เป็นส่วนที่ง่าย และความจริงที่ต้องบอกคือ เราได้ทำไปแล้วในแบบฝึกหัดที่แล้ว เราได้เชื่อมต่อกับคอนเทนเนอร์ของเราโดยใช้ SSH และเราได้ลองทดสอบพอร์ตโดยใช้ telnet ใช่ netcat (nc) ยังใช้งานได้ดี กรุณาปิดความปลอดภัยด้วย มีสองวิธีในการเชื่อมต่อ หนึ่ง คุณสามารถเข้าถึงคอนเทนเนอร์ได้โดยตรงโดยใช้ที่อยู่ IP เหมือนที่เราเคยทำมาก่อน
ssh 172.17.0.5
ไม่สามารถสร้างความถูกต้องของโฮสต์ '172.17.0.5 (172.17.0.5)' ได้ ลายนิ้วมือของคีย์ ECDSA คือ 00:4b:de:91:60:e5:22:cc:f7:89:01:19:3e:61:cb:ea
คุณแน่ใจหรือไม่ว่าต้องการเชื่อมต่อต่อ (ใช่/ไม่ใช่) ใช่
คำเตือน:เพิ่ม '172.17.0.5' (ECDSA) อย่างถาวรในรายการโฮสต์ที่รู้จัก
รหัสผ่านของ [email protected]:
สอง คุณยังสามารถเข้าถึงพอร์ตที่โฮสต์แมปซึ่งสอดคล้องกับพอร์ตบริการภายในคอนเทนเนอร์ หากเราดูที่ข้อมูล PORTS ในเอาต์พุต docker ps:
0.0.0.0:49162->22/tcp, 0.0.0.0:49161->80/tcp net1
0.0.0.0:49163->22/tcp, 0.0.0.0:49164->80/tcp net2
0.0.0.0:49165->22/tcp, 0.0.0.0:49166->80/tcp net3
ในตัวอย่างด้านบน สำหรับคอนเทนเนอร์ชื่อ net1 พอร์ต 22 จะถูกแมปกับพอร์ต 49162 บนโฮสต์ ซึ่งหมายถึงอินเทอร์เฟซ docker0 ซึ่งโดยค่าเริ่มต้นถูกกำหนดให้เป็นเครือข่าย 172.17.42.1/16 แน่นอนเราเห็น:
เทลเน็ต 172.17.42.1 49163
ลอง 172.17.42.1...
เชื่อมต่อกับ 172.17.42.1
อักขระ Escape คือ '^]'
SSH-2.0-OpenSSH_6.6.1
ตอนนี้ทำไมคุณถึงต้องการใช้วิธีที่สองเนื่องจากสับสนและจำยากกว่า คำตอบคือ หากคุณไม่ได้ใช้การแมปแบบไดนามิก แต่คุณระบุพอร์ตโฮสต์ที่รู้จักแทน คุณก็จะมีภูมิประเทศที่ชัดเจนมากว่าเครือข่ายคอนเทนเนอร์ของคุณเป็นอย่างไร นอกจากนี้ หากคุณต้องการอนุญาตให้คอนเทนเนอร์ของคุณสามารถเข้าถึงได้จากภายนอกโฮสต์ คุณจะต้องมีการส่งต่อ IP และ NAT หากคุณใช้อินเทอร์เฟซ docker0 สำหรับการสื่อสาร คุณจะต้องใช้กฎ iptables ที่น้อยลงและเรียบง่ายขึ้น
คุณสามารถตรวจสอบได้โดยการรันคำสั่ง iptables -L และตรวจสอบเชน DOCKER กฎใหม่จะถูกเพิ่มโดยอัตโนมัติเมื่อใดก็ตามที่คุณเรียกใช้คอนเทนเนอร์ด้วยตัวเลือก -p
Chain DOCKER (อ้างอิง 1 รายการ)
เป้าหมาย การเลือกต้นทาง ปลายทาง
ยอมรับ tcp -- ทุกที่172.17.0.5 tcp dpt:http
ยอมรับ tcp -- ทุกที่ 172.17.0.5 tcp dpt:ssh
ยอมรับ tcp -- ทุกที่ 172.17.0.6 tcp dpt:ssh
ยอมรับ tcp -- ทุกที่172.17.0.6 tcp dpt:http
ยอมรับ tcp -- ทุกที่ 172.17.0.7 tcp dpt:ssh
ยอมรับ tcp -- ทุกที่172.17.0.7 tcp dpt:http
ยอมรับ tcp -- ทุกที่ 172.17.0.8 tcp dpt:ssh
ยอมรับ tcp -- ทุกที่172.17.0.8 tcp dpt:http
อย่างไรก็ตาม หากคุณไม่มีข้อจำกัดด้านความปลอดภัย วิธีการไดนามิกอาจมีประโยชน์มาก เนื่องจากคุณไม่จำเป็นต้องทราบการแมปพอร์ตเมื่อคุณเริ่มคอนเทนเนอร์ คุณสามารถรับข้อมูลได้แบบเรียลไทม์ โดยแยกวิเคราะห์เอาต์พุต docker ps อย่างไรก็ตาม สำหรับบริการ มักจะมีประโยชน์ในการตั้งค่าที่อยู่ IP แบบคงที่และพอร์ตที่รู้จัก
สรุป
เนื่องจากทำให้เกิดความสับสนเล็กน้อย จึงขอสรุปสั้นๆ โฮสต์นักเทียบท่าใดๆ จะมี docker0 หรือบริดจ์ที่มีชื่อคล้ายกันทำงานอยู่ โดยปกติจะมีซับเน็ต /16 แม้ว่าคุณจะเปลี่ยนชื่อซับเน็ตหรือแม้แต่เครือข่ายได้ก็ตาม เบื้องหลังนั้น คุณสามารถมีคอนเทนเนอร์ได้หลากหลาย โดยแต่ละคอนเทนเนอร์มีที่อยู่ IP ส่วนตัวของตัวเองและพอร์ตที่เปิดเผยตั้งแต่หนึ่งพอร์ตขึ้นไป
หากคุณต้องการเชื่อมต่อกับคอนเทนเนอร์เหล่านี้และพอร์ตที่เกี่ยวข้อง คุณมีหลายตัวเลือก คุณสามารถเชื่อมต่อได้โดยตรง แต่จากนั้นคุณต้องมีกฎการส่งต่อ IP, NAT และไฟร์วอลล์สำหรับแต่ละรายการ และคุณจำเป็นต้องทราบที่อยู่ IP
หากคุณต้องการเชื่อมต่อโดยใช้อินเทอร์เฟซโฮสต์ (docker0) และวิธีการพอร์ตโฮสต์ คุณไม่จำเป็นต้องรู้ว่าคอนเทนเนอร์ของคุณทำงานอย่างไร คุณจำเป็นต้องรู้การแมปพอร์ตโฮสต์กับพอร์ตคอนเทนเนอร์เท่านั้น กล่าวอีกนัยหนึ่ง หากคุณต้องการให้คอนเทนเนอร์ของคุณสามารถเข้าถึงได้ระหว่างโหนดโฮสต์หลายโหนด คุณต้องทำให้โฮสต์อื่นมองเห็นอินเทอร์เฟซโฮสต์ (docker0) เท่านั้น สิ่งนี้ทำให้การส่งต่อ IP, NAT และกฎไฟร์วอลล์เป็นเรื่องง่าย ตัวอย่างเช่น:
0.0.0.0:30001->22/tcp net1
0.0.0.0:30007->22/tcp net4
0.0.0.0:30008->22/tcp net5
ตัวอย่างด้านบนให้คุณเชื่อมต่อกับ SSH ของคอนเทนเนอร์ 3 รายการ หากคุณใช้การแมปแบบหนึ่งต่อหนึ่ง เช่น พอร์ตโฮสต์และพอร์ตคอนเทนเนอร์เดียวกัน (เช่น 22:22) คุณจะถูกจำกัดให้มีเพียงคอนเทนเนอร์เดียวที่มีบริการเดียวที่รับฟัง นี่เป็นเหมือนเราเตอร์ที่บ้านของคุณ คุณจะต้องใช้พอร์ตที่แตกต่างกันสำหรับคอนเทนเนอร์ของคุณเพื่อให้สามารถใช้การแมปแบบหนึ่งต่อหนึ่งได้ แต่สิ่งนี้ทำให้เกิดความสับสน เนื่องจากคุณคาดหวังว่าบริการของคุณจะทำงานบนพอร์ตที่คาดเดาได้
จากตัวอย่างข้างต้น เราจะเห็นว่าเราสามารถมีสามคอนเทนเนอร์ที่ใช้ SSH ภายใน จากมุมมองคอนเทนเนอร์ จะเป็นพอร์ต 22 เสมอ จากภายนอก หมายเลขพอร์ตจะระบุคอนเทนเนอร์และบริการ และนี่กลายเป็นส่วนเดียวที่คุณต้องรู้โดยไม่ต้องกังวลกับสิ่งที่เกิดขึ้นเบื้องหลัง
ซึ่งหมายความว่าคุณสามารถกำหนดพอร์ตโฮสต์แบบไดนามิกเมื่อสร้างคอนเทนเนอร์ โดยใช้ตรรกะของสคริปต์บางประเภทหรือเช่นนั้น จากนั้นใช้ข้อมูลนั้นเพื่อระบุพอร์ตบริการของคุณ ดังนั้นโฮสต์ไปยังเครือข่ายคอนเทนเนอร์จึงกลายเป็นเรื่องที่เรียบง่ายและสง่างาม และคุณยังสามารถเชื่อมต่อจากโฮสต์ไปยังอีกโฮสต์หนึ่งได้อีกครั้งโดยไม่ต้องรู้ภูมิประเทศของคอนเทนเนอร์ล่วงหน้า
คอนเทนเนอร์โฮสต์เครือข่าย
นี่เป็นชิ้นส่วนที่ค่อนข้างน่าสนใจ คอนเทนเนอร์ของคุณอาจตอบสนองวัตถุประสงค์ที่มีอายุการใช้งานยาวนาน ดังนั้น คอนเทนเนอร์อาจต้องคงสภาพและทำงานต่อไปอีกสักระยะหนึ่ง ในทางกลับกัน หมายความว่าคุณอาจต้องบำรุงรักษาคอนเทนเนอร์ ซึ่งหมายถึงการอัปเกรด การแพตช์ การอัปเดตไฟล์โฮสต์ และอื่นๆ คุณยังอาจใช้เครื่องมือจัดการการกำหนดค่า เช่น Chef, Puppet หรือ Cfengine ดังนั้นจึงมีชิ้นส่วนนั้นด้วย
คำถามใหญ่ข้อแรกที่คุณต้องถามคือ ตู้คอนเทนเนอร์สามารถติดต่อกับโลกภายนอกได้หรือไม่? ก็ใช่ ในคำแนะนำเบื้องต้น เราดาวน์โหลดการอัปเดต CentOS โดยตรงจากแหล่งเก็บข้อมูลอย่างเป็นทางการ ดังนั้นเราจึงรู้ว่าส่วนนี้ใช้งานได้ดี ปิง docker0 เป็นอย่างไร:
คำถามที่สอง เราสามารถเข้าถึงอินเทอร์เฟซ docker0 แล้วเชื่อมต่อกับพอร์ตโฮสต์ได้หรือไม่ สมมติว่าเราได้รับข้อมูลที่จำเป็นแล้วภายในคอนเทนเนอร์
เทลเน็ต 172.17.42.1 49162
ลอง 172.17.42.1...
telnet:เชื่อมต่อกับที่อยู่ 172.17.42.1:ไม่มีเส้นทางไปยังโฮสต์
สิ่งนี้จะไม่ทำงาน เนื่องจากเราไม่ได้กำหนดค่าการส่งต่อ IP บนโฮสต์ของเรา ยิ่งไปกว่านั้น เราจำเป็นต้องมีกฎไฟร์วอลล์เพื่ออนุญาตการรับส่งข้อมูลที่จำเป็น ตรงนี้จะซับซ้อนเล็กน้อย เพราะถ้าคุณไม่คุ้นเคยกับ iptables คุณจะค่อนข้างลำบาก
เสียงสะท้อน 1> /proc/sys/net/ipv4/ip_forward
และกฎของ iptables - ชุดที่ค่อนข้างหละหลวม (เกี่ยวกับโฮสต์):
iptables -t ตัวกรอง -A FORWARD -d 172.17.0.0/16 \
-o นักเทียบท่า 0 -j ยอมรับ
iptables -t filter -A FORWARD -s 172.17.0.0/16 \
-i docker0 -j ยอมรับ
iptables -t filter -A FORWARD -i docker0 -o docker0 -j ยอมรับ
iptables -t nat -A โพสต์ -s 172.17.0.0/16 \
! -d 172.17.0.0/16 -p tcp -j MASQUERADE --to-ports 1016-65535 \
iptables -t nat -A โพสต์ -s 172.17.0.0/16
! -d 172.17.0.0/16 -p udp -j MASQUERADE --to-ports 1016-65535 \
iptables -t nat -A โพสต์ -s 172.17.0.0/16
! -d 172.17.0.0/16 -j สวมหน้ากาก
ทางเลือกที่ง่ายที่สุดคือปิดไฟร์วอลล์ - หรืออนุญาตทั้งหมด ซึ่งหมายถึงการเรียกใช้คำสั่งที่จำเป็น ซึ่งอาจเป็น systemctl stop firewalld, iptables -F หรือเทียบเท่า ในบางสถานการณ์ อาจเป็นไปไม่ได้ เนื่องจากคุณต้องการความปลอดภัยเป็นพิเศษ อย่างไรก็ตาม สิ่งนี้เชื่อมโยงกับกรณีการใช้งานแรกที่เราพูดถึงด้วย ตอนนี้ สมมติว่าคุณต้องสร้างกฎแบบแมนนวลสำหรับทุกคอนเทนเนอร์และบริการที่เกี่ยวข้อง
ด้วยกฎเครือข่ายที่เหมาะสม คุณจะสามารถเชื่อมต่อกับพอร์ตโฮสต์ได้ ซึ่งหมายถึงการพูดคุยกับคอนเทนเนอร์อื่นอย่างมีประสิทธิภาพ แม้ว่าในที่อยู่ IP หรือพอร์ตนั้นจะไม่มีสิ่งใดกำหนดให้เป้าหมายเป็นคอนเทนเนอร์อื่นก็ตาม นอกจากนี้ คุณยังสามารถเชื่อมต่อกับอุปกรณ์เครือข่ายอื่นๆ บนโฮสต์ หรือแม้แต่โฮสต์ระยะไกล
เครือข่ายคอนเทนเนอร์ต่อคอนเทนเนอร์
ชอบเพลง Ashes to Ashes ของ David Bowie เพียงแต่ไม่เจ๋งเท่า ดูเหมือนว่าจะเป็นสถานการณ์ที่มีประโยชน์ที่สุด อีกครั้ง เรามีสองทางเลือก เราสามารถลองเชื่อมต่อกับคอนเทนเนอร์อื่นโดยตรง หรือลองใช้พอร์ตที่แมปแบบไดนามิกของ docker0 เราจะโกง เราจะใช้โฮสต์และพอร์ตโฮสต์เป็นเกตเวย์เข้าสู่คอนเทนเนอร์ ตอนนี้วิธีแรกค่อนข้างตรงไปตรงมา ลอง ping net2 และ net3 จาก net1 กัน
มันใช้งานได้โดยไม่มีปัญหาใดๆ แต่ปัญหาคือเรารู้เกี่ยวกับที่อยู่ IP จากโลกภายนอก! เราไม่ได้รับข้อมูลนี้จากภายในคอนเทนเนอร์ อันที่จริง ด้วยเหตุผลด้านความปลอดภัยและความจริงที่ว่าคอนเทนเนอร์ฐานเป็นอิมเมจที่ค่อนข้างเล็ก คุณจึงไม่มีเครื่องมือเครือข่ายที่ยอดเยี่ยมโดยค่าเริ่มต้น คุณจะไม่มียูทิลิตี ifconfig ให้ใช้งาน นอกจากนี้ คุณไม่สามารถจัดการ iptables ภายในคอนเทนเนอร์ได้เช่นกัน:
iptables -L
iptables v1.4.21:ไม่สามารถเริ่มต้นตาราง iptables `ตัวกรอง':ปฏิเสธการอนุญาต (คุณต้องรูท)
อาจจำเป็นต้องอัปเกรด iptables หรือเคอร์เนลของคุณ
ดังนั้น วิธีที่สองในการเข้าถึง docker0 และการเชื่อมต่อกับพอร์ตโฮสต์อาจไม่สามารถทำได้จริงๆ เนื่องจากเราไม่สามารถควบคุมกฎไฟร์วอลล์ของโฮสต์ได้ ไม่ใช่จากภายในคอนเทนเนอร์ นี่คือเหตุผลที่เราจะพูดถึงวิธีที่สาม
ลิงค์คอนเทนเนอร์!
วิธีที่เหมาะสมในการทำเช่นนี้คือการใช้คุณลักษณะ --link สิ่งนี้หมายความว่า เราจะสร้างอินสแตนซ์ใหม่ในขณะที่เชื่อมโยงอินสแตนซ์กับคอนเทนเนอร์อื่นที่มีอยู่ ฟังก์ชันลิงก์จะแทรกชื่อโฮสต์และที่อยู่ IP ของคอนเทนเนอร์ที่เชื่อมโยงลงในสภาพแวดล้อมและไฟล์ /etc/hosts ของอินสแตนซ์ใหม่ อาจฟังดูสับสนเล็กน้อย ลองยกตัวอย่าง:
นักเทียบท่าเรียกใช้ -d -ti -p 80 --name web image-4:latest
8e689d8ae3ef43eeab3bfa9cf523e1cc6658dae5fc665f8cbf889db17db46c26
นักเทียบท่าตรวจสอบเว็บ | grep -i ipaddr
"ที่อยู่ IP":"172.17.0.9",
nc -w1 -v 172.17.0.9 80
Ncat:เวอร์ชัน 6.40 ( https://nmap.org/ncat )
Ncat:เชื่อมต่อกับ 172.17.0.9:80
เรามีคอนเทนเนอร์ทำงานอยู่ และควรจะเป็นเว็บเซิร์ฟเวอร์ ตอนนี้เราต้องการให้ลูกค้าสามารถเข้าถึงได้ เราต้องการใช้ชื่อเซิร์ฟเวอร์แทนที่อยู่ IP เนื่องจากเราอาจไม่มีความรู้มาก่อนเกี่ยวกับภูมิประเทศ นอกจากนี้ ชื่อยังมีประโยชน์เนื่องจากช่วยให้เราเปลี่ยนรูปแบบเครือข่ายได้ เรามาสร้างคอนเทนเนอร์ไคลเอนต์และเชื่อมโยงไปยังเว็บเซิร์ฟเวอร์ของเรา:
docker run -ti --name client --link web:web image-4:latest /bin/bash
สิ่งที่เรามีดังต่อไปนี้ เรากำลังสร้างลิงค์ของ source:target กล่าวอีกนัยหนึ่ง เซิร์ฟเวอร์ (คอนเทนเนอร์) ชื่อเว็บจะมองเห็นภายในคอนเทนเนอร์ใหม่ของเราที่ชื่อไคลเอ็นต์เป็นเว็บ หากคุณวางคอนเทนเนอร์และต่อเข้ากับคอนเทนเนอร์ คุณสามารถตรวจสอบสภาพแวดล้อมได้โดยการรันคำสั่ง env ในเชลล์ BASH:
WEB_PORT_80_TCP_PORT=80
WEB_PORT_80_TCP=tcp://172.17.0.9:80
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
พวด=/
WEB_PORT_22_TCP_ADDR=172.17.0.9
container_uuid=558a9db0-6d1e-d9d2-b62d-a8dbfbad0b2d
WEB_PORT_22_TCP=tcp://172.17.0.9:22
SHLVL=1
หน้าแรก=/ราก
WEB_NAME=/ลูกค้า/เว็บ
WEB_PORT_80_TCP_PROTO=tcp
WEB_PORT_80_TCP_ADDR=172.17.0.9
LESSOPEN=||/usr/bin/lesspipe.sh %s
WEB_PORT=tcp://172.17.0.9:22
_=/usr/bin/env
เนื่องจากการแมปชื่อเดียวกันอาจทำให้เกิดความสับสน มาลองแมปอื่น:
docker run -ti --name client --link web:dedoimedo image-4:latest /bin/bash
แล้วเราจะได้:
อีกทางหนึ่ง หากคุณกำลังวางไข่คอนเทนเนอร์ที่ต้องเป็นคนทำงานด่วน คุณอาจต้องการสร้างมันโดยใช้ตัวเลือก run --rm สำหรับงานที่มีอายุสั้น ไม่มีเหตุผลใดที่จะต้องเก็บไฟล์คอนเทนเนอร์ไว้ในดิสก์ และคุณสามารถทำให้ Docker ล้างไฟล์เหล่านั้นได้โดยอัตโนมัติ อ่านเอกสารอย่างเป็นทางการ:
ตามค่าเริ่มต้น ระบบไฟล์ของคอนเทนเนอร์จะคงอยู่แม้หลังจากที่คอนเทนเนอร์ออกจากระบบแล้ว วิธีนี้ทำให้การดีบักง่ายขึ้นมาก (เนื่องจากคุณสามารถตรวจสอบสถานะสุดท้ายได้) และคุณเก็บข้อมูลทั้งหมดไว้ตามค่าเริ่มต้น แต่ถ้าคุณกำลังเรียกใช้กระบวนการเบื้องหน้าในระยะสั้น ระบบไฟล์คอนเทนเนอร์เหล่านี้สามารถกองพะเนินได้ หากคุณต้องการให้ Docker ล้างคอนเทนเนอร์โดยอัตโนมัติและลบระบบไฟล์เมื่อออกจากคอนเทนเนอร์ คุณสามารถเพิ่มแฟล็ก --rm
นักเทียบท่าเรียกใช้ --rm -ti --ชื่อไคลเอ็นต์ --link เว็บ:dedoimedo image-4:latest /bin/bash
ไฟล์โฮสต์
ข้อดีประการที่สองเกี่ยวกับฟังก์ชันลิงก์คือคอนเทนเนอร์ใหม่จะมีไฟล์ /etc/hosts บรรจุชื่อที่จำเป็นโดยอัตโนมัติ ดังนั้นคุณก็พร้อมสำหรับการรักษา ซึ่งจะมีลักษณะดังนี้ โดยลบรายการ IPv6:
[root@e1e92f6918dd /]# cat /etc/hosts
172.17.0.11 e1e92f6918dd
127.0.0.1 โลคัลโฮสต์
เว็บ 172.17.0.9 dedoimedo 8e689d8ae3ef
เชื่อมต่อกับเซิร์ฟเวอร์โดยใช้ชื่อ
และเนื่องจากเรามีการแก้ไขชื่อโฮสต์และการตั้งค่าสภาพแวดล้อม มันจึงกลายเป็นเหมือนเครือข่ายทุกที่ เรียบง่าย น่าจดจำ และที่สำคัญที่สุดคือมีสคริปต์
อ่านเพิ่มเติม
หากคุณคิดว่าคุณยังสนุกไม่พอ:
คู่มือการเชื่อมต่อเครือข่ายขั้นสูงของนักเทียบท่า
สรุป
ไปแล้ว อีกหัวข้อที่น่ากลัวทำให้เข้าใจยาก ประเด็นก็คือ ฉันเชื่อว่าความท้าทายที่ยิ่งใหญ่ที่สุดที่คุณจะต้องเผชิญเมื่อทำงานกับคอนเทนเนอร์ Docker คือการกำหนดค่าของกฎไฟร์วอลล์แทนที่จะเป็นส่วนประกอบสำคัญของชิ้นส่วนเครือข่ายของเทคโนโลยีนี้ แต่เมื่อเริ่มชินแล้ว มันก็ไม่ได้ยากหรือซับซ้อนอะไรมากมาย
เราได้เห็นวิธีเริ่มต้นคอนเทนเนอร์และเปิดเผยพอร์ต ใช้โฮสต์กับคอนเทนเนอร์ คอนเทนเนอร์ต่อโฮสต์ และคอนเทนเนอร์ต่อเครือข่ายคอนเทนเนอร์ ตั้งค่าการส่งต่อ และใช้ลิงก์เพื่อทำให้ชีวิตของเราง่ายขึ้นและคาดการณ์ได้มาก สรุปแล้วมันเป็นคำแนะนำที่ยุ่ง แต่หวังว่าจะเป็นประโยชน์ อีกครั้ง หากคุณมีหัวข้ออื่น ๆ โปรดอย่าลังเลที่จะแนะนำพวกเขา และเราทำเสร็จแล้ว
ป.ล. ถ้าคุณชอบบทความนี้ คุณควรมอบความรักให้กับ Dedoimedo บ้าง!
ไชโย
