Southern Bread

I have a few mod_perl web apps that I maintain for my employer. One of the problems that you run into with any web app is the proper placement of global configuration parameters within the application. I’m talking about things such as database hostname, database login credentials, query timeout parameters, etc. Since a web application is stateless(each reply/request cycle is atomic) you have to make these global variables available from within each of your modules independently, but in a way that still let’s you have only a single point of administration for changing them. Here is the method I use for handling this situation.

I use the cpan module Config::Tiny and create a new module that handles returning the current global configuration data whenever it’s functions are called. Config::Tiny reads an INI style configuration file, and since it reads this file each time it’s called, you don’t have to bounce your apache process just to make a configuration change. Here is a mock example of a file that Config::Tiny might read:

##: Config file

[database]
type=mysql
server=mysql.domain.com
user=username
pass=password
database=mywebapp

[global]
expires=86400
maxusers=5

You could save this file as /etc/mywebapp.conf and that would become the administrative point for any configuration changes to your app. Now here is a look at the module(I’m assuming you are familiar with module creation, if not look here) you would use to retrieve that data from the config file and hand it to your application:

package mywebapp::Conf;

#use 5.008;
use strict;
use warnings;

require Exporter;

our @ISA = qw(Exporter);
our %EXPORT_TAGS = ( ’all’ => [ qw() ] );
our @EXPORT_OK = ( @{ $EXPORT_TAGS{’all’} } );
our @EXPORT = qw(
  get_db_config
);

our $VERSION = ’0.01’;

sub get_db_config {
  use Config::Tiny;

  ##: Hash ref to return
  my $dbase;

  ##: Open the config file
  my $config=Config::Tiny->read(’/etc/mywebapp.conf’);

  ##: Get values
  $dbase->{’type’}=$config->{database}->{type};
  $dbase->{’server’}=$config->{database}->{server};
  $dbase->{’user’}=$config->{database}->{user};
  $dbase->{’pass’}=$config->{database}->{pass};
  $dbase->{’database’}=$config->{database}->{database};

  return($dbase);
}

1;
__END__

So now we have a module who’s subroutines we can call from within our mod_perl modules. But this method is not restricted to only mod_perl. Since we created a generic perl module, we can call it from any perl script. For example sometimes you might have to get access to this same config information if you have a perl script that runs from a cronjob to do cleanup on your database.

If you were going to call it from a mod_perl module you might do something like this:

package mywebapp::UpdateUserInfo;
...
use mywebapp::Conf;

sub handler {
...
my $dbase=get_db_config();
...
}

1;

Now you have a hashref full of all the pertinent info needed to login to your database backend. You could go one step further and add a connect_to_db function to your config module and then you wouldn’t even have to mess with the database info at all. With this setup in place, tasks like changing the database server’s hostname or login credentials are now a trivial task that doesn’t require taking your webapp offline.