github.com/Microsoft/fabrikate@v0.0.0-20190420002442-bff75be28d02/docs/config.md (about) 1 # Config Definitions 2 3 Configuration files in Fabrikate allow you to define the structure of your deployment once via [components](./component.md) while enabling elements of it to vary across different environments like QA, staging, and production or across on-prem and a public cloud -- or both. 4 5 By convention, configuration is placed into a directory called `config` with the name of the environment that it applies to. Also by convention, if a `common.yaml` (or `common.json`) config definition exists, it is applied globally as config. 6 7 The schema for these config definitions is fairly simple: 8 9 * `config`: A set of configuration values for the component in the parent directory that is intended to be used in conjunction with a generator. For example, with a Helm generator, these configuration values will be applied through a `values.yaml` file to the helm template specified. 10 * `namespace`: The namespace that should be applied for this component. 11 * `injectNamespace`: Directs Fabrikate to inject the specified namespace into every resource manifest generated for this component. This is intended for generators that don't support applying namespaces or where the template for the generator doesn't parameterize the namespace such that it is user accessible. 12 * `subcomponents`: A set of key/value pairs for the subcomponents of this component that specify the configuration for those components. Each of the values of these keys is a config definition in its own right and has the same schema as this config definition. 13 14 Configuration in Fabrikate is collected from the top of the hierarchy down, meaning if a config definition lower in the hierarchy specifies a value for a key of configuration that has been already collected, the configuration provided higher in the hierarchy wins out. The reasoning behind this is because configuration higher in the hierarchy has a higher level of context over how the portions of the deployment definition should work with each other. 15 16 Configuration can (and is encouraged to be) factored out into its individual concerns. For example, to compose a set of resource manifests for a Production environment in East US in Azure, you might factor your configuration into `prod`, `east`, and `azure` configuration files such that when you need to build a Production environment in West US, you can simply swap out the `east` config for a `west` config. 17 18 ## Examples 19 20 ### Jaeger 21 22 In this [config definition](https://github.com/bnookala/fabrikate-jaeger/blob/master/config/common.yaml), configuration is applied to the subcomponent `jaeger` for `collector.annotations.sidecar.istio.io/inject` with the value `false` which will be passed to the helm `values.yaml` file that is applied to this helm chart. The namespace `jaeger` is also injected into the namespace for every resource manifest generated as the helm chart templates written for Jaeger were not parameterized to inject a namespace. 23 24 ```yaml 25 config: 26 subcomponents: 27 jaeger: 28 namespace: "jaeger" 29 injectNamespace: true 30 config: 31 collector: 32 annotations: 33 sidecar.istio.io/inject: "false" 34 ``` 35 36 ### Istio 37 38 In this [config definition](https://github.com/evanlouie/fabrikate-istio/blob/master/config/common.yaml) we are applying the namespace `istio-system` and also applying the config `global.k8sIngress.enable`: `true` in the `values.yaml` file that is applied to the helm chart. It also applies the namespace `istio-system` to the subcomponent `istio-crd`. 39 40 ```yaml 41 namespace: istio-system 42 config: 43 name: istio 44 global: 45 k8sIngress: 46 enabled: true # Create the auto-generated ingress 47 subcomponents: 48 istio-crd: 49 namespace: istio-system 50 ```