Docker¶

VM vs Docker vs Serverless¶

VM vs Docker vs Serverless

Docker Core Tech¶

Linux Namespace (Isolation)¶

Linux Namespace

Pid: Processes in a PID namespace are isolated from those in other namespaces, allowing for the same PID to be used in different namespaces.s
net: Each namespace has its own network devices, IP Addressed, IP routing tables, /proc/net, etc, providing network isolation.
ipc: Interprocess communication (IPC) resources like message queues, semaphores, and shared memory segments are isolated.
mnt: the processes in different namespaces see different directory structure, allowing for distinct filesystem views.
uts: UTS ("UNIX Time-sharing System") allows each container has its own hostname and domain name, making it appear as an independent network node.
user: user and group IDs in a container are isolated from other containers. Application in a Container is run by the user inside the container.

# look up the namespaces of current system
lsns -t <ns type>

# look up the name space of one process
ls -la /proc/$pid/ns/

# go into a namespace and run command
nsenter -t $pid -n ip addr

Linux CGroups (Control resources)¶

Linux CGroups

Cgroups (Control Ggroups) measure and assign compute resources using various subsystems:

blkio: Control IO (input/output) speed for block devices, such as hard disk, optical disk, USB, etc.
cpu: Provide CPU access and quota.
cpuacct: Generate report of CPU usage of the cgroup tasks.
cpuset: In case of multi CPUs, assign specific CPU and memory (binding) to the cgroup tasks.
devices: Control access of devices for the cgroup tasks.
freezer: Pause and resume cgroup task.
memory: limit and report memory usage.
net_cls: net_cls (network classifier) to classify and prioritize network traffic on a per-cgroup basis, enabling fine-grained control over network resource allocation and usage.
ns: Manage namespaces.
pid: Limit the number of processes.

# lookup cgroup
ls /sys/fs/cgroup

# goto cpu subsystem
cd /sys/fs/cgroup/cpu

# add pid into cgroup for control
echo $pid > cgroup.procs

# goto memory subsystem
cd /sys/fs/cgroup/memory

# Watch usage or memory
watch 'ps -aux | grep <process name> | grep -v grep'

OverlayFS¶

OverlayFS is one of Union FS systems that allows the merging of multiple directories (layers) into a single virtual filesystem. OverlayFS supports features like copy-on-write, enabling efficient file modifications and storage usage.

Docker OverlayFS

# mount overlay file directories
sudo mount -t overlay overlay -0 lowerdir=`pwd`/lower,upperdir=`pwd`/upper,workdir=`pwd`
/work `pwd`/merged

Docker Network¶

Docker Network Mode¶

Mode	Description	Use Case Example
Null(--net=None)	Put container into a network namespace without configuration, user can configure network using `docker network` command for their own requirement.	Delegate Kubernetes configure it.
Host	Share the host's network, placing the container in the same network as host's.	Container can access directly the host for management.
Container	Share a network namespace with other container.	Containers started by docker compose.
Bridge(--net=bridge)	Communicate with each other using Linux bridge and iptables. Docker setups a bridge named `docker0` on a node, each endpoint is connected through veth pair on this node.	Docker default network mode.

Docker Network Bridge

# Lookup the container's pid
docker inspect <docker id (net=none)> | grep -i pid
export pid=<PID>

# Create ns for the container 
nsenter -t $pid -n ip a
ln -s /proc/$pid/ns/net /var/run/netns/$pid
ip netns list

# create a veth link from A to B
ip link add A type veth peer name B

# set docker0 as A
brctl addif docker0 A
ip link set A up

# set the container's ns as B
ip link set B netns $pid

# Prepare ip config for B
SETIP=172.17.0.2
SETMASK=16
GATEWAY=172.17.0.1

# Inside B, setup config
ip netns exec $pid ip link set dev B name eth0
ip netns exec $pid ip link set eth0 up
ip netns exec $pid ip addr add $SETIP/$SETMASK dev eth0
ip netns exec $pid ip route add default via $GETEWAY

# Check network config again
nsenter -t $pid -n ip addr

Cross Node Communication¶

Underlay: Containers communicate over this existing network of the underlying infrastructure using traditional IP routing and switching. The Ip can be seen and accessed directly by infrastructure.
Use case: Suitable for simple, small-scale deployments where physical network configuration can suffice, because there is no container network and it requires a lot of ip addresses from infrastructure.
Overlay: It uses encapsulation techniques like VXLAN to create isolated virtual networks. Containers has their own virtual network, which is different from the underlay network. Packages will be wrapped and translated, allowing containers on different nodes to communicate as if they were on the same network.
Use case: Ideal for large-scale, dynamic environment such as Kubernetes clusters, where network isolation and flexible management are required.