【05】循序渐进学 docker：系统资源和网络

怼烎@ 2021-12-21 14:19 223阅读 0赞

写在前面的话

在上一篇学习 Dockerfile 的时候其实还有几个相当重要得关键中没有谈到，但没关系，在后面的内容会单独提出来一个一个的学习。这里就先谈谈关于资源的控制个容器的网络~

资源限制

其实对于容器的资源使用，无外乎在意 3 个方面，内存，CPU，IO，但 IO 很多时候是没法避免的，所以更多的还是通过内存和 CPU来进行资源限制。

【1】限制内存：

docker run --memory=200M centos

**--memory：**配置 200M，但这并不意味容器最大内存是 200M，在没额外对 Swap 进行限制时，Swap 和内存对等，所以是 400M。

**--memory-swap：**限制 Swap。

【2】CPU 限制：

docker run --cpu-shares=10 centos

限制 CPU，并不是限制使用几核，而是权重占比。

假如一个容器 10，一个 20，另外一个 10，那 CPU 占用实际是 25%，50% 和 25%。

关于资源限制的其他参数可以通过 --help 看到，这里也就谈谈使用较多的，其他都相对于比较冷门，需要的时候再去查。

Network namespace

在学习容器网络之前，可以先学习一下 Linux 网络名称空间，有助于更好的理解容器网络~

【1】先建立两个 network namespace，并启动内部的网卡：

# 查看本机的 network namespace
    ip netns list
    
    # 添加两个 network namespace
    ip netns add ns-1
    ip netns add ns-2
    
    # 查看 network namespace 的网卡信息
    ip netns exec ns-1 ip a
    ip netns exec ns-2 ip a
    
    # 启动 lo 网卡
    ip netns exec ns-1 ip link set dev lo up
    ip netns exec ns-2 ip link set dev lo up
    
    # 再度查看网卡信息
    ip netns exec ns-1 ip a
    ip netns exec ns-2 ip a

结果如图：

![979767-20190327095106045-1720754546.png][]

此时，lo 网卡启动状态显示 **UNKNOWN**状态，情景就好像一根网线只插了一头。

【2】新建两个网卡，并将它们各自分到 network namespace：

# 新建两个网卡
    ip link add veth-1 type veth peer name veth-2
    
    # 查看网卡连接信息
    ip link
    
    # 将网卡分别分配到不同的 network namespace
    ip link set veth-1 netns ns-1
    ip link set veth-2 netns ns-2
    
    # 再度查看网卡信息
    ip link
    
    # 查看 network namespace 中的网卡信息
    ip netns exec ns-1 ip link
    ip netns exec ns-2 ip link

结果如图：

![979767-20190327100108351-911280323.png][]

在网卡刚创建时，属于本机。但当将网卡分配到别的命名空间后，本机就不存在了。而是存在于各自的命名空间。

这就好比新加了一条网线，本来两头都是插在本机的，但现在将它拔了出来，一头插在了 ns-1 的网络命名空间上，另一头插在了 ns-2 上面。

【3】将两个网卡都启动起来并配置上 IP，测试连通信：

# 给 network namespace 中的网卡配置 IP 地址
    ip netns exec ns-1 ip addr add 192.168.1.1/24 dev veth-1
    ip netns exec ns-2 ip addr add 192.168.1.2/24 dev veth-2
    
    # 启动 network namespace 中的网卡
    ip netns exec ns-1 ip link set dev veth-1 up
    ip netns exec ns-2 ip link set dev veth-2 up
    
    # 查看配置后的网卡信息
    ip netns exec ns-1 ip a 
    ip netns exec ns-2 ip a
    
    # 测试连通信性
    ip netns exec ns-1 ping 192.168.1.2

结果如图：

![979767-20190327100920284-520295051.png][]

可以看到两个命名空间已经可以独立的通信了，但本机其实和这个两个网卡是不通的。

这样就产生了一个存在本机，但是又独立于本机，能够互相通信的网络，最终达到的效果类似下图：

![979767-20190327101426122-770656514.png][]

