Question

I just started using Fabric to better control the specific settings for test and deployment environments, and I’m trying to get an idea of the best approach to swapping configurations.

Let’s say I have a module in my application that defines a simple database connection and some constants for authentication by default:

host = 'db.host.com'
user = 'someuser'
passw = 'somepass'
db = 'somedb'

class DB():
  def __init__(self,host=host,user=user,passw=passw,db=db,cursor='DictCursor'):
    #make a database connection here and all that jazz

Before I found fabric, I would use the getfqdn() function from the socket library to check the domain name of the host the system was being pushed to and then conditionalize the authentication credentials.

if getfqdn() == 'test.somedomain.com':
  host = 'db.host.com'
  user = 'someuser'
  passw = 'somepass'
  db = 'somedb'
elif getfqdn() == 'test.someotherdomain.com':
  host = 'db.other.com'
  user = 'otherguy'
  passw = 'otherpass'
  db = 'somedb'

This, for obvious reasons, is really not that great. What I would like to know is what’s the smartest way of adapting something like this in Fabric, so that when the project gets pushed to a certain test/deployment server, these values are changed at post-push.

I can think of a few approaches just from looking through the docs. Should I have a file that just defines the constants that Fabric could output to using the shell commands based off what the deployment was, and then the file defining the database handler could import them? Does it makes sense to run open and write from within the fabfile like this? I assumed I’d also have to .gitignore these kinds of files so they don’t get committed into the repo and just rely on Fabric to deploy them.

I plan on adapting whatever approach is the best suggested to all the configuration settings that I currently either swap using getfqdn or adjust manually. Thanks!

Answer 1

You can do all of that off of the env.host and then use something like the contrib template function to render the conf file and push it up. But templates are best in these instances (see: puppet and other config managers as well)