Closed amab8901 closed 1 month ago
simple_web_server:latest
is built locally via testimages
crate. We don't pull it from dockerhub
How do you execute tests? Are you running cargo test
in the root of the repository?
Try to execute cargo build --tests
, is there any errors?
yes I run cargo t
in root repository and that's where I got the above outcome.
No issues occur in cargo build --tests
.
I suspect that maybe cargo t
runs in a different user than the user in the normal CLI. I have no idea what that user may be. If I knew, I could have perhaps added it to the docker
group to see if it fixes it.
FYI:
I have this in .cargo/config
:
[target.x86_64-unknown-linux-gnu]
runner = 'sudo -E'
This was a fix i used to make some of the tests pass. Without it, basically all tests will fail. But after I added this, most tests passed but some of them still failed.
Could you try to build test images explicitly:
cargo build -p testimages
And then, try to check if the image exists in your local docker registry
I ran cargo build -p testimages
and no errors were thrown. But the image didn't show up in docker images
.
But the image didn't show up in
docker images
.
Hm, that's weird - probably something with your local setup
Could you try with extended output:
cargo clean -p testimages
cargo build -vv -p testimages
After that you should see
[testimages 0.1.0] Built no_expose_port:latest
[testimages 0.1.0] Built simple_web_server:latest
Which means that docker images were built. Do you see these lines?
Alternatively, you could build the image on your own with:
docker build --file {PATH_TO_REPO}/testimages/src/dockerfiles/simple_web_server.dockerfile --force-rm --tag simple_web_server:latest .
when I run these:
cargo clean -p testimages
cargo build -vv -p testimages
... I indeed see these lines:
[testimages 0.1.0] Built no_expose_port:latest
[testimages 0.1.0] Built simple_web_server:latest
But when I run this:
docker build --file {PATH_TO_REPO}/testimages/src/dockerfiles/simple_web_server.dockerfile --force-rm --tag simple_web_server:latest .
... I get this output:
$ docker build --file [...]/testcontainers-rs/testimages/src/dockerfiles/simple_web_server.dockerfile --force-rm --tag simple_web_server:latest .
[+] Building 43.4s (15/19) docker:desktop-linux
=> [internal] load build definition from simple_web_server.dockerfile 0.0s
=> => transferring dockerfile: 955B 0.0s
=> [internal] load metadata for docker.io/library/debian:bookworm-slim 1.0s
=> [internal] load metadata for docker.io/lukemathwalker/cargo-chef:latest-rust-latest 1.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [chef 1/3] FROM docker.io/lukemathwalker/cargo-chef:latest-rust-latest@sha256:5e7553b436d67833f39f588cc1d5048eb4ce9578d5303ee9e3b1547c6579bca7 0.0s
=> [internal] load build context 6.6s
=> => transferring context: 1.67GB 6.6s
=> [runtime 1/5] FROM docker.io/library/debian:bookworm-slim@sha256:a629e796d77a7b2ff82186ed15d01a493801c020eed5ce6adaa2704356f15a1c 0.0s
=> CACHED [chef 2/3] WORKDIR /app 0.0s
=> CACHED [chef 3/3] RUN apt update && apt install lld clang -y 0.0s
=> [planner 1/2] COPY . . 3.1s
=> [planner 2/2] RUN cargo chef prepare --recipe-path recipe.json 0.2s
=> [builder 1/4] COPY --from=planner /app/recipe.json recipe.json 0.0s
=> [builder 2/4] RUN cargo chef cook --release --recipe-path recipe.json 28.5s
=> [builder 3/4] COPY . . 3.1s
=> ERROR [builder 4/4] RUN cargo build -v --release --bin simple_web_server 0.7s
------
> [builder 4/4] RUN cargo build -v --release --bin simple_web_server:
0.444 Fresh unicode-ident v1.0.12
0.444 Fresh autocfg v1.3.0
[...]
0.450 Fresh hyper-util v0.1.8
0.450 Fresh axum v0.7.5
0.562 Running `/app/target/release/build/testimages-0865c6aee4c63e0f/build-script-build`
0.570 error: failed to run custom build command for `testimages v0.1.0 (/app/testimages)`
0.570
0.570 Caused by:
0.570 process didn't exit successfully: `/app/target/release/build/testimages-0865c6aee4c63e0f/build-script-build` (exit status: 1)
0.570 --- stderr
0.570 Error: No such file or directory (os error 2)
------
simple_web_server.dockerfile:16
--------------------
14 | COPY . .
15 | # Build our project
16 | >>> RUN cargo build -v --release --bin simple_web_server
17 |
18 | FROM debian:bookworm-slim AS runtime
--------------------
ERROR: failed to solve: process "/bin/sh -c cargo build -v --release --bin simple_web_server" did not complete successfully: exit code: 101
Try running docker build
from within the repository or specify path to it instead of .
(dot)
However it looks like build script has succeed. But you mentioned that there is no simple_web_server:latest
in your docker images ls
, right?
running docker build
within the repository is what I did in the previous comment. I do actually have simple_web_server:latest
in my docker images
. I previously ran cargo t
in sudo mode (by setting sudo in .cargo/config
) but I removed the sudo now (I think it's supposed to work without having to use sudo), and I get this test result for cargo t
:
I can recommend to take a look at docker host discovery: https://docs.rs/testcontainers/0.22.0/testcontainers/#docker-host-resolution
Thus, testcontainers most likely uses /var/run/docker.sock
in your case, but you can override that with DOCKER_HOST
What docker setup do you use? Is it docker desktop for linux? What OS do you use?
I use Ubuntu Linux v.22. The file /var/run/docker.sock
does exist. I use this Docker setup:
https://docs.docker.com/desktop/install/linux/ubuntu/
Where/how can I find the value I'm supposed to put in DOCKER_HOST
env?
$ which docker
/usr/local/bin/docker
What do you get in your CLI output when you run which docker
?
This command shows where docker cli binary is located and mostly depends on many factors like OS, installation method and etc. And moreover it's not related with docker socket path, so it won't be useful Docker CLI and engine in general two different executable
@amab8901 just one question, don't you have a ~/.testcontainers.properties
file? It may override docker-host too. And if you use Testcontainers Desktop you need to have it running.
However, it might be an issue only if you have enabled properties-config
feature of testcontainers
and your properties config points to unavailable address/socket
You can also check the docker host with docker cli actually:
docker context inspect | jq -r .[0].Endpoints.docker.Host
But as you mentioned:
The file
/var/run/docker.sock
does exist.
This might mean that the you don't have appropriate permissions for the file, that's why behavior with sudo might be different
I do have ~/.testcontainers.properties
:
testcontainers.reuse.enable = true
tc.host = tcp://127.0.0.1:37769
docker.host = tcp://127.0.0.1:37769
It has the field docker.host
, which sounds like it does override docker-host. So then I guess setting the DOCKER_HOST
env won't change anything.
I have these permissions for the docker.sock
file:
$ ls /var/run/docker.sock -la
srw-rw---- 1 root docker 0 sep. 23 08:16 /var/run/docker.sock
Do I need to change the permissions?
So then I guess setting the DOCKER_HOST env won't change anything.
That true only if you run tests with properties-config
feature (or all-features). We use a feature flag to specify if properties should be used. And your applications also can specify this feature if needed.
Do you use Testcontainers Desktop? If so, ensure it's running (I assume you do, because of content of the properties)
And try to run:
cargo test --all-features
Adding write permissions (chmod 602
on docker.sock
) reduced the number of failed tests from 18 to 5 (cargo t
).
When I run cargo t --all-features
, the number of failed tests increases to 9. I have Testcontainers Desktop running, but idk if it's correctly configured
Which ones fail now and what's the output? That might be expected errors depending on your config
What's about docker context inspect | jq -r .[0].Endpoints.docker.Host
? https://github.com/testcontainers/testcontainers-rs/issues/731#issuecomment-2373705794
docker context inspect | jq -r .[0].Endpoints.docker.Host
gives:
unix:///home/<user>/.docker/desktop/docker.sock
In fact the main difference between your runs is sync_runner
- it's also under separate feature - blocking
.
But the issue itself is missing image, probably you have multiple local docker engines? I.e testcontainers and docker cli use different ones.
unix:///home/<user>/.docker/desktop/docker.sock
You can try to set this one in DOCKER_HOST
and run cargo test
(without all features for now).
Or keep using Testcontainers Desktop, select local mode with this socket and then run cargo test --all-features
.
idk why but for some reason the number of failed tests is slowly increasing with time on cargo t
. About a week ago I had 4 tests failed, then a few days ago 5 tests failed and now 6 tests are failing.
Also an observation is that when Docker Desktop is off:
$ docker context inspect | jq -r .[0].Endpoints.docker.Host
unix:///var/run/docker.sock
But when I turn on the Docker Desktop, then:
$ docker context inspect | jq -r .[0].Endpoints.docker.Host
unix:///home/<user>/.docker/desktop/docker.sock
But opening and closing TestContainer didn't change the output of docker context inspect | jq -r .[0].Endpoints.docker.Host
.
Amazingly, all tests pass when I run DOCKER_HOST=unix:///home/<user>/.docker/desktop/docker.sock cargo t
.
But 9 tests fail when I run DOCKER_HOST=unix:///home/<user>/.docker/desktop/docker.sock cargo t --all-features
.
Here is the CLI output for the failed --all-features
I also tried turning off Docker Desktop and change RUST_LOG env accordingly before doing cargo t --all-features
but 9 tests failed in that case too
also an interesting observation when I toggle between local and cloud modes:
31 passed, 9 failed
runners::async_runner::tests::async_run_command_should_map_exposed_port
runners::async_runner::tests::async_run_command_should_map_exposed_port_udp_sctp
runners::async_runner::tests::async_run_command_should_map_ports_udp_sctp
runners::async_runner::tests::async_should_rely_on_network_mode_when_network_is_provided_and_settings_bridge_empty
runners::async_runner::tests::async_should_return_error_when_non_bridged_network_selected
runners::sync_runner::tests::sync_run_command_should_map_exposed_port
runners::sync_runner::tests::sync_run_command_with_container_network_should_not_expose_ports
runners::sync_runner::tests::sync_should_rely_on_network_mode_when_network_is_provided_and_settings_bridge_empty
runners::sync_runner::tests::sync_should_return_error_when_non_bridged_network_selected
9 passed, 31 failed
core::containers::async_container::tests::async_logs_are_accessible
core::containers::sync_container::test::sync_logs_are_accessible
runners::async_runner::tests::async_run_command_should_expose_all_ports_if_no_explicit_mapping_requested
runners::async_runner::tests::async_run_command_should_expose_only_requested_ports
runners::async_runner::tests::async_run_command_should_have_host_cgroupns_mode
runners::async_runner::tests::async_run_command_should_have_host_userns_mode
runners::async_runner::tests::async_run_command_should_have_private_cgroupns_mode
runners::async_runner::tests::async_run_command_should_have_working_dir
runners::async_runner::tests::async_run_command_should_include_name
runners::async_runner::tests::async_run_command_should_include_network
runners::async_runner::tests::async_run_command_should_include_privileged
runners::async_runner::tests::async_run_command_should_include_ulimits
runners::async_runner::tests::async_run_command_should_map_exposed_port
runners::async_runner::tests::async_run_command_should_map_exposed_port_udp_sctp
runners::async_runner::tests::async_run_command_should_map_ports_udp_sctp
runners::async_runner::tests::async_run_command_should_set_shared_memory_size
runners::async_runner::tests::async_should_create_network_if_image_needs_it_and_drop_it_in_the_end
runners::async_runner::tests::async_should_rely_on_network_mode_when_network_is_provided_and_settings_bridge_empty
runners::async_runner::tests::async_should_return_error_when_non_bridged_network_selected
runners::sync_runner::tests::sync_run_command_should_expose_all_ports_if_no_explicit_mapping_requested
runners::sync_runner::tests::sync_run_command_should_expose_only_requested_ports
runners::sync_runner::tests::sync_run_command_should_include_name
runners::sync_runner::tests::sync_run_command_should_include_network
runners::sync_runner::tests::sync_run_command_should_include_privileged
runners::sync_runner::tests::sync_run_command_should_include_ulimits
runners::sync_runner::tests::sync_run_command_should_map_exposed_port
runners::sync_runner::tests::sync_run_command_should_set_shared_memory_size
runners::sync_runner::tests::sync_run_command_with_container_network_should_not_expose_ports
runners::sync_runner::tests::sync_should_create_network_if_image_needs_it_and_drop_it_in_the_end
runners::sync_runner::tests::sync_should_rely_on_network_mode_when_network_is_provided_and_settings_bridge_empty
runners::sync_runner::tests::sync_should_return_error_when_non_bridged_network_selected
But 9 tests fail when I run DOCKER_HOST=unix:///home/
/.docker/desktop/docker.sock cargo t --all-features.
That's because all-features enables properties-config
.
Just to clarify - it means that if ~/.testcontainers.properties
file exists it will be prioritized.
Testcontainers Desktop don't affect docker cli in any way, but only overrides properties file and it's expected.
also an interesting observation when I toggle between local and cloud modes:
As mentioned above, it's important to use properties-config
feature to respect Testcontainer Desktop settings.
This passes all tests:
DOCKER_HOST=unix:///home/<user>/.docker/desktop/docker.sock cargo t
But this fails some tests:
DOCKER_HOST=unix:///home/<user>/.docker/desktop/docker.sock
cargo t
thanks for your help!
I run
cargo t
in this repo after cloning it, and I get this error for some tests:Here are the tests for which I get this error:
The error message suggests I need to login on Docker but I'm already logged in (via
docker login
in the terminal).How do I fix this?