rust-lang / mdBook

Create book from markdown files. Like Gitbook but implemented in Rust
https://rust-lang.github.io/mdBook/
Mozilla Public License 2.0
18.13k stars 1.63k forks source link

mdbook connections reset when run inside container #2226

Open pozix604 opened 1 year ago

pozix604 commented 1 year ago

Problem

mdbook serve doesn't seem to be running properly when inside a Podman container. Everything works but serving. The logging indicates that it starts listening on port 3000, but then upon connect, the connection is dropped immediately.

If I shell into the container, the server is working and responds to requests.

This makes it look like podman is not working, but then all other servers ,like python's http.server, work properly in this container, just mdbook's connections are reset.

Containerfile:

$ cat Containerfile
FROM    alpine
RUN     apk update && apk upgrade
RUN     apk add mdbook
RUN     yes | mdbook init /mnt
WORKDIR /mnt
CMD     ["mdbook", "serve"]

Build:

$ podman build -t mdbook_test .
<lots of output>
Successfully tagged localhost/mdbook_test:latest

Running log:

$ podman run -it --rm -p 3000:3000 mdbook_test
2023-10-26 13:05:16 [INFO] (mdbook::book): Book building has started
2023-10-26 13:05:16 [INFO] (mdbook::book): Running the html backend
2023-10-26 13:05:16 [INFO] (mdbook::cmd::serve): Serving on: http://localhost:3000
2023-10-26 13:05:16 [INFO] (mdbook::cmd::watch): Listening for changes...
2023-10-26 13:05:16 [INFO] (warp::server): Server::run; addr=[::1]:3000
2023-10-26 13:05:16 [INFO] (warp::server): listening on http://[::1]:3000

Try to connect from host:

$ telnet localhost 3000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Try to connect from inside container:

$ podman exec -it vibrant_dirac sh
# telnet localhost 3000
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
...

Steps

No response

Possible Solution(s)

No response

Notes

I tried using mdbook serve --hostname 127.0.0.1, same issue.

Version

# mdbook --version
mdbook v0.4.28

Same issue if mdbook is installed from source, v0.4.35.
pozix604 commented 1 year ago

FYI, using the official rust image results in the same error:

FROM    docker.io/library/rust
RUN     cargo install mdbook
WORKDIR /mnt
KFearsoff commented 11 months ago

Managed to reproduce the issue.

So let's start with IPv4, because it's easier to follow. mdbook serve --hostname 127.0.0.1 won't work, and that's by design. 127.0.0.1 is loopback address; however, since the command is executed inside the container, it takes the loopback of a virtual network device, so mdbook will be available inside the container, but it won't be available outside of it (that's what loopback does). Instead, you are supposed to use 0.0.0.0, which is an IP address that exposes the service on all of network devices, which will make mdbook available on the network device that connects to the host network.

Sorry for the long write-up, unfortunately there's no way to avoid some Docker networking internals to understand the cause.

Now that we know that 127.0.0.1 makes mdbook available inside the container only and 0.0.0.0 makes it available on the host, let's see what happens in IPv6. In IPv6, the loopback has address ::1, and "any address" is ::. Yes, they look pretty weird.

Basically, mdbook by default exposes itself only on the loopback address, which makes it unavailable from inside of the container. This is a sane default: you wouldn't want to expose a service to outside world unless you opt into it. That said, I believe mdbook not providing an image that you can use for yourself causes people to bump into this networking mess, and that's not a good thing to have. I think the best way to resolve the issue is to have officially maintained image, especially since there are tons of caveats with container images that are good to handle upstream anyway.

KFearsoff commented 11 months ago

@rustbot label +A-Installation -C-bug +C-enhancement +Command-serve +S-Not-wrong

KFearsoff commented 11 months ago

Related: #2030