We set up a new internal .net server where a binding IP address was specified for each site on the server. This binding Ip address keeps changing to a * each time we use the deploy nuget package step to a new site. Is there anything natively in Octopus that would force the binding IP to change and default to a * at deploy time?
Thanks for reaching out!
How are you passing the IP value on the step? Using a variable? a hardcoded value?
If you are using variables, could you send me a screenshot of Projects -> [Your project] -> Variables where I can see those variables, their values and scopes?
Finally please follow the bellow instructions to send a full deployment log please.
1) Add these 2 variables to your project http://docs.octopusdeploy.com/display/OD/Debug+problems+with+Octopus+variables 2) Create a new release (so the new variables take effect) and deploy it. If possible skip as many steps as you can and only leave step we are troubleshooting in order to avoid the noise in the log. 3) Send us the raw log of that deployment http://docs.octopusdeploy.com/display/OD/Get+the+raw+output+from+a+task
To my knowledge we aren’t passing any IP addresses in this step. We are copying the nugget package to the server and allowing octopus to do the replacement for the variables we do have. We also don’t have any IP addresses in the variables. That is why I was wondering if there is something interal to the step where this is happening? The sites are built outside of this deployment project and exist from a job that sets the binding IP at the time of creation. We are seeing though that when the code base is deployed, the binding IP is being updated. I don’t see anything in the code base that would direct me toward thinking it was a code issue. I’m not sure where the issue is or if octopus does something that I don’t know that it does.
I am attaching the requested variables and extra variable change.
Project_Variables.docx (1 MB)
ServerTasks-19134.log.txt (196 KB)
The way Octopus works with bindings for IIS sites is that it removes all existing bindings at the time of the deployment, and it sets up the ones you defined in the deployment process step. You cannot tell Octopus “Don’t do anything with my bindings, just respect the ones that are already there”. So Octopus is setting up the defail binding which points to "". For the time being () you’re gonna have to:
- setup the binding using a variable that holds the correct IP. You’re gonna have to create a variable for each machine and scope it to it.
- add a powershell script on that same package deploy step as a “Post deployment Script” that queries the current available IPs on that machine, picks the right one and updates the site to use it. I’d personally recommend this one as you won’t have to manage so many variables.
(*) There’s a uservoice suggestion to add a checkbox to make this work the way you expected it. If you can add votes to it, It’ll help us notice that the community wants support for this scenario.
Dalmiro is this part of the deploy nugget package step itself? I’m not using the binding ip step in my process for deploying applications.
I’m sorry, I should have picked that up from your log!
Can you send me the exported JSON of the step template you are using?
I can’t that I know of. I’m using the deploy nuget package step. I can’t seem to find the json to that. How can I obtain the json for it?
Any chance you can send me a set of screenshots showing me all the fields of the “Deploy package” step and their values? That should be able to finally help me understand this scenario.