Spinnaker Running a Script with Deploy (Manifest)

External

• https://kb.armory.io/s/article/Run-a-Generic-Shell-Script-with-Spinnaker
• https://spinnaker.io/docs/guides/user/kubernetes-v2/run-job-manifest/
• https://blog.spinnaker.io/extending-spinnaker-with-kubernetes-and-containers-5d16ec810d81

Internal

• Spinnaker Concepts
• Run Job (Manifest)

Overview

The execution phase is implemented as a Deploy (Manifest) stage. The manifest contains the definition of a ConfigMap, which includes the script as data, and a Kubernetes Job, which executes the script within a container whose image is specified in the job's definition. A simpler approach is to only specify the container's command, without a script in the ConfigMap and without ConfigMap. This works if we control the image and we can release new versions of the image to include the functionality we need. The stage will deploy the job manifest and wait until it completes, thus gating the pipeline’s continuation on the job’s success or failure. If the pipeline is intended to be run repeatedly, which is the case for most of the pipelines, it must also contain a Delete (Manifest) stage to delete the Job and associated resources after execution, otherwise an attempt to re-run it fails on account of not being able to modify the Job.

Note that this is alternative to

Running a Script with Deploy (Manifest)

Solution

Deploy (Manifest) Definition

Add a "Deploy (Manifest)" stage and name it "Script Job" or similar.

The Account is the target Kubernetes cluster. Override Namespace with the target namespace.

In Manifest Configuration. set Manifest Source: Text, and use this:

apiVersion: v1
data:
  script.sh: |-
    echo "Hello world!"
kind: ConfigMap
metadata:
  labels:
    app: script-job
  name: script-job-cm
---
apiVersion: batch/v1
kind: Job
metadata:
  labels:
    app: script-job
  name: script-job
spec:
  backoffLimit: 2
  template:
    spec:
      containers:
        - command:
            - sh
            - /opt/script/script.sh
          image: 'bitnami/kubectl:1.12'
          name: script
          volumeMounts:
            - mountPath: /opt/script
              name: volume01
              readOnly: true
      restartPolicy: Never
      volumes:
        - configMap:
            name: script-job-cm
          name: volume01

Notes:

• Do not specify a namespace in neither manifests. Spinnaker stage configuration will.
• Both manifests should use an app:script-job label, so they can be deleted with a selector.

Delete (Manifest) Definition

Add a Delete (Manifest) stage, name it "Script Job Clean Up".

Use the same account and namespace.

Selector: Match target(s) by label. In the Kinds control, select both job and configMap. For Labels, use key: "app", value "script-job"

This is the equivalent of manually executing:

kubectl -n of-test delete job,cm  --selector app=script-job

Execution Considerations

This "Script Job" stage deploys a Kubernetes Job, which gets executed immediately. The logic to be executed is provided as the content of a ConfigMap, declared in the same deployment artifact manifest.

If the pipeline fails in the Deploy (Manifest) stage with an error message that includes "field is immutable", it is because an older Job has been left around.

A failed job execution leaves Jobs around.

Upon deployment, the Job will run the script.

Viewing Execution Logs

https://spinnaker.io/docs/guides/user/kubernetes-v2/run-job-manifest/#viewing-execution-logs

The job execution log is captured and can be accessed in the pipeline execution details → Deploy (Manifest) stage → Deploy Status → Console Output (raw).

If the Spinnaker instance is configured as such, logs can be forwarded to dedicated infrastructure.

Also see:

Operations | Log Management

Generating and Using Execution Results

The stage is not equipped to collect and use the execution results. For that, use:

Running a Script with Run Job (Manifest)