这篇文章收录于Rust 实战专栏。这个专栏中的相关代码来自于我开发的笔记系统。它启动于是2023年的9月14日。相关技术栈目前包括:Rust,Javascript。关注我,我会通过这个项目的开发给大家带来相关实战技术的分享。
前言
上上周了吧,写了一篇Rust-后端服务调试入坑记,现在看来那个坑根本就不算什么。这次这个坑才是真正的坑。到写文章这一刻,我只是确定了复现这个问题的最简单代码(参考目录验证4:基于Debian:11镜像创建最简单Rust的http服务)。但依然没有找到解决这个问题的办法。
现在把这个问题以及我的验证过程整理出来,以便路过的朋友了解,我相信肯定有大神知道其中的缘由和解决办法。还望各位大神留言赐教。
问题描述
我用Rust语言创建了一个基于Rocket框架(0.5-rc)的Restful服务api(以下简称api),并将其部署在docker容器内调试。
容器相关描述:
- 容器名称: notes-api
- 网络模式: bridge
- 端口映射: 8003:8000
当容器成功启动后,问题及相关情况描述:
- 不能从宿住机访问容器中的api,错误码56,命令行: curl http://localhost:8003/api/notes
- 能够从宿主机上ping通容器,命令行:ping 172.22.0.2
- 登录到容器中,能够运行命令行成功访问api,命令行: sudo docker exec -it notes-api curl http://localhost:8000/api/notes
- 如果将网络模式改为host,能够从宿主机上正常访问容器中的api,命令行: curl http://localhost:8000/api/notes
对自己的怀疑
这个问题导致了我对我的Docker使用经验和相关的记忆产生怀疑。难道Docker容器在网络模式为bridge时,不能从宿住机访问?很快,这个问题被否定了,因为我早些时候就在Nginx服务器上配置过多个api的路由,这些api都通过Docker部署在一台服务器上,通过不同的端口来访问部署在这些容器中的api。
即然是早些时候,我的下一个判断是,会不会是因为我现在这台服务器上安装的Docker版本比较新,新版本的Docker Engine是否有一些关于端口映射的设置,导致部署在Docker容器中的api不能够被正常访问呢?
验证之路
1. Python应用
说实话,我的关于用Docker容器部署Api的经验主要来至于Python。我还是第一次将Rust构建的api部署到Docker容器中。因此,我决定用Python创建一个简单的api,将其部署到Docker容器中,看是否能够从宿主机上正常访问。
docker-compose.yml
version: '3'services: web:build:context: ./dockerfile: Dockerfilecontainer_name: python-apinetwork_mode: bridgeports:- 8004:5000
Dockerfile
from python:latestworkdir /app
copy ./main.py ./requirements.txt /app/run pip install -r requirements.txt
cmd ["python3", "main.py"]
结果:能够从宿主机上成功访问到容器内的api。
因此,是不是镜像本身的问题呢?
我对比了Python镜像和Rust镜像所使用的linux系统。Python镜像使用的是"Debian GNU/Linux 11",Rust使用的是"Debian GNU/Linux 12"。
2. 从Debian:11镜像来创建Rust的镜像
因此,我决定基于Debian:11的镜像来制作Rust的api容器的镜像。
docker-compose.yml
version: '3'
services: web:build:context: ./dockerfile: Dockerfilecontainer_name: notes-api1network_mode: bridgeports:- 8004:8000
Dockerfile
from debian:11
run apt update
run apt install -y curl gccrun curl -s --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
env PATH=/root/.cargo/bin:$PATH
run rustup default nightlyworkdir /appcopy ./Cargo.toml ./config.toml ./Cargo.lock /app/
copy ./src /app/srccmd ["cargo", "run"]
结果:不能从宿主机访问Docker容器中的api。
会不会是Python的镜像虽然基于"Debian GNU/Linux 11",但是,在制作镜像的时候有一些设置关于端口映射的设置呢?
3. 从Debian:11镜像来创建Python的镜像
因此,为了排出关于“设置”的猜想,我决定基于Debian:11的镜像来制作Python的api容器的镜像。
如果能够正常访问,说明不存在关于“设置”的猜想。
docker-compose.yml
version: '3'services: web:build:context: ./dockerfile: Dockerfilecontainer_name: my-python2 network_mode: bridgeports:- 8009:5000
Dockerfile
from debian:11
run apt update
run apt install -y curl gccrun apt install python3 pip -yworkdir /app
copy ./main.py ./requirements.txt /app/env PATH=/usr/local/bin:$PATHrun pip install -r requirements.txtcmd ["python3", "main.py"]
结果:能够从宿主机上成功访问到容器内的api。
说明,Python的镜像中,关于端口映射的相关“设置”猜想不存在。
因此,我的视线又回到了Rust项目,我的api是基于Rocket 0.5-rc开发的,是不是因为这个框架的原因呢?
4. 基于Debian:11镜像创建最简单Rust的http服务
因此,我让AI帮我写了一个没有任何依赖的Rust的http服务,然后将这个服务部署到基于Debian:11的镜像中。
docker-compose.yml
version: '3'
services: web:build:context: ./dockerfile: Dockerfilecontainer_name: rust-simple-httpnetwork_mode: bridgeports:- 8012:8080
Dockerfile
from debian:11
run apt update
run apt install -y curl gcc# 安装rust
run curl -s --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
env PATH=/root/.cargo/bin:$PATH workdir /appcopy ./Cargo.toml ./entry.sh /app/
copy ./src/main.rs /app/src/main.rsentrypoint ["./entry.sh"]
main.rs
use std::io::{Read, Write};
use std::net::{TcpListener, TcpStream};fn handle_client(mut stream: TcpStream) {let mut buffer = [0; 1024];stream.read(&mut buffer).unwrap();let response = "HTTP/1.1 200 OK\r\n\r\nHello, World!";stream.write(response.as_bytes()).unwrap();stream.flush().unwrap();
}fn main() {let listener = TcpListener::bind("127.0.0.1:8080").unwrap();for stream in listener.incoming() {match stream {Ok(stream) => {std::thread::spawn(|| {handle_client(stream);});}Err(e) => {eprintln!("Failed to establish a connection: {}", e);}}}
}
entry.sh
#!/bin/bashecho "cargo build"
cargo build --release
echo "cp bin"
cp target/release/app ./
echo "run app"
./app
结果: 不能从宿主机访问Docker容器中的api。
因此,貌似和Rocket 0.5-rc这个框架没有关系。
目前的情况可以归纳为:
- Rust创建的api部署到容器中,容器的网络模式为bridge,不能够从宿主机通过容器的端口访问到容器中运行的api。
- Python创建的api部署到容器中,容器的网络模式为bridge,能够从宿主机通过容器的端口访问到容器中运行的api。
这个特殊现象是否只存在于Rust和Python之间呢?如果再找一个应用部署到网络模式为bridge的Docker容器中,能否从宿主机通过容器端口访问到容器中运行的应用呢?如果答案是“能”,那么,多少可以得出结论:
Rust创建的api部署到网络模式为bridge的Docker容器中,不能从宿主机通过容器的端口访问到容器中运行的api。
5. 基于Debian:11镜像从apt安装简单的http服务
docker-compose.yml
version: '3'
services: web:build:context: ./dockerfile: Dockerfilecontainer_name: simple-http-servernetwork_mode: bridgeports:- 8013:8080
Dockerfile
from debian:11
run apt update
run apt install -y curl gccrun apt install libhttp-server-simple-perl -yworkdir /app
copy entry.sh /app/
entrypoint ["./entry.sh"]
entry.sh
#!/bin/bash
perl -MHTTP::Server::Simple -e 'my $server = HTTP::Server::Simple->new(); $server->run()'
结果:能够从宿主机上成功访问到容器内的api。
结论
看来目前只能得出这样的结论了:
Rust创建的api部署到网络模式为bridge的Docker容器中,不能从宿主机通过容器的端口访问到容器中运行的api。
问题整理好了,先放在这里。
后面的工作如何开展
暂时将容器的网络模式设置为host进行调试。如果后面配置的服务很多,估计需要做一个cli来管理各个服务端口的配置(这可是我的强项,哈哈)。
如有问题,欢迎大家留言交流。关注我,后面会在Rust 实战专栏中给大家带来更多关于Rust开发实战的分享。