When a tentacle is installed via DSC in Azure, when it added to an environment and role is it possible to auto install the octopus release that is installed on other tentacles with that role in the environment?
We would like to start using the ARM Virtual Machine Scale Sets to enable better auto scale. Whilst is seems pretty easy to get my base install auto installed via DSC, when a VM is auto provisioned I’m struggling to work out how to auto install the latest Octopus Release applied to that role and environment.
Thanks for getting in touch! Currently customers in this situation script projects to deploy when they add machines to their environment using the API.
We are right now working on an elastic environments feature that will, when a machine comes online, deploy any corresponding projects related to its roles.
Unfortunately it is due to be release in 3.4 which includes Multi-Tenancy which is a very large feature and is still a few months away.
Dalmiro (our PowerShell god) said he will provide you a modified script for a suggested way to automate this process in his morning (He is in Argentina)
The below script will help you deploying an existing/latest release to a specific machine. The values you’ll need to know are:
Project name.
Environmet Name.
Machine name.
The release version is optative. If you pass a value It’ll deploy that one, but if you just put “latest” It’ll look for the latest one.
All these values will be filled in the Config section of the script.
Now, this script does pretty much the same as Octo.exe deploy-release with the --specificmachines parameter. Is there a reason why you can’t use that approach? You could have a task in your DSC Pull server that calls Octo.exe and triggers deployments for all the new Tentacles. This way you’ll only need to have Octo.exe in 1 server.
We currently use Azure VMs to host our web applications and I also want to move to Virtual machine Scale sets (VMSS) in Azure.
In our VMSS environment we’re also going to have an Azure Automation DSC Pull Server which each VM is going to be assigned.
Could you please help me solve this problem: How do you prevent a VM in a Scale Set from sending a page from an out dated release. And I was wondering if anyone else has came across this problem before.
In our environment we have an IIS Web Application configured as a health probe so that the Azure Load Balancer can check to see if the VMSS web server is healthy or not.
I was thinking I can run a script to stop that web application until it has the latest release but what do other people do?
If you follow the approach of “Deploying the latest release to the new machine using Octo.exe” that I described in this thread or you wait for 3.4 until we release our Elastic Environment feature, in both cases Octopus will be deploying the latest release of the project. This means that only the latest version of the package will be deployed to the VM, and that the IIS site on them will be pointed to the folder where the latest content was deployed. So your VMs will always be publishing the latest version of your page.
The recommended practice in this case is to have a process similar to this in Octopus.
[On the Tentacle] Stop/make sure the IIS site is stopped on the scale VM. This way you make sure that the VM wont be publishing content while a new version is being deployed to it.
[On the Tentacle] Deploy the new site to the VM.
[On the Tentacle] Start the IIS site on the VM.
[On the Octopus Server or the Tentacle] Run a PS script to add/enable this machine in your load balancer.
that sounds pretty good but what about the few minutes where a VM just booted up and hasn’t received the latest release from Octopus Deploy? isn’t it possible that it could still be sending an older release?
I haven’t tried any of this in a lab yet so I don’t know how it will work in practice but it seems like there’s a chance an older release could accidentally be used for a minute or so just after a VM started
There’s plenty of ways to do this. Personally I would go this way:
If the machine was just provisioned and its booting up for the first time, it shouldn’t be added to the load balancer just yet. The machine should only be added right after the first deployment. Then during the 2nd deployment, It will be taken out of the LB during the first step, get the latest version of the app deployed, then re-added to the LB during the last step of the deployment. Repeat ad eternum.
So after much planning I’m now in the middle of enacting a strategy to get all of my VMSS members up to the latest web application version when they boot.
Also, I want there to be 0 chance that a VM can send a page from an out dated release.
all VMs are members of a scale set
All VMs are behind an Azure Load Balancer with a probe pointing to /checker.aspx (on a custom TCP port - 1113)
I have a separate application called ‘checker’ that gets deployed to the VM if that responds with a HTTP 200 OK to the azure load balancer probe, Azure assumes the VM is healthy and it participates in the load balancing set.
Here is the deployment procedure in action!
Step 1. I Tell Azure to provision a VMSS using ARM template which registers the VMs to azure automation dsc pull service
Step 2. a Pre compiled MOF file is loaded to each VM that does this:
installs IIS and ODS tentacle
copy The ‘DeployExistingReleaseToSpecificSingleMachine.ps1’ to the VM
create a scheduled task that stops the IIS website Checker on system shutdown (this makes azure think the VM is unhealthy and can’t deliver pages anymore)
create a scheduled task that starts the DeployExistingReleaseToSpecificSingleMachine.ps1 script every time the VM boots if that runs successfully start the checker application so azure now thinks the vm is healthy.
