Port Forwarding Openshift
Kayleigh Telega
One of the benefits of OpenShift over a traditional Platform-as-a-Service (PaaS) is that you can have access to persistent volumes. This means you can attach storage to your web applications or run applications such as databases.
Databases deployed to OpenShift will typically be used to support the operations of a front-end web application, and therefore only need to be accessible by other applications running in the same OpenShift cluster.
In this post, you will learn how to access a database using an interactive shell, and also how to use port forwarding to temporarily expose a database outside of OpenShift, allowing you to access it from a database tool running on your own local machine.
Anything you want to do to the database could be done through any database admin tool included in the container. However, this will be limited to console-based tools, and you would not be able to use a GUI-based tool that runs from your local machine, as the database is still not exposed outside of the OpenShift cluster at this point.
When a web application is made visible outside of the OpenShift cluster a route is created. This enables a user to use a URL to access the web application from a web browser. A route is usually used for web applications which use the HTTP protocol. A route cannot be used to expose a database, as they would typically use their own distinct protocol, and routes would not be able to work with the database protocol.
There are ways of permanently exposing a database service outside of an OpenShift cluster. However, the need to do that would be an exception and not the norm. If you're only wanting to access the database to perform administrative tasks on it, you can instead create a temporary connection back to your local machine using port forwarding. The act of setting up port forwarding creates a port on your local machine that you can then use to connect to the database using a database administration tool.
To setup port forwarding between a local machine and the database running on OpenShift, you can use the oc port-forward command. You will need to pass the name of the pod and details of the port the database service is using, as well as the local port to use.
Port 15432 is used here for the local machine, rather than using 5432, in case an instance of PostgreSQL was also running on the local machine. If an instance of PostgreSQL was running on the local machine and the same port was used, setting up the connection would fail as the port would already be in use.
In this form, the local port is left off, resulting in a random available port being used. You would need to look at the output from the command to work out what port number was used for the local port, and use that.
When the oc port-forward command is run and the connection setup, it will stay running until the command is interrupted. You can then use a separate terminal window to run the administration tool, which will connect via the forwarded connection.
With the port forwarding in place, you can now run psql again. This time, it is being run from the local machine, and not from inside of the container. Because the forwarded connection is using port 15432 on the local machine, you need to explicitly tell it to use that port, rather than the default database port.
oc port-forward :: This forwards connections between your local machine and an application running in OpenShift. The remote port is the port the application running in OpenShift uses to accept connections. The local port is the port on your local machine that you wish to make the remote port available as, and to which any client application running on your local machine would connect.
oc port-forward :: This forwards connections between your local machine and an application running in OpenShift. The remote port is the port the application running in OpenShift uses to accept connections. As a local port to use is not specified, a random local port is used, with the port number being displayed. Any client application running on your local machine would connect to the randomly assigned port.
By port forwarding the debugging port for the application server, we can attach the debugger from our IDE and actuallystep through the code in the pod as it is running in real time. By default EAP is not in debug mode, therefore we firstneed to turn on the debug ports
It is very simple to turn on debugging. The EAP S2I container we are using is looking for an environment variable tocontrol whether or not to enable the debug port. All we need to do is set an environment variable for the deployment.
Whilst we can connect to a Pod directly to debug it, when there is only one instance of a Pod running it can be convenient to setup port-forwarding through a Service (since Pod names change but the name of the Service is static). See Exercise: Port-Forwarding from the pod to our local machine
On the resulting dialog page, change the name at the top to "on OpenShift" or whatever is informative to you. Thentowards the bottom right, change the port number to 8787. When you have done that click "OK".
Now when you click the Debug icon in IntelliJ, it will open the debugger and attach to JVM in the pod on OpenShift. Goahead and set a break point in any class you want and it will do normal debugging - just like you know and love!
But luckily I found the solution for me. I was pushing my work with sourcetree but it gave me an error that my private key wasn't loaded. So I loaded my private key in Pageant. After that I tried port-forwarding again, and to my surprise it did work.
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
When you're developing a cloud-native application on any PaaS, static provisioning of persistent volumes existed. One of the benefits of OpenShift over a traditional PaaS is that you have access to dynamic provisioning of persistent volumes. In this week's article, I will fix a technical challenge of my hypothetical customer Alex. Alex has a backend application outside of his OpenShift cluster and is trying to access a database within OpenShift.
This will start up an instance of a PostgreSQL database. Although a database would normally be paired with a persistent volume, I only want to demonstrate how to access the database from a remote application in this article (without persistent volumes). Persistent volume on OpenShift will be covered in detail in a later article. The database instance created here will only store the database in the filesystem local to the container. This means that if the database were restarted, any changes would be lost. To monitor the deployment status of the database application:
During this step, I find out the pod details of the database container, capture the name of the pod in an environment, remote shell to the pod and execute PostgreSQL commands. To learn more about the remote shell command, visit this page.
I could now dynamically create database tables, add data, or modify existing data. \q exits the database prompt and exit command takes me out of the interactive shell of the database container.
In order to access the database from a remote machine/application, it will be necessary to expose the database service outside of the OpenShift cluster. Typically, Routes would be used to allow access to the database from another service within the OpenShift cluster. Since the application in question is outside the cluster, I'll be using port forwarding. The act of setting up port forwarding creates a port on the local machine which one can then use to connect to the database using a database administration tool.
With the port forwarding in place, I can now run psql again. This time it is being run from a remote machine, and not inside of the container. Because the forwarded connection is using port 15432 on the remote machine, I need to explicitly tell it to use that port rather than the default database port.
Congratulations! You just learned how to set up a connection between a service running inside of OpenShift and a remote application/machine. That's it for this week. See you next Monday with another OpenShift 4.X article.
oc port-forward :: Forward connections between your local machine and an application running in OpenShift. The remote port is the port the application running in OpenShift accepts connections. The local port is the port on your local machine you wish to make it available as, and to which any client application running on your local machine would connect to.
oc port-forward :: Forward connections between your local machine and an application running in OpenShift. The remote port is the port the application running in OpenShift accepts connections. As a local port to use is not specified, a random local port is used, with the port number being displayed. Any client application running on your local machine would connect to the randomly assigned port.
OpenShift Tools enables you to debug your deployed OpenShift applications within the IDE, enabling you to take advantage of the IDE debugging tools. This article specifically details the steps needed to set up an OpenShift Online Java application for debugging. A number of configuration tasks are required both locally and remotely to enable the IDE debugger to connect to the OpenShift server and OpenShift Tools for achieving this. Some tasks only need to be completed once for each OpenShift Online application but others must be completed every time you reconnect to OpenShift Online from the IDE.
You must first configure your OpenShift application for debugging, which requires setting the Enable JPDA (Java Platform Debugger Architecture) marker in your application source code and republishing the application. Marker information is retained with the application so you only need to complete this task once for each OpenShift Online application:
c80f0f1006