Closed oscarfh closed 8 years ago
Caused by: com.github.dockerjava.api.ConflictException:
This is not because of Cube but because of Docker, if all the test is executed within Cube then it takes care of cleaning this, if not you need to do it manually.
The only way that the docker image gets started is having the container qualifier match the Docker Container name
Yes this is the case when you want to deploy the deployment file using @Deployment annotation, and not using standalone mode.
Why am I getting the "cannot connect error" and why is my STARTORCONNECT being ignored Probably is not ignored but there is another error.
Have you seen this example? https://github.com/arquillian/arquillian-cube/tree/master/docker/ftest Here you can see an example of Wildfly (apart from other containers).
Thanks for the reply. I didn't know this example. Taking a look at it, I can't see any reason why I can't connect to the container. I will take a more detailed look at it.
hummm it is strange since you are running in Linux and it should works natively.
For information, I get this printed when I run mvn isntall.
CubeDockerConfiguration: serverUri = unix:///var/run/docker.sock certPath = /home/user/.boot2docker/certs/boot2docker-vm dockerServerIp = localhost definitionFormat = CUBE dockerContainers = containers: jboss: alwaysPull: false await: {iterations: 3, sleepPollingTime: 15 s, strategy: polling} image: test/wildfly portBindings: [9990/tcp, 8080/tcp] readonlyRootfs: false
/home/user/.boot2docker/certs/boot2docker-vm doesn't exist in my machine (ubuntu doesn't need boot2docker)
so true .... why is this value set mmmm @aslakknutsen are you able to test it on Linux without boot2docker? I am not sure if this might affect your test but obviously this is wrong (even if it is not used in case of Linux it prints wrong information).
@oscarfh Are you binding mgm port to 0.0.0.0? https://github.com/arquillian/arquillian-cube/blob/master/docker/ftest/src/test/resources/wildfly/Dockerfile#L3
Yes. And exposing ports 8080 and 9990,
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
I can access the management using the browser. It seems that it is a step "before" reaching wildfly: I think Arquillian Cube can't identify that the container is started, in order to connect to it.
@oscarfh Do you have this example pushed somewhere?
@oscarfh The ."CubeControlException: Could not start jboss" happen normally due to not being able to ping the contianer. The polling strategy will by default ping all portBindings.
I will push it as soon as possible to my github account, would that be ok?
@oscarfh That would be perfect.
Here is it: https://github.com/oscarfh/docker-cube-test
It is a simple project, runs on my local wildfly (9.0.2 fresh install), but can't start the container using docker.
Just in case there is a need for some code change in docker cube, I would be happy to make the pull request :)
This fixes the reconnect issue; https://github.com/oscarfh/docker-cube-test/pull/1
It's a Cube extension setting, not a Docker setting. :)
It still fails the first time you start it, but success on second time. The reason it fails to connect on first attempt is because the 'ss' command is not found in the contianer image. Which is a bit odd as it's based on centos:7..
Documentation is wrong about this. @oscarfh you have your PR if you want to help :)
Here is the certpath issue; https://github.com/arquillian/arquillian-cube/issues/279
Doesn't seem to make a difference, but.. still technically wrong :)
I've been using the jboss/wildfly images for all demos for a long time, but never WildFly 10. It seems jboss/base changed from fedora:20 to centos:7 some time ago: https://github.com/jboss-dockerfiles/base/commit/328f451604a917a9680516ab55297811836ee296
@goldmann any comment?
And here is an improvment to the missing SS command issue; https://github.com/arquillian/arquillian-cube/issues/280
@lordofthejars Cool :) I will make it :)
@aslakknutsen Which jboss/wildfly image are you using? I tried the 9.0.2.Final and it didn't work (still using CentOS). I was able to use it by using this image: https://github.com/arun-gupta/docker-images/blob/master/wildfly-ubuntu/Dockerfile
@aslakknutsen Yep, it was changed long time ago as it was a popular request + made the resulting image smaller. Is there any issue with it?
@goldmann the jboss/wildfly:10 image is missing the ss command. But my local centos:7 image has it. Not sure why atm. But Cube rely on SS by default to detect when a Service has started listening on the ports we need to communicate with.
Please open an RFE against https://github.com/jboss-dockerfiles/base, I'll add it.
@aslakknutsen Can we close this issue with won't fixed?
yes
Yeah, I think we got all issues covered elsewhere
@lordofthejars I am having the same issue in a widows machine. I have tried to install the legacy docker toolbox, but even doing that I got:
Caused by: java.io.IOException: Cannot run program "boot2docker": CreateProcess error=2, O sistema nÒo pode encontrar o arquivo especificado at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047) at org.arquillian.spacelift.task.os.SpawnProcessTask.process(SpawnProcessTask.java:107) at org.arquillian.spacelift.task.os.SpawnProcessTask.process(SpawnProcessTask.java:34) at org.arquillian.spacelift.task.Task.run(Task.java:98) at org.arquillian.spacelift.task.Task$1.call(Task.java:70) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)
Boot2Docker shouldn't be used anymore. It seens that the docker recomendation is to use docker-machine. Do you have some tip to give about this cenario?
The boot2docker Windows Installer is officially deprecated in favor of the new Docker Toolbox. And Docker Toolbox is depracate in favor of Docker for windows and Docker for Mac. On the future in this plataforms will be more and more rare to be boot2docker availiable.
Are you setting machine name as arquillian property? Is that docker machine started manually?
El 31 may. 2017 4:45 p. m., "Adriano S. Fonseca" notifications@github.com escribió:
The boot2docker Windows Installer is officially deprecated in favor of the new Docker Toolbox. And Docker Toolbox is depracate in favor of Docker for windows and Docker for Mac. On the future in this plataforms will be more and more rare to be boot2docker availiable.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arquillian/arquillian-cube/issues/274#issuecomment-305209167, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcmYQzTX7MwSSaNPQACmosCkIkHUaW_ks5r_X0HgaJpZM4HRYyu .
My quilifier is like follows:
This is not about qualifier but simething relatef to cube conf/bug. Can you paste your arquillian.xml?
El 31 may. 2017 10:34 p. m., "Adriano S. Fonseca" notifications@github.com escribió:
My quilifier is like follows: wildfly:9.0.0.Final:remote admin Admin#70365
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arquillian/arquillian-cube/issues/274#issuecomment-305309006, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcmYf7MRAqCJ5zmayKsz-1_A_3AL5jDks5r_c7XgaJpZM4HRYyu .
I am trying to use Arquillian Cube to use Docker to run my Integration Tests. I have a project which was already using arquillian tests to an existing Wildfly. Now I want it to communicate with a Widlfly that is running on a Docker container. To do so I added the following dependencies:
My Arquillian.xml is the following:
If there is no container with this name, I get:
But the container starts and I am able to connect to the image through docker exec -it jboss bash
If there is a container with this name, I get:
Questions: 1- The only way that the docker image gets started is having the container qualifier match the Docker Container name. If hey do no have a matching name, the docker extension is ignored. Is this expected? 2- Why am I getting the "cannot connect error" and why is my STARTORCONNECT being ignored?
I am using ubuntu 14.04.
$ docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64
Server: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64
Thanks!