Whilst working on a project that required an event driven platform, we decided to create an Azure Function that would handle Event Grid Events, and be deployed using Octopus Deploy.
The function deployed to a staging deployment slot fine with no issues but when switching the slot back it would always fail on this step. Looking into the logs, we could see a smoke test is performed to ensure the slot is responding with a 200 status code, and is ready to take traffic, however for some reason it would never respond and as a result the status code passed back was always empty. The strange thing here was we could actually see the function was responding on this slot by navigating to the url in the browser.
My colleague and I then decided to look into the step template powershell code and pin point what was happening behind the scenes. We found the code that was failing.
try
{
$response = (Invoke-WebRequest -UseBasicParsing -Uri $httpEndpoint -TimeoutSec $timeout).statusCode
}
catch
{
$response = $_.Exception.Response.StatusCode.Value__
}
The $response here was empty so we added additional logging inside the catch block to get the full exception details so we had something to work with. (We could do this because we had a slightly customized version of the original step template)
Write-Output $_.Exception
We could then see our error:
NotSpecified: Error in Switch Azure RM Staging Deployment Slot Script. Response code to https://weu-azure-functionname-dev-staging.azurewebsites.net/ was System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
After some investigation we could see the Azure Function had defaulted to a minimum TLS Version of 1.2 in the SSL Protocol Settings, powershell defaults to TLS 1.0 so we forced powershell to use TLS 1.2 by adding this code to the top of our powershell script. Alternatively you can also lower the TLS version in the SSL Protocol settings in Azure to 1.0 but this is not recommended and is less secure.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
This change allowed a 200 status code response from the smoke test, the slot then switched successfully completing the deployment.
Credit to Dan Horrocks-Burgess for looking into this with me.