以上的内容完全是作为帮助理解，只需要知道有这么一回事就行。

带着这个基础，再来看容器网络。

容器网络

先看容器到底是怎么通信的：

![979767-20190327101729406-880891233.png][]

和前面的图很像。但相比于那个图，本机多了一个 docker0 网卡，简单的可以把这个 docker0 假设成一个交换机，一根网线接到互联网，然后我们的电脑都可以用网线连接上去，不仅内网互通，还能上网。

这样的技术放在容器的实现里面就是通过本机的防火墙的 NAT 转发实现。

docker 自带了 3 种网络：

docker network ls

结果如图：

![979767-20190327102347850-685550804.png][]

在三种网络中，默认是 **bridge**（桥接），其他两种用的相对较少。

**host：**容器和本机一起共享端口，共享一个 IP。

**none：**“孤儿网络”，建立一个容器，完完全全独立。

当然，除了这 3 种网络，还可以自己建立一个其他名称的网络，但是在接触 **overlay** 网络之前，你的网络的 **DRIVER** 终究逃不脱这 3 种。

比如新建一个网络：

docker network create -d bridge my-network

结果如图：

![979767-20190327103302644-207215082.png][]

通过 **--network **参数将新建立的容器指定使用这个网络~

docker run --name b3 --network my-network -it -d busybox /bin/sh -c "while true; do sleep 300; done"

后面执行个死循环的目的是为了容器不自动退出。

docker container inspect b3

查看容器的详细信息，里面的  **Networks** 项变成了 **my-network**，默认网段也变了。

![979767-20190327104159404-1245312076.png][]

再新建一个容器，让它属于默认的网络：

docker run --name b4 -it -d busybox /bin/sh -c "while true; do sleep 300; done"

此时，用新的网络来测试和默认的网络的连通性：

![979767-20190327104612949-1252579408.png][]

结果：无法通信。

查看某个网络的接入情况需要借助 **brctl**了，默认不存在，需要自己安装：

yum install bridge-utils -y

查看：

brctl show

结果如下：

![979767-20190327104942152-1639077446.png][]

有两个桥接网络，每个都连接了一个网卡，docker0 我们知道，但是 br-xxx 是啥？

其实，br-xxx 就是手动创建的 my-network，xxx 部分就是 network 的 ID，可以查看：

docker network ls

查看本机目前的网络情况：

![979767-20190327105330135-966203568.png][]

结合上面的图，30 和 32 网卡其实是连接到 docker0 和 br-xxx 的。

这时候的 docker0 和 br-xxx 就相当于两个网络接口，30 和 32 网卡就像两条网线，一头已经插在了这两个接口上。那另外一头，自然就插在了容器里面，这样就实现了容器与当前主机的通信了。

再配合防火墙转发规则，那么就实现了容器的上网。

查看指定网络到底有哪些容器连接到上面：

docker network inspect my-network

结果如图：

![979767-20190327105912566-1541194823.png][]

但现在有一个需求来了：

有一个机器，需要以容器的形式运行一个 MySQL 数据库，有一个同样以容器运行的程序需连接到这个数据库，但是由于容器被分配到的 IP 地址是自动分配的，下一次重新构建可能就变了，那怎么保证下次不需要修改配置依然能够连接到数据库呢？

**--link：**将一个容器连接到另外一个容器。

先一次性删除掉之前的建立的所有容器，在不停止容器的前提下依然删除容器：**-f**参数，强制执行：

docker container rm -f $(docker ps -qa)

【1】新建两个容器，都隶属相同的默认网络：

docker run --name b1 -it -d busybox /bin/sh -c "while true; do sleep 300; done"
    docker run --name b2 -it -d busybox /bin/sh -c "while true; do sleep 300; done"

【2】通过**容器名称**测试容器连通性：

docker exec -it b1 ping b2

结果如图：

![979767-20190327112452372-1219269430.png][]

结果：通过容器名称是无法通信。

【3】新建一个容器，连接到 b1：

docker run --name b3 --link b1 -it -d busybox /bin/sh -c "while true; do sleep 300; done"

