Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the function of Namespace". In daily operation, I believe that many people have doubts about the role of Namespace. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "what is the role of Namespace?" Next, please follow the editor to study!

Namespace concept

Namespace is a feature of the Linux kernel, which can isolate resources such as process ID, hostname, user ID, file name, network and inter-process communication in the same host system. Docker uses the Namespace feature of the Linux kernel to isolate the resources of each container, thus ensuring that only the resources of its own Namespace can be accessed inside the container.

Currently, there are eight types of Namespace available in the Linux kernel:

The role of various Namespace Mount Namespace

Mount Namespace is the first Namespace implemented by the Linux kernel and has been added since kernel 2.4.19. It can be used to isolate mount points seen by different processes or process groups. Popularly speaking, it is possible to see different mount directories in different processes. Using Mount Namespace, you can only see your own mount information in the container, and the mount operation in the container will not affect the mount directory of the host.

Let's demonstrate Mount Namespace with an example. Before we demonstrate, let's take a look at a command-line tool, unshare. Unshare is a tool in the util-linux toolkit, which has been integrated into the CentOS 7 system by default, and different types of Namespace can be created and accessed using the unshare command.

First, let's create a bash process and create a new Mount Namespace using the following command:

# create a Mount Namespaceroot@docker-demo ~] # unshare-- mount-- fork / bin/bash

After executing the above command, we have created a new Mount Namespace on the host, and the newly created Mount Namespace has been added to the current command line window. Let me verify through an example that creating a mount directory in a separate Mount Namespace does not affect the mount directory of the host.

Then create a directory under the / tmp directory, and then use the mount command to mount a directory of type tmpfs:

[root@docker-demo ~] # mkdir / tmp/tmpfs [root@docker-demo ~] # mount-t tmpfs-o size=20m tmpfs / tmp/tmpfs

Then use the df command to view the mounted directory information:

[root@docker-demo ~] # df-h File system capacity used used mount point / dev/mapper/centos-root 50G 15G 36G 29% / devtmpfs 3.9G 03.9G 0% / devtmpfs 3.9G 03.9G 0% / dev/shmtmpfs 3 .9G 0 3.9G 0% / sys/fs/cgrouptmpfs 3.9G 8.9M 3.9G 1% / runtmpfs 797M 8.0K 797M 1% / run/user/42tmpfs 797M 0797M 0% / run/user/0/dev/sda1 1014M 222M 793M 22% / boot/dev/mapper/centos-home 142G 40m 142G 1% / hometmpfs 20m 0 20m 0% / tmp/tmpfs # the directory just mounted

You can see that the / tmp/tmpfs directory has been mounted correctly. To verify that this directory is not mounted on the host, we open a new command line window and also execute the df command to view the mount information of the host:

Root@docker-demo ~] # df-hT file system type capacity available available mount point devtmpfs devtmpfs 3.9G 0 3.9G 0% devtmpfs tmpfs 3.9G 0 3.9G 0% / dev/shmtmpfs tmpfs 3.9G 9.0m 3.9G 1 % / runtmpfs tmpfs 3.9G 03.9G 0% / sys/fs/cgroup/dev/mapper/centos-root xfs 50G 15G 36G 29% / / dev/sda1 xfs 1014M 222M 793M 22% / boot/dev/mapper/centos-home xfs 142G 40M 142G 1% / hometmpfs tmpfs 797M 8.0K 797M 1% / run/user/42tmpfs tmpfs 797M 0 797m 0% / run/user/0

From the output above, you can see that / tmp/tmpfs is not mounted on the host, so it can be seen that the execution of mount in our separate Mount Namespace will not affect the host.

To further verify our idea, let's continue to look at the Namespace information of the current process in the current command line window, with the following command:

