Skip to content

Releases: tenforwardconsulting/subspace

3.0 release

10 Jan 20:33
Compare
Choose a tag to compare

What's Changed

Major version update from Subspace 2.x to 3.0

Full Changelog: v2.5.8...v3.0.0

3.0 prerelease

24 Oct 19:28
8652ef9
Compare
Choose a tag to compare
3.0 prerelease Pre-release
Pre-release
v3.0.0.rc1

Version 3.0.0.rc1

Update Bootstrap

17 Apr 13:43
Compare
Choose a tag to compare

The Bootstrap task no longer replaced authorized_keys for the privileged user.

Better Environment Variables

29 May 02:08
Compare
Choose a tag to compare

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.templatethat 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