search

testcontainers / testcontainers-java

Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
https://testcontainers.org
MIT License
8.02k stars 1.65k forks source link

Unable to run Testcontainers on Windows Server 2019 (LinuxKit installed, LCOW) #2960

Open iamsraja opened 4 years ago

iamsraja commented 4 years ago

Unable to run containers from testcontainer in Windows Server 2019 (LinuxKit installed). This link https://www.testcontainers.org/supported_docker_environment/ mentions that LCOW is supported. Able to run a linux container without any issue from Docker CLI.

Facing issues only when tried to run a container from testcontainer.

Error logs as below:

2020-07-01 20:12:59.342 ERROR 4936 --- [           main] o.t.d.DockerClientProviderStrategy       : Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
2020-07-01 20:12:59.342 ERROR 4936 --- [           main] o.t.d.DockerClientProviderStrategy       :     NpipeSocketClientProviderStrategy: failed with exception InvalidConfigurationException (ping failed). Root cause TimeoutException (null)
2020-07-01 20:12:59.342 ERROR 4936 --- [           main] o.t.d.DockerClientProviderStrategy       :     WindowsClientProviderStrategy: failed with exception TimeoutException (org.rnorth.ducttape.TimeoutException: java.util.concurrent.TimeoutException). Root cause TimeoutException (null)
2020-07-01 20:12:59.342 ERROR 4936 --- [           main] o.t.d.DockerClientProviderStrategy       : As no valid configuration was found, execution cannot continue

Docker Info as below:

Client: Debug Mode: false Plugins: cluster: Manage Docker clusters (Docker Inc., v1.2.0) Server: Containers: 4 Running: 1 Paused: 0 Stopped: 3 Images: 6 Server Version: 19.03.5 Storage Driver: windowsfilter (windows) lcow (linux) Windows: LCOW: Logging Driver: json-file Plugins: Volume: local Network: ics internal l2bridge l2tunnel nat null overlay private transparent Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog Swarm: inactive Default Isolation: process Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434) Operating System: Windows Server 2019 Standard Version 1809 (OS Build 17763.1294) OSType: windows Architecture: x86_64 CPUs: 4 Total Memory: 16GiB Name: DHUBAS204 ID: ZWHK:7HAM:2IKC:YTDS:RD7L:P2V6:6ECL:A2I3:X6T2:2N33:3KSQ:ZX24 Docker Root Dir: C:\ProgramData\docker Debug Mode: true File Descriptors: -1 Goroutines: 31 System Time: 2020-07-01T14:00:30.2657542+10:00 EventsListeners: 0 Registry: https://index.docker.io/v1/ Labels: Experimental: true Insecure Registries: registry-1.docker.io 127.0.0.0/8 Registry Mirrors: Live Restore Enabled: false

kiview commented 4 years ago

Thanks for bringing this to our attention. We don't have a Windows Server environment available for testing or debugging, so we are in kind of a blind spot here.

From the error log, we can infer, that Testcontainers was not able to communicate with the Docker daemon over the named pipe. From looking into the Docker docs, I wonder if running this PowerShell command would give us further insights:

