Skip to content

File Based Namespaces

Jump to bottom
Jeff Felchner edited this page Jan 12, 2018 · 5 revisions

So far we've only looked at what we call "Inline Namespaces", where the namespaces are nested inside a settings file, but Chamber also allows you to completely separate a namespace into another file.

If we were using one of our offical plugins, which loads a namespace for the environment as well as a namespace for the current hostname, Chamber attempts to auto-detect other files you might want to load.

Example

For this example we're going to assume we're loading a project in development and that our hostname is devbox.

While Chamber will always load settings.yml if it exists, when namespaces are specified, it would also attempt to load:

  • settings-development.yml
  • settings-development.yml.erb
  • settings-devbox.yml
  • settings-devbox.yml.erb

This also goes for any files in your settings subdirectory. Each file gets this treatment. If your settings subdirectory looked like this:

<basepath>/settings
|
|-- email
|    |
|    |-- addresses.yml
|    |-- smtp
|         |
|         |-- servers.yml
|
|-- http
|    |
|    |-- main.yml
|
|-- sidekiq
|    |
|    |-- queues.yml
|
|-- redis.yml.erb

Chamber will load:

  • settings/email/addresses.yml
  • settings/email/addresses-development.yml
  • settings/email/addresses-devbox.yml
  • settings/email/smtp/servers.yml
  • settings/email/smtp/servers-development.yml
  • settings/email/smtp/servers-devbox.yml
  • settings/http/main.yml
  • settings/http/main-development.yml
  • settings/http/main-devbox.yml
  • settings/sidekiq/queues.yml
  • settings/sidekiq/queues-development.yml
  • settings/sidekiq/queues-devbox.yml
  • settings/redis.yml
  • settings/redis-development.yml
  • settings/redis-devbox.yml

in that order. The settings in any later files will override settings in any earlier files.

Note: One of the biggest advantages to this approach is that it allows you to easily gitignore settings for an entire namespace (eg settings/*-production.yml)

This file-based approach is more commonly used to keep all your production settings in separate files which are then stored outside the repository. However with Chamber that is not a use case we find useful since you can just encrypt your settings using a namespace key pair.

In general, most Chamber users always use inline namespaces.

Kompanee Logo Copyright ©2023

  1. Release News
  2. Gem Comparison
  3. 12-Factor App Rebuttal
  4. Environment Variable Problems
    1. Lack of Complex Values
    2. Organization
    3. Environment Sharing
    4. Team Member Syncing
    5. Environment Syncing
    6. Local Settings
    7. Tracking Changes
  5. Installation
    1. Initialization
    2. In a Ruby Project
    3. In a Rails Project
    4. In a Rails Engine
    5. In a Sinatra Project
    6. In a Padrino Project
    7. In a Hanami Project
  6. Basics
    1. File Layout
    2. Defining Settings
    3. Accessing Settings
    4. Namespace Basics
      1. Inline Namespaces
      2. Host-Based Settings
    5. Encryption Basics
      1. Encrypting Your Settings
      2. Accessing Encrypted Settings
    6. Environment Variables
  7. Defining Settings
    1. ERB Preprocessing
    2. Runtime Values
    3. Dynamic Templating
  8. Accessing Settings
    1. Dig
  9. Verifying Settings
  10. Namespaces
    1. File-Based Namespaces
    2. Mix and Match
    3. Custom Namespaces
  11. Environment Variables
    1. Coercions
  12. Integrations
    1. Git Commit Hooks
    2. Cloud Services
  13. Encryption
    1. Keypair Encryption
    2. What Keys Can Do
    3. Encrypting Nested Structures
    4. Namespaced Key Pairs
    5. Re-Securing
    6. Loading Keys from ENV
  14. Advanced Usage
    1. Manually Specifying Settings Files
    2. Outputting Your Settings
    3. Specifying Multiple Namespaces
    4. Handling Duplicates/Collisions
    5. Extending Chamber
  15. Command Line Reference
    1. init
    2. show
    3. files
    4. sign
    5. secure
    6. unsecure
    7. compare

Clone this wiki locally