Support for variables in Kubernetes Container names

Continuing the discussion from Custom Names for Containers Deployed to Kubernetes:

Please excuse me for bringing up this issue again, but I too have a desire to have custom names for my containers. I am debugging container memory usage in Azure, and the log entries are marked with “InstanceName” which is something like /subscriptions/{subscription-guid}/resourceGroups/{resourcegroup-name}/providers/Microsoft.ContainerService/managedClusters/{cluster-name}/{container-guid}/{container-name}. There is no reference to pod-name or something app-specific here, except the container-name, which unfortunately can’t be customized using variables in the “Deploy Kubernetes Containers” step.

It would be incredibly useful for me if I could be allowed to use variables in this field, so I could name the individual containers after my app.

Example screenshot of the best memory overview I’m currently able to create (with all containers named “docker-image”):
image

Good morning @Tosh,

Thank you for contacting Octopus Support, I took a look at the previous discussion we had regarding this and as Adam mentioned in the previous forum post we do not think this is possible, at least at the moment.

Our engineers can look into this further but this would fall under a feature request. You can use our UserVoice page to register your interest to get this request looked at by our engineers who may be able to implement it in the future.

If you mention the other forum ticket too that’s two customers who have an appetite for this feature which gives it a bit more clout for our engineers to look at.

I am sorry I could not help you further but post your suggestion up and our engineers will take a look.
Reach out if you need anything in the future.

Kind Regards,

Clare

From the previous thread I got the understanding that the biggest problem would be getting unique naming of the different containers inside a replica set. I understand the problem with implementing this, as this isn’t something supported in Kubernetes.

The follow-up question is similar to mine though, and is closed with an explanation saying the “the name field […] cannot contain special characters and [this] step does not undergo variable substitution”. As several of the other container fields currently supports variables, I hope this is something that could be reconsidered.

Hey @Tosh,

You are correct in that the issue here is that at the moment we do not offer the ability to use a variable in the Container Name field.

This would be a feature request unfortunately and would need to be raised on our UserVoice pages so our engineers can look into what it would take to get this implemented.

I have gone ahead and posted this up in the conversation Adam was having with the engineers in the forum post you linked but we usually look in the feature request pages for things like this so in order for us to get this out to customers your best bet would be to post something up in there.

Kind Regards,

Clare

I understand. I added my vote to an existing UserVoice request, as well as some additional background information.

Thanks for your help

1 Like

Hey @Tosh,

Thank you for posting that up, I have sent that to the engineers too, if they have a response I will let you know.

Kind Regards,

Clare

Hey @Tosh,

Sorry it has taken so long to get back to you but i have some good news. Our engineers have reviewed this and said it is a legitimate case and they would look into ways to implement it!

They did say it will take them a while to do as they are pretty busy right now with some P1 issues but they have created a Public GitHub Issue for this (linked below) so please feel free to subscribe to it. You will then get updates as to the progress of it and when its implemented!

Add support for container name variables in “Deploy Kubernetes containers” step template

I hope that is some welcomed news, reach out if you need anything further,

Kind Regards,

Clare

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.