PS C:\Users\Administrator> [System.IO.Directory]::GetFiles(https://success.docker.com/api/asset/.%2Funable-to-connect-to-docker-engine-locally-via-namedpipe%2F"\\.\\pipe\\") | Select-String "docker"
iamsraja commented 4 years ago

@kiview Thank you very much for your response. Tried to execute the command (various combinations of that URL as well) in powershell with no luck. Is that URL correct inside GetFiles command? Could you please help me out

Below is the error I receive on executing that command in powershell: image

Also to note: I'm able to run testcontainer successfully with named pipe in my laptop with Windows installed. The failure is only in Windows server

kiview commented 4 years ago

TBH no idea if the URL is correct or not, this was simply copied from Docker Enterprise docs. It also does not work on my Windows machine.

Maybe we can find another way to investigate if the named pipe is accessible.

I found another blog post, which might be relevant to the problem. It seems, that under Windows server, the named pipe is only accessible with elevated permissions.

Reading into this, I assume there is nothing Testcontainers can do here.

iamsraja commented 4 years ago

Thanks @kiview. It really helped to progress to next step. When running with Admin privileges, it fails with the below error in testcontainer: windows is currently not supported. 

2020-07-02 07:37:14.014  INFO 5816 --- [           main] o.t.d.NpipeSocketClientProviderStrategy  : Accessing docker with local Npipe socket (npipe:////./pipe/docker_engine)
2020-07-02 07:37:14.014  INFO 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : Found Docker environment with local Npipe socket (npipe:////./pipe/docker_engine)
2020-07-02 07:37:14.144  WARN 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : windows is currently not supported
2020-07-02 07:37:14.516  INFO 5816 --- [           main] o.t.d.NpipeSocketClientProviderStrategy  : Accessing docker with local Npipe socket (npipe:////./pipe/docker_engine)
2020-07-02 07:37:14.516  INFO 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : Found Docker environment with local Npipe socket (npipe:////./pipe/docker_engine)
2020-07-02 07:37:14.533  WARN 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : windows is currently not supported
2020-07-02 07:37:19.545 ERROR 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
2020-07-02 07:37:19.545 ERROR 5816 --- [           main] o.t.d.DockerClientProviderStrategy       :     NpipeSocketClientProviderStrategy: failed with exception InvalidConfigurationException (windows containers are currently not supported)
2020-07-02 07:37:19.545 ERROR 5816 --- [           main] o.t.d.DockerClientProviderStrategy       :     WindowsClientProviderStrategy: failed with exception TimeoutException (Timeout waiting for result with exception). Root cause ConnectException (Connection refused: no further information)
2020-07-02 07:37:19.545 ERROR 5816 --- [           main] o.t.d.DockerClientProviderStrategy       : As no valid configuration was found, execution cannot continue

Additional info:-

image

kiview commented 4 years ago

So, Testcontainers sees the environment as a Windows container environment, I will need to investigate this in the sources.

Maybe the check is just overly cautious abd it would work from a technical standpoint.

iamsraja commented 4 years ago

Thanks for looking into this @kiview . Will wait for your feedback

kiview commented 4 years ago

Ok, I found the problematic part in our code. We check the OS type as reported by the Docker client: https://github.com/testcontainers/testcontainers-java/blob/780b8e33811f046e64c7cdf6a25b49fb0fe79ce8/core/src/main/java/org/testcontainers/dockerclient/DockerClientProviderStrategy.java#L258-L267

And your Docker daemon would indeed respond with OSType: windows. However, since you are running as LCOW, this should not be a problem.

Therefore, I pushed an experimental branch which removed this strict check, could you try it out in your environment?

You can consume it using Jitpack.

iamsraja commented 4 years ago

Thanks @kiview. Apologies for the delay as I was behind a corporate proxy. Needed to sort that out first to use jitpack.

Your solution helped me progress further but getting errors with volume mount while starting a localstack container. I noticed few previously reported issues in testcontainer around volume mount but couldn't get it to work.

Could you please help @kiview 

org.testcontainers.containers.ContainerLaunchException: Container startup failed
Caused by: org.testcontainers.containers.ContainerFetchException: Can't get Docker image: RemoteDockerImage(imageName=images-releases.upm.asx.com.au/localstack/localstack:0.10.8, imagePullPolicy=DefaultPullPolicy())
Caused by: com.github.dockerjava.api.exception.InternalServerErrorException: 
Status 500: {"message":"invalid volume specification: '//var/run/docker.sock:/var/run/docker.sock:rw'"}

StackTrace:-

org.testcontainers.containers.ContainerLaunchException: Container startup failed
    at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:313)
    at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:294)
    at com.asx.data.hubble.commontest.mocks.ftp.S3ContainerUtil.init(S3ContainerUtil.java:48)
    at com.asx.data.hubble.commontest.steps.CommonHooks.s3Setup(CommonHooks.java:117)
Caused by: org.testcontainers.containers.ContainerFetchException: Can't get Docker image: RemoteDockerImage(imageName=localstack/localstack:0.10.8, imagePullPolicy=DefaultPullPolicy())
    at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1261)
    at org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:595)
    at org.testcontainers.containers.localstack.LocalStackContainer.configure(LocalStackContainer.java:69)
    at org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:299)
    at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:294)
    at com.asx.data.hubble.commontest.mocks.ftp.S3ContainerUtil.init(S3ContainerUtil.java:48)
    at com.asx.data.hubble.commontest.steps.CommonHooks.s3Setup(CommonHooks.java:117)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    at io.cucumber.java.Invoker.invoke(Invoker.java:27)
    at io.cucumber.java.JavaHookDefinition.execute(JavaHookDefinition.java:61)
    at io.cucumber.core.runner.CoreHookDefinition.execute(CoreHookDefinition.java:31)
    at io.cucumber.core.runner.HookDefinitionMatch.runStep(HookDefinitionMatch.java:20)
    at io.cucumber.core.runner.TestStep.executeStep(TestStep.java:64)
    at io.cucumber.core.runner.TestStep.run(TestStep.java:49)
    at io.cucumber.core.runner.TestCase.run(TestCase.java:47)
    at io.cucumber.core.runner.Runner.runPickle(Runner.java:67)
    at io.cucumber.junit.PickleRunners$NoStepDescriptions.run(PickleRunners.java:149)
    at io.cucumber.junit.FeatureRunner.runChild(FeatureRunner.java:83)
    at io.cucumber.junit.FeatureRunner.runChild(FeatureRunner.java:24)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at io.cucumber.junit.Cucumber.runChild(Cucumber.java:185)
    at io.cucumber.junit.Cucumber.runChild(Cucumber.java:83)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at io.cucumber.junit.Cucumber$RunCucumber.evaluate(Cucumber.java:219)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
    at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:40)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
    at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:71)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:229)
    at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:197)
    at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:211)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:191)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)
    at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invokeAllTests(JUnitPlatformProvider.java:154)
    at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:127)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:186)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:161)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:84)
    at org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:87)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1198)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1063)
    at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:889)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:567)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
