Поделиться через


Infrastructure as Code-Azure Environment Deployment using ARM templates, DSC, PowerShell and VSTS

I had an amazing opportunity to automate the Azure Infrastructure creation using ARM templates, DSC(Desired State Configuration), PowerShell. The deployment of the artifacts was done using VSTS(Visual Studio Online). The templates are highly parameterized so that it can be leveraged for other environments needing similar setup. VSTS is used to deploy these environments to Azure so that changes can be tracked.

The following core fundamentals have been the guiding principles for this project:
a. Tracking any environmental changes that gets deployed to Azure.
b. Infrastructure as Code.
c. One Click Deployment.
d. Reusable Code.

As part of this project, the artifacts have been created and used to create the environment in Azure

SQL Server Environment
The SQL environments created has the following artifacts. Most of the artifact values (like VM names, locations image used…) are specified in parameters input file
- VMs with SQL on IaaS
- VMs are configured in a two-node cluster
- VM names are created based on the parameters
- TAGs added to the VMs as per requirements
- SQL Listeners and Availability Groups Added
- SQL Always On
- SQL Witness VM
- VMs use Availability Zones for Higher resiliency
- VMs joined to the domain specified in the parameters
- VMs deployed to the Network and Subnet specified
- Managed Disk attached to the VM as per the specifications
- NICs with Accelerated Networking Enabled
- VMs have software like antivirus and monitoring Agents installed

Application Servers
The Application environments created has the following artifacts. All of the artifact values (like VM names, location, image, TAG values, #of VMs…) are specified in parameters input file
- ‘X’ number of VMs
- TAGs added to the VMs as per requirements
- VM names are created based on the parameters
- VMs use Availability Zones for Higher resiliency
- VMs joined to the domain
- VMs deployed to the Network and Subnet specified
- Managed Disk attached to the VM
- NICs with Accelerated Networking Enabled
- VMs behind a n nternal Load Balancer(ILB)
- ILB rules and Probes
- VMs added to the ILB
- Storage account for diagnostics logs
- VMs have software like antivirus and monitoring Agents installed

Domain Controllers
The Domain Controller environment created has the following artifacts. All of the artifact values (like VM names, location, image, TAG values, #of VMs…) are specified in parameters input file
- Primary Domain Controller
- Backup Domain Controller
- Active Directory
- Create ADForest
- TAGs added to the VMs as per requirements
- VMs are named as per customer standards
- VMs use Availability Zones for Higher resiliency
- VMs joined to the domain
- VMs deployed to the Network and Subnet specified
- Managed Disk attached to the VM
- NICs with Accelerated Networking Enabled
- Storage account for diagnostics logs
- VMs have software like antivirus and monitoring Agents installed

Application Gateway and Traffic Manager
Separate templates for Application Gateway and another template for Traffic Manager. So that each one can be independently deployed.
The Application Gateways and Traffic Manager created has the following artifacts. All the artifact values (like AppG name, location, size …) are specified in parameters input file
- Application Gateway(AppG) Instances created
- AppG deployed to the Network and Subnet specified
- Backend Pool configuration-ILBs added to the AppG backend pool
- FrontEnd IP configurations
- Listeners added to AppG
- Protocols Specified
- Health Probes
- AppG Rules
- WAF settings
- Traffic Manager Profile Created
- AppG added to Traffic Manager Endpoints

VSTS for Deployments
VSTS helps to fulfill the requirement of tracking changes and one click deployment. We setup the VSTS Build Definitions for deployment to Azure
-ARM templates are checked in VSTS
-DSC scripts are checked in VSTS
-Build Definitions for each unit of deployment that are currently setup to deploy these ARM templates to Azure
-Going forward there can be release definitions so that there can be:
o Approval processes
o Deployment to different environments
o Build definitions can combine units of work as one deployment for a new environment
o Scheduled Deployments
- Deliver training to the required teams to educate them about this setup and how to use it