Remenv
Remote environment management. Heroku style environment configuration brought to
any production environment that has a key/value store.
Why Remenv?
Managing your system's configuration with environment variables is effective,
convenient, safe, and flexibile. It lets an application use the same code across
all environments and be configured entirely by variables in the environment.
The problem comes in when you have multiple production systems that need to have
the same environment. Problems are compounded when there are multiple developers
deploying to the same environment but with differing local copies of production
environment variables. Of course, ideally nobody would be in that kind of
distributed race conundrum, but in reality people make mistakes and the
production flow isn't as coordinated as we may like.
The goal of remenv is to provide a very simple (very Heroku inspired) set of
tools for managing an applications environment across any number of systems. It
approaches the problem by applying a thin layer of sugar over maniupating a
centralized key value store—namely Redis.
Installation
Add this line to your application's Gemfile.
gem 'remenv'
You'll probably want to binstub it so you can avoid typing bundle exec
all of
the time:
bundle binstub remenv
Command Line Usage
Running remenv
from the command line will print out a (hopefully) helpful bit
of documentation about each command. That is certainly the best place to start:
$ remenv
Commands:
remenv clear # Clear all stored key/value pairs
remenv dump FILENAME # Dump all stored key/value pairs to FILENAME
remenv help [COMMAND] # Describe available commands or one specific command
remenv load FILENAME # Load all key/value pairs from FILENAME
remenv set KEY=VALUE # Store VALUE for KEY
remenv show [KEY] # Show value for KEY or all stored key/value pairs
remenv unset KEY # Remove values for KEY
Options:
[--adapter=ADAPTER] # Default: redis
[--stage=STAGE] # Default: development
[--namespace=NAMESPACE] # Default: remenv
[--url=URL]
Configuration
Settings should be persisted by writing configuration as YAML to .remenv.yml
for the current directory. Multiple stages (development, production, etc) can be
specified within the same configuration if desired. The default stage is assumed
to be development.
test:
adapter: memory
namespace: remenv-test
development:
adapter: redis
namespace: remenv
url: redis://localhost:6379/15
production:
adapter: redis
namespace: remenv-production
url: redis://server.com:6379/0
Workflow
- Import your existing
.env
configuration for development or production:
$ remenv load .env
- Update any vars that may be missing or incorrect:
$ remenv show
LOG_LEVEL DEBUG
RACK_ENV production
RAILS_ENV production
$ remenv set LOG_LEVEL=INFO
OK!
LOG_LEVEL INFO
- Sync the configuration to a remote server using Capistrano:
$ cap production remenv:sync
Contributing
- Fork it ( http://github.com/dscout/remenv/fork )
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request