Releases: tenforwardconsulting/subspace
3.0 release
3.0 prerelease
v3.0.0.rc1 Version 3.0.0.rc1
Update Bootstrap
The Bootstrap task no longer replaced authorized_keys for the privileged user.
Better Environment Variables
Previously we had a hodgepodge solution which was to encrypt, in it's entirety, the application.yml into the environment specific vault files using an obscure key, appyl:
, eg:
# secure secrets needed for ansible
database_password: 123abc
# the entire appplication.yml file, regardless of secrecy
appyml:
AWS_ACCESS_KEY_ID: "THIS IS SECRET"
AWS_BUCKET: "probably-not-secret"
AWS_HOST_NAME: "not-secret-either.amazonaws.com"
ROLLBAR_ACCESS_TOKEN: "MaybeASecretOnProdButNotOnDev"
This was not ideal. This update attempts to move everything into a CLI-driven solution that should be able handle things like viewing application.yml diffs, ensuring the presence of keys on all environments, and still protecting secrets.
The new system uses a file in config/provision/templates/application.yml.template
that contains environment variables for all environments. The configuration that is not secret is visible and version controlled, while the secrets are stored in the vault files for their environments. The default file created by subspace init
looks like this:
# These environment variables are applied to all environments, and can be secret or not
# This is secret and can be changed on all three environment easily by using subspace vars <env> --edit
SECRET_KEY_BASE: {{SECRET_KEY_BASE}}
#This is not secret, and is the same value for all environments
ENABLE_SOME_FEATURE: false
development:
INSECURE_VARIABLE: "this isn't secret"
dev:
INSECURE_VARIABLE: "but it changes"
production:
INSECURE_VARIABLE: "on different servers"
Further, you can use the extremely convenient subspace vars development --create
to create a local copy of config/application.yml
(which should be gitignored) to get your application up and running with the good defaults for the development environment (including secrets).
TODO
I would still like to add support to create values easily. We could also possibly use the single variable construct here: http://docs.ansible.com/ansible/playbooks_vault.html#single-encrypted-variable
Alternatively (and probably easier) is to simply decrypt the vaults temprorarilty, alter them in ruby, and then re-encrypt them:
http://docs.ansible.com/ansible/playbooks_vault.html#decrypting-encrypted-files
subspace vars --add SOME_NEW_VAR
Add a new variable
- to all environments? default values somehow?
subspace vars dev --set SOME_VAR="set from the command line"
Automatically decrypt, update, and encrypt the vars file.
possibly even run a very simple play to only update the environment on the server
subspace vars dev --remote
View the current variables/application.yml as they are set on the remote dev machine