Lecture 2 — Container & Docker

คาบนี้จะพาไปไหนบ้าง

สไลด์บอกไว้ตรง ๆ ว่าคาบนี้ ถือว่าคุณเคยเจอ container และ Docker มาแล้ว จากวิชา Operating Systems และ Software Engineering II คาบนี้จึงไม่ได้สอนซ้ำแบบผิวเผิน แต่ลงไปดูว่ามันทำงานยังไงข้างใน

หัวข้อที่สไลด์วางไว้มีสี่เรื่อง

หน้านี้เดินตามลำดับสไลด์ คือ พื้นฐาน → Docker → คำสั่ง → ที่เก็บข้อมูล → เครือข่าย → ตัวอย่างรวมท้ายคาบ

ปัญหาที่ container เกิดมาแก้

คำถามของทั้งคาบนี้จึงมีประโยคเดียว

เขียนโปรแกรมครั้งเดียว แล้วทำยังไงให้มันรันได้เหมือนกันทุกที่?

ของที่มีอยู่แล้วสองอย่าง: machine abstraction กับ process abstraction

ก่อนจะประดิษฐ์ของใหม่ ต้องดูก่อนว่าวิทยาการคอมพิวเตอร์มีของอะไรใกล้เคียงอยู่แล้ว สไลด์แบ่ง Abstraction (การซ่อนรายละเอียดข้างใต้ไว้ แล้วยื่นหน้าตาที่ง่ายกว่าให้ใช้) ในคอมพิวเตอร์ออกเป็นสองสาย

สองสายนี้แก้คนละปัญหา สายซ้ายแก้เรื่องย้ายเครื่อง สายขวาแก้เรื่องอยู่ร่วมกัน

แล้วอันไหนแก้ปัญหาของเราได้

สไลด์สรุปทางเลือกไว้ประโยคเดียว

แนวคิด process มีแวว แค่ต้องแก้สองเรื่องคือ การแยกขาดจากกัน และ การย้ายเครื่อง

container คือคำตอบของประโยคนี้ ไม่ใช่เทคโนโลยีใหม่ทั้งดุ้น แต่คือ process ที่ถูกอุดสองรูนี้

สามอย่างที่ Linux มีอยู่ก่อนแล้ว

การอุดสองรูข้างบนไม่ต้องเขียนของใหม่เลย Linux มีเครื่องมือครบอยู่แล้วสามชิ้น

ชั้น Libcontainer ในรูปคือไลบรารีที่ Docker ใช้เรียกความสามารถทั้งสามอย่างของ kernel แทนที่จะเรียกเองตรง ๆ ส่วน Docker Daemon คือตัวที่รับคำสั่งจากผู้ใช้

จำภาพนี้ไว้ เพราะทุกอย่างที่เหลือในคาบนี้คือรายละเอียดของสามกล่องล่าง

Isolation: แยกด้วย namespace

Isolation (การแยกส่วนประกอบของระบบออกจากกันและป้องกันไม่ให้กวนกัน) ในความหมายของสไลด์คือการทำให้ส่วนต่าง ๆ ของระบบแยกกันและกันไม่ให้เข้าถึงกัน

VM ทำ isolation ระดับสูงสุด เพราะมันสร้างระบบปฏิบัติการครบชุดขึ้นมาทับฮาร์ดแวร์ของ host แต่มันแลกมาด้วยขนาดและความช้า

ส่วน process ธรรมดา แยกอะไรไปแล้วบ้างและยังไม่ได้แยกอะไร

namespace คือของที่มาอุดคอลัมน์ขวา

namespace คืออะไร

ทรัพยากรของระบบทั้งหมดถูกซอยเป็นส่วน ๆ เรียกว่า namespace แต่ละ namespace มี ชุดตัวระบุ (identifier) ของตัวเอง ตัวระบุตัวเดียวกันที่อยู่คนละ namespace จะหมายถึงคนละของ

process แต่ละตัวผูกอยู่กับ namespace หนึ่ง และเห็นได้เฉพาะทรัพยากรใน namespace นั้น ผลคือ process ที่อยู่ namespace เดียวกันจะรู้สึกว่าตัวเองมีทรัพยากรเป็นของตัวเองทั้งชุด

namespace มีกี่ชนิด

docker run -it ubuntu
root@b9f6fed68de7:/# top

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1 root      20   0   18504   3260   2840 S   0.0   0.2   0:00.04 bash
   11 root      20   0   36640   3096   2620 R   0.0   0.2   0:00.02 top

