akuryan / vsts.extensions Goto Github PK

ARM templates added feature to allow limiting access to KUDU site via IP address (it is also possible via GUI and Powershell as well).
I shall add this feature to extension as well

This will allow to ease deployment pipeline configuration, as variables will be there

This will allow to remove requirement for hack:
In Sitecore Deploy task in field Additional ARM parameters define following string templateLinkBase=$(storageUri)/$(blobPrefix)/ \n templateLinkAccessToken=$(storageSas)
This allows to inject URL for storage account and it's SAS, so, template starts deploying from local disk, but will get nested templates from Azure Storage account (actually, this is ARM limitation: you could not use nested templates from local disk - they shall be always located on URI, accessible to host, which is executing script, hence, this upload to Azure Storage task addition)

Shall be done like this:
Add a dropdown "Template location" with values filePath and URI
If filePath is selected - leave command as is
If URI is selected - all commands New-AzureRmResourceGroupDeployment must have parameter -TemplateUri instead of -TemplateFile

Hi Anton,

Good idea to make an extension for deploying Sitecore.
I am trying to use this extension for deploying the infrastructure.
I am using the ARM Templates for Sitecore 9.0.2
https://github.com/Sitecore/Sitecore-Azure-Quickstart-Templates/tree/master/Sitecore%209.0.2/XPSingle

In my build definition I filled in all the parameters in the azuredeploy.parameters.json but I get the following errors.
##[error]Cannot process command because of one or more missing mandatory parameters: sitecoreAdminPassword licenseXml sqlServerLogin sqlServerPassword singleMsDeployPackageUrl xcSingleMsDeployPackageUrl.

Do you have any idea why I get this error?

Kind regards,
Martijn

As advised at https://msdn.microsoft.com/en-us/magazine/mt767695.aspx - it is better to implement extension publish pipeline, to be able to test extensions internally, before rolling them out in the wild

If default parameters file is used, then Powershell receives just one object "parameters", instead of collection.

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": { }
}

This means, that I need to perform additional changes in my params files :( currently to remove schema and contenVersion

If SCWDP package is overridden in Additional ARM parameters field - SAS for it will not be generated

If https://github.com/akuryan/vsts.extensions/blob/master/SitecoreDeployer/tests/SplitUpOverrides.Tests.ps1#L15 replace by $testString = '-test 123 -test2 1234 -test3 "123" -test4 "1234"'; - test will fail, as $testHashTable3 will contain not contain key test4. Instead, key will be added to test3 key value as 123 -test4

Need to find a fix for this

https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/AzurePowerShellV3/make.json
As far as I can understand - this will allow me to minimize noise of stored data in repositry (like moving AzureHelpers to common folder, adding common Tls12 helpers, retrieving SDK from Nuget)

Seems to be connected with make.js and make-util.js (which will do everything).
Need to work it out further
At this time, we are using TlsHelper_, VstsAzureHelpers_ and VstsTaskSdk - this shall be moved to Common folder

https://github.com/Microsoft/azure-pipelines-tasks/blob/1d75fa8f66aa1cf7a9cb62946939f30f087b2969/Tasks/ServiceFabricUpdateManifestsV2/make.json

Currently, to set IP restrictions on web app, powershell is using API 2016-08-01, which consumes following object:

$webIP = [PSCustomObject]@{ipAddress = ''; subnetMask = ''}

However, newer API version 2018-02-01 consumes other object:

$rule = [PSCustomObject]@{
    ipAddress = "$($clientIp)/32"
    action = "Allow"  
    priority = 123 
    name = '{0}_{1}' -f $env:computername, $env:USERNAME 
    description = "Automatically added ip restriction"
}

I need to test, if it will work with current implementation of mask recommended (255.255.255.255). If it works - then it is easy to update basing on this example: https://github.com/mjisaak/azure/blob/master/Add-AzureIpRestrictionRule.ps1

Replace current checkboxes with just one checkbox and additional line input to control, which web apps shall be limited by IP access, in case they are using non-standard naming

Proceed when akuryan/Powershell.Modules/issues/14 finished