[root@docker-demo] # ls-l / proc/self/ns/ total dosage 0lrwxrwxrwx. 1 root root March 21 19:58 cgroup-> cgroup: [4026531835] lrwxrwxrwx. 1 root root March 21 19:58 ipc-> ipc: [4026531839] lrwxrwxrwx. 1 root root March 21 19:58 mnt-> mnt: [4026532670] lrwxrwxrwx. 1 root root March 21 19:58 net-> net: [4026531992] lrwxrwxrwx. 1 root root March 21 19:58 pid-> pid: [4026531836] lrwxrwxrwx. 1 root root March 21 19:58 pid_for_children-> pid: [4026531836] lrwxrwxrwx. 1 root root March 21 19:58 time-> time: [4026531834] lrwxrwxrwx. 1 root root March 21 19:58 time_for_children-> time: [4026531834] lrwxrwxrwx. 1 root root March 21 19:58 user-> user: [4026531837] lrwxrwxrwx. 1 root root March 21 19:58 uts-> uts: [4026531838]

Then open a new command line window and use the same command to view the Namespace information on the host:

[root@docker-demo] # ls-l / proc/self/ns/ total dosage 0lrwxrwxrwx. 1 root root March 21 19:58 cgroup-> cgroup: [4026531835] lrwxrwxrwx. 1 root root March 21 19:58 ipc-> ipc: [4026531839] lrwxrwxrwx. 1 root root March 21 19:58 mnt-> mnt: [4026531840] lrwxrwxrwx. 1 root root March 21 19:58 net-> net: [4026531992] lrwxrwxrwx. 1 root root March 21 19:58 pid-> pid: [4026531836] lrwxrwxrwx. 1 root root March 21 19:58 pid_for_children-> pid: [4026531836] lrwxrwxrwx. 1 root root March 21 19:58 time-> time: [4026531834] lrwxrwxrwx. 1 root root March 21 19:58 time_for_children-> time: [4026531834] lrwxrwxrwx. 1 root root March 21 19:58 user-> user: [4026531837] lrwxrwxrwx. 1 root root March 21 19:58 uts-> uts: [4026531838]

By comparing the output of the two commands, we can see that except for the different ID values of Mount Namespace, the ID values of other Namespace are the same.

From the above results, we can conclude that a new Mount Namespace can be created using the unshare command, and that the mount within the newly created Mount Namespace is completely isolated from the outside.

PID Namespace

The role of PID Namespace is to isolate processes. In different PID Namespace, the process can have the same PID number. Using PID Namespace, the main process of each container is process No. 1, while the process in the container has a different PID on the host. For example, if a process has a PID of 122on the host, you can use PID Namespace to realize that the PID seen by the process in the container is 1.

Let's demonstrate the role of PID Namespace through an example. First, let's create a bash process and create a new PID Namespace using the following command:

[root@docker-demo] # unshare-- pid-- fork-- mount-proc / bin/bash [root@docker-demo ~] #

After executing the above command, we created a new PID Namespace on the host and added the newly created PID Namespace to the current command line window. Use the ps aux command in the current command line window to view the process information:

[root@docker-demo] # ps auxUSER PID% CPU% MEM VSZ RSS TTY STAT START TIME COMMANDroot 1 1.70.0 116752 4884 pts/0 S 19:59 0:00 / bin/bashroot 31 7.00.0 151124 3872 pts/0 R + 19:59 0:00 ps aux

From the output of the above command, we can see that bash is process 1 under the current Namespace, and we can't see any other process information on the host.

UTS Namespace

UTS Namespace is primarily used to isolate hostnames, allowing each UTS Namespace to have a separate hostname. For example, our host name is docker, and we can use UTS Namespace to implement the host name in the container as lagoudocker or any other custom host name.

Similarly, we use an example to verify the role of UTS Namespace. First, we use the unshare command to create a UTS Namespace:

[root@docker-demo] # unshare-- uts-- fork / bin/bash [root@docker-demo ~] #

After creating the UTS Namespace, the current command line window is already in a separate UTS Namespace. Let's use the hostname command (hostname can be used to view the hostname) to set the hostname:

[root@docker-demo ~] # hostname-b lagoudocker# to view the changed hostname [root@docker-demo ~] # hostnamelagoudocker

From the output of the above command, we can see that the hostname in the current UTS Namespace has been changed to lagoudocker. Then we open a new command line window and use the same command to check the hostname of the host:

[root@docker-demo ~] # hostnamedocker-demo

You can see that the name of the host is still docker-demo and has not been modified. From this, you can verify that UTS Namespace can be used to isolate hostnames.

