As I’ve mentioned in some of my other posts on using the UrbanCode Designer to design HOT documents, one of the key benefits is the significant productivity gain in not having to hand code a lot of the “tedious” Heat constructs, not having to remember resource names when hooking them up together, not worrying about YAML indentation and validation. Every new version adds more of these features which you can find in the Knowledge Centre or on Youtube (search for UrbanCode Deploy with Patterns” ).
One of the other major benefits that UrbanCode Designer is the idea of “cloud portability” : the ability to design blueprints that are “cloud agnostic”.
Continue reading “Which cloud? Any cloud: Getting started with portable HOT documents”
Different strokes for different folks. When it comes to full-stack environment provisioning every customer has their own opinions and cobbled together set of tools: homegrown scripts to Chef and everything in between (and on either side). Working with UrbanCode customers over the past year there was a sort of trend where they want “everything” on the stack – from infrastructure up through application and configuration – sometimes including the operating system, to be done in/from one place. This is particularly true where they don’t already have investments in say Chef or don’t want to take on yet another technology/tool/solution/language. What they might have is a bunch of existing automation in the form of scripts or knowledge in the heads of their development/operations folks. Or in reams of documentation that must be worked through carefully to get an environment up
Continue reading “Deploying IBM MobileFirst Platform with UCD”
A question came up on how to end an UrbanCode Deploy application process quickly when any one of many component processes executing in parallel fails.
Continue reading “Killing it softly”
“O! be some other name:
What’s in a name? that which we call a rose
by any other name would smell as sweet”
From one of my favourite plays, rendered in somewhat recent times in superb fashion IMHO, by one of my favourite directors (a fellow Aussie and New South Welshman by the way:-).
The naming gods must have finally read “Connecting UrbanCode Deploy with Patterns to OpenStack” and decided the UrbanCode Deploy with Paterns (UCDP/UCDwP/UCD+P..) name is indeed a mouthful. Mouthful or not, Eric Minick provides a bit more detail on UCDwP becoming part of UrbanCode Deploy with the 6.1.2 version in his post . Problem solved indeed and does make perfect sense as I’ve been finding when showing UCDwP to customers moving into the cloud over the past year or so. For simplicity I’m just going to call the cloud blueprint capability the “Designer”.
Continue reading “What’s in a name?”
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.
Continue reading “UrbanCode Deploy with Patterns: Hello World, the vSphere edition”
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.
Continue reading “UrbanCode Deploy with Patterns: Hello World”
One of the neat features of UrbanCode Deploy with Patterns (UCDP) is the ability to deploy blueprints to multiple clouds. Last time around I wrote about hooking up UCDP to an OpenStack cloud. In this post I’ll look at how to setup UCDP to connect to Amazon EC2.
Continue reading “Connecting UrbanCode Deploy with Patterns to Amazon EC2”