Provisioners

• Overview
• PowerShell DSC
• Custom Scripts
  • Parameters
• Chocolatey
• Inbuilt Scripts
  • DSC
  • Custom

Overview

Fogg has inbuilt support for a number of provisioners, which it can use to provision your virtual machines once they have been deployed. Fogg currently has support for the following:

• PowerShell Desired State Configuration (DSC)
• Custom scripts; like PowerShell, Batch or Bash (if deploying Linux VMs)
• Chocolatey to automate installation of software and tools

It is possible to have python, ruby, perl and other custom scripts if you install the language using Chocolatey first

To use provisioners within a Fogg template, you first need to define the provisioners by giving them a key, stating the type, and declaring the path. The declaration of new provisioners is done in the main "provisioners" object of the template file, just after the "template" object, ie:

{
    "template": [ ],
    "provisioners": {
        "key": "type: path"
    }
}

Paths to provisioning scripts must be relative to the template file - unless you specify an absolute path

PowerShell DSC

Let's say you have the DSC script .\scripts\web-server.ps1, which will install IIS on the VM. To declare this as a provisioner with key web you could use the following:

{
    "provisioners": {
        "web": "dsc: .\\scripts\\web-server.ps1"
    }
}

When the DSC script is called, the Configuration name of the script must match the name of the file (without dashes). So for above, you would have: Configuration webserver { ... }

This will load the script into Fogg, ready for referencing on a VM template. In order to reference a defined provisioner in a VM template, you specify the key of the provisioner within the "provisioners" array of a template object:

{
    "template": [
        {
            "tag": "example",
            "type": "vm",
            "provisioners": [
                "web"
            ]
        }
    ]
}

Once Fogg has deployed a VM, the provisioners are run in the order you give them

Custom Scripts

Custom scripts don't vary too much to using DSC scripts; they are defined and called in the same way:

{
    "template": [
        {
            "tag": "example",
            "type": "vm",
            "provisioners": [
                "directories"
            ]
        }
    ],
    "provisioners": {
        "directories": "custom: .\\scripts\\create-directories.ps1"
    }
}

This will just run the create-directories.ps1 script on a newly deployed VM to create some initial directories.

Parameters

You can also have a custom script that accepts parameters, and pass those in through the template as well.

Let's say the above create-directories.ps1 script accepted a single argument which was an array of directory names. To pass in this array of names, you define them on the call to the provisioner in the VM template:

{
    "template": [
        {
            "tag": "example",
            "type": "vm",
            "provisioners": [
                "directories: logs,websites,test,output"
            ]
        }
    ]
}

But, what if you had a script that accepted more than one argument? Well, you do the same as above, except you separate each argument value with a pipe "|":

{
    "template": [
        {
            "tag": "example",
            "type": "vm",
            "provisioners": [
                "multiple: some,array,values|1|true|more,values"
            ]
        }
    ]
}

Chocolatey

Chocolatey is effectivly an inbuilt custom script, to use this provisioner you define it with a list of softwares to install - rather than a path:

{
    "provisioners": {
        "software": "choco: googlechrome, notepadplusplus.install, 7zip.install"
    }
}

To specify specific versions of a software:

{
    "provisioners": {
        "software": "choco: notepadplusplus.install(7.4.1)"
    }
}

After that, you just call the provisioner the same way you did for the DSC and Custom Scripts:

{
    "template": [
        {
            "tag": "example",
            "type": "vm",
            "provisioners": [
                "software"
            ]
        }
    ]
}

Inbuilt Scripts

In order to help out, we've added in some inbuilt provisioning scripts for Fogg to use. These scripts only exist for DSC and Custom provisioners, and you define then within the main provisioner object:

{
    "provisioners": {
        "web": "dsc: @{web-server}"
    }
}

You'll notice that the path to a script has been replaced with @{web-server}. the @{...} informs Fogg that is needs to use one of the inbuilt DSC/Custom scripts.

The following are a list of inbuilt scripts:

DSC

Name	Description
file-server	Installs File Server, DFS Namespace/replication and Resource Manager roles
remoting	Enables RDP remoting onto the provisioned VM
web-server	Installs the IIS role and all Management sub-features, as well a .NET Framework

Custom

Name	Description
enable-winrm	Enabled PSRemoting, sets-up the WinRM port on the Windows Firewall, and configures WinRM with a self-signed certificate
file-access	Altering permissions on files/folders. Parameters: Path, User, Access Level, Allow/Deny Example: "file-access: c:\inetpub | IIS_IUSRS | FullControl | Allow"
sql-firewall-ports	Configures the Windows Firewall with inbound SQL ports 1433-1434
sql-mixed-auth	Enables mixed SQL Authentication on a SQL Server (most times requries a restart)