John McDougald, Senior Consultant

The Database is Not Working

You’ve undoubtedly heard the buzz about DevOps, the new software design lifecycle (SDLC) paradigm that combines agile development with agile infrastructure – placing infrastructure specifications, configuration, and settings into code and building this into software releases. It is a game changer, now you can have harmony between the two previously siloed organizations of Development and Infrastructure/Operations. In organizations using SDLC, hours are no longer spent debugging problems resulting from promoted code missing the correct driver version of JDBC, or spent on servers that need to be added to the /etc/hosts file.

One particular pain point, which I’ve dealt with in my career, is Oracle listener administration files. Specifically, entries in the tnsnames.ora file. The Oracle listener configuration is considered black magic by those who don’t deal with it on a semi-regular basis. When Development and Operations are separate, it is easy for the file to be missed when the code is promoted. Especially if Development forgets to tell Operations that they are migrating code changes, which was a regular occurrence at previous employers. We would get a help ticket stating “the database is not working” and have to dig around a bit in order to discover that they promoted code without asking for the associated infrastructure changes to be put into place. Had a DevOps methodology been in place, it could have gone more like the scenario described below.

DevOps to the Rescue

The Acme Data Warehouse (ADW) Company has decided to embrace DevOps as a supplement to their Agile Development methodology. They standardized on the Chef platform, setting up a Chef server and multiple Chef nodes. The Chef nodes correspond to their various Web Application Servers, which contain the Oracle Client software and JDBC drivers that need to be synchronized.

To set this up, the chef administrator for ADW Company (who incidentally is also the DBA, the Sysadmin, the Webadmin, etc.) uses his Chef workstation to set up and manage the nodes for the Unit, System, QA, and Prod environments.

Below is a graphic of the basic architecture, as shown in the Chef Tutorial.

Figure 1: Chef Architecture

The Chef workstation can be either Windows based or Linux based. It is used to communicate with the Chef server, create roles/environments/policies, and push them (and other items) to the Chef server. There is a command line tool called Knife, which is used to manage the Chef server.

The simplest way to keep the tnsnames.ora file current is to create a recipe to copy the correct version of the file from the Chef server to the appropriate environment. I will walk through the steps involved in setting this up on a Linux server- in this case, Ubuntu. Perform the following steps while logged in as the root user.

1. Install the Chef Development Kit

curl https://omnitruck.chef.io/install.sh | sudo bash -s -- -P chefdk -c stable -v 0.16.28

2. Check the Chef DK version

root@jbuntu:~/chef-repo# chef --version
Chef Development Kit Version: 0.16.28
chef-client version: 12.12.15
delivery version: master (921828facad8a8bbbd767368bfc72f19bd30e7bd)
berks version: 4.3.5
kitchen version: 1.10.2

3. Create the repository directory

mkdir -p ~/chef-repo/cookbooks
cd ~/chef-repo/cookbooks

4. Create a cookbook for Oracle Configuration

knife cookbook create oracle_config -C "John McDougald" -m "jmcdougald@houseofbrick.com" -I apachev2 -r md

5. Update the default.rb file in the ~/chef-repo/cookbooks/oracle_config/recipes folder

#
# Cookbook Name:: oracle_config
# Recipe:: default
#
# Copyright 2016, John McDougald
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
cookbook_file '/tmp/tnsnames.ora' do
source 'tnsnames.ora'
owner 'oracle'
group 'dba'
mode '0755'
action :create
end

6. Place the tnsnames.ora file in the ~/chef-repo/cookbooks/oracle_config/files directory

root@jbuntu:~# ls -l ~/chef-repo/cookbooks/oracle_config/files/
total 8
drwxr-xr-x 2 root root 4096 Sep 8 13:06 default
-rw-r--r-- 1 root root 538 Sep 8 13:11 tnsnames.ora

7. Run chef-client in local mode to demonstrate the file creation

 

8. As can be seen above, the tnsnames.ora file was copied from the ~/chef-repo/cookbooks/oracle_config/files directory to the target file /tmp/tnsnames.ora.

CONCLUSION

In this blog, I discussed the use of DevOps principles, and specifically the Chef platform, to configure and manage database installations.