-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it work with a remote docker host #89
Comments
I ran into this issue on Gitlab CI where you need to set the I ended up writing an extension trait that extends |
@mchlstckl Could you please provide us some snippets of the relevant lines including the .gitlab-ci.yml? My integration tests are running fine on my local machines but not in the GitLab runner. I was struggling the past days to get this working, but I haven't figured out yet. |
Sorry. That was a while back and I don’t have that code anymore.
…On Tue, 14 Mar 2023 at 23:29, kuba ***@***.***> wrote:
I ran into this issue on Gitlab CI where you need to set the
DOCKER_HOST=tcp://docker:2375.
I ended up writing an extension trait that extends Container with a
get_host() method. The method url parses the DOCKER_HOST value and if
scheme is ”tcp” returns the url host else returns ”localhost” (like when
the scheme is ”unix”).
@mchlstckl <https://github.com/mchlstckl> Could you please provide us
some snippets of the relevant lines including the .gitlab-ci.yml? My
integration tests are running fine on my local machines but not in the
GitLab runner. I was struggling the past days to get this working, but I
haven't figured out yet.
—
Reply to this email directly, view it on GitHub
<#89 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAARXEXEQF32CQUPND6QMWDW4DWOHANCNFSM4HLWYGLA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No problem, thanks for checking though. I managed to get it working and want to share it in case someone else stumbles on on this. .gitlab-ci.yml:
rust trait:
Then you can just connect to the container using its IP and internal port in your integration test. |
Quite large refactoring as part of project revamp #563, and also the long-awaited refactoring #386 Now it's really simple API, e.g: ```rs let container = GenericImage::new("redis", "latest") .with_exposed_port(6379) .with_wait_for(WaitFor::message_on_stdout("Ready to accept connections")) .start(); ``` I find this new API much easier to use, solves a lot of problems, and seems flexible enough to be extended. This also works regardless of the tokio runtime flavor (multi-thread vs current-thread). And the sync API is still available, right under `blocking` feature (just like `reqwest` does). From a maintainer's perspective this also simplifies the code, we don't have to worry about two different clients and their differences. ### Docker host resolution The host is resolved in the following order: 1. Docker host from the `tc.host` property in the `~/.testcontainers.properties` file. 2. `DOCKER_HOST` environment variable. 3. Docker host from the "docker.host" property in the `~/.testcontainers.properties` file. 4. Else, the default Docker socket will be returned. ### Notes - MSRV was bumped to `1.70` in order to use `std::sync::OnceLock`. This should NOT be a problem, tests usually executed on more recent versions (also see [this ref](https://github.com/testcontainers/testcontainers-rs/pull/503/files#r1242651354)). - `Cli` client is removed, instead we provide `sync` (under `blocking` feature) and `async` impls based on HTTP client (bollard) - tested with [modules](https://github.com/testcontainers/testcontainers-rs-modules-community) ## Migration guide - Sync API migration (`Cli` client) - Add `blocking` feature - Drop all usages of `clients::Cli` - Add `use testcontainers::runners::SyncRunner;` - Replace `client.run(image)` with `image.start()` - Async API migration (`Http` client) - Remove `experimental` feature - Drop all usages of `clients::Http` - Add `use testcontainers::runners::AsyncRunner;` - Replace `client.run(image)` with `image.start()` ## References Closes #386 Closes #326 Closes #475 Closes #508 Closes #392 Closes #561 Closes #559 Closes #564 Closes #538 Closes #507 Closes #89 Closes #198
The docker daemon can be hosted on a remote machine, hence in addition to the
port
of a container, we should also expose thehost
on which the docker container was started.The text was updated successfully, but these errors were encountered: