Slimming down the explanation here
@@ -5,9 +5,7 @@ title: Habitat - Dynamically Configure Services
section
h2 Dynamically Configure Services
- p From the beginning, Habitat was built with configuration in mind. Instead of constantly destroying, rebuilding, and redeploying packages for each change, Habitat produces an immutable package artifact where you define which configuration settings should be exposed. You can make configuration changes through environment variables and through a configuration update process that sends updated values to any member within a given service group.
-
- p In the example below, a workstation machine is connected to the same network as the Rails and PostgreSQL services. Run the <code>hab config apply</code> subcommand to send the <code>update_config.toml</code> to the <code>myrubyapp.default</code> service group. This will update the appropriate configuration values for the Rails app and allow it to connect to the database.
+ p Habitat produces an immutable package artifact where you define which configuration settings should be exposed. You can make configuration changes through environment variables and through a configuration update process that sends updated values to any member within a given service group.
pre
code.console $ hab config apply --peer 172.17.0.2 myrubyapp.default 1 update_config.toml
