You are viewing version 2.26 of the documentation, which is no longer maintained. For up-to-date documentation, see the latest version.

Advanced Operator Configuration

Learn how to configure the Armory Operator for specialized use cases.

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

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(Proprietary), 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:

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


Last modified May 7, 2021: (066ebea)