Automating AWS - Speaker Deck

Slide 1

Slide 1 text

Automating AWS

Slide 2

Slide 2 text

Part 1 Automating Infrastructure

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Page Step 1: Deploy infrastructure › Deploy.ps1 › Package and upload bootstrapping resources to S3 › Package and upload configuration variables to S3 › Do we need to deploy a new stack? › Yes - New-CFNStack › No - New-CFNChangeSet › CloudFormation resource creation based on template / Copyright ©2014 by Readify Pty Ltd 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Page Step 3: Deploy software › Prior to Octopus 3.4 => DSC › Octopus 3.4 => Project Triggers › Software is deployed by Octopus via the Project Trigger › DSC polls a local health check endpoint › ASG waits to be signalled before completion › DSC => cfn-signal.exe › fin / Copyright ©2014 by Readify Pty Ltd 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Part 2 Immutable infrastructure

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Page CloudFormation Change Sets › Supply your updated template to a Change Set via New-CFNChangeSet › AWS diffs the updated template against the current stack › A detailed list of what changes and what doesn’t is provided › Details the dependency chain and how it is effected / Copyright ©2014 by Readify Pty Ltd 16

Slide 17

Slide 17 text

Page Immutability › Rev infrastructure package => refresh instances › CI + CloudFormation can do this for us › Inject version into Launch configuration userdata › Triggers a replacement of the launch configuration › How do we stay HA while our infrastructure refreshes? / Copyright ©2014 by Readify Pty Ltd 17

Slide 18

Slide 18 text

Page AutoScaleGroup Update Policies › Allows an ASG to stay HA while undergoing a refresh › Keeps a number of instances in service while terminating stale and creating fresh instances › Works with cfn-signal.exe to ensure updates are successful › Rolls back on failure / Copyright ©2014 by Readify Pty Ltd 18

Slide 19

Slide 19 text

Part 3 Phoenix environments The really really cool part!

Slide 20

Slide 20 text

Page Deploying feature branches › The Dream: › Developer checks in code on a feature branch › The feature branch is built by our CI service of choice › Once complete, our CI service then invokes Octopus and triggers an isolated stack of hardware to be deployed for it › Once the hardware is ready, the feature branch’s payload is automatically deployed to it by Octopus › From check-in to our feature running on new, isolated compute. Ready to test and destroy when we are done / Copyright ©2014 by Readify Pty Ltd 20

Slide 21

Slide 21 text

Page Octopus 3.4 › Introduces new features that allow us to work with a tonne more flexibility in elastic environments › Multi-tenancy › Project Triggers / Auto Deploy Overrides › Machine Policies / Copyright ©2014 by Readify Pty Ltd 21

Slide 22

Slide 22 text

Page Setup › We have built a new feature ryan on an isolated feature branch! We push the code up to our repository › Our CI service notices this and creates a release for our feature branch package, with a semver version number 1.0.0-ryan0001 / Copyright ©2014 by Readify Pty Ltd 22

Slide 23

Slide 23 text

Page Octo 3.4 – Multi-tenancy › We created a tenant ryan0001for our feature branch –we are using the semver from the built package as a naming convention › Allows us to isolate and group sets of machines within an environment › Allows us to configure projects with tenant-specific variables › Allows us to control what software gets deployed to what sets of machines via triggers within an environment / Copyright ©2014 by Readify Pty Ltd 23

Slide 24

Slide 24 text

Page Octo 3.4 – Auto Deploy Overrides › We created an auto deploy override for our feature branch tenant ryan0001 for the feature branch package version 1.0.0-ryan0001 › Part of Project Triggers › Auto Deploy Overrides allow us to say ‘when a project trigger fires, and the machine that triggered it is for a given tenant, deploy an explicit version of the project to the machine, not the default’ / Copyright ©2014 by Readify Pty Ltd 24

Slide 25

Slide 25 text

Page Octo 3.4 – Machine Policies › When our instances register with Octopus via tentacle.exe, they indicate a machine policy › When we clean up our CloudFormation, how do we ensure Octopus is cleaned up as well? › Old way: AWS Lambda › New way: Octopus Machine Policies › Healthchecks and unavailable machines › Cleanup unavailable machines / Copyright ©2014 by Readify Pty Ltd 25