IPC Namespace

IPC Namespace is mainly used to isolate inter-process communication. For example, PID Namespace and IPC Namespace can be used together to realize that processes in the same IPC Namespace can communicate with each other, while processes with different IPC Namespace can not.

Similarly, we use an example to verify the role of IPC Namespace. First, we use the unshare command to create an IPC Namespace:

[root@docker-demo] # unshare-- ipc-- fork / bin/bash [root@docker-demo ~] #

Next we need to use two commands to validate IPC Namespace.

Ipcs-Q command: used to view a list of communication queues between systems.

Ipcmk-Q command: used to create inter-system communication queues.

Let's first look at the list of system communication queues under the current IPC Namespace using the ipcs-Q command:

[root@docker-demo ~] # ipcs-Q-message queue-key msqid owner permission byte count message

You can see from the above that there is currently no system communication queue, and then we use the ipcmk-Q command to create a system communication queue:

[root@docker-demo ~] # ipcmk-Q message queue id:0

Use the ipcs-Q command again to view the list of system communication queues under the current IPC Namespace:

[root@docker-demo ~] # ipcs-Q-message queue-key msqid owner permission byte count message 0x91ce1a3d 0 root 644 00 0

You can see that we have successfully created a system communication queue. Then we open a new command-line window and use the ipcs-Q command to check the host's system communication queue:

[root@docker-demo ~] # ipcs-Q-message queue-key msqid owner permission byte count message

Through the above experiment, it can be found that the system traffic queue created in a separate IPC Namespace is not visible on the host. That is, IPC Namespace realizes the isolation of the communication queue of the system.

User Namespace

User Namespace is mainly used to isolate users and user groups. A typical application scenario is that processes running as non-root users on the host can be mapped as root users in a separate User Namespace. Using User Namespace, you can realize that the process has root permissions in the container, but is only an ordinary user on the host. User Namesapce can be created without root permission. Let's create a User Namespace as an ordinary user with the following command:

# create and switch to ordinary user [root@docker-demo ~] # su-chengzw [chengzw@docker-demo ~] $iduid=1002 (chengzw) gid=1004 (chengzw) groups=1004 (chengzw) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023# create User Namespace [chengzw@docker-demo ~] $unshare-- user-r / bin/bash

Then execute the id command to view the current user information:

[root@docker-demo ~] # iduid=0 (root) gid=0 (root) group = 0 (root) environment = unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

From the output above, you can see that we are already root users in the new User Namespace. Let's verify that only the host root user can execute the reboot command, and execute the reboot command in the current command line window:

[root@docker-demo ~] # rebootFailed to open / dev/initctl: Permission deniedFailed to talk to init daemon.

View the process in which the current User Namespace resides:

[root@docker-demo ~] # echo $2157

If you view the corresponding user of the process on the host machine, you can see that it is actually the chengzw user on the host:

[root@docker-demo ~] # ps-ef | grep 2157chengzw 2157 2092 0 20:41 pts/0 00:00:00 / bin/bash

As you can see, we are root users in the newly created User Namespace, but we do not have permission to execute reboot commands. This shows that the root permission of the host cannot be obtained in the quarantined User Namespace, that is, User Namespace implements the isolation of users and user groups.

Net Namespace

Net Namespace is used to isolate information such as network devices, IP addresses, and ports. Net Namespace allows each process to have its own IP address, port and network card information. For example, the host IP address is 192.168.1.41, and a separate IP address 172.16.1.2 can be set in the container.

Also verified by an example, let's first use the ip addr command to look at the network information on the host:

[root@docker-demo ~] $ip addr1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 scope host lo valid_lft forever preferred_lft forever inet6:: mtu 65536 scope host valid_lft forever preferred_lft forever2: ens192: mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:9b:2d : 90 brd ff:ff:ff:ff:ff:ff inet 192.168.1.41/24 brd 192.168.1.255 scope global ens192 valid_lft forever preferred_lft forever inet6 fe80::2556:f369:b4e7:fb64/64 scope link tentative dadfailed valid_lft forever preferred_lft forever inet6 fe80::6b8d:29f7:a5fe:dbee/64 scope link tentative dadfailed valid_lft forever preferred_lft forever inet6 fe80::f387:57a3:4975:d8f2/64 scope Link tentative dadfailed valid_lft forever preferred_lft forever

