Open hunter opened 8 years ago
Helm uses a similar approach for their values/templates - https://github.com/kubernetes/helm/blob/master/docs/charts.md#templates-and-values
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.
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
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"
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.
Opened PR #53 for discussions...
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
These will be keys of the pipeline vars and ENV vars?
"KONTINUOUS_REQUIRE_SOURCE_CODE" what does this do?
it's use in the kontinuous agent to git clone
source.
Why is it needed globally?
i don't think we'll be needing that soon.
the list is just partial. we can cherry-pick on what would be useful to the user.
Fixes #53 Added support for templated deployment manifest file/s Added support for templated pipeline yaml Added support for single file / directory for deployment resources
deploy_file
for single filedeploy_dir
for resource directory Added support for global and local vars
Does this also include the Kontinuous variables?
yes.
LGTM!
can we close this?
The deploy stage is a good start but there are some improvements needed to be useful for real deployments.
<basenamespace>-staging
or<basenamespace>-<commitid>
). Regex/Variable support useful here too?kubectl apply
support - updating existing resources in placePerhaps it is easier to use
kubectl
directly for the stage instead of the APIA 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)