Spinnaker Running a Script with Run Job (Manifest): Difference between revisions
Line 13: | Line 13: | ||
{{Note|⚠️ Make sure you use [[Spinnaker Stage Run Job Manifest#Overview|Run Job (Manifest)]] and NOT [[Spinnaker_Stage_Deploy_(Manifest)#Overview|Deploy (Manifest)]]!}} | {{Note|⚠️ Make sure you use [[Spinnaker Stage Run Job Manifest#Overview|Run Job (Manifest)]] and NOT [[Spinnaker_Stage_Deploy_(Manifest)#Overview|Deploy (Manifest)]]!}} | ||
[[Spinnaker Stage Run Job Manifest#Overview|Run Job (Manifest)]] only accepts Job manifests, so a ConfigMap to specify the script cannot be used. | [[Spinnaker Stage Run Job Manifest#Overview|Run Job (Manifest)]] only accepts Job manifests, so a ConfigMap to specify the script cannot be used. The functionality must be already present in the container image and can be controlled via <code>command</code> and arguments. 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. The stage may optionally collect the Job output and inject it back into the pipeline. | ||
<font color=darkkhaki>If the pipeline is intended to be run repeatedly, which is the case for most of the pipelines, it '''must''' also contain a [[Spinnaker Stage Delete (Manifest)#Overview|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. An alternative is to specify a [[Kubernetes_Job#Overview|time to live for the Job]].</font> | |||
=Solution= | =Solution= |
Revision as of 04:45, 30 April 2022
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
Overview
The execution phase is implemented as a Run Job (Manifest) stage.
⚠️ Make sure you use Run Job (Manifest) and NOT Deploy (Manifest)!
Run Job (Manifest) only accepts Job manifests, so a ConfigMap to specify the script cannot be used. The functionality must be already present in the container image and can be controlled via command
and arguments. 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. The stage may optionally collect the Job output and inject it back into the pipeline.
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. An alternative is to specify a time to live for the Job.
Solution
Run Job (Manifest) Definition
Add a "Run Job (Manifest)" stage and name it "Script Job" or similar.
The Account is the target Kubernetes cluster.
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
namespace: REPLACE-WITH-TARGET-NAMESPACE-NAME
---
apiVersion: batch/v1
kind: Job
metadata:
labels:
app: script-job
name: script-job
namespace: REPLACE-WITH-TARGET-NAMESPACE-NAME
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:
- Replace 'REPLACE-WITH-TARGET-NAMESPACE-NAME' with the target namespace for both the ConfigMap and Job.
- Both manifests should use an
app:script-job
label, so they can be deleted at the same time with one 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
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:
Generating and Using Execution Results
I haven't found a way to inject the stout of the script back into the pipeline, as an artifact. The only way the output of the script can be useful is to write it in S3 or GitHub and read it in a later stage as an artifact.