Then we create a Net Namespace using the following command:

[root@docker-demo] # unshare-- net-- fork / bin/bash

Similarly, let's use the ip addr command to check the network information:

[root@docker-demo ~] # ip addr1: lo: mtu 65536 qdisc noop state DOWN qlen 1000 link/loopback 00lo 000000 brd 0000000000000000000000000000000000000000000000000000000000

You can see that there are lo, ens192 and other network devices on the host, but the network devices in our newly built Net Namespace are different from those on the host. We can add Nic and configure IP in Net Namespace:

[root@docker-demo ~] # ip link add eth0 type dummy [root@docker-demo ~] # ip addr add 172.16.1.2 go 24 dev [root@docker-demo ~] # ip addr1: lo: mtu 65536 qdisc noop state DOWN qlen 1000 link/loopback 00VlV 0000VlV 0000VlV 0000VlV 0000RV 002: eth0: mtu 1500 qdisc noqueue state UNKNOWN qlen 1000 link/ether e6:b7:92:d4:cc:ae brd ff:ff:ff : ff:ff:ff inet 172.16.1.2/24 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::e4b7:92ff:fed4:ccae/64 scope link valid_lft forever preferred_lft foreverTime Namespace

First of all, check the time of the host. It is now March 21:

[root@docker-demo ~] # CST at 21:02:38 on Sunday, March 21, date2021

Start a centos container and check it at the same time as the host (UTC + 8 = CST):

[root@docker-demo ~] # docker exec-it centos bash [root@a695de10917d /] # dateSun Mar 21 13:02:46 UTC 2021

An attempt was made to modify the time in the container, indicating that there are not enough permissions:

[root@a695de10917d /] # date-s 05/28date: cannot set date: Operation not permitted

When starting the container, add the-- cap-add SYS_TIME parameter, and change the time in the container to March 20th:

Root@docker-demo ~] # docker run-it-- cap-add SYS_TIME-- name centos centos / bin/bash [root@e7b61aba6222 /] # date-s 03/20Sat Mar 20 00:00:00 UTC 2021 [root@e7b61aba6222 /] # dateSat Mar 20 00:00:01 UTC 202 exit container [root@e7b61aba6222 /] # exitexit

Check the time on the host computer and find that it has also been changed to March 20:

[root@docker-demo] # Saturday, March 20, date2021, 08:00:07 CST

-- cap-add SYS_TIME is used to mount the kernel time of the host and share it with the container, so the container time is changed, and the host time is changed accordingly.

Why does Docker need Namespace?

Mount Namespace was added to the Linux kernel from version 2.4.19 in 2002, and it was not until the kernel version 3.8 that User Namespace was added that sufficient support was provided for the container.

When Docker creates a new container, it creates these six Namespace and then adds the processes in the container to these Namespace, so that the processes in the Docker container can only see the system resources in the current Namespace.

It is because Docker uses these Namespace technologies of Linux that Docker containers are isolated. It can be said that without Namespace, there would be no Docker containers.

Docker exec principle

After learning about the isolation mechanism of Linux Namespace, you should naturally think of a question: how does docker exec get into the container?

In fact, the isolated space created by Linux Namespace is invisible, but the Namespace information of a process does exist on the host machine and exists as a file.

First create a container:

$docker run-p 4000 purl 80 helloworld python app.py

With the following instructions, you can see that the process number (PID) of the currently running Docker container is 25686:

$docker inspect-- format'{{.State.Pid}} '4ddf4638572d25686

At this point, you can see all the Namespace files corresponding to this 25686 process by looking at the proc file of the host:

$ls-l / proc/25686/nstotal 0lrwxrwxrwx 1 root root 0 Aug 13 14:05 cgroup-> cgroup: [4026531835] lrwxrwxrwx 1 root root 0 Aug 13 14:05 ipc-> ipc: [4026532278] lrwxrwxrwx 1 root root 0 Aug 13 14:05 mnt-> mnt: [4026532276] lrwxrwxrwx 1 root root 0 Aug 13 14:05 net-> net: [4026532281] lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid-> pid: [4026532279] lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid_for_children-> pid: [4026532279] lrwxrwxrwx 1 root root 0 Aug 13 14:05 user-> user: [4026531837] lrwxrwxrwx 1 root root 0 Aug 13 14:05 uts-> uts: [4026532277]

