Track Product Version vs Git Version for a Wrapped Service? #40541
-
|
Let's say I'm running Redis but a custom Docker build of it, so Right now, I'm labeling my pods like this: tags.datadoghq.com/env=dev
tags.datadoghq.com/service=redis
tags.datadoghq.com/version=adc83b19e793491b1c6ea0fd8b46cd9f32e592fcThis is nice because then it's easy for me to locate the exact Git version that produced the image/deployment. However, since the underlying version of Redis may change, it would be nice to be able to add metadata referencing the actual Redis version so that in Datadog, I can distinguish the difference between Redis (e.g. 8.2.1). Is there a labeling strategy where I can expose the Redis version to Datadog so I can group deployments based on what actual version of Redis that they are running? Should I instead be labeling the version as the Redis version and embed the Git commit in some other label? How do most customers deal with this issue? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
@naftulikay yes this is more possible if you package your Kubernetes manifests into a Helm chart so you can leverage helm templates and set values of the version that you're looking to set (redis version), rather than the git sha hash, for example in the CI you can install your application Helm chart with setting helm install myapp ./myapp --set redisVersion 8.2.2this tags.datadoghq.com/redis-version: {{ .Values.redisVersion }} |
Beta Was this translation helpful? Give feedback.
@naftulikay yes this is more possible if you package your Kubernetes manifests into a Helm chart so you can leverage helm templates and set values of the version that you're looking to set (redis version), rather than the git sha hash, for example in the CI you can install your application Helm chart with setting
redisVersionvaluethis
redisVersionfield is listed in thevalues.yamlof your helm chart, and reflected in your application resource template as