再度测试和 b1 与 b2 的连通性：

docker exec -it b3 ping b1
    docker exec -it b3 ping b2

结果如图：

![979767-20190327112705512-1226111234.png][]

结果：b3 在使用 **--link** 连接到 b1 后可以通过容器名称直接进行通信，但反过来不行。

【4】再度建立一个容器，link 到 b1：

docker run --name b4 --link b1 -it -d busybox /bin/sh -c "while true; do sleep 300; done"

测试 b4 和 b1，b3 的连通性：

docker exec -it b4 ping b1
    docker exec -it b4 ping b3

结果如图：

![979767-20190327113151721-98486723.png][]

结果：单独 link 的容器正向可以通信，反过来不行。

由此，可以暂时得出这样一个结论：

**在默认的 bridge 网络中，可以使用 --link 参数实现容器通过容器名称访问容器，但是这个参数的作用是单向的。**

上面的方法实现了简单的需求，但是每次都需要指定，岂不麻烦？再次删除掉所有容器，用自己创建网络测试：

【1】创建两个容器，让它们属于我们自己建立的网络：

docker container rm -f $(docker ps -qa)
    docker run --name b1 --network my-network -it -d busybox /bin/sh -c "while true; do sleep 300; done"
    docker run --name b2 --network my-network -it -d busybox /bin/sh -c "while true; do sleep 300; done"

测试网络的连通性：

docker exec -it b1 ping b2
    docker exec -it b2 ping b1

结果如图：

![979767-20190327115506826-2111569061.png][]

结果：自动实现互相通过容器名称通信。

是不是真香？再新建一个容器试试？

docker run --name b3 --network my-network -it -d busybox /bin/sh -c "while true; do sleep 300; done"

测试连通性：

docker exec -it b3 ping b1
    docker exec -it b3 ping b2

结果如图：

![979767-20190327115747069-1383517971.png][]

完全没问题，由此可以得出另外一条结论：

**在自建的网络中容器，默认会自动互相 link，由此能够实现直接通过容器名称进行互相通信。**

这就很好解决了上面 IP 会变但不想修改配置照样连上数据库，直接使用容器名称代替 IP 就行。

结论：在容器中，需要摒弃之前在虚拟机应用时代关于 IP 的重视程度，**在容器应用中，IP 几乎可以不需要理会。**

端口映射

之前 Flask 的例子已经发现了，当容器中启动某个端口的服务，宿主机以外的其他用户是不能访问的。

那么如何才能访问呢？这就得依靠端口映射，将 docker 容器的端口转换成宿主机的某个端口。

其实就是 2 个参数，**-p**和 **-P**：

\-p：将宿主机的某个端口映射到容器中的某个端口。

\-P：将容器中的所有端口映射成宿主机 32768 之上的随机端口。

对之前的 Flask 项目做改进：**app.py** 如下

from flask import Flask
    from redis import Redis
    import os
    import socket
    
    app = Flask(__name__)
    redis = Redis(host=os.environ.get('REDIS_HOST', '127.0.0.1'), port=6379)
    
    @app.route('/')
    def hello():
        redis.incr('hits')
        return 'Hello Container World! I have been seen %s times and my hostname is %s.\n' % (redis.get('hits'),socket.gethostname())
    
    if __name__ == "__main__":
        app.run(host="0.0.0.0", port=5000, debug=True)

项目是这样的，用户在每请求一次，redis 给这个值增加 1，进而实现页面显示的数字加 1 的效果：

mkdir  flask-redis
    cd flask-redis/
    vim app.py

添加 **Dockerfile**：

FROM python:2.7
    LABEL maintainer="Dylan <1214966109@qq.com>"
    COPY app.py /app/
    RUN pip install flask && pip install redis
    WORKDIR /app/
    EXPOSE 5000
    CMD ["python", "app.py"]

构建镜像：

docker build -t dylan/flask-demo:v1.0 .

再运行一个 redis 容器，和之前 MySQL 问题类似，这里也准备使用容器名称来连接，因为只连接了一个服务，直接使用 **--link**就行~

