Docker Networking Basics

Docker overview:

Docker is an open source project to pack, ship and run any application as a lightweight container. The idea is to provide a comprehensive abstraction layer that allows developers to containerize or package any application and have it run on any infrastructure.

Docker leverages LXC (Linux Containers), which encompasses Linux features like cgroups and namespaces for strong process isolation and resource control.

Terminologies:

IP: An Internet Protocol address (IP address) is a numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication

Virtual IP: A virtual IP address (VIP or VIPA) is an IP address that doesn’t correspond to an actual physical network interface (port). Uses for VIPs include Network Address Translation (especially, One-to-many NAT), fault-tolerance, and mobility.
Bridge: A bridge device filters traffic at a network boundary. It works at data link layer and decides whether packets should forward or discard.
LXC: LXC (Linux Containers) is an operating-system-level virtualization environment for running multiple isolated Linux systems (containers) on a single Linux control host.
Namespaces: A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource.
Cgroups: control groups is a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes.
Docker Networking
When Docker starts, it creates a virtual interface named docker0 on the host machine. It randomly chooses an address and subnet from the private range defined by RFC 1918 that are not in use on the host machine, and assigns it to docker0. This subnet is usually /16 and is shared between all containers on the Docker host. docker0 is a bit more than a virtual interface – it is a virtual Ethernet bridge which is created in software inside the kernel of Docker host.
Docker0 is virtual Ethernet bridge that automatically forwards packets between any other network interfaces that are attached to it. This will make containers communicate with host as well as with each other.
Every time Docker creates a container, it creates a pair of “peer” interfaces that are like opposite ends of a pipe — a packet sent on one will be received on the other. It gives one of the peers to the container to become its eth0 interface and keeps the other peer, with a unique name like veth7d399CB, out in the namespace of the host machine. By binding every veth*interface to the docker0 bridge, Docker creates a virtual subnet shared between the host machine and every Docker container.
Start docker container:
[root@centos6-local ~]# docker run -i -t ubuntu /bin/bash
IP address on container:
root@899ba2b2a2c7:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:0a:00:00:03
          inet addr:10.0.0.3  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:aff:fe00:3/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:328 (328.0 B)  TX bytes:238 (238.0 B)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
IP address on host:
[root@centos6-local ~]# ifconfig
docker0   Link encap:Ethernet  HWaddr 52:7A:56:20:E0:02
          inet addr:10.0.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::5ccb:a0ff:fe08:2f30/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:972 (972.0 b)  TX bytes:1057 (1.0 KiB)
eth0      Link encap:Ethernet  HWaddr 08:00:27:DB:1A:7C
          inet addr:172.17.101.125  Bcast:172.17.101.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fedb:1a7c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:188801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33009 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:19832749 (18.9 MiB)  TX bytes:3419967 (3.2 MiB)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)
veth7d399cb Link encap:Ethernet  HWaddr 52:7A:56:20:E0:02
          inet6 addr: fe80::507a:56ff:fe20:e002/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1002 (1002.0 b)  TX bytes:1057 (1.0 KiB)
virbr0    Link encap:Ethernet  HWaddr 52:54:00:0C:3B:0D
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Notice that all container’s eth0 interface IP address is within the bridge’s range of network addresses and the gateway is docker0 bridge’s IP address. Also note the veth interfaces bound to docker0 bridge.
[root@centos6-local ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.527a5620e002       no              veth7d399cb
To know more email: marketing@calsoftinc.com
 
Share:

Related Posts

Product Lifecycle Management in Software Development using Large Language Models

Product Lifecycle Management in Software Development using Large Language Models

The data of any organization is of extreme value. But what happens when that data is not trustworthy and accessible to your teams? You will face challenges…

Share:
Kubernetes Introduction and Architecture Overview

Kubernetes: Introduction and Architecture Overview

Containers are taking over and have become one of the most promising methods for developing applications as they provide the end-to-end packages necessary to run your applications….

Share:
How to Perform Hardware and Firmware Testing of Storage Box

How to Perform Hardware and Firmware Testing of Storage Box

In this blog will discuss about how to do the Hardware and firmware testing, techniques used, then the scope of testing for both. To speed up your testing you can use tools mentioned end of this blog, all those tools are available on internet. Knowing about the Hardware/Firmware and how to test all these will help you for upgrade testing of a product which involve firmware

Share:
Cloud Application Development

Challenges of Cloud Application Development

Explore the challenges and solutions of cloud application development, including benefits, performance issues, and overcoming vendor lock-in for seamless cloud integration.

Share:
5 Best Practices in Cloud-native Application Development

5 Best Practices in Cloud-native Application Development

Explore the top 5 best practices in cloud-native application development to ensure your apps are robust, scalable, and efficient. Learn more now!

Share:
Anomaly Detection in Machine Learning Classification Algorithms vs Anomaly Detection

Anomaly Detection in Machine Learning: Classification Algorithms vs Anomaly Detection

Discover the power of anomaly detection in machine learning to enhance operational efficiency, reduce costs, and mitigate risks with the right algorithms and features.

Share: