You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Certain domains (for me it's github.com) always fail to resolve in rootless Docker when the image is built with muslrust:
main.rs
use std::net::ToSocketAddrs;fnmain(){let domains = ["google.com","github.com"];for domain in domains
{println!("Trying to resolve {domain} with to_socket_addrs()");format!("{domain}:443").to_socket_addrs().unwrap();println!("it worked");}}
There are no dependencies installed.
Dockerfile
# syntax=docker/dockerfile:1FROM clux/muslrust:1.71.0 as musl#USER rootWORKDIR /appCOPY . .ARG CARGO_INCREMENTAL=0# trying to resolve URLs, just show errors, don't abort# this *works* in rootless Docker in muslRUN curl -sS -o /dev/null https://google.com; exit 0# this *fails* in rootless Docker in muslRUN curl -sS -o /dev/null https://github.com; exit 0RUN cargo build --release --target x86_64-unknown-linux-muslCMD ["/app/target/x86_64-unknown-linux-musl/release/mwedns"]FROM rust:1.71.0-slimWORKDIR /appCOPY . .ARG CARGO_INCREMENTAL=0# this *works* in rootless Docker with the official Rust imageRUN curl -sS -o /dev/null https://google.com; exit 0# this *works* in rootless Docker with the official Rust imageRUN curl -sS -o /dev/null https://github.com; exit 0RUN cargo build --releaseCOPY --link --from=musl /app/target/x86_64-unknown-linux-musl/release/mwedns /app/musl# run the one compiled with the official Rust image firstCMD echo "official Rust" && /app/target/release/mwedns && echo "musl Rust" && /app/musl
$ git clone git@github.com:KonradHoeffner/mwedns.git
$ cd mwedns
$ docker build . -t mwedns
[...]
$ docker run --rm mwedns
Output
official Rust
Trying to resolve google.com with to_socket_addrs()
it worked
Trying to resolve github.com with to_socket_addrs()
it worked
musl Rust
Trying to resolve google.com with to_socket_addrs()
it worked
Trying to resolve github.com with to_socket_addrs()
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Uncategorized, error: "failed to lookup address information: Name does not resolve" }', src/main.rs:8:51
I reported this first at algesten/ureq#645 but then found out it has nothing to do with ureq.
You can also verify that DNS lookup fails in rootless Docker with:
$ docker run --rm --entrypoint "/bin/bash" clux/muslrust:1.71.0 -c "curl -sS -o /dev/null https://github.com"
curl: (6) Could not resolve host: github.com
Relation to Alpine?
There is a known bug with the Alpine image reported at alpinelinux/docker-alpine#155.
However the things that differ here:
looking at the muslrust Dockerfile, it is based on Ubuntu Jammy, not on Alpine
the error occurs inside a muslrust container
inside an official Rust container, the errors occurs with a binary built within a muslrust container but not with a binary built within an official Rust container
The text was updated successfully, but these errors were encountered:
This is almost certainly down to how musl does dns and not something we can solve here.
You are putting a musl built static binary inside of a rust container which is a debian based (glibc) distro, with dns resolution settings (resolv.conf / dnsmasq.conf) that is probably not ideal for what it was built for.
I would recommend following this post and seeing where that takes you. There's also a more kubernetes focused issue that may be useful at k3s-io/k3s#6132.
Certain domains (for me it's github.com) always fail to resolve in rootless Docker when the image is built with muslrust:
main.rs
There are no dependencies installed.
Dockerfile
You can test this MWE at https://github.com/KonradHoeffner/mwedns:
Output
I reported this first at algesten/ureq#645 but then found out it has nothing to do with ureq.
You can also verify that DNS lookup fails in rootless Docker with:
Relation to Alpine?
There is a known bug with the Alpine image reported at alpinelinux/docker-alpine#155.
However the things that differ here:
The text was updated successfully, but these errors were encountered: