Azure Pipelines architecture for IaaS
Important
CI/CD for IaaS applications is a variant of Design a CI/CD pipeline using Azure DevOps. This article focuses on the specifics of deploying web applications to Azure Virtual Machines.
Azure Virtual Machines is an option for hosting custom applications when you want flexible and granular management of your compute. Virtual machines (VMs) should be subject to the same level of engineering rigor as Platform-as-a-Service (PaaS) offerings throughout the development lifecycle. For example, implementing automated build and release pipelines to push changes to the VMs.
This article describes a high-level DevOps workflow for deploying application changes to VMs using continuous integration (CI) and continuous deployment (CD) practices using Azure Pipelines.
Architecture
Download a Visio file of this architecture.
Dataflow
This section assumes you have read Azure Pipelines baseline architecture and only focuses on the specifics of deploying a workload to Azure Virtual Machines.
PR pipeline - Same as the baseline
CI pipeline - Same as the baseline, except the build artifacts created for deploying a Web App to IaaS is a Web Deploy package
CD pipeline trigger - Same as the baseline
CD release to staging - Same as the baseline with 2 exceptions: 1) the build artifact that is downloaded is the Web Deploy Package and 2) the package is deployed to a staging Azure Virtual Machine.
CD release to production - Same as the baseline with 2 exceptions:
a. The release to production is done by updating Azure Traffic Manager to swap staging and production. This strategy can be accomplished by having a Traffic Manager profile with two endpoints, where production is enabled and staging is disabled. To swap staging and production, disable production and enable staging.
b. A rollback can be accomplished by updating Azure Traffic Manager to swap production and staging back.Monitoring - same as the baseline
Components
This section assumes you have read Azure Pipelines baseline architecture components section and only focuses on the specifics of deploying a workload to Azure Virtual Machines.
Azure Virtual Machines provide on-demand, high-scale, secure, virtualized infrastructure using Windows or Linux servers. Virtual Machines are used in this architecture to host workloads.
Virtual Machine Scale Sets let you create and manage a group of identical load-balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets can also be used to host workloads.
Azure Traffic Manager is a DNS-based traffic load balancer that you can use to distribute traffic to configured endpoints. In this architecture, Traffic Manager is the single entrypoint for clients and is configured with multiple endpoints, representing the production Virtual Machine and the staging Virtual Machine. The production Virtual Machine endpoint is enabled and staging is disabled.
Alternatives
This article focuses on the use of Azure Traffic Manager as the load balancer. Azure offers various Load balancing options that you could consider.
Considerations
This section assumes you have read the considerations section in Azure Pipelines baseline architecture and only focuses on the considerations specifics to deploying a workload to Azure Virtual Machines.
Operational Excellence
Because Traffic Manager is DNS-based, client caching of IP addresses introduces latency. Even though you might enable one endpoint and disable another in Traffic Manager, clients will continue to use their cached IP address until the DNS Time-to-live (TTL) expires. Consider load balancing options that act at layer 4 or layer 7.
Consider implementing environments beyond just staging and production to enable things like rollbacks, manual acceptance testing, and performance testing. The act of using staging as the rollback environment keeps you from being able to use that environment for other purposes.