AJR/TechradarDev
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix: update links and remove .html extension

Browse Source
This commit is contained in:
Mathias Schopmans
2024-03-12 11:42:36 +01:00
committed by Mathias Schopmans
parent bc1e5b2d70
commit daa86a3f59
75 changed files with 103 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
radar/2017-03-01/settings-injection.md
View File

@@ -6,6 +6,6 @@ quadrant: methods-and-patterns
While deploying applications to an environment, the application typically needs to be configured for that specific environment. Typical settings include domain names, database credentials and the location of other dependent services such as cache backends, queues or session storages.
These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul.html), [kubernetes](/platforms-and-aoe-services/kubernetes.html) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD).
These settings should not be shipped with the build package. Instead, it's the environment - this build is being deployed to - that should expose these values to application. A common way to "inject" these values is by making them available as environment variables or dynamically creating configuration files for the application. You can achieve this pattern without special tools - but this concept of settings injection also works with tools such as [Consul](/tools/consul/), [kubernetes](/platforms-and-aoe-services/kubernetes/) (with configMaps and secrets) or [YAD](https://github.com/AOEpeople/YAD).
In this manner, the build package can be independent of the environment it's being deployed to - making it easier to follow the "Build once, deploy often" CI/CD principle.