How to define IIS bindings in Json file

Hi there,

here is the json file I created for a step, everything gets created perfectly but the IIS bindings, could you help me out here what was wrong with the bindings? here is the json file content:

{
“Name”: “Deploy my Portal”,
“RequiresPackagesToBeAcquired”: false,
“Properties”: {
“Octopus.Action.TargetRoles”: “PlatformWeb”
},
“Condition”: “Success”,
“StartTrigger”: “StartAfterPrevious”,
“Actions”: [
{
“Name”: “Deploy my Portal”,
“ActionType”: “Octopus.TentaclePackage”,
“Environments”: [],
“Channels”: [],
“Properties”: {
“Octopus.Action.EnabledFeatures”: “Octopus.Features.CustomDirectory,Octopus.Features.ConfigurationVariables,Octopus.Features.ConfigurationTransforms,Octopus.Features.IISWebSite”,
“Octopus.Action.Package.AutomaticallyRunConfigurationTransformationFiles”: “True”,
“Octopus.Action.Package.AutomaticallyUpdateAppSettingsAndConnectionStrings”: “True”,
“Octopus.Action.Package.DownloadOnTentacle”: “False”,
“Octopus.Action.Package.NuGetFeedId”: “feeds-builtin”,
“Octopus.Action.Package.NuGetPackageId”: “Elastic.Portal”,
“Octopus.Action.IISWebSite.CreateOrUpdateWebSite”: “True”,
“Octopus.Action.IISWebSite.Bindings”: “[{“protocol”:“https”,“ipAddress”:”",“port”:“443”,“host”:“myportal.#{TargetEnvironment}.elasticgrid.com”,“thumbprint”:"#{CertificateProvider.ThumbPrint}",“requireSni”:false,“enabled”:true},{“protocol”:“http”,“ipAddress”:"",“port”:“80”,“host”:“myportal.#{TargetEnvironment}.elasticgrid.com”,“thumbprint”:"",“requireSni”:false,“enabled”:true}]",
“Octopus.Action.IISWebSite.ApplicationPoolFrameworkVersion”: “v4.0”,
“Octopus.Action.IISWebSite.ApplicationPoolIdentityType”: “SpecificUser”,
“Octopus.Action.IISWebSite.EnableAnonymousAuthentication”: “True”,
“Octopus.Action.IISWebSite.EnableBasicAuthentication”: “False”,
“Octopus.Action.IISWebSite.EnableWindowsAuthentication”: “False”,
“Octopus.Action.IISWebSite.WebSiteName”: “#{TargetEnvironment} my Portal”,
“Octopus.Action.IISWebSite.ApplicationPoolName”: “Platform App Pool”,
“Octopus.Action.IISWebSite.ApplicationPoolUsername”: “#{AppPoolUserId}”,
“Octopus.Action.Package.AdditionalXmlConfigurationTransforms”: “#{web.env.config} => web.config”
},
“SensitiveProperties”: {}
}
],
“SensitiveProperties”: {}
}

and this is the api I used to send the request of adding a step:
Invoke-RestMethod -Method Put -Uri “$OctopusURL/$uri” -Body $($resource | ConvertTo-Json -Depth 10) -Headers $header

Hi,

Thanks for getting in touch!

Before we jump to investigate the raw JSON, may I ask why are you taking this approach of programatically adding/modifying a step of your deployment process? As you probably figured out already, manipulating the deployment process from code blindly (without contextual help of the UI like dropdown lists, pre-loaded values, etc) is not an easy task at all, and sometimes can lead to really bad results like corrupted deployment processes that cripple your project.

I’m interested in knowing why did you take this approach, mostly to see if there’s another more safer way to do what you need.

Best regards,
Dalmiro

Hi Dalmiro,

Thanks for asking for the context, appreciated if you can suggest the best practice to do it.

Actually I been using the web interface to create the project, variables, process and steps, and then I’ve got 22 sites to deploy which use the same Nuget package but slight different web config, it means I need to create 22 steps in the process with almost same step config but different site name and bindings. It is a bit boring to repeat clicking buttons and filling in editors to create 22 steps.

On the other hand, I thought to keep the process and step settings in source control would be easier for tracking. Using Json files and checking it in source control can easily retain the history of setting changes.

Please correct me if I’m wrong. Thanks:)

Regards
Bella

Hi Bella,

You could use variables to define the values of those fields in only 1 deploy step, and then scope those variables depending on the step/environment/project you are deploying to.

Are those 22 sites in 1 same project, or spread across 22 projects?

Regards,
Dalmiro

Hi Dalmiro,

these 22 sites are in 1 same project, but they vary in IIS site name, IIS binding and web.config, they are deployed to same target server from same nuget package.

For example, the nuget package is Portal.nupkg, I need to deploy Portal 1 and Portal 2.
I created 2 steps of “Deploy a Nuget package” to deploy the same package Portal.nupkg with different site name, binding and web.config. For these 3 settings, I can define 3 variables, for site name it can be #{portal name} Portal, for bindings it can be #{portal name}.mydomain.com, for web.config it can be web.#{portal name}.config. By using variables, these 2 steps can be identical, but no way to differentiate them because they are deployed to the same target role and target machine. That’s why the {portal name} has to to presented in steps rather than variables. Any advice?

Regards
Bella

Hi Dalmiro,

I just noticed variables can be applied on particular step, then the question comes, does it mean I need to repeat the same step 22 times (as they are 22 independent sites) then apply #{portal name} which stands for different portal on each step?

another finding is “Add binding” manually after the step gets created from Json thru restAPI doesn’t work. when I click “Add binding” button and filled in everything then click OK, nothing showed in the “IIS bindings” section

Hi Bella,

I’d recommend you to keep the name of the variables more generic like “SiteName”. Then on your variables screen, create multiple copies of the same variable, but scope each to a different step using the right value as shown on the attached screenshot. Apply same logic for all the other fields.

when I click “Add binding” button and filled in everything then click OK, nothing showed in the “IIS bindings” section

Which version of Octopus are you using? Could you provide steps with screenshots to reproduce this?

Thanks,
Dalmiro

Forgot to attach the screenshot.

Hi Dalmiro,

I did what you recommend, I’ve created variable “PortalName” and gave it different values then assign this variable to different steps. E.g:
PortalName Portal1 Step1
PortalNmae Portal2 Step2
By doing this, I no need to change the settings in each step, I created completely identical 22 steps for 22 portals. But then the problem is, seems copying step is not supported, I had to create the same step 22 times. Is there a way to copy step on the web interface? if not, is it good practice to use restAPI and Json to copy step?

Regarding this issue:
when I click “Add binding” button and filled in everything then click OK, nothing showed in the “IIS bindings” section
Octopus version I’m using is 3.2.14.
The reproduce the issue, here are the steps:

  1. download the Json file from http://octopusURL/api/deploymentprocesses/deploymentprocess-Projects-22
  2. delete the existing steps from the json file
  3. add new step in “Steps” section
  4. run this in powershell:
    function Get-StepsToCopy () {
    param(
    [parameter(Mandatory=$true)] [string]$stepJasonFile = “”,
    [parameter(Mandatory=$true)] [string]$projectId = “”
    )

$OriginalProcess = Get-Content $stepJasonFile -Raw | ConvertFrom-Json

#Changing colletion to ArrayList to be able to add steps
[System.Collections.ArrayList]$Steps = $DeploymentProcess.Steps

#Deep copy
$ms = New-Object System.IO.MemoryStream
$bf = New-Object System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
$bf.Serialize($ms, $OriginalProcess)
$ms.Position = 0
$OriginalStepDC = $bf.Deserialize($ms)
$ms.Close()

foreach ($step in $OriginalProcess.Steps) {
Write-Host Step name: $Step.Name
#Adding step to ArrayList collection. The step will be added to the bottom.
$Steps.Add($Step)
}

#Adding new steps array to Deployment process
$DeploymentProcess.Steps = $Steps

#Saving Deployment process to database
Invoke-RestMethod -Method Put -Uri “$OctopusURL/$DeploymentProcess.Links.Self” -Body $($DeploymentProcess | ConvertTo-Json -Depth 10) -Headers $header
}

Hi Bella,

Instead of re-creating the step 22 times filling the same info on each, create a step template with those values already pre-filled and add it 22 times. You can’t avoid the addingx22 and using the API for that is NOT recommended.

The script you provided is wrong in a few places, and as I recommended already, try not to use the API to add/remove steps from the build process.

Thanks,
Dalmiro

Hi Dalmiro,

Thanks for your advice. I created a template and a bunch of parameters, it is now more flexible to change the common settings by modifying the template. However, it still requires “add step” multiple times and specify parameters multiple times as you mentioned.

I’d really like to make it a bit easier by programming it, what approach would you recommend? When you say “not to use API to add/remove steps”, did you mean monitoring steps programatically is not recommended? well…monitoring steps is the essential part of Octopus deploy, it would be frustrating if programming it is not supported…

Regards
Bella

Hi Bella,

Dalmiro is on leave, and I just found this ticket sorry you haven’t had a response in so long, it looks like it accidentally got moved from our pending queue.
Are you still having issues with this?

Thanks!
Vanessa