root     27474  0.0  0.1  36640  3096 pts/0    S+   08:48   0:00 top

Resource control: จำกัดด้วย cgroups

กลไก Control Group (cgroup) (กลุ่มควบคุมทรัพยากร) ให้เราคุม CPU หน่วยความจำ และ I/O ได้ละเอียด วิธีทำงานคือ จับ process มารวมกลุ่ม แล้วบังคับนโยบายหรือเพดานการใช้ทรัพยากรกับทั้งกลุ่ม ผลคือไม่มี process กลุ่มไหนใช้เกินที่จัดสรรไว้ ซึ่งจำเป็นมากกับสมรรถนะ ความเสถียร และสภาพแวดล้อมที่มีหลายผู้เช่าอยู่ร่วมกัน

เพดานเก็บไว้ที่ไหน

เพดานทรัพยากรถูกเขียนเป็นไฟล์ในระบบไฟล์ของ cgroup

• บน host: /sys/fs/cgroup/docker/ โดยมีโฟลเดอร์ย่อยหนึ่งอันต่อหนึ่ง container ชื่อโฟลเดอร์คือ container ID เต็ม
• ใน container แต่ละตัว: /sys/fs/cgroup/

docker run --rm -d --name big   --cpus=1   --memory=512m alpine sh -c 'yes >/dev/null'
docker run --rm -d --name small --cpus=0.5 --memory=256m alpine sh -c 'yes >/dev/null'

$ docker exec big   cat /sys/fs/cgroup/cpu.max
100000 100000
$ docker exec small cat /sys/fs/cgroup/cpu.max
50000 100000

$ docker exec big   cat /sys/fs/cgroup/memory.max
536870912
$ docker exec small cat /sys/fs/cgroup/memory.max
268435456

CONTAINER ID   NAME    CPU %    MEM USAGE / LIMIT     MEM %
d0f24fbd0b9c   small   49.65%   1.047MiB / 256MiB     0.41%
93f4593622f7   big     98.66%   760KiB / 512MiB       0.14%

เพดาน กับ ส่วนแบ่ง ไม่ใช่เรื่องเดียวกัน

cgroup มีค่าสองตัวที่คนสับสนกันบ่อย

• cpu.max คือ เพดาน — ใช้ได้มากที่สุดเท่านี้ ต่อให้เครื่องว่างก็ไม่เกิน
• cpu.weight คือ ส่วนแบ่ง — มีผลเฉพาะตอนแย่ง CPU กันเท่านั้น ถ้าไม่มีใครแย่ง ก็ใช้ได้เต็มที่

docker run --rm -d --name big   --cpuset-cpus=0 --cpu-shares=1024 alpine sh -c 'yes >/dev/null'
docker run --rm -d --name small --cpuset-cpus=0 --cpu-shares=512  alpine sh -c 'yes >/dev/null'

$ docker exec small cat /sys/fs/cgroup/cpu.weight
59
$ docker exec big   cat /sys/fs/cgroup/cpu.weight
100

CONTAINER ID   NAME    CPU %
a537634c2bf1   small   36.53%
e817da98c2c5   big     62.18%

image กับ container ต่างกันยังไง

Image (แม่พิมพ์ของโปรแกรม) คือแพ็กเกจที่รันได้ซึ่งบรรจุทุกอย่างที่โปรแกรมต้องใช้ ได้แก่ โค้ด ไลบรารีที่มันพึ่งพา (เรียกรวมว่า Dependencies (ของที่โปรแกรมต้องมีถึงจะรันได้)) ไฟล์ตั้งค่า และตัวแปรสภาพแวดล้อม

Container (ของที่รันอยู่จริงหนึ่งชุด) คือหนึ่งครั้งของการรัน image นั้น

ความสัมพันธ์นี้เทียบได้ตรง ๆ กับของที่คุณรู้จักอยู่แล้ว

image ต่อ container = program ต่อ process

ทำไมระบบไฟล์ธรรมดาไม่พอ

Union File System (ระบบไฟล์แบบซ้อนชั้น) คือระบบไฟล์ที่เอาไฟล์และโฟลเดอร์จากหลายระบบไฟล์มาวางซ้อนกันเป็นชั้น ๆ แล้วทำให้ดูเหมือนเป็นระบบไฟล์เดียว แต่ละชั้นเป็นแบบอ่านอย่างเดียวหรืออ่านเขียนได้ก็ได้ จึงแก้บางชั้นโดยไม่แตะชั้นอื่นได้ ตัวอย่างที่ใช้จริงคือ Overlay2, AUFS และ Btrfs

