This document provides an overview of how Spinnaker integrates with Azure. It discusses the core principles of following an immutable infrastructure model and consistency across cloud providers. It also maps common Spinnaker concepts like accounts, server groups, and load balancers to their Azure equivalents. Additionally, it covers how Azure resource groups and networking are handled, and how Spinnaker uses pipelines to deploy server groups and enable traffic to new versions on Azure.

1. Azure and Spinnaker
Deep Dive

2. Our Core Principles
• Follow the Netflix immutable VM philosophy
• Conform to Spinnaker conventions
• Consistency across cloud providers
• Commit directly to the Netflix repositories on Github

3. Principle - Immutable VMs
• Once a VM is deployed it is never altered*
• Applications are “baked” onto an image
• The baked image is used as-is for deployments
• Rollback to previous images or roll forward for updates
* Configuration (e.g. connection strings) is altered per environment (e.g. test, stage, prod)

4. Principle - Conventions and Consistency
• High level terms are maintained across cloud providers
• Applications
• Clusters
• Server Groups
• Load Balancers
• Security Groups

5. Principle - Working in the Open
• All Azure support is submitted directly to the Netflix managed Github
repositories
• We do not provide a Microsoft specific implementation of Spinnaker
• The recommended version for Azure support is taken from the master
branches in the Github.com/Spinnaker hierarchy

6. Azure Mappings
Spinnaker Azure
Account Subscription
Server Group Virtual Machine Scale Set
Load Balancer Application Gateway (L7 Load Balancer)
Security Group Network Security Group

7. Azure Resource Groups
An Azure Resource Group is created when the first resource in a region
is created for an application
1. Create a new Spinnaker Application – entry is created in Spinnaker
local storage (Cassandra/S3) no Azure resource is created
2. Create a Security Group in West US – A new resource group is
provisioned in West US (<appname>-westus) and an NSG is created
in that resource group
3. Create a Spinnaker Load Balancer in West US – An Azure Application
Gateway is created in the same resource group (<appname>-
westus)

8. Load Balancers
• A Spinnaker Load Balancer creates an Azure Application Gateway
which is an L7 load balancer
• Application Gateways support:
• http/https
• SSL termination
• Multiple attached, one active, virtual machine scale sets*
• Zero downtime scale set transitions*
• Each scale set when provisioned gets a dedicated Azure Load Balancer
(L4) for TCP/UDP (SSH/RDP) access to individual machine instances
*discussed in further detail later

9. Azure Networking
Currently (August 2016) a new virtual network (VNet) and subnet are
provisioned along with a new resource group
This is being changed so that you will be able to select from pre-
created VNets and Subnets. Leaving control of network address space
up to you.

10. Clusters, Server Groups, and Scale Sets
• A Spinnaker Server Group maps 1:1 to an Azure Scale Set
• A Server Group represents a single version of a single service
• An application may contain multiple services
• All versions of a service deployed in all regions defines a cluster
E.g. The Spinnaker application itself is made up of many services (one user interface and multiple
backend micro-services). When one of the services is deployed to both West US and East US they are
both grouped as a cluster. When a new version is deployed it is added to the same cluster. Clusters
are defined using service naming conventions.

11. Image Selection
• Default configuration includes top 6 marketplace images
• Completely customizable
• Can be extended to custom images
• Configure target Azure storage to scan for vhd files
• Discovered vhd files are presented for selection

12. Pipelines
• Pipelines are at the core value proposition of Spinnaker
• Arbitrarily complex using multiple provided stages
• Typically start with some external trigger (e.g. completion of a Jenkins
job) but they can be executed manually
• Typically includes a bake stage to generate a new machine image with
the latest version of your service
• Deploy, validate, enable

13. Initial Deployment

14. Deploy V2

15. Enable V2

16. Deployments
• Application Gateways can support up to 20 attached scale sets (20
versions of the same service)
• Only one scale set can be receiving traffic at any given time
• Deploying a new version does not route traffic to it unless it is the very
first version deployed
• Enabling a server group configures the application gateway to send
traffic to that scale set
• You are responsible for removing old versions, typically with a stage in
the pipeline

18. User Security
• Authentication is available using OAuth and Azure Active Directory
• Authorization (RBAC) is a work in progress
• Triggered pipelines are executed as anonymous adding a manual step
should inject user identity