at least one port for external use (excluding 8080), please

148 votes

open for external use at least one port (I want to use sockets, but the proxy on port 80 redirect http traffic only)

or vote

At least 10 ports for external use I would say.

I want to get data from a robot (ROS - robotic operating system) that has a communication of publisher to listener per port. That can be quit some listeners (motorspeed, orientation limbs,etc. ) I want to be able to send this data to the cloud (openshift) where I can present the data in a webinterface. Also including streaming video from the robots head. Don't know if the openshift-platform is adequate for this because port availability is bottleneck. The amount of data to be streamed is not that big (not 10's of viewers of streaming video).

Hi

I'd like to host a SIP proxy that listens for external traffic over both UDP and TCP on port 5060 (as mandated by RFC 3261). Is this possible today with the JBoss AS7 cartridge, and if not, would it be covered by this feature? Are there any timescales for this work?

Thanks!

I should say that I've tried binding to port 5060 using the internal Openshift IP and get a permission denied error. Presumably this is because we can only bind to ports 15000+?

Right now what I want to do is create an easy way to share some 3D worlds which are built using Minecraft (because its surprisingly great for that).

In general I just tend to come up with ideas for which http may not be the best approach and I want to use my gears as a play-pen for those ideas. I can work around this with ssh tunnelling on my own workstations but that's not ideal when I want to get other people to look at or comment on them.

External ports can only be opened one at a time. They must be opened by the cartridge. And you only get 5 per gear.

With the ability to download a custom cartridge into your gear, this is now possible. Check the "mock" cartridge manifest for "PUBLIC_PORT" examples.

Just one problem, though: this doesn't work quite like the cartridge authors guide indicates (yet). Public ports are actually only exposed when the app is scalable. So you need to start with a scalable cartridge (the mock one is, so are PHP/Ruby/etc.) and install it in a scalable app.

That sucks if you don't need scalability because (a) you have to make the cartridge scalable (b) you have to remember to make the app scalable (c) you have to waste memory on an HAproxy cartridge and (d) most scalable cartridges blow a port on the HTTP connection. I have a bug in to expose ports on non-scalable apps too -- watch that to see what happens.

If you can hang tight until OpenShift Online's new release next week, there will be a hackish workaround via an unrelated feature. You can add the ssl_to_gear option on your endpoint to get it routed externally, even on a non-scaled app. This is intended for a use case of terminating SSL directly on the gear, but you can use it for anything you want.

I have built on the DIY cartridge as an example cartridge to add an additional port. The naive approach that doesn't work is on master at https://github.com/sosiouxme/diy-extra-port-cartridge/ (check the most recent commit). The kludgey approach that will work next week is on a branch at https://github.com/sosiouxme/diy-extra-port-cartridge/tree/ssl-hack (again, see last commit). Using Clayton's cartridge reflector, you could pull that down and try it like so:

rhc app create mydiy "http://cartreflect-claytondev.rhcloud.com/reflect?github=sosiouxme/diy-extra-port-cartridge&commit=ssl-hack"

It occurs to me that a better approach to this, rather than incorporating it into the framework cartridge, would be to do it in a plugin cartridge and just add to any existing app. I'll leave that as an exercise for the reader.

Hi Luck, Is it possible to open public port from embedded cartridge?

Yes, that should be possible; e.g. DB cartridges do it (but again, only if scaled, or after the release this week, with the ssl_to_gear option).

The ssl_to_gear option I mentioned is now available in OpenShift Online (as of 2013/07/02 actually). I tested it and it works, but I have to add one caveat; the port(s) you expose... cannot be reached from outside OpenShift Online. You can use from another app inside the OpenShift Online cloud, but exposed ports are blocked at the cloud external router.

From the current Cartridge Developer's Guide about port declaration in manifest.yml:

"Publicly proxied ports which expose gear-local ports for use by the application’s users or intra-gear. These endpoint ports are only created when the application is scalable."

"application's users or intra-gear"

What does that mean if not that these ports are available outside the OpenShift cloud?

Hey luke, I'm trying to open a non-http tcp port for my application and I have no idea where to start. First of all , is it possible to open a non-http tcp port ? If yes, then how ?

Thanks in advance.

Please review: https://www.openshift.com/kb/kb-e1038-i-cant-bind-to-a-port
If you are still unsure, please open a new forum thread and let us know more about your use case, and cartridges used.

I'm trying to set up an open port for external access to mysql. (I know, I can do port forwarding to my local machine, but that does not help my potential customers. To help with security, I am thinking of setting up a java RMI connection later, but I'm just trying to get this external access working now.)

I used the command provided:

rhc app create rdb "http://cartreflect-claytondev.rhcloud.com/reflect?github=sosiouxme/diy-extra-port-cartridge&commit=ssl-hack"

The rdb application became gear 2 (GEAR2).

I logged into this diy application using Putty.

I used the following port forwarding command to get access to mysql from another gear (GEAR1):

ssh -i ./custom_id_rsa -N -L 127.7.101.129:15000:127.2.137.130:3306 ${OPENSHIFT_GEAR1_UUID}@${OPENSHIFT_GEAR1_DNS}

Using a java test application, I was able to access the mysql database (GEAR1) from the rdb application (GEAR2) in the Putty session, so I know the port forwarding works.

Here is the code snippet used to attempt access from my local PC (remember, with appropriate values, this works from the Putty session) :

        strReturn = selectGeneric("${OPENSHIFT_GEAR2_DNS}",
                    "${OPENSHIFT_MYSQL_DB_USERNAME}",
                    "${OPENSHIFT_MYSQL_DB_PASSWORD}",
                    ":15000",   //OPENSHIFT_DIY_EXTRA_PORT
                    "dfe",
                    "select type_label from control_type_table");

public static String selectGeneric(     String strMySQLServer, 
                                 String strMySQLUser, 
                                 String strMySQLPassword, 
                                 String strPort, 
                                 String strDatabase,
                                 String strPredicate) {

        con = DriverManager.getConnection("jdbc:mysql://" + strMySQLServer + strPort + "/" + strDatabase + "?autoReconnect=true",
                                        strMySQLUser, 
                                        strMySQLPassword);

etc.

From my PC I'm getting the following error:

selectGeneric.catch: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.

So, it appears that port 15000 is not an external port, so where to I go from here? I'm sure that I am missing something, but I don't really know what that is. How is this external port process supposed to work?

Thanks, Jon Oman

$OPENSHIFT_DIY_EXTRA_PORT is the internal gear port for the gear application (SSH tunnel in your example) to bind to (on the gear IP, $OPENSHIFT_DIY_IP).

For an external port on the node that proxies to that internal gear port, you would use $OPENSHIFT_GEAR_DNS:$OPENSHIFT_DIY_EXTRA_PROXY_PORT (where the proxy port is in that 35531+ range).

I'm not entirely sure this will help your use case, though, given clients outside the cloud won't be able to reach it (see comment above). It still seems to be the case that any traffic in/out of the cloud must be via http or ssh (or tunneled over same). Sorry about that :(

Thanks for the reply, but I guess I'm still stuck. I have this nice java swing application, with all of its nice gui interface, that works just fantastic as a client link to my local tomcat7 system, and the mysql database, but will never see the light of day on openshift! I originally wrote it as a java swing applet, but with more and more browsers not really supporting them, I thought that I could use it as a java swing application running on the client computer. Speaking of java applets, are they considered http, and will they interface with openshift? Maybe I can require a certain level of browser to support the applet.....

As another thought, is there any new api's supported by the newest browsers that would allow me to embed a java swing applet into them, and give me that http connection? I don't really want to rewrite this thing from scratch.....

Thanks again,

Jon Oman

A java applet is just something that you download and run in the browser. To the web server it's really no more interesting than providing an image, sound clip, video, etc. So you should be able to make that available via HTTP. But you do have to think about how it is getting any data it needs, as the applet runs from the browser making any requests into the cloud; so in your case, it sounds like it is making requests to tomcat7 (which could be HTTP, depends what you are doing) and a MySQL database which would probably not work over HTTP; so it really just moves the problem.

Sorry to bear bad news :( I think a lot of people could do really useful things with poking various protocols into OpenShift but the message I am getting internally is that from an operational standpoint, having a single chokepoint at HTTP access helps prevent a lot of abuse, and we want to think very seriously about a supportable implementation of anything further, not just declare open season on OpenShift ports.

I would love to see some extra ports. My use case is a server to client notification.

It could be easily implemented using any of the standard Java EE tools:

  • RMI - needs two extra ports, one for the invocations and the other for the registry.
  • EJB remote - EJB uses RMI so the above point applies as well.
  • JMS - in JBOSS AS specifically, uses the remoting port AND the netty acceptor port (to which the client connects).
  • WebSockets - the AJAX updates as implemented in IceFaces 3, AFAIK, use extra port for persistent connections

All of the above allow the server to push notifications to a client. It all can be also implemented using long polling as a fallback.

I haven't found yet a Java EE hosting provider, which allows to use any of the above and doesn't require to build own stack (love to hear a reply in case I'm wrong).

This is what could make any cloud provider significantly better from the rest - as from the viewpoint of a typical client developer.

I might investigate the port forwarding option, using a java SSH implementation. If it works reliably enough, I'll probably leave a note here.

openshift allows websockets on port 8000 (see https://www.openshift.com/blogs/paas-websockets ) it should be easy to configure the jboss cartridge to support that (note: websocket connections are accepted on port 8000 on the outside but are routed to the normal http ports on your gear)

+1 for the use cases provided by user gregmatoga reflect mines

I would also like to be able to expose an additional (non-HTTP) port. I'm trying to implement a Gerrit Review cartridge, and it has an HTTP interface as well as a SSH interface. Exposing the HTTP interface works just fine (80 external -> 8080 internal), but there is currently no way for me to expose the SSH interface. I think that this functionality would be very useful for many other applications as well.

I would like external access to MQTT port 1883.

We need this feature very much.. I need to expose an API over both SocketIO & HTTP port.. just two flavours of same thing.. But as only one port is allowed.. I am unable to do this

If you are using Node.js (sounds like it) then you can listen for WS and HTTP over the same port and sort them out in your application, see this repository (it uses WebSockets, but it should be similar) https://github.com/developercorey/openshift-nodejs-http-and-websocket-example