image ของ container ถูกเก็บแบบนี้ ชั้นที่ใช้ร่วมกันเป็นแบบอ่านอย่างเดียวและแชร์กันได้ทุก container จึงไม่มีการเก็บซ้ำ

copy-on-write

ความสามารถสำคัญที่ทำให้ทั้งหมดนี้เป็นไปได้เรียกว่า Copy-on-Write (ก๊อปตอนจะเขียนเท่านั้น)

Docker

Docker (แพลตฟอร์มสำหรับสร้างและรัน container) คือแพลตฟอร์มที่ให้นักพัฒนา พัฒนา ส่งมอบ และรัน โปรแกรมด้วย container ของ Linux

จุดที่ต้องรู้ก่อนใช้งานจริง — Docker for Mac และ Docker for Windows ไม่ได้รัน container บน macOS หรือ Windows ตรง ๆ แต่ยกเครื่อง Linux เสมือนขึ้นมาหนึ่งตัวแล้วรัน container ข้างในนั้น เพราะ container ต้องใช้ความสามารถของ Linux kernel

สิ่งที่ Docker เปลี่ยนไปจริง ๆ มีสองข้อ

• Standardization — เปลี่ยนการตั้งค่าเซิร์ฟเวอร์ที่เละและทำซ้ำไม่ได้ ให้กลายเป็นรูปแบบที่ย้ายที่ได้ คือ Dockerfile และ container image
• ไม่มีคำว่า "เครื่องผมรันได้นะ" อีก — เพราะไลบรารีและไฟล์ไบนารีถูกมัดไปพร้อมโค้ดเลย พฤติกรรมบนโน้ตบุ๊กกับบนเซิร์ฟเวอร์จริงจึงเหมือนกัน

VM กับ container ต่างกันตรงไหนแน่

สองอย่างนี้ใช้ด้วยกันก็ได้

สไลด์ยกไว้สองแบบ

• Docker without VM — Docker Engine วางบนระบบปฏิบัติการที่วางบนเครื่องจริงเลย ทุก container แชร์ kernel เดียวกันหมด
• Docker with VMs — hypervisor แบ่งเครื่องจริงเป็นหลาย VM ก่อน แล้วค่อยลง Docker Engine ในบาง VM ส่วน VM อื่นรันโปรแกรมแบบปกติ

แบบหลังคือสิ่งที่ผู้ให้บริการคลาวด์ทำ: ผู้เช่าแต่ละรายได้ VM ของตัวเอง (แยกขาดจากผู้เช่าอื่น) แล้วในนั้นผู้เช่าจะรัน container กี่ตัวก็เรื่องของเขา

Docker Engine ประกอบด้วยอะไร

เวลาพิมพ์ docker run สิ่งที่เกิดขึ้นคือ CLI แปลงคำสั่งเป็นคำขอ REST API ส่งไปให้ daemon แล้ว daemon เป็นคนสร้าง container จริง ๆ ตัว daemon นี่เองที่ถือครองและจัดการ container, image, network และ data volume ทั้งหมด

image ของ Docker และการแบ่งชั้น

Docker image คือ แม่แบบแบบอ่านอย่างเดียว สำหรับสร้าง container กฎที่ต้องจำมีสี่ข้อ

1. Docker ใช้ union file system รวมหลายชั้นให้กลายเป็น image เดียว
2. ชั้นล่างสุดเรียกว่า Base Image (ชั้นฐาน) ซึ่งกำหนดสภาพแวดล้อมตอนรัน เช่น ubuntu หรือ alpine
3. ตอน build ชั้นใหม่จะถูกเขียนทับซ้อนขึ้นไปเรื่อย ๆ ชั้นเหล่านี้เปลี่ยนไม่ได้และแชร์กันได้
4. ตอนสร้าง container จาก image ระบบจะเอาระบบไฟล์แบบอ่านเขียนได้มา mount ทับด้านบนอีกหนึ่งชั้น

จุดที่ทำให้ระบบนี้ประหยัดพื้นที่คือ แต่ละชั้นมีลิงก์ชี้ไปชั้นที่อยู่ล่างกว่า เวลาดึง image มา Docker จึงตามลิงก์ไปดึงครบทุกชั้นได้ และชั้นล่างชั้นเดียวกันถูกใช้ร่วมได้โดย image หลายอัน

Registry: ที่เก็บและแจกจ่าย image

