I've spinnaker with kubernetes manifest v2. Now, I'm creating spinnaker pipeline with manifest files in which I'd like to have namespace named as applicationName-pipelineName.
I'm looking for spinnaker environment variable for pipeline name which I can use in manifest file to would append in file.
Ex. I'm using docker registry latest tag as
imageName:${trigger['tag']}
similarly something like
apiVersion: v1
kind: Namespace
metadata:
name: appName-${pipelineName}
please advise. Thanks.
During pipeline runtime you have following parameters available:
${execution.id} - unique id of execution;
${execution.name} - name of pipeline used during creation;
${execution.pipelineConfigId} - unique id for pipeline across whole Spinnaker instance, it also could be set to something meaningful if you create pipeline using API.
Do not forget that namespace's name is very sensitive to case and non-alphanumerical symbols. Such functions like #alphanumerical(string) and ${java.lang.String.toLowerCase()} will be very helpful.
You may find this reference useful - Pipeline Expression Reference.
Related
I'm deploying a spring cloud data flow cluster on kubernetes with helm and the chart from bitnami. This works fine.
Now I need an additional template to add a route. Is there a way to somehow add this or inherit from the bitnami chart and extend it? Of course I'd like to reuse all of the variables which are already defined for the spring cloud data flow deployment.
That chart has a specific extension point for doing things like this. The list of "Common parameters" in the linked documentation includes a line
Name: extraDeploy; Description: Array of extra objects to deploy with the release; Value: []
The implementation calls through to a helper in the Bitnami Common Library Chart that calls the Helm tpl function on the value, serializing it to YAML first if it's not a string, so you can use Helm templating within that value.
So specifically for the Bitnami charts, you can include an extra object in your values.yaml file:
extraDeploy:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: '{{ include "common.names.fullname" . }}'
...
As a specific syntactic note, the value of extraDeploy is a list of either strings or dictionaries, but any templating is rendered after the YAML is parsed; this is different from the normal Helm template flow. In the example above I've included a YAML object, but then quoted a string value that begins with a {{ ... }} template, lest it otherwise be parsed as a YAML mapping. You could also force the whole thing to be a string, though it might be harder to work with in an IDE.
extraDeploy:
- |-
metadata:
name: {{ include "common.names.fullname" . }}
You can just create the YAML template file in the templates folder and it will get deployed with the chart.
You can also edit the existing YAML template accordingly and extend it no need to inherit or much things.
For example, if you are looking forward to adding the ingress into your chart, add ingress template and respective values block in values.yaml file
You can add this whole YAML template in folder : https://github.com/helm/charts/blob/master/stable/ghost/templates/ingress.yaml
and specific values.yaml block for ingress.
Or for example your chart dont have any deployment and you want to add deployment you can write your own template or use form internet.
Deployment : https://github.com/helm/charts/tree/master/stable/ghost/templates
there is deployment.yaml file template and you can get specific variables that the template uses into values.yaml and you have extended the chart successfully.
I have this ConfigMap where I am constructing a app-config.json file that I pass into Angular. This file is how I get environment variables into Angular as they must be served.
Below is how I thought passing variables into the JSON would work in ConfiMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: frontend-settings
data:
app-config.json: |-
{
"keycloakUrl": "http://${minikube ip}:${keycloak_port}/auth",
"realm": "eshc",
"clientId": "eshc-frontend",
"backendApi": "http://localhost:${backend_port}"
}
The problem is that these are not evaluated. I want to pass Kube service aliases, and the minikube ip command as in the example above. Could someone point me in the right direction as to how I might do this?
Thanks in advance!
Kubernetes doesn't provide this facility in the API.
You can do this at deploy time with helm or kubectl's kustomization features.
Depending on your use case, this can also be done at runtime in a container entry point before the app starts up or in a Kubernetes specific init container. Avoid the init container unless you are working with shared file systems, or with the Kubernetes API to apply these changes.
From your example it looks like everything should be available at deploy time, maybe not the minikube IP. For that you should be able to use the magic DNS name host.minikube.internal
I have a config map that defines some variables like environment that are then passed into alot of deployment configurations like this
- name: ENV
valueFrom:
configMapKeyRef:
name: my-config-map
key: ENV
secrets and some volumes like ssl certs are common across the configs also. Is there some kubernetes type that I could create a base service deployment that extends a normal deployment? Or some other way to deal with this? Also using kustomize, there might be an option there.
You can use a PodPreset object to inject information like secrets, volume mounts, and environment variables etc into pods at creation time.
Before starting using PodPreset you need to take few steps:
Firstly need to enable API type settings.k8s.io/v1alpha1/podpreset, which can be done by including settings.k8s.io/v1alpha1=true in the --runtime-config option for the API server
Enable the admission controller PodPreset. You can do it by including PodPreset in the --enable-admission-plugins option value specified for the API server
After that you need to creatie PodPreset objects in the namespace you will work in and create it by typing kubectl apply -f preset.yaml
Please refer to official documentation to see how it works.
I want keep version of all pods (App) in env inside namespace. so i can use them in yaml file to create deployment. or even in ci/cd makes devops easier.
right now developer must set the version in yaml file.
If you want to use the environment variables in menifest file or in yaml file you can simply use the kubernetes secrets & config maps.
where can store the environment and use them during the deployment.
That's about the design principle, and that's the ideal approach to apply for your pipeline.
You don't have to save the exact version of all your Pods inside the manifest file, just use the latest or environment-like tag (e.g staging or production)
And in your pipeline, you could patch the deployment with the corresponding tag based on your build.
One example of this approach:
kubectl patch deployment $YOUR_DEPLOYMENT_NAME -p "{\"metadata\":{\"labels\":{\"image\":\"$YOUR_BUILD_STAGE-$PIPELINE_ID\"}},\"spec\":{\"revisionHistoryLimit\":2,\"template\":{\"spec\":{\"containers\":[{\"name\":\"$YOUR_CONTAINER_NAME\",\"image\":\"$DOCKER_IMAGE_NAME:$YOUR_BUILD_STAGE-$PIPELINE_ID\"}]}}}}"
In Azure pipeline I download kubernetes deployment.yml property file which contains following content.
spec:
imagePullSecrets:
- name: some-secret
containers:
- name: container-name
image: pathtoimage/data-processor:$(releaseVersion)
imagePullPolicy: Always
ports:
- containerPort: 8088
env:
My intention is to get the value from pipeline variable $(releaseVersion). But it seems like kubernetes task doesn't allow this value to be accessed from pipeline variable.
I tried using inline configuration type and it works.That means If I copy same configuration as inline content to kubernetes task configuration, it works.
Is there anyway that I can make it work for the configuration from a file?
As I understand, you may want to replace the variable of deployment.yml file content while build executed.
You can use one task which name is Replace Tokens task (Note:The token under this task name is not same with PAToken). This is the task which support replace values of files in projects with environments variables when setting up VSTS Build/Release processes.
Install Replace Tokens from marketplace first, then add Replace Tokens task into your pipeline.
Configure the .yml file path in the Root directory. For me, my target file is under the Drop folder of my local. And then, point out which file you want to operate and replace.
For more argument configured, you can check this doc which I ever refer: https://github.com/qetza/vsts-replacetokens-task#readme
Note: Please execute this task before Deploy to Kubernetes task, so that the change can be apply to the Kubernetes cluster.
Here also has another sample blog can for you refer.
You should have it as part of your pipeline, to substitute environment variables inside the deployment template
Something along the lines of:
- sed -i "s/$(releaseVersion)/${RELEASE_VERSION_IN_BUILD_RUNNER}/" deployment.yml
- kubectl apply -f deployment.yml
You can set the variables in your pipeline. https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch