0

Happy new year 2017!

Hello everybody!

I have some issues when I try to deploy my docker image in a BlueMix container (where cf ic run = docker run)
I can't access the container from web even if the image is running well inside. I pinged the binded adress:

ping 169.46.18.91
PING 169.46.18.91 (169.46.18.91): 56 data bytes
64 bytes from 169.46.18.91: icmp_seq=0 ttl=48 time=124.247 ms
64 bytes from 169.46.18.91: icmp_seq=1 ttl=48 time=122.701 ms

The image was working locally but now that I gave it an IP and hosted it on bluemix container service, I have reported an issue while the image is setting up after cf ic -v run command

Here are the logs of the command:

cf ic -v run -p 3000 --name bootingtest 1ed1b527771b

DEMANDE : [2017-01-18T10:32:31+01:00]
POST /UAALoginServerWAR/oauth/token HTTP/1.1
Host: login.ng.bluemix.net
Accept: application/json
Authorization: [DONNEES PRIVEES MASQUEES]
Connection: close
Content-Type: application/x-www-form-urlencoded
User-Agent: go-cli 6.22.2+a95e24c / darwin

grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwNzJlYTFmNy00NGRlLTRmYmYtODUxOS1lNmU0NmU2MTk1Y2ItciIsInN1YiI6ImZkMWVmM2Q3LTI2OTQtNDQ4Ni1iNjY2LWRmNTVjY2M4MzVmOCIsInNjb3BlIjpbIm9wZW5pZCIsInVhYS51c2VyIiwiY2xvdWRfY29udHJvbGxlci5yZWFkIiwicGFzc3dvcmQud3JpdGUiLCJjbG91ZF9jb250cm9sbGVyLndyaXRlIl0sImlhdCI6MTQ4NDczMTE3MSwiZXhwIjoxNDg3MzIzMTcxLCJjaWQiOiJjZiIsImNsaWVudF9pZCI6ImNmIiwiaXNzIjoiaHR0cHM6Ly91YWEubmcuYmx1ZW1peC5uZXQvb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJncmFudF90eXBlIjoicGFzc3dvcmQiLCJ1c2VyX25hbWUiOiJlbW1hbnVlbC5zb2xvbUBmci5pYm0uY29tIiwib3JpZ2luIjoidWFhIiwidXNlcl9pZCI6ImZkMWVmM2Q3LTI2OTQtNDQ4Ni1iNjY2LWRmNTVjY2M4MzVmOCIsInJldl9zaWciOiI2MWNkZjM4MiIsImF1ZCI6WyJjZiIsIm9wZW5pZCIsInVhYSIsImNsb3VkX2NvbnRyb2xsZXIiLCJwYXNzd29yZCJdfQ._gxevCN9cCYX3Fw_FUEYvxFsRhHqfOT9KhjZFiHcNao&scope=

REPONSE : [2017-01-18T10:32:32+01:00]
HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
Cache-Control: no-cache, no-store, max-age=0, must-revalidate,no-store
Content-Security-Policy: default-src 'self' www.ibm.com 'unsafe-inline';
Content-Type: application/json;charset=UTF-8
Date: Wed, 18 Jan 2017 09:32:31 GMT
Expires: 0
Pragma: no-cache,no-cache
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=2592000 ; includeSubDomains
X-Backside-Transport: OK OK,OK OK
X-Client-Ip: 91.151.65.169
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Global-Transaction-Id: 1804077409
X-Powered-By: Servlet/3.1
X-Vcap-Request-Id: e683d47d-28aa-43c1-6356-d5818dfd86f1
X-Xss-Protection: 1; mode=block

6f6
{"access_token":"[DONNEES PRIVEES MASQUEES]","token_type":"[DONNEES PRIVEES MASQUEES]","refresh_token":"[DONNEES PRIVEES MASQUEES]","expires_in":1209599,"scope":"cloud_controller.read password.write cloud_controller.write openid uaa.user","jti":"edcd9c51-4521-4f49-bf03-def030e81626"}
0


a9dc3ad4-1a34-4848-9b16-8d1410b79a06

So is there a way to set up the connection from a "close" state to a "waiting for incoming connection" state when i'm running or building the image?

Something like an option cf ic (docker) run -p 3000 --accept_all imageid cmd (I didn't saw it in the --help menu) or maybe you saw something wrong elsewhere?

I thought about logging into the container with docker exec -it ID /bin/bash but I don't know a bash command to accept all incoming connection... (and moreover I think it's the bash of the VM not the container itself)

Thank you for your answers and have a good day!

Emmanuel

Other infos:

Dockerfile

FROM ubuntu:14.04
RUN apt-get update && apt-get -y install python2.7
RUN apt-get -y install python-pip
RUN pip install Flask
RUN pip install ibmiotf
RUN pip install requests
RUN pip install flask-socketio
RUN pip install cloudant
ENV PORT=12345
EXPOSE 12345
ADD ./SIARA /opt/SIARA/
WORKDIR /opt/SIARA/
CMD sleep 80 && python testGUI.py

Flask server port mapping and running:

if __name__ == '__main__':
    # Bind to PORT if defined, otherwise default to 5000.
    port = int(os.environ.get('PORT', 5000))
    socketio.run(app, host='0.0.0.0', port=port)

Clues

I had this warning messages when I used to test my image locally they weren't responsible of any crash but maybe now it's on the cloud this kind of error are responsible of the unsuccessful connection attempt from web?

tl;dr: apparently SSH connection are not available since (apparently) my version of python (2.7) needs an update (??) But SSH aren't supposed to be relevant only in case of https:// connection?

cf ic logs -ft guiplay

2017-01-19T09:17:38.870006264Z /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:334: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
32017-01-19T09:17:38.870062551Z   SNIMissingWarning
�2017-01-19T09:17:38.870081733Z /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:132: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
92017-01-19T09:17:38.870089026Z   InsecurePlatformWarning
�2017-01-19T09:17:39.145906849Z /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:132: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
92017-01-19T09:17:39.145950355Z   InsecurePlatformWarning
�2017-01-19T09:17:39.186165706Z WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.
Y2017-01-19T09:17:39.192990810Z  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
Manu
  • 352
  • 1
  • 4
  • 14

2 Answers2

1

Hmm - I see that you published port 3000 (the -p 3000 parameter in the run command), but the default port would be 5000. In the dockerfile, you switched that to 12345, so that's presumably what you're actually listening on there. Guessing that's the reason you want to open all ports?

Docker only exposes the ports that you tell it to - adding an additional -p 5000 for that default, or -p 12345 according to that Dockerfile, or both should allow you to connect to the app in those cases. Or, if you want to just publish all the ports that are EXPOSEd via the Dockerfile (in this case, that would be 12345), use the -P parameter.

More info: running in the cloud, there is additional security that your container is only accessible via the ports you want published. Within a space (in the private ips from other containers in the same space, or definitely from within the container itself), you should still be able to access those ports. From external, though, only the ports you have published should be accessible. I don't see a way to effectively publish * (and, that seems like a rather questionable practice from a security standpoint)

N Fritze
  • 431
  • 3
  • 9
  • Thank you for your answer N Fritze! I used to expose the same port on my dockerfile, my server and in the command but it didn't worked but it's possible it was something else which was wrong, I keep you in touch! Very good teaching answer ^^ Thanks again – Manu Jan 19 '17 at 08:43
  • I updated the post since it seems it doesn't come from port exposing (but I think you told me the proper way to do so, and it's done now :D) I added clues of maybe a irrelevant problem on local but that can cause troubles once in the cloud, does it looks like a problem to you? (the SSH warnings) – Manu Jan 19 '17 at 09:25
  • And also: Even with the problem mentioned above, the container have already worked 1 time on bluemix, that's why I'm so confused, I'm solving problems step by step and when I found them, but the fact that it has already worked troubles so much! – Manu Jan 19 '17 at 09:52
  • Agreed - that's strange. From the log snippet you posted, looks like it's actually listening on port 5000: `* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)` perhaps, on the `cf ic run` command, try using all three ports: (i..e -p 3000 -p 12345 -p 5000) and see which one lets it work. I think there's a disconnect between the exposed port and which one is actually in use. As to ssh - I wouldn't expect that to be necessary here. Think that's extraneous (famous last works? :) ) – N Fritze Jan 23 '17 at 14:20
  • Thank you for following my topic again haha Got a solution yesterday, without changing anything (port 5000 everywhere), it looks like Bluemix single container is a bit touchy on the parameters, I just add a scalable container (an option when building containers on bluemix) that have in parameters the HTTP Port I want (the one which seems to be not well declared), everything run even after many tries! :) – Manu Jan 25 '17 at 08:38
0

Looks like Bluemix single container service is a bit touchy, it was hard to reach from web until I added a "scalable" container which asks for the required HTTP port.

I think the problem was this http port wasn't exposed, but now problem is solved the way I said above.

Manu
  • 352
  • 1
  • 4
  • 14