Configurator is a version control and a sync service that keeps Kubernetes ConfigMaps and Secrets in sync with the deployment. Configurator uses CRDs to create CustomConfigMaps and CustomSecrets that in turn create ConfigMaps and Secrets with a postfix. As and when a change is detected in the CustomConfigMap or CustomSecret, Configurator automaticatlly generates a new ConfigMap with a new postfix. This acts like version controlling the ConfigMaps. In order to keep the deployments and statefulsets in sync with the ConfigMap and Secret version, users must start with creating a CustomConfigMap as the first step. This creates a new ConfigMap with a postfix ie., first version. Users then have to reference the ConfigMap along with the postfix in their deployment and satefulset specifications. From them on, users can edit the CustomConfigMap directly. Any change in the CustomConfigMap will be automatically rolled out to all the deployments and statefulsets referencing the initial configMap version. A change in ConfigMap not only creates a new ConfigMap version, but also rolls out a new deployment version. This enables both rolling update and rollback of ConfigMaps in sync with the deployment versions.

• K8s 1.16+

Build the source code and the docker image for Configurator. Push the image to registry and deploy configurator in the cluster.

make clean build push deploy 

Remove the configurator deployment from cluster and delete local binary and docker image

make remove clean 

YAML files for deploying the latest version of Configurator is available under the deploy folder.You need to deploy the CRDs, the controller and the service/role binding.

kubectl apply -f deploy/crd-customConfigMap.yaml
kubectl apply -f deploy/crd-customSecret.yaml
kubectl create ns configurator
kubectl apply -f deploy/configurator-clusterrole.yaml
kubectl apply -f deploy/configurator-clusterrolebinding.yaml
kubectl apply -f deploy/configurator-serviceaccount.yaml
kubectl apply -f deploy/configurator-deployment.yaml

Verify if configurator resources are created successfully.

kubectl get deployment -n configurator
NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
configurator-controller              1/1     1            1           4h38m

Once configurator is deployed in the cluster, start creating customConfigMaps. Example customConfigMaps are available under artifacts/examples folder. Create customConfigMap. This will create a configMap with a postfix.

kubectl apply -f artifacts/exmaples/example-customConfigMap.yaml

List the configMap and make a note of the postfix for the first time.

kubectl get configMap -n test
NAME               DATA   AGE
testconfig-srseq   1      9s

Here "srseq" is the postfix. Create deployment referencing the newly created configMap and its postfix. Please note the deployment metadata label must contain the config name and the config postfix that was created initially. say =. Under the VolumeMounts section use the complete name of the configMap along with the postfix.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-deployment
  labels:
   testconfig: srseq
    app: busybox
spec:
  replicas: 1
  revisionHistoryLimit: 1
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command: ['sh', '-c', 'echo Container 1 is Running ; sleep 3600']
        volumeMounts:
        - mountPath: /test
          name: test-config
      volumes:
      - name: test-config
        configMap:
          name: testconfig-srseq

From now, you can directly update the customConfigMap and this will create a configMap with a new postfix and will automatically sync up the related deployments with the newly created configMap. Same functionality applies for secrets as well.

kubectl get ccm -n <namespace>
kubectl get customconfigmap -n <namespace>
kubectl describe ccm -n <namespace>
kubectl describe customconfigmap -n <namespace>
kubectl delete ccm -n <namespace>
kubectl delete customconfigmap -n <namespace>
kubectl get customsecret -n <namespace>
kubectl get ccs -n <namespace>
kubectl describe customsecret -n <namespace>
kubectl describe ccs -n <namespace>
kubectl delete customsecret -n <namespace>
kubectl delete ccs -n <namespace>

1. Start contributing by creating an issue in the issue tracker.
2. Create a separate feature branch for new enhancements.
3. We follow the standard ‘Fork and Pull’ workflow.

1. Fetch the latest code from master branch and resolve any conflicts before sending a pull request.
2. Make sure you build and test the changes before sending a pull request.
3. Ensure the README is updated with any interface or architecture changes.

Congurator is maintained by gopaddle.io team.