As you can see, each Linux Namespace of a process has a corresponding virtual file under its corresponding / proc/ [process number] / ns and is linked to a real Namespace file.

With such a file that can "hold" all Linux Namespace, we can do something meaningful with Namespace, such as adding to an existing Namespace.

This means that a process can choose to join the existing Namespace of a process, so as to achieve the purpose of "entering" the container where the process is located, which is the principle of docker exec implementation.

This operation relies on a Linux system call called setns (). Its calling method, I can use the following paragraph Mini Program to explain to you:

# define _ GNU_SOURCE#include # define errExit (msg) do {perror (msg); exit (EXIT_FAILURE);} while (0) int main (int argc, char * argv []) {int fd; fd = open (argv [1], O_RDONLY); if (setns (fd, 0) = =-1) {errExit ("setns");} execvp (argv [2], & argv [2]) ErrExit ("execvp");}

The function of this code is very simple: it receives a total of two parameters, the first parameter is argv [1], that is, the path of the Namespace file to which the current process is to be added, such as / proc/25686/ns/net;, and the second parameter is the process you want to run in this Namespace, such as / bin/bash.

The core operation of this code is to open the specified Namespace file through the open () system call and give the file's descriptor fd to setns () for use. After setns () is executed, the current process is added to the Linux Namespace corresponding to this file.

Now, you can compile and execute this program and add it to the Network Namespace of the container process (PID=25686):

$gcc-o set_ns set_ns.c $. / set_ns / proc/25686/ns/net / bin/bash $ifconfigeth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:02 inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:12 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:976 (976.0 B) TX bytes:796 (796.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: 1hand 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:1000 RX bytes:0 (0.0B) TX bytes:0 (0.0B)

As shown above, when we execute the ifconfig command to check the network devices, I will find that there are fewer network cards I can see: only two. My host has at least four network cards. What's going on?

In fact, the two NICs I saw after setns () are the NICs in the Docker container I started earlier. In other words, my newly created / bin/bash process, because it has joined the Network Namepace of the container process (PID=25686), it sees the same network devices as in this container, that is, the network device view of the / bin/bash process has also been modified.

Once a process is added to another Namespace, it will also be reflected in the Namespace file of the host.

On the host, you can use the ps instruction to find the / bin/bash process executed by the set_ns program, and its real PID is 28499:

# ps aux on the host machine | grep / bin/bashroot 28499 0.0 19944 3612 pts/0 S 14:15 0:00 / bin/bash

At this point, if you look at the Namespace of this PID=28499 process, you will find this fact:

$ls-l / proc/28499/ns/netlrwxrwxrwx 1 root root 0 Aug 13 14:18 / proc/28499/ns/net-> net: [4026532281] $ls-l / proc/25686/ns/netlrwxrwxrwx 1 root root 0 Aug 13 14:05 / proc/25686/ns/net-> net: [4026532281]

In the / proc/ [pid] / ns/net directory, this PID=28499 process is exactly the same as the Network Namespace file pointed to by our previous Docker container process (PID=25686). This shows that the two processes share this Network Namespace called net: [4026532281].

In addition, Docker specifically provides a parameter that allows you to launch one container and "add" to the Network Namespace of another container. This parameter is-net, such as:

$docker run-it-net container:4ddf4638572d busybox ifconfig

In this way, our newly launched container will be added directly to the ID=4ddf4638572d container, that is, the Network Namespace of the application container (PID=25686) we created earlier. So, the network card information returned by ifconfig here is exactly the same as the result returned by Mini Program before me, you can also give it a try.

If I specify-net=host, it means that the container will not enable Network Namespace for the process. This means that the container removes the "wall" of Network Namespace, so it will directly share the host's network stack like other ordinary processes on the host. This provides a channel for the container to directly operate and use the host network.

At this point, the study of "what is the role of Namespace" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.