It was one of those rare occasions that I was in the office when my boss started a conversation with me that went along the lines of:
Steve: I’ve been thinking…..
Alan: Yes? (I wonder where this conversations going)
Steve: Alan, you have been working with Chef for customer ‘X’ for about a year now’
Alan: Yes? (Still not sure where this conversation is going)
Steve: I know you have been working on deployments to large scale JBoss EAP 5.x/6.x (Standalone) clusters, but would Chef be a suitable tool to help provide ‘Continuous Delivery of Oracle SOA Suite Applications?
Alan: Give me a couple of days to review our WLST scripts used to deploy Oracle SOA applications (currently executed manually) to assess if Chef can be used and I’ll write an article about it.
I have been working with one of our customers for just over a year helping them to achieve their goal towards providing ‘Continuous Delivery’ for a number of their core business applications. Continuous focuses on automating all the build and deployment steps up to and including the UAT environments. The Dev Ops teams have been using git, Maven, Jira, Stash and Jenkins for a number of years so have a well-established ‘Continuous Integration’ process, but lacked the tools to automate the deployment.
In order to implement Continuous Delivery, a tool was required to deploy the applications to JBoss EAP 5.x and 6.x (Standalone) application server clusters with up to 100 nodes per environment, enter Chef...(see one of my previous posts: Who’s pulling the strings when it comes to provisioning IT systems, Puppet or Chef?)
Chef is a software provisioning system which allows the infrastructure to be modelled as code on the Chef server, with clients installed on the servers to be managed (Nodes). The Chef clients communicate with the Chef server to determine what changes need to be made to the nodes configuration. The infrastructure is modelled using the following Chef objects:
Cookbooks contain Chef DSL/ruby code in recipes, libraries and definitions to define what resources/operations need to be carried out on a node. The ruby code references from attributes defined in either the cookbook, roles, data bags or environments.
Data Bags are used to define global attributes that can be used by all code defined in the cookbooks.
Environments are associated to nodes managed by Chef and define the cookbooks and any attributes specific for that environment. The cookbook definitions can be pinned to a version, allowing for different versions to be applied to the DEV, TEST and PROD environments.
Roles describe the purpose of a server and defines the run-list and order of recipes to be applied to the node.
Nodes are registered with the Chef server and assigned a role(s) and environment
Chef provides a command line utility called knife, which is used to manage the Chef objects and environment. The knife ssh subcommand is used to invoke SSH commands (in parallel) on a subset of nodes, based on the results of a search query made to the Chef server. This allows you to invoke a Chef client run on nodes to provision/deploy an environment.
As an example, say we have an application that processes ‘Insurance Claims’ and comprises of a web tier deployed to a 2 node cluster and business logic tier to a 5 node cluster.
In the above example the following Chef Roles would be created, ‘ClaimsUI’ and ‘ClaimsBusinessLogic’, defining the run-list of recipes that are executed to deploy each component.
A Chef Environment ‘ClaimsDev’ would be created where the environment specific properties for the application would be defined, such as database connection details, web server urls etc. The nodes would be assigned the appropriate roles and environment, so for example, to deploy the Claims UI to the development environment, the following knife command would be issued:
knife ssh -x afryer “chef_environment:ClaimsDev AND role: ClaimsUI” “sudo -u root chef-client -l info”
The knife ssh command queries the Chef Server returning a list of matching nodes in the Claims Development environment that need the Claims Web interface to be deployed. An ssh session is started on each node returned as the user ‘afryer’ and runs the Chef client with sudo access. The Chef client connects to the Chef server and updates the attributes in the node’s hash map and executes the recipes defined in the ClaimsDev Role’s run-list. The recipes read the attributes from the nodes hash map (defined in cookbooks/environments/roles) and performs the operations in the recipes, deploying the Claims Web component on the required nodes.
We now have a mechanism to deploy/provision applications to an environment on multiple nodes from a single command line call. Configuring the knife tool on the server running Jenkins and executing a shell from a Jenkins task to run the appropriate knife ssh command enables ‘Continuous Delivery’ to be achieved in the Dev, Test and UAT environments.
So can Chef be used to provision Oracle SOA Suite? Oracle SOA Suite is based on the Oracle Weblogic server which consists of an Administration Server and Managed Servers in a Domain. The Administration Server is used to configure Managed Servers in a Domain and deploy applications to them. The WebLogic Scripting Tool (WLST) is a command-line interface used to automate domain configuration, application deployment and configuration, see Oracle WebLogic Scripting Tool for more information. This still requires all the Oracle Weblogic binaries to be installed on the hosts in the Domain, but the majority of the configuration will be done via the Administration Server typically using WLST.
Chef has an execute resource that can run any OS script/command which means that WLST scripts can be executed from a Chef client run. The properties required to drive the deployment would need to be modelled as attributes in Chef Environments/Cookbooks, which would be read from the node hash at runtime by the Chef recipes and passed to the required WLST scripts. Hence Chef would be able to install the Weblogic binaries on all the nodes in a Domain, perform any configuration on the individual Managed servers, executing any WLST scripts via the Administration Server.
In summary, Chef can deliver a solution that automates the provisioning/deployment of Oracle SOA Suite applications in a repeatable manner, significantly reducing deployment times. This lends itself to provisioning consistent configuration across multiple environments leading to a reduction in time spent trying to debug configuration errors which can occur with manual deployments. With careful design of the recipes in a granular way, it can also help to promote the building of standard environments quickly for new projects using a certified middleware stack. This enforces good practices across all projects, improving the quality of the systems delivered, reducing development and support costs.
In the next post I’ll create a simple Chef cookbook to deploy and configure Oracle Weblogic SOA Suite in a development environment.