Registry (คลังเก็บและแจกจ่าย image) คือระบบเก็บและส่งมอบเนื้อหาที่ถือ Docker image ที่มีชื่อเอาไว้ Docker ดูแล registry สาธารณะชื่อ Docker Hub และผู้ให้บริการรายอื่นก็มี registry ของตัวเองสำหรับ image คนละกลุ่ม

สไลด์แบ่ง registry เป็นสองฝั่ง

ชื่อ image อ่านยังไง

ชื่อเต็มของ image มีรูปแบบเดียว

registry/username/image_name:tag

ส่วนไหนไม่ได้เขียน Docker เติมค่าปริยายให้ ดังนั้น

docker pull hello-world
# เป็นทางลัดของ
docker pull docker.io/library/hello-world:latest

บน Docker Hub มีกติกาตั้งชื่อสองแบบ

• image ทางการ ใช้แค่ชื่อ เช่น ubuntu, hello-world
• image ของคนอื่น ต้องมีชื่อเจ้าของนำหน้า เช่น ubuntu/nginx, grafana/grafana, prom/node-exporter

สามงานพื้นฐานของ Docker

ทุกอย่างที่ Docker ทำ ย่อลงมาได้เป็นสามเส้นทางระหว่าง client, host และ registry

docker run ทำอะไรตามลำดับ

$ docker image ls
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE

$ docker run hello-world
Unable to find image 'hello-world:latest' locally
Status: Downloaded newer image for hello-world:latest

Hello from Docker!

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
1b930d010525: Pull complete
Digest: sha256:b8ba256769a0ac28dd126d584e0a2011cd2877f3f76e093a7ae560f2a5301c00
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

คำสั่งที่ต้องใช้จริง

ชุดพื้นฐาน

## ดูรายการคำสั่งทั้งหมด
docker
docker COMMAND --help

## ดึง image จาก registry
docker pull IMAGE

## รัน image (สร้าง container) — ใส่ COMMAND เพื่อทับคำสั่งปริยายของ image ได้
docker run IMAGE [COMMAND]
docker run --name NAME IMAGE [COMMAND]

## ดูรายการ image
docker image ls          # เท่ากับ docker images
docker image ls --all    # เท่ากับ docker images -a

## ดูรายการ container
docker container ls          # เท่ากับ docker ps
docker container ls --all    # เท่ากับ docker ps -a

ตัวเลือกของ docker run ที่ใช้บ่อยที่สุด

docker run [OPTIONS] IMAGE [COMMAND] [ARGS]

container "Hello World" ที่เล็กที่สุดคือ

docker run ubuntu /bin/echo 'Hello world'

docker run กับ docker exec ไม่เหมือนกัน

$ docker run --detach --tty --name ubuntu ubuntu
b91555fadae3c5f1cd65b4625528e900c8677babd59c50196771ea2216181ed7
$ docker exec ubuntu hostname
b91555fadae3
$ docker exec -it ubuntu bash
root@b91555fadae3:/# ls
bin  boot  dev  etc  home  lib  ...

หยุด เริ่มใหม่ และลบ

docker start จะรัน คำสั่งเดิม ที่ใช้ตอนสร้าง container นั้น ซึ่งก็คือ CMD ใน Dockerfile หรือ COMMAND ที่ใส่ต่อท้าย docker run ถ้าอยากรู้ว่าคำสั่งนั้นคืออะไร ให้ดูส่วน Config จาก docker inspect CONTAINER

ลบทีเดียวหลายตัว

docker container rm $(docker container ls --all --quiet)
# เขียนสั้นได้เป็น
docker rm $(docker ps -a -q)

ดูว่าเปลี่ยนอะไรไปบ้าง แล้วแช่ให้เป็น image ใหม่

$ docker run -it ubuntu
root@f33b176d0054:/# ifconfig
bash: ifconfig: command not found
root@f33b176d0054:/# apt update
root@f33b176d0054:/# apt install net-tools
root@f33b176d0054:/# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.3  netmask 255.255.0.0  broadcast 172.17.255.255

$ docker diff f33b176d0054
C /sbin
A /sbin/mii-tool
A /sbin/slattach
A /sbin/ifconfig

$ docker commit f33b176d0054 ubuntu-nettools
sha256:2eca02e842367861f911c06c5f9a09be398b5554b3c037b12d5074439d4b18dc
$ docker images
REPOSITORY        TAG      IMAGE ID       CREATED          SIZE
ubuntu-nettools   latest   2eca02e84236   8 seconds ago    103MB

ลบ image และเก็บกวาด

