We have been using Octopus Deploy since the last 2 years for many of our clients. We have recently come across a situation where the client website has over 500 IIS bindings and will be having more as we progress on the project.
We had decided to offload the adding of bindings from OD and write a custom script which updates bindings based on a de-duped list which automatically gets passed per environment. However, because of accidental human intervention / faults in the actual de-duped list itself, there were times when a few of the websites would break / become wrongly configured (with wrong SSL sertificates, getting missed out, etc).
Is there a clean approach using native OD functionality which we can use to improve / avoid such issues happening in the future?
Thanks for getting in touch. Could we take a step back, and get some more details so we can have a better picture of your objective.
How exactly are you managing the bindings now? Are all 500 necessarily associated and need to operate together? Could some partitioning take place that may simplify things?
The script is not a problem at all, the answer I am looking for is around point 2.
Currently if we use the default update IIS / update website step on octopus deploy, for every new binding we require, we would have to create an HTTP and HTTPS entry on the configuration manually. This would make it impossible to maintain and manage 400 bindings from the update website step.
Leaving all the other factors aside, we would like to understand whether there is a graceful way built in OD / suggested by OD which we can use to handle a very high number of bindings?
e.g. if you were to handle an IIS website deployed using OD and has 500 bindings, how would you do it?
If this is about the binding user interface in Octopus, and how it handles a large set of data, there’s nothing better than the UI in the deployment process screen where it shows a long list of them. That UI and nothing else in Octopus is capable of making managing a very large number of bindings easily.
A completely different idea we had is to consider the use of a reverse proxy as another system to replace the need for configuring the bindings at deployment time, but with this you would be on your own to work out exactly what’s needed to achieve the same outcome.
I am still not very convinced and would give you a scenario based explanation using which I may be able to get the answer to my problem
Scenario: IIS .NET website hosted using IIS DNS Names: 600 DNS entries, all as IIS bindings on the website Problem : IIS taking 600 sites down for a small period when OD deploys application, client does not have the budget for HA / using 2 VMs
Consulting needed on the following question: If you were to design and implement this solution using OD, what approach would you use to minimise risk and downtime?
Thanks for more info, but without knowing exactly where your task is slow we’re just guessing. Could you send us an export of your deployment logs, so we can see where it’s going slow, which parts in particular? On a few different deployments where large amount of bindings are present.
Have a look at the timings in the log, to see where it spends the most time, is it really the bindings, is it copying files, is it something else, is it perceived time when you go to the sites again after the deployment?
As an example, I had a 1 step project, with 605 bindings, it took 17 seconds to complete on the first run. It took 12 seconds on a subsequent run. 10 seconds on a 3rd run. The 2 latter ones did not have to do anything with bindings as no changes were detected. On a 4th run with a new binding addition, it was only at 13 seconds but with all the bindings being recreated.
Use a code-diff tool to help you see the difference between 2 runs, and see where the times are varying in different cases and where most of the time is being spent. A key thing to work out is, are you sure enough of the time of concern is binding related.
Change of thinking, you’re trying solve this problem with Octopus exclusively, you may be tying your hands by only trying to use 1 tool. Our suggestion is to manage a large set of bindings using a reverse proxy, which would be the right tool for the job.