Caused by: com.github.dockerjava.api.exception.InternalServerErrorException: Status 500: {"message":"invalid volume specification: '//var/run/docker.sock:/var/run/docker.sock:rw'"}
    at com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:247)
    at com.github.dockerjava.core.DefaultInvocationBuilder.post(DefaultInvocationBuilder.java:125)
    at com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:33)
    at com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:13)
    at com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
    at com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
    at com.github.dockerjava.core.command.CreateContainerCmdImpl.exec(CreateContainerCmdImpl.java:595)
    at org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:89)
    at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:174)
    at org.testcontainers.LazyDockerClient.getDockerClient(LazyDockerClient.java:14)
    at org.testcontainers.LazyDockerClient.listImagesCmd(LazyDockerClient.java:12)
    at org.testcontainers.images.LocalImagesCache.maybeInitCache(LocalImagesCache.java:68)
    at org.testcontainers.images.LocalImagesCache.get(LocalImagesCache.java:32)
    at org.testcontainers.images.AbstractImagePullPolicy.shouldPull(AbstractImagePullPolicy.java:18)
    at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:59)
    at org.testcontainers.images.RemoteDockerImage.resolve(RemoteDockerImage.java:26)
    at org.testcontainers.utility.LazyFuture.getResolvedValue(LazyFuture.java:17)
    at org.testcontainers.utility.LazyFuture.get(LazyFuture.java:39)
    at org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1259)
bsideup commented 4 years ago

