In the previous posts we created a very basic application for BlueMix using Java Servlet technologies. It was a great introduction but not very useful.
In future posts I will be writing more about UrbanCode products but as the script we are creating concerns UrbanCode Deploy, I'll give an ancillary description of what it is.
A great intro about how UrbanCode Deploy related to Bluemix can be found here on developerWorks. I recommend reading and watching the YouTube video for some context. Essentially, UrbanCode Deploy is a deployment automation orchestration tool and can be used in hybrid cloud scenarios where source code in BlueMix Git and assets that are built using the Delivery Pipeline can be brought back on-premises in an automated fashion using a secured tunnel provided by the BlueMix Secure Gateway (a candidate for a future blog post.). Once these assets undergo further build steps, component additions, deployment and other release engineering tasks that must be done on-premises, the resulting assets can be posted back into BlueMix's CloudFoundry as deployed applications and services. This is just one scenario in a multitude of UrbanCode Deploy scenarios, some of which can involve deploying entire containers, and virtual machines and entire deployment patterns.
UrbanCode Deploy uses agents that need to be installed on machines that will have assets deployed into them. So for example, if a web application is built that is to be deployed into application servers hosted on machines in QA they will need to have Urban Code Deploy agents. Potentially, a large UrbanCode Deployment architecture could consist of thousand of agents in multiple environments. In the UrbanCode Deploy UI there are various widgets that present a pick list of these agents. Usually this list is qualified using team and role assignments but a user with all rights could have pick lists with thousands of these agents. This could lead to unwieldy UI views and slowdowns that can be avoided using a simple reorganization of these agents, this is where the script comes in.
The script reorganizes the agents ("resources") into folders ("groups") with each letter of the alphabet (A..Z) and moves the agents into the folder corresponding to the first letter in it's name. Agents have names assigned to them that can be a host name, for example. This may not be the best organization pattern for your organization and you are free to fork the source code and download a build from the project on BlueMix. You can also access the application here. http://ucdresopt.mybluemix.net/ (you'll need to login with a Google+ account.) The interface is self explanatory. The button executes the script.
You can also build/run the script locally from the source code archive by running ./grailsw run-app from the unzipped archive.
- Make sure the JAVA_HOME environmental variable is pointing to a Java 7 JDK.
- Unzip the archive into a directory
- We need to disable SSO security constraints used by the BlueMix, the easiest was to do this is to delete the src/templates/war/web.xml file.
- type ./grailsw run-app
- Ignore any exceptions.
- Once the server is started you can access the app from http://localhost:8080/
- To build a war file type ./grailsw war and it will be placed into target/
As previously mentioned, this script is based on a script that was given to me from our development team. That script was written in Groovy. Groovy is a scripting and compiled based language based on Java that has functional and object oriented language concepts. In fact, Java syntax can be used directly. I thought it would a good opportunity to create a Grails application on Bluemix. Grails is a "A powerful Groovy-based web application framework for the JVM" and because they are JVM applications, they can easily be build and hosted on BlueMix. The Java and Liberty BlueMix CloudFoundry build packs have native support for Groovy, Grails and the Groovy written build tool, Gradle.