Skip to content
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

Cannot connect to docker container started by Arquillian Cube #274

Closed
oscarfh opened this issue Feb 2, 2016 · 31 comments
Closed

Cannot connect to docker container started by Arquillian Cube #274

oscarfh opened this issue Feb 2, 2016 · 31 comments

Comments

@oscarfh
Copy link

oscarfh commented Feb 2, 2016

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:

<dependency>
          <groupId>org.arquillian.cube</groupId>
          <artifactId>arquillian-cube-docker</artifactId>
          <version>1.0.0.Alpha8</version>
          <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
            <version>4.3</version>
            <scope>test</scope>
        </dependency>
        <dependency>
              <groupId>com.github.docker-java</groupId>
              <artifactId>docker-java</artifactId>
              <version>2.1.4</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.resteasy</groupId>
            <artifactId>resteasy-jaxrs</artifactId>
            <version>3.0.14.Final</version>
            <scope>test</scope>
        </dependency>

My Arquillian.xml is the following:

<?xml version="1.0"?>
<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://jboss.org/schema/arquillian"
  xsi:schemaLocation="http://jboss.org/schema/arquillian
  http://jboss.org/schema/arquillian/arquillian_1_0.xsd">

   <extension qualifier="docker"> 
      <property name="connectionMode">STARTORCONNECT</property> 
      <property name="dockerContainers"> 
           jboss:
            image: test/wildfly
            portBindings: [9990->9990/tcp, 8080->8080/tcp]
            await:
                strategy: polling
                sleepPollingTime: 15 s #1
                iterations: 3 #2
      </property>
  </extension>

     <container qualifier="jboss" default="true">
      <configuration>
           <property name="managementAddress">localhost</property>
            <property name="managementPort">9990</property>
            <property name="username">admin</property>
            <property name="password">admin</property>
      </configuration>
  </container>

</arquillian>

If there is no container with this name, I get:

org.arquillian.cube.spi.CubeControlException: Could not start jboss
Caused by: java.lang.IllegalArgumentException: Cannot connect to jboss container

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:

Caused by: com.github.dockerjava.api.ConflictException:
Conflict. The name "jboss" is already in use by container 60d6936cf7bf. You have to remove (or rename) that container to be able to reuse that name.

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!

@lordofthejars
Copy link
Member

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).

@oscarfh
Copy link
Author

oscarfh commented Feb 2, 2016

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.

@lordofthejars
Copy link
Member

hummm it is strange since you are running in Linux and it should works natively.

@oscarfh
Copy link
Author

oscarfh commented Feb 2, 2016

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)

@lordofthejars
Copy link
Member

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).

@aslakknutsen
Copy link
Member

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

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.

@aslakknutsen
Copy link
Member

@oscarfh Do you have this example pushed somewhere?

@aslakknutsen
Copy link
Member

@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.

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

I will push it as soon as possible to my github account, would that be ok?

@aslakknutsen
Copy link
Member

@oscarfh That would be perfect.

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

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 :)

@aslakknutsen
Copy link
Member

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..

@lordofthejars
Copy link
Member

Documentation is wrong about this. @oscarfh you have your PR if you want to help :)

@aslakknutsen
Copy link
Member

Here is the certpath issue; #279

Doesn't seem to make a difference, but.. still technically wrong :)

@aslakknutsen
Copy link
Member

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:
jboss-dockerfiles/base@328f451

@goldmann any comment?

@aslakknutsen
Copy link
Member

And here is an improvment to the missing SS command issue; #280

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

@lordofthejars Cool :) I will make it :)

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

@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

@goldmann
Copy link
Contributor

goldmann commented Feb 3, 2016

@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?

@oscarfh
Copy link
Author

oscarfh commented Feb 3, 2016

#281 Just opened it. I am working on it now.

@aslakknutsen
Copy link
Member

@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.

@goldmann
Copy link
Contributor

goldmann commented Feb 3, 2016

Please open an RFE against https://github.com/jboss-dockerfiles/base, I'll add it.

@lordofthejars
Copy link
Member

@aslakknutsen Can we close this issue with won't fixed?

@oscarfh
Copy link
Author

oscarfh commented Feb 5, 2016

yes

@aslakknutsen
Copy link
Member

Yeah, I think we got all issues covered elsewhere

@adriano-fonseca
Copy link

@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?

@adriano-fonseca
Copy link

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.

@lordofthejars
Copy link
Member

lordofthejars commented May 31, 2017 via email

@adriano-fonseca
Copy link

My quilifier is like follows:

wildfly:9.0.0.Final:remote admin Admin#70365

@lordofthejars
Copy link
Member

lordofthejars commented May 31, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants