Azure allows Virtual Machine extension objects to be attached to provisioned virtual machines. As they are objects, they may be declared directly with Resource Manager templates.
There are hundreds of custom VM Extension objects available although the two most common are script extensions and disk encryption extensions.
Extension objects declare the publisher, type and version as properties of the ARM object. When they are deployed, they are attached to the targeted VM resource (as seen with the New-AzureRmResource syntax below).
The example below shows the custom script extension for Linux
Any property values listed under “protectedsettings” will not be included in logs. Traditionally, "storageAccountName" and "storageAccountKey" are properties that are often included with the custom script extension. Doing so, allows the VM Extension to directly reference files hosted on a Storage Account. Using Storage Account keys however is a real security concern as they provide full rights to all contents of the storage volume. These properties do no accept Shared Access Signatures (which are restricted to perhaps provide read-only access).
To satisfy security, its better not to use this feature at all – instead falling back on Shared Access Signature references for files.
Shared Access Signatures can be configured to provide least privilege access to the Storage Account. Because the Script extension is being run locally from the target system with root access – there is no strict requirement to use Storage Accounts at all. There is a real advantage if we have a business requirement to be able to install software on all tenancy Virtual Machines as, in most cases, we can rely on these machines being able to access the internet.
Either through templates, or through creating an Azure RM object resource directly (either PowerShell or Bash etc as shown above), we can simply supply a command to execute on the provisioned virtual machine that retrieves a package and runs the install.
There is a trick that doesn’t appear to be documented with using Custom Script Extensions. In theory, ARM templates do not allow multiple extensions (of the same type) to be applied to a machine within a single template deployment.
The caveat – is that you can’t change the name given to the extension. You can force multiple packages / script extension objects to be deployed against a machine if you retain the same name AND you alter the “forceupdatetag” property – which forces a new download and install. An ARM template can contain multiple deployments (which are themselves an object). This allows multiple extensions to be deployed.
The use of VM Script Extensions meets business requirements in a way that no other solution I’ve seen does. It allows for:
- The entire configuration management / software deployment of a machine to occur purely through the invocation of a template.
- In conjunction with Storage Accounts, standard software deployment and configuration management of machines can target all machines on all subscriptions in the Tenancy without the need of a traditional monolithic network. As we are seeing huge numbers of development machines not being provisioned to a central corporate network, this is a major point.
Package Management History
A lot of what we are seeing in Cloud / DevOps today is a rerun of the technology arguments from the Windows world in the early 2000’s. There used to be arguments over which system would be best for managing the configuration of the entire environment – Unicentre TNG, Tivoli, Zenworks or Microsoft’s SMS. It’s a similar argument to Chef, Puppet, Ansible today. The big problem with that argument is that central configuration management systems could not target (at the time) systems not attached to a network. It also encouraged lock-in to a particular vendor technology. By about 2005, technology wisdom had swung away from arguments over management products and focused on the idea of defining what software packages should look like. There was general industry acceptance packages should be self-contained, auditable, strongly versioned, portable, removable, peer reviewed.
By simply creating folders for packages with a standardised bootstrap (install.sh with linux and install.ps1 etc for Windows), Virtual Machine Script Extensions can aid in providing package management maturity to a somewhat imature technology direction.
Using bootstrapped packages with script extensions still allows the benefits of formal package management while supporting a variety of installers.
- Log in to post comments