We have two load balanced web servers in a farm (a “farm-ette” ). What support is there in Octopus for this scenario?
Depending on how you want to deploy, you can set up steps for your web site package like this:
1. Package A -> Machine 1, 2
Or like this:
1. Package A -> Machine 1
2. Package A -> Machine 2
The second approach will wait for the deployment to machine 1 to finish before deploying to machine two.
If your load balancer can be configured via an API, you could then use a PowerShell script inside the package that takes a machine out of the load balancer before continuing.
Those are two approaches I’ve seen used. How would you like your deployment to work?
Thanks for the response. To be honest, I’m not sure how to approach this.
I work for a large UK local government organisation (in the day!) and we
have some central middleware on a single server currently. We’re moving to
a dual server balanced scenario in the next 1-4 months. Ideally we want to
be able to retain service whilst deploying, so scenario 2 sounds better.
I’m tasked with finding an automated deployment solution and am comparing
Octopus with the MS Web Farm Framework. Any guidance here is appreciated!
Also, any indication as to when you may be releasing? That’s a factor for
I’ve got exactly the same kind of setup. Our load-balancer is configured by returning anything but HTTP 200 from an “lbcheck” page. I think the order for deployment would be something like:
Server1) Remove “lbcheck” (server1 offline)
Server1) Prime the file system with new content
Server1) switch to new app version
Server2) Prime the file system with new content
Server2) remove “lbcheck” (takes server 2 offline)
Server1) restore “lbcheck” (restore server1)
Server2) switch to new app version
Server2) restore “lbcheck”
With more servers, it gets complicated. But how could I do something like this, to minimize downtime when deploying to multiple servers but also synchronize deployments and version overlap which might have related DB schema changes?
I guess what I’m really looking for is an extra script so I can re-order multi-machine-environment deployments and execute custom actions at certain stages. It also turns out that I’ll be needing to disable a network interface/adapter and re-enable it to affect the loadbalancer removal correctly.
Is it possible for Octopus to install and aspnet_compile, and even load it internally, under a second IIS domain temporarily to say c:\inetpub\directory2?
When its ready to go, IIS can then be told to now use directory2 for serving requests instead of directory1.
In effect, you “hot swap” the application that IIS serves requests from in one hit, without a performance penalty to customers, because the site was already prime’d and ready to go.
Or, can I write a poweshell script to trigger octopus deployments interspersed with our other necessary server tasks instead of executing powershell scripts within the deployment task?
I have on the backlog a feature called “Ad-hoc PowerShell script” which will be a ‘step’ that gets executed without being in a NuGet package:
When that is ready it should solve the problem. For now the only way is to add it to a NuGet package (possibly a package that only includes the script)
Octopus already does part of this - when you install YourApp.1.0.2, Octopus will place it in its own folder (C:\Octopus\Applications\YourApp.1.0.2) and then update the Home Directory setting in IIS to point to that folder.
In your package, you could add a PreDeploy.ps1 file that calls aspnet_compile on the project to perform the compile before the Home Directory setting is changed.
Hope that helps,
Nice topic - also a hot one on our site - loadbalancers - watching closely how this develops further! But the scripting option allows for a lot of options. The out of package scriptings sounds like a nice way… Just Great stuff by the way.
I think I have to vote in some of the trello cards for v2! Yeah!
Paul, as you mention the relocation thing in the last reply - a question comes to my mind: so if we had a lot of virtual directories that point to the same base directory (for separated applications and internationalization for example) we need to script that as well - right? Maybe just have to try and see, what happens