【1】运行 redis 容器：

docker run -d --name redis redis

【2】运行刚刚的 flask-redis：

docker run -d --name flask-redis-demo --link redis -e REDIS_HOST=redis dylan/flask-demo:v1.0

**-e：**给容器设置一个环境变量，因为程序代码会从环境变量中获取 redis 的地址，如果没有，才默认使用 127.0.0.1。

这样写的达到了灵活配置的目的。

curl http://172.17.0.3:5000

在本机通过 curl 访问容器 IP 加端口就能够访问到内容了，如下图：

![979767-20190327150353856-801485568.png][]

那为啥之前那个简单的 flask 项目在宿主机无法直接访问呢？原因很简单。

**因为监听 IP 的原因，之前监听的是 127.0.0.1 只能本机访问，而这里监听的是 0.0.0.0 都允许~**

【3】再运行一个随机映射的项目：

docker run -d --name flask-redis-demo1 -P --link redis -e REDIS_HOST=redis dylan/flask-demo:v1.0

通过查看本机的端口可知是 32769 端口，访问测试：

![979767-20190327150707165-231521832.png][]

【4】再运行一个指定端口的：

docker run -d --name flask-redis-demo2 -p 8080:5000 --link redis -e REDIS_HOST=redis dylan/flask-demo:v1.0

将它映射到 8080，访问测试：

![979767-20190327151058988-1636565012.png][]

小结

对于资源管理和网络的知识暂时谈到这里，后面会谈到另外一种网络 DRIVER（overlay）网络~

转载于:https://www.cnblogs.com/Dy1an/p/10600980.html

[979767-20190327095106045-1720754546.png]: /images/20211220/47aaac1f05ff464faa3e66d0b22756dc.png
[979767-20190327100108351-911280323.png]: /images/20211220/9de061007761413cb7fdf5b506dbe2f3.png
[979767-20190327100920284-520295051.png]: /images/20211220/d91da9b3bb1b43ca8754b6e3ba58b0b3.png
[979767-20190327101426122-770656514.png]: /images/20211220/dd4ad555c24b4fa4a83147baf818f2a9.png
[979767-20190327101729406-880891233.png]: /images/20211220/3267fe950734459789e2c9f7304c4070.png
[979767-20190327102347850-685550804.png]: /images/20211220/cf7cf0878aae4746a4fe001a4d28ddf6.png
[979767-20190327103302644-207215082.png]: /images/20211220/f4c70942346f476dad0b019fc5398f77.png
[979767-20190327104159404-1245312076.png]: /images/20211220/b73e883dcb074d038677dee078dc11ff.png
[979767-20190327104612949-1252579408.png]: /images/20211220/965cb44b7ae04701b94db96fa6cd57a0.png
[979767-20190327104942152-1639077446.png]: /images/20211220/5687859f186842aa92c567a55378edf6.png
[979767-20190327105330135-966203568.png]: /images/20211220/2196d24ce3374a0280a214dc668da10b.png
[979767-20190327105912566-1541194823.png]: /images/20211220/9cb1a2187c0c4f2f9362b786d42f78fb.png
[979767-20190327112452372-1219269430.png]: /images/20211220/7046d92e6ed04f108c661720411debeb.png
[979767-20190327112705512-1226111234.png]: /images/20211220/b07e660a53ac48979442c4275bfc9327.png
[979767-20190327113151721-98486723.png]: /images/20211220/0163da94bc7746be9e426c47d5310233.png
[979767-20190327115506826-2111569061.png]: /images/20211220/3ded52f9324a473baee5ac2bebffe8af.png
[979767-20190327115747069-1383517971.png]: /images/20211220/fed1d4a1121f4e469ed529d7756bd6dd.png
[979767-20190327150353856-801485568.png]: /images/20211220/85cc9682530c419da2b167924a6b23f5.png
[979767-20190327150707165-231521832.png]: /images/20211220/bc6f3fd8b3d34332a792d05de855df2a.png
[979767-20190327151058988-1636565012.png]: /images/20211220/94863808d07245ad845804a6171da3ea.png