## ลบ image หนึ่งอัน — container ทุกตัวที่รันจาก image นี้ต้องถูกลบก่อน
docker image rm IMAGE

## ลบ image ทั้งหมด
docker image rm $(docker image ls -q)

Dangling Image (image ที่ไม่มีชื่อเหลืออยู่) คือ image ที่ไม่ได้ใช้และไม่มีชื่อกับ tag แล้ว มันเกิดตอนที่ image ชื่อและ tag เดิมถูกเขียนทับด้วย image ใหม่ ตัวเก่าจึงกลายเป็น <none>:<none> แต่ยังกินพื้นที่อยู่

## หา
docker image ls -f "dangling=true"

## ลบทั้งหมด
docker image rm $(docker image ls -f "dangling=true" -q)

มีคำสั่งกวาดแบบสั้นให้ด้วย

docker container prune   # ลบ container ที่หยุดแล้วทั้งหมด
docker image prune       # ลบ image ที่ไม่ได้ใช้

ส่ง image ขึ้น registry

docker run -d -p 5000:5000 --name registry registry

คำสั่งไว้ส่องและตรวจปัญหา

docker inspect แสดงข้อมูลระดับล่างของอ็อบเจ็กต์ทุกชนิดของ Docker ทั้ง image, container, network และ volume

docker inspect [OPTIONS] NAME|ID

## ดึงเฉพาะค่าที่ต้องการด้วย --format
docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 44407e86ac38
172.17.0.2

ชุดคำสั่งสำหรับดูว่าเกิดอะไรขึ้นข้างใน

docker top CONTAINER          # process ที่กำลังรันใน container
docker logs CONTAINER         # log ที่ container พ่นออกมา
docker exec -it CONTAINER bash # เปิด shell เข้าไปดูเอง
docker stats                  # การใช้ทรัพยากรแบบสด ๆ ของทุก container

Persistent Storage: ทำยังไงให้ไฟล์ไม่หาย

Docker ให้สองวิธีในการฝากไฟล์ไว้นอก container

วิธีที่ 1: Bind Mount

ผูกโฟลเดอร์ของ host เข้ากับโฟลเดอร์ใน container ตรง ๆ

docker run -v [host_directory]:[container_directory] IMAGE

$ ls /home/veera/container/
                                     # ว่างเปล่า
$ docker run --name ubuntu -it -v /home/veera/container:/home ubuntu
root@3cfc393b56a3:/# cat > /home/test.txt
test
root@3cfc393b56a3:/# exit

$ docker rm ubuntu
ubuntu
$ cat /home/veera/container/test.txt
test

วิธีที่ 2: Volume Mapping

Volume (พื้นที่เก็บข้อมูลที่ Docker สร้างและดูแลให้) คือที่เก็บข้อมูลถาวรที่ถูกสร้างขึ้นนอก container เก็บอยู่ในระบบไฟล์ของ host แต่ Docker เป็นคนจัดการให้ สไลด์แนะนำให้ใช้วิธีนี้เป็นหลัก เพราะย้ายที่ได้ง่ายกว่า

docker volume create myvol
docker run -v [volume]:[container_directory] IMAGE

$ docker volume create myvol
myvol
$ docker volume ls
DRIVER    VOLUME NAME
local     myvol
$ docker volume inspect myvol
        "Mountpoint": "/var/lib/docker/volumes/myvol/_data",

[
    {
        "CreatedAt": "2019-09-16T00:01:18+07:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/myvol/_data",
        "Name": "myvol",
        "Options": {},
        "Scope": "local"
    }
]

$ docker run --name ubuntu -it -v myvol:/home ubuntu
root@c376a358e77a:/# cat > /home/test
test
root@c376a358e77a:/# exit
$ docker rm ubuntu
ubuntu
$ sudo cat /var/lib/docker/volumes/myvol/_data/test
test

Docker Networking

container ทุกตัวได้ IP มาเองอัตโนมัติ

$ docker container inspect nginx | grep IPAddress
        "SecondaryIPAddresses": null,
        "IPAddress": "172.17.0.2",

เปิดพอร์ตให้โลกภายนอกเข้าถึง

docker run -p [host_port]:[container_port] IMAGE
docker run -p [container_port] IMAGE          # ให้ Docker สุ่มพอร์ตฝั่ง host ให้

$ docker run -d --name nginx -p 4000:80 nginx
533898a25687d5cda2911b935053c9740d646984d99025e2e2a3254b7f1bd6b4
$ docker ps
CONTAINER ID   IMAGE   COMMAND                  PORTS
533898a25687   nginx   "/docker-entrypoint.…"   0.0.0.0:4000->80/tcp, :::4000->80/tcp

