I am involved in the Zentaur Server project. It is a brand new a lightweight HTTP server written in Java by Simone Tripodi. It is so easy that I immediately was attracted. In not time we agreed to rename it from SHS to Zentaur and put some more effort in it. Of course a web server implementation needs to serve its own web pages and so we were looking for a provider.
Red Hat provides OpenShift, which is a PaaS (Project as a Service) platform. Everybody can join there and create some apps for free (limited to three at the time of this writing). OpenShift seems to be very supportive to Open Source: they provide several “quick start” repositories on Github. As Red Hat is an open source company, it is not surprising that OpenShift itself is Open Source.
I was looking for a good while at OpenShift for my own App Time & Bill. But I don’t think it’s ready for production yet: I am in need of a price list. And another thing which prevents me to use it for mission critical apps: I need to learn more on scaling on OpenShift. Besides that, it is perfect for Zentaur Server. Why?
OpenShift provides you some “cartridges”, which allow you to get on speed with your app quickly. Basically you can say you can create an app, which is basically a git repository and a domain name. Then you add some functionality to it, like for example Wordpress, Jenkins or something else. In the Zentaur case we would need the DIY cartridge: Do it yourself. It allows me to run nearly everything I want: if it runs on Red Hat Enterprise 6, it runs on OpenShift. If that is not enough: with Open Shift you have access to SSH and can use GCC. That being said, OpenShift allows you to get started quickly and easily or to get some more complicated tasks done.
Basically you get a git repository from Red Hat OpenShift. You push to it and then OpenShift runs several git hooks. There are hooks for “pre-build”, “build”, “deploy”, “post-deploy”, “start” and “stop”. If you want to do something special you can add your commandos here. As we just want to try out Zentaur, I decided to commit everything we need to the repository. There might be other options for that. I found a “runtime” directory when exploring the folder structure with SSH. Guess, I can put my own runtime specifics there, without committing it to the repository.
Anyway, I want to use the commit, push and automatic deploy workflow.
I simply copied everything I needed to this repository and committed. I did not push yet, because it would not do anything except stopping and starting the default ruby server. To disable this server, you can force to close all app processes. Of course you can simply stop, but I didn’t care much on the test app and wanted to make sure everything is closed:
Zentaur is my app name, as you might have guessed. Now, everything is stopped. You need to change your start hook afterwards, which would start the ruby server in case of a push. Here is the new code:
The shs script is starting Zentaur. The name is coming from the original name Simple HTTP Server, which has been changed to Zentaur recently. Therefore this scripts name will change in future. The interesting part here are the variables we need to use: $OPENSHIFT_REPO_DIR is the absolute path to my app. $OPENSHIFT_INTERNAL_IP is the IP I need to bind my server; otherwise it will not work. Same is with the port 8080. OpenShift is running behind a Proxy which uses this port and a specific IP to send requests.
This is actually much better and comfortable compared to for example Amazon EC2. I needed some time to figure out how to do port forwarding to get my Jetty server connected on port 8080. Well, EC2 is not PaaS, so yes, you get some comfort with OpenShift.
The rest is pretty Zentaur specific, like the folder in which my site resides or how many threads are used. Please mind the & sign at the end, which starts my process in the background.
The stop script is pretty simple too. There is room for improvement:
Basically I am looking for a process number of my server (look at the class name) and, well, kill it. There are surely less drastic ways to do that, but for now I am happy.
Now we can commit everything and push it.
It should look similar to that:
When pushing, OpenShift stops and starts the app. Some other hooks are executed too. You could run maven for example, or something else, like Flyway. However, for me start/stop is enough.
I have come so far, I want to look into my logfiles now. I could connect via SSH, but the Red Hat client tools are much more comfortable. Here we go:
After entering my password, I will see something really nice:
Heya, we made it! Zentaur is running! Lets send a request with the browser:
2ms - super-fast. As expected :-).
You can look at the running app at http://zentaur-grobmeier.rhcloud.com/(Not longer working).
The whole code is located at GitHub. Once we have a proper version of Zentaur we’ll provide a better quick start sample for OpenShift. But of course you can already use that one, if you want to experiment. It is already supporting Velocity and JAXB.
Yesterday I had the issue that not all my requests are passed by the proxy. I needed to create a second tab and fire a second request to get both responses. Otherwise the proxy would return an error code after minutes. I have learned that the RedHat people are very responsive and nice with helping on IRC or the forum.
Today it suddenly worked so I blame yesterdays OpenShift upgrade to somehow impact the proxy.
A recommendation I got on the forum was to bypass the proxy and see if it helps. I note it here for others.
If you suspect its the proxy, you can bypass the proxy completely (remove it out of the mix) in a couple of ways:
- 1. ssh into your app instance and use curl -vvv http://$OPENSHIFT_INTERNAL_IP:$OPENSHIFT_INTERNAL_PORT/ and see if that works
- 2. You can do an rhc port-forward -a $app and then just connect to the http://$OPENSHIFT_INTERNAL_IP:$OPENSHIFT_INTERNAL_PORT/ on your local workstation.
After all this was an impressive first step into OpenShift. I got into it in no time. Time & Bill tells me I needed 100 minutes - this includes all the debugging work for the Proxy problem, which should be substracted. My estimation is that one can get to a running app in 30 minutes without having any clue about OpenShift. This is great. RedHat gets a +1 for the great proxy solution, which does not require me to deal with port forwarding directly. Another +1 for the great docs, the supportive Red Hat people and the ready-to-go cartridges. After all I am very happy and will follow OpenShifts progress more closely from now on.