Применение нескольких DSC с помощью диспетчера ресурсов Azure

Можно ли применить несколько конфигураций DSC к одному виртуальному серверу через Azure Resource Manager?

В настоящее время я использую что-то вроде этого:

    {
      "apiVersion": "2015-06-15",
      "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/', variables('vm_name'))]"
      ],
      "location": "[resourceGroup().location]",
      "name": "DSCSetup",
      "properties": {
        "publisher": "Microsoft.Powershell",
        "type": "DSC",
        "typeHandlerVersion": "2.20",
        "autoUpgradeMinorVersion": true,
        "settings": {
          "modulesUrl": "[concat('https://', variables('sa_name'), '.blob.core.windows.net/.../dsc.ps1.zip')]",
          "configurationFunction": "dsc.ps1\\Main",
          "properties": {
            "MachineName": "[variables('vm_name')]",
            "UserName": "[parameters('vm_user')]"
          }
        },
        "protectedSettings": {}
      },
      "type": "extensions"
    }

Если нет, можете ли вы объединить несколько DSC автоматически?

Сценарий это:

  • Иметь несколько DSC
  • Один DSC для IIS + ASP.Net
  • Один DSC для создания Site1
  • Еще один DSC для создания Site2
  • В Dev разверните Site1 и Site2 на одной машине
  • В производственном развертывании на отдельных машинах, возможно, даже в наборах доступности...
  • (Будьте готовы использовать отдельные контейнеры в будущем)
Источник

2 ответа

Решение

В настоящее время DSC допускает только одну конфигурацию, поэтому, если вы развернули 2 расширения DSC на одной и той же виртуальной машине (я не уверен, что она действительно будет работать), вторая конфигурация перезапишет первую.

Вы могли бы, вероятно, сложить DSC и CustomScript, но, поскольку DSC может запускать сценарии, я не уверен, зачем вам это нужно...

Какой у тебя сценарий?

Источник

Есть несколько подходов к этому, один простой и полезный, который я использую, это Nested Configurations, чтобы смешать все конфигурации DSC в одну.

Вы создаете конфигурации без какого-либо конкретного узла. Затем создайте конфигурации с узлами, которые группируют необходимые конфигурации.

Этот простой пример может служить руководством для того, о чем я говорю. См. [MS doc]] 1 для более подробной информации.

Configuration WindowsUpdate
{
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Service ModulesInstaller {
        Name = "TrustedInstaller"
        DisplayName = "Windows Modules Installer"
        StartupType = "Disabled"
        State = "Stopped"
    }

}

Configuration ServerManager
{
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Registry DoNotOpenServerManagerAtLogon {
        Ensure = "Present"
        Key = "HKLM:\SOFTWARE\Microsoft\ServerManager"
        ValueName = "DoNotOpenServerManagerAtLogon"
        ValueData = 1
        DependsOn = "[Registry]NoAutoUpdate"
    }       
}


Configuration VMConfig
{
    Node localhost
    {
        WindowsUpdate NestedConfig1 {}

        ServerManager NestedConfig2 {}
    }
}

При таком подходе мне легко на каждом добавочном номере DSC вызывать конфигурацию входа машины, которая является просто составом конфигурации, которую я хочу применить.

"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.20",
"configuration": {
    "url": "[concat(parameters('_artifactsLocation'), '/Configuration.zip')]",
    "script": "Configuration.ps1",
    "function": "FrontEndVM"
}

Другим подходом будет выполнение нескольких расширений ARM DSC на одном компьютере. Хитрость заключается в том, чтобы всегда использовать одно и то же имя, поскольку может быть выполнено только одно расширение DSC.

Предостережение при таком подходе заключается в том, что предыдущая конфигурация на машине перезаписывается. С функциональной точки зрения результат может быть таким же, но если вы хотите, чтобы локальный менеджер DSC исправил неправильную конфигурацию, это будет возможно только для самой последней.

Источник
Другие вопросы по тегам