fix: support detecting if k3s module is running from inside a Docker container #1289
Conversation
The k3s module previously didn't work properly inside of a Docker container; the caller would connect to its HTTPS server via the Docker network gateway, which wasn't included in the list of SANS from the TLS certificate exposed by the k3s container. This change determines what the DaemonHost address is prior to creating the container request, and then injects that address as one of the TLS SANs. When not running in a Docker container, the k3s module continues to function as it did before, as the DaemonHost address in that scenario is "localhost".
✅ Deploy Preview for testcontainers-go ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
Kudos, SonarCloud Quality Gate passed!
|
There was a problem hiding this comment.
Thanks for this contribution! It makes sense to distinguish the execution context: from inside a container or not.
Apart from the PR, I'm interested in knowing more about your use case for this module: could you share with us a little bit of how you use it and which use cases it does resolve in your projects? 🙏
| if logging == nil { | ||
| logging = testcontainers.Logger | ||
| } | ||
| p, err := req.ProviderType.GetProvider(testcontainers.WithLogger(logging)) |
There was a problem hiding this comment.
I'm taking a look to check if it's possible to get a Provider instance from the library, instead of from the container request + customisers. In fact in https://github.com/testcontainers/testcontainers-go/pull/1251/files#diff-e9b78e9b34e14f076ba250ebd1042b315e63673569f82372a8064cece5f034bfR25 I'm deprecating the field in order to get them automatically from the environment.
In any case, I think this is good enough for now :)
|
@mritunjaysharma394, as original contributor of the module, could you also take a look? 🙏 |
Sure! We have a Kubernetes operator where we run a Kubernetes cluster to do integration tests. We previously embedded k3d as a library for bringing up a Kubernetes, but started to look for another solution when we realized importing k3d was causing some dependency hell issue. (We have a ton of dependencies already). We were already using testcontainers-go for bringing up a Vault server for integration tests, so switching out our k3d code for the k3s module made a ton of sense for us. We'll be making more heavy use of the k3s module over time, as we're starting to add more Kubernetes controllers into our non-operator binary, where integration tests will help with having confidence in the stability of our code. |
mdelapenya
changed the title
|
@rfratto we plan a release in the short term, but we need to resolve one issue with Windows first (see #1249) At the moment, each module follows the core library release cycle, as we don't want to fall in the trap of maintaining multiple release branches (one per module), so the next full release will include these changes. 🙏 |
|
No worries! We'll use the main branch until is a release is available. Thanks for the update! |
|
@rfratto just sharing that v0.21.0 is out, including the k3s module 😉 |
The k3s module previously didn't work properly inside of a Docker container; the caller would connect to its HTTPS server via the Docker network gateway, which wasn't included in the list of SANS from the TLS certificate exposed by the k3s container. This would cause requests to fail due to TLS validation errors:
This change determines what the DaemonHost address is prior to creating the container request, and then injects that address as one of the TLS SANs.
When not running in a Docker container, the k3s module continues to function as it did before, as the DaemonHost address in that scenario is "localhost".
I have successfully tested this PR both locally and verifying that it fixes the tests in our environment (see grafana/agent#4161).