@ssureshraja when pasting stacktraces, please use triple backtick (```), so that it renders correctly.

kiview commented 4 years ago

The first error probably happens when we try to run Ryuk and mount the Docker socket. So there is no Docker socket to be mounted, which is very different to how Docker for Windows works on Windows 10 Pro (where Docker is running in a Linux VM and therefore can mount the socket).

You can disable Ryuk, but I expect you to run in another problem afterwards. But maybe give it a try.

TBH, because of lack of resources and testing environment, I currently see the only solution in changing the docs to highlight, that Windows Server is currently not supported.

iamsraja commented 4 years ago

Thanks for all your help @kiview . For now, I'll switch to other option

jonashackt commented 3 years ago

Hey @kiview & @bsideup - good to somehow meet again ✌️ It's been far to long... Remember the great testcontainers talk from @bsideup at JUG Thüringen in Gotha!

We're currently setting up a Windows Build for our https://github.com/codecentric/spring-boot-admin project, since we get more and more Windows related bugs and wanted to have a build for that. Using GitHub Actions together with the windows-latest environment, we are running into this very issue here now - and I spotted in the docs, that there's currently no support for Docker on Windows Server 2019 & Testcontainer 😢 https://github.com/codecentric/spring-boot-admin/runs/1844705455?check_suite_focus=true

From the state of this issue I assume that there's no big progress with this problem, right? I just read the "blind spot" thing:

"We don't have a Windows Server environment available for testing or debugging, so we are in kind of a blind spot here."

With GitHub Actions it would be an option to eliminate the blind spot 😃 (see https://docs.github.com/en/actions/reference/specifications-for-github-hosted-runners#supported-runners-and-hardware-resources).

bsideup commented 3 years ago

Hi @jonashackt! Good to "see" you too :)

The problem with windows-latest is that it uses Windows Containers, not Linux containers. It means that Testcontainers itself works, but all the images that it starts are Linux-based and, in Windows Containers mode, they obviously fail to start :)

FYI we do have a Windows CI node running now. It runs Docker for Windows (in Linux mode) and we test every commit in our main branch before we cut a release :)

jonashackt commented 3 years ago

Ah really nice, I tried to find a CI configuration (Circle, GitHub Actions, Travis..) in testcontainers root but wasn't able to find a Windows config. Could you give me a hint?

bsideup commented 3 years ago

@jonashackt we use Azure Pipelines for (Although we do plan to migrate to a self hosted GitHub Actions runner), see https://github.com/testcontainers/testcontainers-java/blob/master/azure-pipelines.yml

LorenzoBettini commented 3 years ago

From my experiments it doesn't work with windows-2016 either, though it fails with a different error:

java.lang.IllegalStateException: Could not find a valid Docker environment. Please see logs and check configuration

which looks like the same error like the one of @jonashackt in the linked commit above

jonashackt commented 3 years ago

@LorenzoBettini not a real fix, but we went with the workaround to not run testcontainers tests on Windows right now - but have all the other tests and the build there. Therefore we used @Testcontainers(disabledWithoutDocker = true) to disable the testcontainers test on systems, where the Docker environment doesn't work as expected (see https://github.com/codecentric/spring-boot-admin/commit/c16ffc13c91d9e61ce5bd06b3e721e304b281a52).

LorenzoBettini commented 3 years ago

@jonashackt I basically did the same ;)

amyreit commented 2 years ago

i've actually been able to start a BrowserWebDriver container on my windows 2019 vm but when I try getWebDriver() I hit this error - org.rnorth.ducttape.TimeoutException: Timeout waiting for result with exception at org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:54) at org.testcontainers.containers.BrowserWebDriverContainer.getWebDriver(BrowserWebDriverContainer.java:292)

Has there been any progress on this?

kiview commented 2 years ago

@amyreit Can you please specify which steps and workaround you did to get Testcontainers working to this point on Windows Server 2019 with LCOW enabled?

Also, can you please verify if this example works with your setup? https://github.com/testcontainers/testcontainers-java-repro

amyreit commented 2 years ago

my bad, it was late and I was desperately googling "unable to get webdriver from testContainer on windows" - missed that this issue was using LCOW. I'm using a plain windows docker container. But I then also later read that any use of testContainers on 2019 is unsupported, so I assume I am just out of luck?

kiview commented 2 years ago

How do you define Windows Docker Container in this case? Windows container should not directly work with Testcontainers and more specifically, I don't think the Selenium images in BrowserWebdriverContainer would be Windows container compatible.

Did you try running the example I linked to above in your setup? This would help us understand the actual problem better.

gesellix commented 2 years ago

Is there any shortlist of issues/tasks to be solved to make Testcontainers work on WCOW? I'd like to help and enable native WCOW support. Creating multi-arch/multi-platform images for Ryuk should only be a matter of time (been there for my own projects), but I suspect there might be harder issues to be solved?

edit: I'm going to create a dedicated issue.