I tried delploying kie workbench using docker command docker run -p 8080:8080 -p 8001:8001 -d --name drools-wb jboss/business-central-workbench-showcase:latest and kieserver using the docker command docker run -p 8180:8080 -d --name kie-server --link drools-wb:kie-wb jboss/kie-server-showcase:latest. I deployed a sample drl file to kie server using the business central. The screen image after deployment is as shown below.
The remote server is given as 172.17.0.3:8080. But when I try to test the deployment file using Postman the server is not responding.The requests are getting timed out.The two endpoint services I tried to access are http://172.17.0.3:8080/kie-server/services/rest/server/and http://172.17.0.3:8080/kie-server/services/rest/server/DemoRule_1.0.0-SNAPSHOT. First of all Iam not understanding why is it getting deployed in some remote server and not localhost. Secondly why is it not getting accessible. I even tried the kie server container endpoint http://localhost:8180/kie-server/services/rest/server/. But none of this works. Can someone help me understand the problem.
I found the answer for myself. The service was available at http://localhost:8180/kie-server/services/rest/server/containers/instances/DemoRule_1.0.0-SNAPSHOT. That's were the actual controller was available. Port 8080 was endpoint for wildfly server. The IP 172.17.0.3:8080 was related to docker container. It had nothing do with the controllers.
Related
I am trying to connect to rabbitmq management interface via vm that I created on Azure portal using docker. However, even though rabbitmq is started, cant access the ports.
P.S. the management plugin is enabled. I did almost everything on the internet however still no progress.
I used commands such as:
docker run -d --hostname my-rabbit --name some-rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3-management
Also tried to dockerize a rabbitmq instance using docker containers. Also no progress.
I got already binding port error however I killed the ports and run again so there was no issue with it. Still no access to localhost:15672.
If anyone also trying to solve this issue, I solved it by adding an inbound port (15672) to the VM via Azure.
Im currently trying to install the Jfrog container registry via the docker image and it errors just as it reaches the ui after setup. My process of installing is as follows
docker pull docker.bintray.io/jfrog/artifactory-jcr:latest
docker run --name artifactory -d -p 8081:8081 docker.bintray.io/jfrog/artifactory-jcr:latest
I navigate to localhost:8081/artifactory and after the setup image it redirects to localhost:8082/ui/ and shows page not found. Im not sure why the port changes and I have looked at the documentation for installing and there isnt anything about the port change. changing the port back to 8081 just shows a HTTP Status 404 – Not Found.
Im on docker for windows, looking to test this out. Any ideas what im doing wrong?
Artifactory internal architecture has changed, and there are separate micro services for Artifactory and its UI. This is done via the JFrog router, which listens on port 8082.
If you follow the Docker installation documentation, you can see you need to also expose port 8082.
docker run --name artifactory -d -p 8081:8081 -p 8082:8082 docker.bintray.io/jfrog/artifactory-jcr:latest
You can also drop the port 8081 and stick to 8082 only. 8081 allows for direct access to Artifactory (bypassing the jfrog router) for better performance on high load systems.
I have a java application and it can successfully connect to api.meraki.com in my local machine but when I deploy my java application to the test server,
the application which lives in a docker container can not connect to api.meraki.com.
In the host machine, I can also curl the api.meraki.com but inside my docker container (docker exec -it xxx /bin/bash), I can't curl as it gives a connection refused error.
I tried to use a new API key to test server but it is still giving connection refused error. I also tried to allow my test server from Meraki dashboard but no success.
Any ideas that what is the problem and the solution?
edit: i run container with
docker run -dit -p 9078:8080 -e "SPRING_PROFILES_ACTIVE=prod,swagger,preprod" --name abc -v /etc/localtime:/etc/localtime:ro -v /etc/hosts:/tmp/hosts example.com.com:5000/abc:v1.12.5
and in my container when i run getent hosts api.meraki.com resolves dns as:
209.206.57.71 mun211.meraki.com api.meraki.com emea.api.meraki.com n23.meraki.com
test server was behind proxy and it was not configured, configuring both container and the application resolved the problem. (i think the application is connecting other service by bypassing the proxy.
I have pulled hyperledger/composer-rest-server docker image , Now if i wanted to run this docker image then on which port should i expose ? Like mentioned below.
docker run --name composer-rest-server --publish XXXX:YYYY --detach hyperledger/composer-rest-server
Here please tell me what should i replace for XXXX & YYYY ?
I run the rest server in a container using a command as follows:
docker run -d \
-e COMPOSER_CARD="admin#test-net" \
-e COMPOSER_NAMESPACES="never" \
-v ~/.composer:/home/composer/.composer \
--name rest -p 3000:3000 \
hyperledger/composer-rest-server
For the Published Port, the first element is the Port that will be used on the Docker Host, and the second is the Port it is forwarded to inside the container. (The Port inside the container will always be 3000 by default and is more complex to change.)
I'm passing 2 environment variables into the Container which the REST server will recognise - Namespaces just keeps the endpoints simple, but the COMPOSER_CARD is essential for the REST server to start properly.
I'm also sharing a volume between the Docker Host and the Container which is where the Cards are stored, so that the REST server can find the COMPOSER_CARD referred to in the environment variable.
Warning: If you are trying to test the REST server with the Development Fabric you need to understand the IP Network and Addressing of the Docker containers - by default the Composer Business Network Cards will be built using localhost as the address of the Fabric servers, but you can't use localhost in the REST server container as that will redirect inside the container and fail to find the Fabric.
There is a tutorial in the Composer Docs that is focused on Multi-User authentication, but it does also cover the networking aspects of using the REST Server Container. There is general information about the REST server here.
In short - Can I run Elasticsearch & Dropwizard app in separate docker containers and allow them to see each other?
I am running Elasticsearch 6.2.2 from Docker (on mac). using the command..
docker run -p 9200:9200 -p 9300:9300 -e "network.host=0.0.0.0" \
-e "http.port=9200" -e "discovery.type=single-node" \
docker.elastic.co/elasticsearch/elasticsearch:6.2.2
I can access Elasticsearch (POST & GET) fine using Postman directly on mac e.g
localhost:9200/testindex/_search
However when running a Dropwizard application from a different docker image which accesses the docker Elasticsearch instance, I get connection refused using same host and port (localhost 9200).
I have no problems at all when running the Dropwizard app direct from an IDE, only when its running from a docker image and accessing ES from a different image.
docker image -p 8080:8080 -p 8081:8081 testapp
Has anyone else had similar issues or solved this in the past?
I'm assuming it 'network' related and that connecting to localhost from one docker image will not be map to the other docker image
The issue you are facing is in the url you pass to the dropwizard container. As a container by default has its own networking, a value of localhost means the dropwizard container itself, not what you see as your local host from outside the container.
Please have a look at docker networking, how you can link two containers by name. I would suggest to check out docker-compose for multi-container setups on a local machine.
What would also work (but is not good practice) is to pass the dropwizard container the ip of your machine as elasticsearch host because you created a port mapping from your host into the elasticsearch container. But better have a look at compose to do it as it is supposed to be done.
For details how to use compose please have a look at this answer with a similar example.