UrbanCode Deploy with Patterns 22.214.171.124 is out. A whole lot of fixes and some new stuff. Take a look at
A recent post from Doug Davis “Docker: Managing the excitement” has some nice insights on Docker as a “relatively new” technology. Among the other Docker niceties that Doug points out, one that resonated with me is, and I quote “it takes seconds (if not less than a second, after the first time since things are cached) for it to complete”. Reading between the lines in some of my other posts, I’ve often battled the dark forces of virtual machine world, usually trying to squeeze every bit of extra juice out of my poor laptop. Then I tried Docker and well, suffice to say I need fewer coffee breaks.
My long-time colleague and friend Takehiko Amano has a post on “Immutable Infrastructure” where he talks about Docker in the context of OpenStack and with a bunch of my earlier posts focused on OpenStack, I decided to figure out how the three – OpenStack, Docker, and UCD+P might work together.
In the concluding paragraphs of my last post, UrbanCode Deploy with Patterns: Hello World ,I briefly compared the UrbanCode Deploy with Patterns (UCD+P) use of OpenStack HEAT Templates (HOT) for blueprints with my own simple XML blueprint for vSphere compute resources. In the past week a Fix Pack was released for UCD+P which adds initial support for provisioning to VMware vSphere infrastructure. So in this post I’ll do a “Hello World” -style example of connecting UCD+P to a vCenter 5.5 server, provisioning a VM on it and deploying multiple UrbanCode Deploy (UCD) components to the VM.
Having hooked up UrbanCode Deploy with Patterns (UCDP) to OpenStack and UrbanCode Deploy (UCD), it’s time to take a look at a “HelloWorld”-style example. I’ll work through a single-server UCDP blueprint, deploying a single UCD component to it.
UrbanCode Deploy with Patterns (UCDP): a mouthful right? A pretty neat and powerful mouthful though. Consider theses two posts: Cooking up deployments on stacked clouds and UrbanCode Deploy with vSphere and Chef. UCDP makes it simpler and easier to carry out a bunch of steps detailed in those posts. Before I get into the details, let me first quickly go through how to install UCDP and connect it to an OpenStack setup.
In a previous post (Cooking up deployments on stacked clouds) I looked at using UrbanCode Deploy with OpenStack and Chef. I showed one way of creating a stack from a Heat template, injecting the UCD agent and Chef into one of the newly provisioned servers, cooking a Chef recipe and deploying an application on it. This time round I look at how to do almost the same thing with VMware vSphere.
Managing database schema changes can be a non-trivial task. Very often the danger associated with potential bad changes being deployed makes DBAs very protective of their territories and resistant to changing tried and true methods.
However, the push towards more Agile development methods, adoption of DevOps practices and Continuous Delivery capabilities is including database development in its embrace; the last 10 years or so has seen a lot of work towards aligning database development with application development best practices. That said, there are probably quite a few organisations out there where the normal practice for deploying database changes is to use some sort of “list of instructions” and various GUI DB tools with maybe some scripts thrown in. Even adopting practices such as SCM and CI can appear daunting.
Calling Rational Team Concert an old dog isn’t fair – it’s only just over 5 years old – and I mean it in the nicest possible way in the context of the Jazz Jumpstart team being “old”, and the Rational Emerging Technologies Team, well, “emerging”.
Anywho, as is my wont, I was going through what could be in the next CLM release, noticed the bit about Rational Team Concert Build and IBM UrbanCode Deploy and decided to try out this “emerging” feature with Rational Team Concert 4.0.5 RC1.
Having successfully gone through installing WebSphere and creating Base WepSphere profiles using Urbancode Deploy (UCD), the next logical step is to use the profile in some way. Here’s where the Application Deployment for WebSphere plug-in comes in. There are a bunch of steps in this plug-in that help with a whole range of WebSphere tasks.
After creating generic UCD processes to first install WebSphere and then create standalone (Base) WebSphere profiles, I wanted to turn my attention to applying the second process to WebSphere ND. I’d already written about creating a clustered CLM setup using the command line in my old post Clusters of CLM applications without a GUI so this should have been pretty simple. It occurred to me that the steps in both the processes from the last two posts could actually be steps in a UCD plug-in, just like the Application Deployment for WebSphere plug-in. Of course I’ve never written an UCD plug-in before and my experiences with writing RTC extensions had left me with the distinct feeling that this kind of thing was not for mere mortals like me. This was the domain of gurus and gods like Ralph Schoon. However, the thought had been planted in my head and, like in Inception, I could not help but follow it through.