The good news is that it fairly easy to create a Docker build using the same source code base we are using for the Cloud Foundry build in DevOps services. The big not-so-secret is that Cloud Foundry also uses a containers, called Warden that provides isolation between the application running within in. (A container is a isolated, ephemeral, and resource-controlled environment.). In the case of Cloud Foundry, the container is hidden behind APIs and runtime environments called "build packs". Cloud Foundry also has the ability to set up services that can be easily bound to application containers but the biggest difference is how these environments are built and interact. This is where I personally prefer Docker.

As opposed to Cloud Foundry, which uses hooks from Ruby for building the environment ("buildpack"), Docker provides a very familiar environment to anybody who is a Linux guru, it's basically a Linux kernel, isolated shell with a (default) empty file system and network connectivity. (Docker runs on Windows and Mac using a emulated kernel host using Boot2docker.) To "build" a Docker image, a Dockerfile is required which provides the steps to copy executables, libraries, configurations and the default command to execute when the imagine is run as a container. This would be painful to do for every build as many dependencies are usually required just to run something like a JDK: shared libraries, executables, etc. Fortunately, Docker has an inheritance model that allows containers to be extended. So, there is are pre-made docker images that contain Linux distribution typical expected in a Linux distribution. There is a base image of the Ubuntu, Red Hat and many other distributions that already contain package managers and common utilities pre-installed. Pre-built docker images are available in a registry on https://registry.hub.docker.com/ and Bluemix also has a image registry at registry.ng.bluemix.net. There is also a Websphere Liberty docker container, which we extend for our Grails UrbanCode script application.

In this script we install a few WebSphere Liberty features and a JDK 1.7 in order to run the grailsw build executable and copy the server configuration files to the image; the installation of WebSphere Liberty and the default executable is already provided by the websphere-liberty image, contained in the BlueMix image registry, that we inherit from. As the websphere-liberty image inherits the ubuntu image that has the apt-get (the installation package manager for ubuntu) pre-installed.

We have a build deploy step ("Docker Build") that builds the image using the Dockerfile and posts as new image to the BlueMix registry as registry.ng.bluemix.net/bkuschel/ucdscripts:<version>. There is also a a deploy step ("Docker Deploy") that deploys the application to IBM Containers as the ucdscripts_<version> container and binds it to a public IP available here.

If you wish to build and run the image locally Fork the project, load it, modify it as desired. Install docker or Boot2docker change to ucdscripts directory and run (You can call the image something other then bkuschel/ucdscripts) :

Saturday, 18 July 2015

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.

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.