Advanced Operator Configuration

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Custom Halyard configuration

To override Halyard’s configuration, create a Kubernetes ConfigMap with the configuration changes you need. For example, if you’re using secrets management with Vault(), Halyard and Operator containers need your Vault configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: halyard-custom-config
data:
  halyard-local.yml: |
    secrets:
      vault:
        enabled: true
        url: <URL of vault server>
        path: <cluster path>
        role: <k8s role>
        authMethod: KUBERNETES    

Then, you can mount it in the Operator deployment and make it available to the Halyard and Operator containers:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: spinnaker-operator
  ...
spec:
  template:
    spec:
      containers:
      - name: spinnaker-operator
        ...
        volumeMounts:
        - mountPath: /opt/spinnaker/config/halyard.yml
          name: halconfig-volume
          subPath: halyard-local.yml
      - name: halyard
        ...
        volumeMounts:
        - mountPath: /opt/spinnaker/config/halyard-local.yml
          name: halconfig-volume
          subPath: halyard-local.yml
      volumes:
      - configMap:
          defaultMode: 420
          name: halyard-custom-config
        name: halconfig-volume

Patching Runtime Resources with Kustomize

Your Kubernetes cluster may require additional sidecars or configuration present when managing Spinnaker resources. In these situations, the Armory Operator provides the ability to patch resources during reconciliation. These patches are executed via an embedded Kustomize instance in the Operator, and requires no additional installation on the user’s part. You can apply Kustomize patches at two levels of specificity:

• Spinnaker as a whole
• Individual services within Spinnaker

Additionally, you may make changes to the following resources generated by the Operator:

• Deployment manifests
• Service manifests

For example, to ensure that a ConfigMap is present on all Spinnaker services, you would add the following configuration block to your SpinnakerService config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  kustomize:
    spinnaker:
      deployment:
        patchesJson6902: |
          - op: add
            path: /spec/template/spec/volumes/-
            value:
              name: custom-volume
              configMap:
                name: custom-volume
          - op: add
            path: /spec/template/spec/containers/0/volumeMounts/-
            value:
              mountPath: /opt/spinnaker/config/foo
              type: configMap
              name: custom-volume          

The previous configuration sample indicates how to specify patches in the patchesJson6902 format, that mounts a ConfigMap called custom-volume into the /opt/spinnaker/config/foo namespace.

When you no longer need the patches, you can remove them from the Operator config and they will be removed on next reconciliation for your cluster.

Help resources

• Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
• Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.