At this year’s Oracle OpenWorld conference I presented during two sessions. Firstly, I co-presented “Oracle WebLogic on Oracle Database Appliance: Combining High Availability and Simplicity [CON8004]” with Frances Zhao-Perez from Oracle. I have been presenting with Frances for several years now – originally about GridLink for RAC, then Application Continuity and most recently WebLogic on ODA – and always thoroughly enjoy it (though we both invariably run out of time!).
For this session Frances discussed the WebLogic on ODA implementation, what’s new in the 12.1.3 release, and the up-coming Enterprise Manager 12c plug-in for ODA. I then described what you needed to do to install SOA (and so other ‘upper stack’ Fusion Middleware products) on the ODA.
In summary, if you’re looking to install SOA on ODA using the WebLogic on ODA implementation, you need to tackle:
- Disk space, in particular the middleware home which only comes with 3GB and you’ll need at least 5GB for SOA (fortunately ODA 12.1.2 now has an API to add extra disk space so you no longer need the trickery we had to do for O-box)
- Packages: you need to install another 17-43 RPMs (depending on version)
- Tuning to suit SOA WebLogic instances (the default managed server heap is 3GB but you’ll probably want to increase that)
- Installing Fusion Middleware Infrastructure for SOA 12c
- Port management as the VMs have firewalls enabled out of the box
- Domain design and how to add extra SOA environments (i.e. domains) later
- Licensing and setting up CPU pools
- Status of VMs and their lifecycle management (currently only possible via CLI)
- SSL certificates as by default WebLogic on ODA uses Demo Certificates which aren’t suitable for production use
- Automating patches and updates, e.g. for the JDK quarterly security updates
These are most of the areas we have been working on since the O-box proof of concept back in May 2013. We hope that if you’re looking for SOA on ODA you’ll consider the O-box SOA Appliance, but otherwise tackling these steps should help you to provision a SOA platform for yourself.
For the complete slide deck see the OpenWorld website:
You may then be wondering how we do all these things in a totally automated way on O-box… which was the topic of my other session: “Next-Generation Oracle WebLogic Server Provisioning: Puppet, Chef, and More [CON7894]“. This was a panel session chaired by Steve Button from Oracle Australia (whom many of you will be familiar with from his presentations and videos on WebLogic, Maven and other development topics). Panellists included Edwin Biemond (of open source Puppet oracle modules fame! https://forge.puppetlabs.com/biemond), Craig Barr from Rubicon Red, Goran Stankovski from Limepoint and myself.
O-box hasn’t made any secret of the fact that, under the covers on our O-box Manager VM, we’re using Chef to manage provisioning. For my part in this session I described our requirements when considering possible tools and some of the reasons we chose Chef back in summer 2013. I had a handful of slides:
<iframe style="border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;" src="//www.slideshare propecia online canada.net/slideshow/embed_code/39944155″ width=”425″ height=”355″ frameborder=”0″ marginwidth=”0″ marginheight=”0″ scrolling=”no” allowfullscreen=”allowfullscreen”>
I’d say that we only seriously considered Puppet and Chef as they were the products with most momentum. In particular Edwin’s open source Puppet modules looked very interesting but (at that time) didn’t have clustering (IIRC) and were a bit too sequential script-like, plus we needed to bake in patching since we wanted to offer an O-box Updates Service. The debates around master-less architectures (which both Puppet and Chef support, albeit you lose some features) weren’t relevant to us as we knew we needed a management VM anyway. Language choice is worth considering – both Puppet and Chef are based on Ruby, whereas Ansible uses Python which might be more natural for Fusion Middleware administrators who regularly use WLST. Note I found out from Edwin last week that Puppet are moving to a more SOA-like model with the new Puppet Server running on Clojure on the JVM so this may increase its language options.
Anyway, we ended up choosing Chef and have been mostly very happy with it. All of these modern tools have their pros and cons though – the main thing is to choose one so that you have a solid basis to build provisioning upon.
Stay tuned for a post tomorrow about the latest ODA news from OpenWorld!