- Yair Mark
Today I needed to debug why an application was misbehaving in a none development environment. The first thing to do for sanity sake is ensure that the code you are debugging is the code you expect has been deployed.
Luckily in my case we use a very good naming strategy so we can easily inspect running containers in an environment and tie it back to the code. For example in our Kubernetes environment for the pod I am investigating I would run:
kubectl describe pod my-apps-pod-3213sdasa
which would output something like the below:
ame: my-apps-pod-3213sdasa Namespace: default Node: k8s-agentpool1-83254052-6/10.240.0.11 Start Time: Sat, 10 Mar 2018 04:22:11 +0200 ... Containers: my-app: Container ID: docker://04bad116fda85f46cdc5aa4d77088020629e63c65c118c0254a681f94150c53f Image: my.companies.docker.registry.io/foundery/my-app:f5699e1 ...
The line I am looking for in this case is this one:
In the above I can see what docker image is being run in the pod. The hash at the end of the registry URL matches with a hash of the code that is running in the container. This makes it trivial to easily link this back to the exact code being run making debugging just that little bit easier.