Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spinnaker for Azure

1,951 views

Published on

This deck presents how Azure support has been built into the Netflix OSS Spinnaker project.

Published in: Internet

Spinnaker for Azure

  1. 1. Azure and Spinnaker Deep Dive
  2. 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. 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. 4. Principle - Conventions and Consistency • High level terms are maintained across cloud providers • Applications • Clusters • Server Groups • Load Balancers • Security Groups
  5. 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. 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. 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. 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. 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. 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. 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. 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. 13. Initial Deployment
  14. 14. Deploy V2
  15. 15. Enable V2
  16. 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
  17. 17. 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

×