# 1. จากเครื่อง host ผ่านพอร์ต 4000
$ curl localhost:4000
<title>Welcome to nginx!</title>

# 2. จากข้างใน container เดียวกัน ผ่านพอร์ต 80
$ docker exec -it nginx bash
root@0f5e4c2df1fb:/# curl localhost:80
<title>Welcome to nginx!</title>

ภาพรวมสามชั้นของที่อยู่

สไลด์ใช้ container ตัวช่วยตัวหนึ่งชื่อ ubuntu_tools ในการทดลอง มันคือ ubuntu ที่ลงเครื่องมือเครือข่ายเพิ่มไว้

FROM ubuntu
# add tools
RUN apt-get update
RUN apt-get install -y iputils-ping
RUN apt-get install -y net-tools
RUN apt-get install -y iproute2
RUN apt-get install -y curl
CMD ["bash"]

root@863d667ab61d:/# curl 172.17.0.2:80
<title>Welcome to nginx!</title>

root@863d667ab61d:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.238 ms

ปัญหา: container ไม่รู้จักกันด้วยชื่อ

พอลองเรียกด้วยชื่อแทน IP กลับพัง

root@863d667ab61d:/# curl nginx:80
curl: (6) Could not resolve host: nginx

root@863d667ab61d:/# curl 9dc8ed7ab142:80
curl: (6) Could not resolve host: 9dc8ed7ab142
root@863d667ab61d:/# ping 9dc8ed7ab142
ping: 9dc8ed7ab142: Name or service not known

เหตุผลอยู่ในไฟล์ /etc/hosts ของ container ซึ่งเก็บการจับคู่ IP กับชื่อเครื่อง

root@863d667ab61d:/# cat /etc/hosts
127.0.0.1       localhost
172.17.0.3      863d667ab61d

มีแต่ชื่อของตัวเอง ไม่มีบรรทัดของ nginx เลย

127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3      863d667ab61d

Bridge network

Bridge Network (เครือข่ายสะพานภายในเครื่อง) คือเครือข่ายที่ทำให้ container ที่ต่ออยู่บน bridge เดียวกันคุยกันได้ ส่วน container ที่อยู่คนละ bridge จะคุยกันตรง ๆ ไม่ได้

กฎที่ต้องรู้

• Docker สร้าง bridge ปริยายชื่อ bridge ให้อัตโนมัติตอนเริ่มทำงาน
• container ที่สร้างใหม่จะต่อเข้ากับ bridge นี้เอง ถ้าไม่ระบุอย่างอื่น
• bridge network ใช้ได้เฉพาะ container ที่อยู่บน Docker daemon เครื่องเดียวกัน

$ docker network inspect bridge
        "Subnet": "172.17.0.0/16",
        "Gateway": "172.17.0.1"
        ...
        "Containers": {
            "863d667ab61d...": { "Name": "ubuntu_tools", "IPv4Address": "172.17.0.3/16" },
            "9dc8ed7ab142...": { "Name": "nginx",        "IPv4Address": "172.17.0.2/16" }
        }

ทางแก้: สร้าง bridge ของตัวเอง

ความต่างมีข้อเดียว แต่เป็นข้อที่เปลี่ยนทุกอย่าง

$ docker network create mynet
045e8187e372b7778af6d8517a096e52032ca69605b23dc65055187801023090
$ docker network ls
NETWORK ID     NAME     DRIVER   SCOPE
08d98d8ae48b   bridge   bridge   local
e1eeed546e58   host     host     local
045e8187e372   mynet    bridge   local
731053211c6d   none     null     local

ใช้หลายเครือข่ายเพื่อกันไม่ให้ของหลังบ้านโดนเข้าถึง

docker network create backend-network
docker network create frontend-network

docker run -d --name backend-app --network backend-network my-backend-app

docker run -d --name frontend-app --network frontend-network \
  --network backend-network -p 80:80 my-frontend-app

ตัวอย่างรวม: ระบบเฝ้าดูทรัพยากรใน 3 container

ท้ายคาบสไลด์ประกอบทุกอย่างที่ผ่านมาเป็นระบบเดียว — เครือข่ายที่สร้างเอง การเปิดพอร์ต การ mount ไฟล์ตั้งค่า และ volume

docker run --rm -d -p 9100:9100 --network mynet --name node-exporter prom/node-exporter

# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 8