Hi,
We’ve been using Octopus for a year now with great success and appreciation! We now run into a new use-case where we want to deploy a website to a web farm. The key thing in this scenario is that the files the website consists off are not stored on each web server in the farm, but on one centralized storage server.
Is there a best practice on how to do this, without deploying the actual files to each web server?
Best regards,
Raymond
Hi Raymond,
Thanks for getting in touch! That’s awesome to hear you’ve been successful with Octopus - we really like to hear that! 
In the case of having one centralized storage server in your web farm, you would only need to configure a Tentacle on the centralized server, as opposed to configuring a Tentacle on each server in the farm. This will ensure your website is deployed only to the required server. If you have a script to tell the other webservers that there’s another version available, you can then add that as a script step after the deployment step.
I hope this helps! Don’t hesitate to reach out if you have any further questions going forward.
Kind regards,
Kenny
Hi Kenny,
I’m somewhat confused on your proposal on how to solve this. To be more specific: We have a separate central storage server and multiple web servers. The storage server is not one of the web servers and the web servers don’t store any files. Instead the websites point to a share on the central storage server for their files. Also the web server’s configuration is stored centrally on a separate share on the same central storage server.
When deploying a website I’d like Octopus to publish the files to the central storage server and create a website on one of the web servers, pointing to the central storage server share for the files. Because the web servers share their configuration the website will also be configured for all other web servers in the farm automatically.
Can you maybe have another look at this and explain your approach?
Best regards,
Raymond
Hi Raymond,
Thanks for following up and expanding on your scenario. I apologize about the confusion I caused with my initial message!
The limitation here is that our IIS step is tied to the package deploy step, so an IIS site can’t be created without deploying a package. The workaround that I would suggest is to configure a second IIS step to deploy an empty dummy package (like emptyPackage.1.0.0.nupkg) to deploy to your secondary web server. You can then select the option Skip any package step that is already installed in your project’s advanced settings, as shown in my attached screenshot. Note that this package will need to be deployed to the server at least once.
This dummy package solution will work to create the IIS site, but the IIS site will point to the package on deployment by default. You can fix that by using the custom installation directory feature in this step and use your shared drive (ensuring the Purge option is unselected).
Another idea could be to use the IIS step templates in our community library, which wouldn’t require a package to be deployed. These steps aren’t as robust as our built-in IIS step, so I’d suggest the first option.
I hope this helps get you going! Let me know how you go and if you have any further questions.
Kind regards,
Kenny
Hi Kenny,
Because I don’t like to implement workarounds for standard problems, I chose to use the standaard “Deploy a package” step plus a couple of scripts from the community library (“IIS AppPool - Create” and “IIS Website - Create”).
I’d prefer to have a more robust solution based on the IIS step (but without it being tied to deploying a package, of course). Why don’t you create a separate step to just create an IIS site and add that to your standard steps? Or even better: Remove the requirement of deploying a package from the IIS step altogether? You already have a standard step to deploy a package, so why also tie that requirement it to the IIS step? That would make a lot of sense to me and make the whole process a lot more flexible and suitable for enterprise usage.
Best regards,
Raymond
Hi Raymond,
That sounds great! Let me know if you have any further questions going down this route.
As for the IIS step question - you make a good point, where a built-in IIS step that doesn’t require you to deploy a package, but still does all the setup and config would be a good addition. Using a dummy package is a workaround, so I see what you mean and it would be handy in your scenario. This isn’t currently on our radar, but there is a fairly popular UserVoice suggestion for just this. I’d really appreciate you giving it some votes and/or comments!
Kind regards,
Kenny
