Stage: Deploy Improvements

[hunter]

The deploy stage is a good start but there are some improvements needed to be useful for real deployments.

• Variable support for updating a manifest before deployment (perhaps adding gotmpl support and/or a regex)
• Deploy to different namespace (eg. <basenamespace>-staging or <basenamespace>-<commitid>). Regex/Variable support useful here too?
• Image Tag handling - deploying the image built in an earlier stage. Another variable to be used in a template?
• kubectl apply support - updating existing resources in place

Perhaps it is easier to use kubectl directly for the stage instead of the API

A few of these ideas are coming from the GCE CD Jenkins example (https://github.com/GoogleCloudPlatform/continuous-deployment-on-kubernetes/blob/master/sample-app/Jenkinsfile#L39-L48)

[hunter]

Helm uses a similar approach for their values/templates - https://github.com/kubernetes/helm/blob/master/docs/charts.md#templates-and-values

[madziefe]

For variables we can use gotemplate and toml to provide the values.
we can add value_file or any better name for that? as param in deploy

      - name: Deploy App
        type: deploy
        params:
          deploy_file: manifest.yml
          value_file: manifest.toml

If value_file is left empty, then will run/apply manifest.yml as is.

[hunter]

A few alternatives to consider too...

KVs in the yaml:

      - name: Deploy App
        type: deploy
        params:
          deploy_file: manifest.yml
        vars:
          value1: something
          value2: somethingelse

or otherwise ConfigMaps

One consideration with any of these options is how do we handle/specify global variables (commit id, tags, etc) or pass vars them between stages

[madziefe]

for approach 1 these are the sample files:

manifest.yml

---
kind: Service
apiVersion: v1
metadata:
  name: {{.name}}
  namespace: {{default "kontinuous" .namespace}}

spec:
  selector:
    app: {{.name}}
    type: ci-cd
  ports:
    - name: api
      port: 8080
      targetPort: 8080
---
kind: Pod
apiVersion: v1
metadata:
  name: {{.name}}
  namespace: {{default "kontinuous" .namespace}}
  labels:
    app: {{.name}}
    type: ci-cd    
spec:
  containers:
    - name: {{.name}}
      image: {{.imageRegistry}}/{{.imageName}}:{{.dockerTag}}
      imagePullPolicy: {{.pullPolicy}}
      ports:
        - name: api
          containerPort: 8080
          protocol: TCP

manifest.toml

dockerTag = "latest"
pullPolicy = "Always"
name = "myproj"
namespace = "mayspace"
imageRegistry = "quay.io/myrepo"
imageName = "myprojimage"

[madziefe]

we can add globalvars in definition.yml to cater global variables and localvars for stage specific variables. In case a localvars key has the same key in globalvars, we'll use that localvars key for that stage.

[hunter]

Opened PR #53 for discussions...

[madziefe]

initial list of Kontinuous variables to be exposed to the user

        "KONTINUOUS_PIPELINE_ID":         Generated UUID for pipeline
        "KONTINUOUS_BUILD_ID":            Current build number
        "KONTINUOUS_STAGE_ID":            Curren stage number
        "KONTINUOUS_BRANCH":              Build Branch
        "KONTINUOUS_NAMESPACE":           Namespace defined in the .pipeline.yml
        "KONTINUOUS_ARTIFACT_URL":        Artifact path specified by user,
        "KONTINUOUS_REQUIRE_SOURCE_CODE": Always set to "TRUE".
        "KONTINUOUS_INTERNAL_REGISTRY":   Used by kontinuous as its own registry. Default value from System env. INTERNAL_REGISTRY
        "KONTINUOUS_COMMIT":              The commit of the build
        "KONTINUOUS_URL":                 Current url of Kontinuous 

[hunter]

These will be keys of the pipeline vars and ENV vars?

"KONTINUOUS_REQUIRE_SOURCE_CODE" what does this do?

[madziefe]

it's use in the kontinuous agent to git clone source.

[hunter]

Why is it needed globally?

[darkcrux]

i don't think we'll be needing that soon.