Skip to content

Latest commit

 

History

History
204 lines (173 loc) · 7.35 KB

service-configuration.md

File metadata and controls

204 lines (173 loc) · 7.35 KB

Configuring a Service through Fabrikate configurations

The goal of this guide is to explain how to configure a single service's deployment within the High Level Definition repository's configurations.

Requirements

To follow this guide, there are some setup requirements:

  • The service's deployment needs to be templatized as a Helm Chart.
  • The service needs to be added to the High Level Definition repository as a fabrikate component referencing the above Helm Chart.
  • The Deployment configuration needs to exist as a Helm Chart variable.

Validating Helm Chart

Using the sample azure-vote Helm Chart, we'll go over how to set the replicas values for a service's Kubernetes Deployment, however this workflow could apply for any other configuration as long as there is a supporting Helm Chart value.

In the azure-vote deployment.yaml:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: vote-front-{{.Values.serviceName}}
spec:
  replicas: {{ .Values.front.replicaCount }}
  ...

we see that the replicas spec is mapped to {{ .Values.front.replicaCount }}.

Additionally, in the chart values.yaml:

# Deployment controls
image:
  repository: mtarng
  tag: latest

back:
  replicaCount: 1

front:
  replicaCount: 2

we see that the default replica count for the frontend is mapped to 2.

If we added the azure-vote application to an HLD repository component and ran fab generate, the materialized manifest would subsitute the default value into the Helm template:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: vote-front-azure-vote
spec:
  replicas: 2

Now, lets look at an example where we want to configure a different number of replicas depending on which Ring the service is deployed to. For a sample HLD that has 2 rings: master and qa-ring and looks something like this:

$ tree
.
├── bedrock.log
├── component.yaml
├── fabrikam2019
│   ├── access.yaml
│   ├── azure-vote
│   │   ├── component.yaml
│   │   ├── config
│   │   │   └── common.yaml
│   │   ├── master
│   │   │   ├── component.yaml
│   │   │   ├── config
│   │   │   │   └── common.yaml
│   │   │   └── static
│   │   │       ├── ingress-route.yaml
│   │   │       └── middlewares.yaml
│   │   └── qa-ring
│   │       ├── component.yaml
│   │       ├── config
│   │       │   └── common.yaml
│   │       └── static
│   │           ├── ingress-route.yaml
│   │           └── middlewares.yaml
│   ├── component.yaml
│   └── config
│       └── common.yaml
└── manifest-generation.yaml

Overwriting a default Helm Template Value with fabrikate configs

Now according to the fabrikate documentation on config definitions the value for replicaCount can be set at any level of the HLD tree, keeping in mind that the closer to the "root" of the repository, the higher the priority.

Setting the default helm chart config override can be done manually, or with the help of fabrikate.

Setting fabrikate configs manually

Let's make the change manually first by adding the config values at the master ring level for the azure-vote service:

$ cat fabrikam2019/azure-vote/master/config/common.yaml 
subcomponents:
  chart:
    config:
      serviceName: azure-vote-master
      front:                # "front" deployement values
        replicaCount: 5     # Setting front end replica count to 5 for master ring

Now commit and push the changes, and when the final manifests are generated by fabrikate, we should see the changes in the master ring manifests. Let's verify:

# In the manifest repository:
# via: $ cat prod/fabrikam2019/azure-vote/master/chart.yaml 
...
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: vote-front-azure-vote-master
spec:
  replicas: 5
...

Great, our frontend service will now have 5 replicas for the master ring.

Setting fabrikate configs through fabrikate

Now let's have the fabrikate tool set our config values for us instead of having to manually edit the config file.

In this example, we'll run this command from the very root of our HLD repository, and since this is at a higher hierarchy level than the ring level config we made in the manual example, it'll override the changes made there.

$ tree
.
├── bedrock.log
├── component.yaml
├── fabrikam2019
│   ├── access.yaml
│   ├── azure-vote
│   │   ├── component.yaml
│   │   ├── config
│   │   │   └── common.yaml
│   │   ├── master
│   │   │   ├── component.yaml
│   │   │   ├── config
│   │   │   │   └── common.yaml
│   │   │   └── static
│   │   │       ├── ingress-route.yaml
│   │   │       └── middlewares.yaml
│   │   └── qa-ring
│   │       ├── component.yaml
│   │       ├── config
│   │       │   └── common.yaml
│   │       └── static
│   │           ├── ingress-route.yaml
│   │           └── middlewares.yaml
│   ├── component.yaml
│   └── config
│       └── common.yaml
└── manifest-generation.yaml

# Running `fab` command at the HLD root
$ fab set --subcomponent fabrikam2019.azure-vote.master.chart front.replicaCount=7
INFO[04-05-2020 00:41:20] 💾  Loading config/common.yaml                
INFO[04-05-2020 00:41:20] 🌱  Creating new subcomponent configuration for fabrikam2019 
INFO[04-05-2020 00:41:20] 🌱  Creating new subcomponent configuration for azure-vote 
INFO[04-05-2020 00:41:20] 🌱  Creating new subcomponent configuration for master 
INFO[04-05-2020 00:41:20] 🌱  Creating new subcomponent configuration for chart 
INFO[04-05-2020 00:41:20] 🌱  Created new value for front.replicaCount 

# Verifying changes
$ cat config/common.yaml 
subcomponents:
  fabrikam2019:
    subcomponents:
      azure-vote:
        subcomponents:
          master:
            subcomponents:
              chart:
                config:
                  front:
                    replicaCount: "7"

Now commit and push the changes. The generated manifest should now reflect the higher level changes:

# In the manifest repository:
# via: $ cat prod/fabrikam2019/azure-vote/master/chart.yaml 
...
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: vote-front-azure-vote-master
spec:
  replicas: 7
...

And that's it, you've successfully configured your service deployment!

Note - fab set can be run at any level of the HLD repository. If you were looking to set the config at the master ring level, then the command would look something like:

$ cd fabrikam2019/azure-vote/master/
$ fab set --subcomponent chart front.replicaCount=4