On my first look at OpenShift I described what the initial getting started experience was like . Now I’d like to go over what it’s like when you deploy a JBoss Application using the deploy your own application route. I had to endure being talked at by my Significant Other about the intricacies of JBoss for this mind and I now know a little bit more about JBoss than I ever wanted or needed to know ( I didn’t know much about it before though ). As a result though this post has sneaked a look behind the scenes and focus’s on what is happening at the AWS end as well as some JBoss specifics which I guess most users may not want to do. In this this post we do also list some of our gripes and also some questions we have. Anyway enough of that here comes the good stuff
The first thing you need to get your head around is that the JBoss server is part of your application .
We created a load balanced Cluster which if you’re interested in what is going on with your AWS estate consisted of a minimum of two ec2 instances with a loadbalancer in front of them. The ec2 instances are launched with a generated ec2 security group which has your cluster name embedded in it.
My first question was why are both instances in the same availability zone?
This unfortunately ended up with myself and my significant other both educating each other . Me explaining about AZ’s and him explaining about how JBoss clusters work . We decided to park that conversation as I think we were both making each others heads hurt at some point (Our works lives do not normally collide).
The reason we started a cluster is because we wanted to show that when you create a clustered JBoss application you do actually get a JBoss cluster and not just two standalone JBoss instances behind a load balancer. I’ll show this later on in this post.
The application we are using is the one that is used in the getting started with JBoss guide to go with it the JBoss Seam booking application. This application doesn’t actually work when deployed ( I know why as I was told why but that explanation would distract from this post) but as we were interested in poking around it served its purpose (and I had already downloaded it )
To deploy an application you also need to deploy the components that go with it
Basically you need to go through all the tabs but you can say just deploy the components and deploy the files ( in our case an ear file ) later, OpenShift doesn’t seem to mind that.
Gripe : The annoying yellow circle that appears is a counter telling you how many files has been modified. In the screen shot above you scan see that the ‘20’ matches the Configuration files modified. It rapidly became as annoying as the paper clip in word it needs to go.
We deployed the components first that consisted of JBoss 6 and MySQL. At the moment there is only a community version of JBoss supported. What I want to know is there going to be a supported version of JBoss so that we could see a Pay as you go support service like the RedHat instances on ec2?
Anyway after we deployed the components we logged on to the JMX console on one of the nodes so we could show you that it really is a JBoss cluster and what happens after you deploy the files that make up your application.
The terminology is slightly confusing as JBoss usually has applications deployed to it and now its a component but that component is actually part of an application. Hopefully by the end of this post you’ll understand it all though.
So pre application file deployment but post component deploy .When logging onto the JMX console as you can see from the screen shots below that a JBoss Cluster/group exists with both our ec2 instances in it.
I have included a screen shot of the ec2 instances so you can match up the IP addresses with the walkthrough
Those of you familiar with JBoss will see there is no application deployed as yet so we went back to the Flex console and then deployed our application ear file.
The JMX console then looked like this:
and from the JMX console on our second instance looked like this
To get the password to log onto the JBoss console we actually had to log onto the instance via ssh to get the randomly generated admin password from the jmx-console-users.properties file.
It would be good if there was a way to change this password from the Flex console . There is the ability change ports via the console. We feel this is a must have enhancement.
After we’d had a poke around I then wanted to delete the application . So I stopped the application and then clicked delete but got this error :
The application ( deployed files and components i.e JBoss is no more) was deleted from both nodes so it did work.
This still leaves the instances and loadbalancer on AWS running though so next it was delete the cluster and another error although it did successfully delete the cluster and the underlying AWS infrastructure
So there you have it a quick peek behind the deployment of a JBoss application sing OpenShift.
Some other comments we have for RedHat :
As we can log onto the instances it needs to be made absolutely clear as to what an end user is actually allowed to do in terms of tweaking. If you ‘over tweak’ what support will be provided?
The Getting Started documentation needs to reflect he actuality. For example in the ‘Getting Started with JBoss on OpenShift flex guide’ there is no indication that you cannot have spaces in your application name as shown by the screenshots in the guide .
You do not find out till you have tried to create a cluster ( a Flex cluster) that there is a 10 characters maximum constraint on the cluster name. Some on screen help is needed before you hit submit .
The UI still needs a lot of work as the scrolling around is annoying and buttons not being obvious because your browser/laptop resolution isn’t small enough although I have been told even on a dev size screen it’s still rubbish ( I know that they are working on this but worth listing)