I am trying to run the docker example here.
http://chembl.blogspot.com/2020/01/new-chembl-ligand-based-target.html
I can start the docker correctly.
docker run -p 8080:8080 chembl/mcp:25
But when I run this
curl -X POST -H 'Accept: */*' -H 'Content-Type: application/json' -d '{"smiles": "CC(=O)Oc1ccccc1C(=O)O"}' http://127.0.0.1:8080
I got these logging messages.
2020/03/26 13:21:38 Started logging stderr from function.
2020/03/26 13:21:39 Started logging stdout from function.
2020/03/26 13:21:39 OperationalMode: http
2020/03/26 13:21:39 Timeouts: read: 10s, write: 10s hard: 10s.
2020/03/26 13:21:39 Listening on port: 8080
2020/03/26 13:21:39 Writing lock-file to: /tmp/.lock
2020/03/26 13:21:39 Metrics listening on port: 8081
2020/03/26 13:24:53 Upstream HTTP request error: Post http://127.0.0.1:5000/: dial tcp 127.0.0.1:5000: connect: connection refused
I use Mac OS X.
Does anybody know how to fix the problem? Thanks.
I was able to run into the same problem and managed to fix it. All I had to do was increase the resources on Docker Desktop for Mac OS X (the RAM, to be more specific). And also, wait a minute or two as it seems that the module loading is quite resource-intensive.
Related
In my java spring-boot app time to time I get this error.
Restarting docker and starting container again fixes it.
But I want to know how can I deal with it faster?
Docker logs do not give me anything - for example issue occurred now (14:25) but logs are old:
2019-02-04 13:19:41.885 [error] <0.1509.0> closing AMQP connection <0.1509.0> (172.17.0.1:55060 -> 172.17.0.2:5672 - rabbitConnectionFactory#6049c421:648):
missed heartbeats from client, timeout: 60s
2019-02-04 13:19:41.903 [error] <0.1517.0> closing AMQP connection <0.1517.0> (172.17.0.1:55064 -> 172.17.0.2:5672 - rabbitConnectionFactory#575a1719:1056):
missed heartbeats from client, timeout: 60s
PS C:\Users\user> docker logs -f rabbit-fox
I created this container by following command:
docker run -d --hostname my-rabbit --name rabbit-fox -p 5672:5672 -p 8090:15672 rabbitmq:3-management
I used a different port to expose 4369:4369, you can try. I dont know the reason but its worked for me. In the rabbit documentation is said about this port, you can see more in https://www.rabbitmq.com/networking.html
Mac here, running Docker Community Edition Version 17.12.0-ce-mac49 (21995).
I have Dockerized a web app with a Dockerfile like so:
FROM openjdk:8
RUN mkdir /opt/myapp
ADD build/libs/myapp.jar /opt/myapp
ADD application.yml /opt/myapp
ADD logback.groovy /opt/myapp
WORKDIR /opt/myapp
EXPOSE 9200
ENTRYPOINT ["java", "-Dspring.config=.", "-jar", "myapp.jar"]
I then build that image like so:
docker build -t myapp .
I then run a container of that image like so:
docker run -it -p 9200:9200 --net="host" --env-file ~/myapp-local.env --name myapp myapp
In the console I see the app start up without any errors, and all seems to be well. Even my metrics publishes (which publish heartbeat and other health metrics every 20 seconds) are printing to the console as I would expect them to. Everything seems to be fine.
Except when I go to run a curl against my app from another terminal/session:
curl -i -H "Content-Type: application/json" -X POST -d '{"username":"heyitsme","password":"12345"}' http://localhost:9200/v1/auth/signIn
curl: (7) Failed to connect to localhost port 9200: Connection refused
Now, if this were a situation where the /v1/auth/signIn path wasn't valid, or if there was something wrong with my request entity/payload, the server would pick up on it and send an error (I assure you; as I can confirm this exact same curl works when I run the server outside of Docker as just a standalone service).
So this is definitely a situation where the curl command can't connect to localhost:9200. Again, when I run my app outside of Docker, that same curl command works perfectly, so I know my app is trying to standup on port 9200.
Any ideas as to what could be going wrong here, or how I could begin troubleshooting?
The way you run your container has 2 conflicting parts:
-p 9200:9200 says: "publish (bind) port 9200 of the container to port 9200 of the host"
--net="host" says: "use the host's networking stack"
According to Docker for Mac - Networking docs / Known limitations, use cases, and workarounds, you should only publish a port:
I want to connect to a container from the Mac
Port forwarding works for localhost; --publish, -p, or -P all work. Ports exposed from Linux are forwarded to the Mac.
Our current recommendation is to publish a port, or to connect from another container. This is what you need to do even on Linux if the container is on an overlay network, not a bridge network, as these are not routed.
The command to run the nginx webserver shown in Getting Started is an example of this.
$ docker run -d -p 80:80 --name webserver nginx
Check that your app bind to 0.0.0.0:9200 and not localhost:9200 or something similar
Problem seems to be in the network mode you are running the container.
Quick test: Login to your container and run the curl cmd there, hopefully it works. That would isolate the problem to request not being forwarded from host to container.
Try running your container on the default bridge network and test.
Refer to this blog for details on the network modes in docker
TLDR; You will need to add an IPtables entry to allow the traffic to enter your container.
I've followed this tutorial: https://www.digitalocean.com/community/tutorials/how-to-migrate-a-parse-app-to-parse-server-on-ubuntu-14-04
All fine, except that when it comes to sending a POST request to the Parse-server, I get an error 502. Here are both POST and GET requests which return a 502 when using https and a 301 when using HTTP:
curl -X POST \
-H "X-Parse-Application-Id: AppId" \
-H "Content-Type: application/json" \
-d '{"score":1337,"playerName":"Sammy","cheatMode":false}' \
https://domain.name/parse/classes/GameScore
curl -H "X-Parse-Application-Id: APPID" http://domain.name/parse/classes/GameScore
I specially wanted to check if
mongod.conf
is fine (mine is the same as the one on the tutorial) and if
/etc/nginx/sites-enabled/default
is also fine.
Here is the log:
2016/03/07 22:11:30 [error] 7288#0: *7 connect() failed (111: Connection refused) while connecting to upstream, client: myComputerIP, server: domain.name, request: "GET /parse/classes/GameScore HTTP/1.1", upstream: "http://127.0.0.1:1337/classes/GameScore", host: "domain.name"
Any ideas? Thanks
I was running into the same problem, in my case was an error due to the change of the path of an internal dependency during the migration.
I was able to troubleshoot it using:
pm2 logs 0
Hope it helps.
There was a syntax error in my cloud code.
Looks like your node.js server isn't running (or not listening on port 1337) - make sure it's up by running and if not, start the parse-server.
here is an example of part of my circle.yml how I am currently verifying if my mongodb docker container is responding to an http request, so that I can verify if the response is ok and that the server is up.
test:
override:
# RUN DOCKER CONTAINERS
# MongoDB -------------
- docker run --name MongoDB -p 27018:27018 -d mongo:3.0 mongod --port 27018 --replSet "rs"; sleep 10
- curl --retry 10 --retry-delay 5 -v http://localhost:27018
with this curl it's working fine, sometimes.
And sometimes it gives me this error:
curl --retry 10 --retry-delay 5 -v http://localhost:27018
* About to connect() to localhost port 27018 (#0)
* Trying 127.0.0.1... Connection refused
* couldn't connect to host
* Closing connection #0
How can I improve this, to make it more reliable so my tests won't sometimes pass and sometimes fail, if I rebuild the same build?
note: this question was also asked on discuss.circleci.com
I am trying to manage a EC2 cloud instance with deltacloud API through curl. With the mock driver everything works fine: deltacloudd -i mock -r 10.0.0.3
curl --user "mockuser:mockpassword" "http://10.0.0.3:3001/api/instances?format=xml"
curl -X POST --user "mockuser:mockpassword" "http://10.0.0.3:3001/api/instances/inst1/stop?format=xml"
But with EC2 I am unable to start a stopped instance: deltacloudd -i ec2 -P eu-west-1 -r 10.0.0.3 -V
curl --user "accesskey:secretaccesskey" "http://10.0.0.3:3001/api/instances?format=xml"
curl -X POST --user "accesskey:secretaccesskey" "http://10.0.0.3:3001/api/instances/i-NNNNNNNN/start?format=xml"
Returns: The required capability to execute this operation is missing
Deltacloud log output:
Listening on 10.0.0.3:3001, CTRL+C to stop
D, [2014-06-25T10:47:34.149001 #3575] DEBUG -- : New Aws::Ec2 using per_thread-connection mode
D, [2014-06-25T10:47:34.150897 #3575] DEBUG -- : Opening new HTTPS connection to ec2.eu-west-1.amazonaws.com:443
10.0.0.5 - - [25/Jun/2014 10:47:34] "GET /api/instances?format=xml HTTP/1.1" ec2 eu-west-1 200 1628 0.6204
10.0.0.5 - - [25/Jun/2014 10:48:14] "POST /api/instances/i-NNNNNNNN/start?format=xml {} HTTP/1.1" ec2 eu-west-1 412 60 0.0077
Its therefore obvious that deltacloud process GET, but not forward the POST request to AWS.
The Problem also happens even by clicking the start button at the webinterface (10.0.0.3:3001). The accesskey and secretaccesskey are working fine with python-boto.
Can anyone suggest me whats wrong?
The short answer is, that you can not start a stopped Amazon EC2 instance with deltacloud in the current version 1.1.3 (2013-04-17). Perhaps there will be soon a newer version, but since Red Hat reduced their support the development of deltacloud slowed down.