I have a Spring Boot application with integration tests that are using testContainers.
Till recently, I used Docker Desktop and was able to easily run the test from within Intellij or from CLI.
Recently I changed my Windows machine to Rancher desktop.
Now when trying to run the integration tests gradle integrationTest I'm getting this error:
Caused by: java.lang.IllegalStateException: Previous attempts to find a Docker environment failed. Will not retry. Please see logs and check configuration
at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:109)
at org.testcontainers.DockerClientFactory.getOrInitializeStrategy(DockerClientFactory.java:136)
at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:178)
at org.testcontainers.LazyDockerClient.getDockerClient(LazyDockerClient.java:14)
at org.testcontainers.LazyDockerClient.authConfig(LazyDockerClient.java:12)
at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:310)
Is there an additional configuration that is needed in Intellij or Rancher or Windows to make it work?
UPDATE Feb 2022: As reported here TestContainers works nicely with Rancher Desktop 1.0.1.
Based on the following two closed issues - first, second - in the testcontainers-java github, Testcontainers doesn't seem to support Rancher Desktop, at least officially.
I'm running rancher desktop version 1.0.0 on my windows mashine and could get testcontainers to work just by simple adding 'checks.disable=true' in .testcontainers.properties (located under C:\Users<your user>)
updating Rancher Desktop to version 1.0.1 fixed this issue for me
I got this error because my Rancher was using containerd. If you also use Rancher Desktop try to switch to dockerd under settings, but first back up the data you have just in case.
Related
This has been happening ever since I have updated Intellij (IDEA CE 2020.3) to a newer version (today). I am getting this exception from the plugin when running the Develop on Kubernetes Run Configuration that I usually use with my local Minikube instance to get all of the services in the cluster up and running, and able to Debug in debug mode.
My local Minikube instance is fine shown by the following:
(Dev) $ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
I've tried checking for updates, restarting Intellij, and I am still getting the same thing. It must be something in relation to my Intellij Update but we'll have to see...
The full stack trace is:
java.util.ServiceConfigurationError: io.grpc.ManagedChannelProvider: io.grpc.netty.shaded.io.grpc.netty.NettyChannelProvider not a subtype
at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1236)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
at io.grpc.ServiceProviders.loadAll(ServiceProviders.java:67)
at io.grpc.ServiceProviders.load(ServiceProviders.java:42)
at io.grpc.ManagedChannelProvider.<clinit>(ManagedChannelProvider.java:37)
at io.grpc.ManagedChannelBuilder.forAddress(ManagedChannelBuilder.java:37)
at com.google.cloud.tools.intellij.kubernetes.skaffold.events.SkaffoldEventHandler.newManagedChannel(SkaffoldEventHandler.kt:319)
at com.google.cloud.tools.intellij.kubernetes.skaffold.events.SkaffoldEventHandler.listenEvents(SkaffoldEventHandler.kt:75)
at com.google.cloud.tools.intellij.kubernetes.skaffold.run.SkaffoldCommandLineState$startProcess$1.invokeSuspend(SkaffoldCommandLineState.kt:189)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:740)
I am getting the same behaviour in both DEBUG mode and RUN mode.
Environment Info
IDE type: IntelliJ
IDE version: Community Edition 2020.3
Cloud Code version: 20.10.1-202
Skaffold version: v1.14.0
Operating System: Windows 10 Pro 64-bit
Any help, suggestions or resolutions would be really appreciated so thank you in advance! Thanks
This issue was fixed with patch release 20.12.1 that was put out shortly after the EAP release. Please try it out and if you run into any other issues feel free to post on our GitHub. – eshaul
Background
I am tasked with replacing our IE based printing logic with Chromium so that we can eventually support running our current server software on Windows Server Core or potentially other operating systems that support .Net Core. My current thought is to either use Chromium embedded framework or to make use of Puppeteer. I am leaning towards the later because I feel it would be easier to port between operating systems.
Issue
Originally it failed to start with an error about sandboxing so I added the no-sandbox flag. Now when I try to load Chromium it fails to start with the exception below stating that it cannot load chrome.dll
PS C:\Program Files (x86)\Google\Chrome\Application>> .\chrome --headless --enable-logging --disable-gpu --screenshot="C:\screen.png" "https://www.chromestatus.com/"
Which yields the following error in the debug.log file:
[0813/133208.016:ERROR:main_dll_loader_win.cc(134)] Failed to load Chrome DLL from c:\Program Files (x86)\Google\Chrome\Application\68.0.3440.106\chrome.dll: The specified module could not be found. (0x7E)
I have checked around the internet and found a few mentions of this error but the suggested fixes don't seem to fix the issue.
I was able to download Chromium 72.0.3592.0 via Chocolatey and the issue is resolved in that version. I tested using Server Core 2016 LTSB.
choco install chromium --pre -y
chrome --headless --disable-gpu --dump-dom --enable-logging https://www.chromestatus.com/ --no-first-run
Edit:
If you are attempting to run Selenium Tests using Docker windowsservercore and chromium: The command line tests of chromium chrome.exe appear to never work from the container command line.
However when you run dotnet test app.csproj or dotnet vstest app.dll inside the container the webdriver successfully starts and drives the browser
This has been reported to the Chromium team. It appears that Chromium 68+ might have issues with Windows Server 2016.
https://bugs.chromium.org/p/chromium/issues/detail?id=873097
I have created API's in API connect toolkit. For testing the API locally in Explore tab, I am trying to start server.
But getting "Error: It appears that Docker for Windows has not been installed. To install Docker for Windows, please visit https://docs.docker.com/docker-for-windows/install/ For more information, check the docs" error.
From my understanding you don't need docker to test locally in toolkit. Any suggestions to fix the issue?
More Info: APIC version: API Connect: v5.0.8.3 (apiconnect: v2.7.209) NPM version : 6.1.0
It used to work before suddenly I am getting the above error. I tried re-installing but issue persist.
With new versions of APIC you must have Docker installed and working properly on your Windows environment to be able to install the API Connect Toolkit with DataPower.
Please find the steps to install the APIC toolkit on these pages:
https://www.ibm.com/support/knowledgecenter/en/SSFS6T/com.ibm.apic.toolkit.doc/tapim_cli_install.html
https://www.ibm.com/support/knowledgecenter/en/SSFS6T/com.ibm.apic.toolkit.doc/tapim_apic_test_with_dpdockergateway.html
I am beginning to set up on Restcomm Mobicents framework.
In particular I am trying to set up Restcomm on my Windows 8.1 laptop.
Can anyone assist with how to set up RESTCOMM on Windows Server please. The reason I ask this is that most of the information is presumed to be on Linux, Ubuntu. Environments like "installation of screen" and also any sample configuration shared are for Ubuntu, Linux environments, but not specifically on Windows.
Restcomm is currently prepared to run natively on Linux operating systems, indeed.
Considering the diversity of OSs and configurations, a Docker image was created to gather everything Restcomm needs to run properly, as an independent layer.
Please check the following links to install Docker in Windows 8.1 and use Restcomm docker image.
About docker: https://www.docker.com/what-docker
Docker installation: http://docs.docker.com/windows/step_one/
About Restcomm docker image: http://www.telestax.com/docker-image-for-mobicents-restcomm-7-3-0/
Restcomm docker image: https://hub.docker.com/r/gvagenas/restcomm/
You should avoid installing Restcomm on windows, although the simulation will work, when you will have to go live, you will be unable because Windows does not implements the SCTP stack need by Restcomm.
I am attempting to start Apache Geronimo using the command:
./bin/geronimo run
When I do this, it spins for a minute, issues the message "Main not found" and exits.
This article suggests that it is a system resource issue:
http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5551-Failing-to-start-the-server-with-the-error-quot-Main-not-found-quot-td1324013.html
I have tried it on both an Amazon EC2 box (running Linux), and an Azure A1 box (running Windows Server), and I have tried the "Full Profile Release" and "Web Profile Release" of Geronimo, all with no change.
I'm at a complete loss as to what I could try. I am led to believe that the EC2 box, at the very least, should have the muscle to run Geronimo.
Any suggestions would be welcome.
Version 3 of Apache Geronimo is designed to run on JRE 1.7 instead of JRE 1.8. As stated in the other answers, the issue was caused by Geronimo being run on JRE 1.7 instead of 1.8.
You are not limited to JRE 1.7 and earlier in order to run Geronimo though. Therefore, all you have to do is to rename or copy the property jre-1.7 in the file etc/config.properties in your installation to jre-1.8. Afterwards, you should be able to run Geronimo without an error.
This has a huge benefit, since now you will be able to run programs on Geronimo that use Java 8 features.
It turns out that the issue is that I had the wrong version of the JDK installed. I had installed the most recent version (8), but Geronimo apparently won't work with that. When I instead installed version 6, everything worked fine.
I was getting the same error with Java 8. I tried the latest version of Java SE 7 and that resolved the problem. So I wouldn't use Java 6, since it is and has been out of support for awhile now (read: security issue).