Other Deployment Types
- Rolling: Deploy one or more servers with new code in batches. Use a new AutoScaling Launch Configuration. Abort if issues arise and roll back fraction with new code. Going back and start deploying original launch configurations
- Canary: Deploy a canary group of servers behind an ELB. Set up Route 53 Weighted Round Robin records for the current and Canary ELBs at %100 and %0.
Common deployment risks
- Application failure => Downtime
- Infrastructure failure => Data loss
- Capacity issues => Bad customer experience
- Scaling issues => Lost revenue
- People failure => Grumpy managers
- Process failure => Burned out stuff
- Rollback issues => Wasted time/resources
- Blue: Existing production environment
- Green: Parallel environment running a different version of the app
- Deployment: Ability to switch traffic between the two environments
- Examples are app component, app tier and microservices
|Using EC2 instances||Using EC2 Container Service|
|Classic DNS cutover||Swap ECS services via DNS|
|Swap Autoscaling group||Swap ECS services vis ELB|
|Swap launch configurations||Swap ECS task definitions|
Classic DNS cutover
- Start with blue current app, deploy a new green app environment. Start distributing some of the traffic via Route 53 Endpoint to the green environment and test it. This is canary analysis, gives you the ability to test performance and cutover traffic while monitoring the environments.
- Use CloudFormation templates to model your environment and Version control your templates
- Use ElasticBeanstalk or OpsWorks to model your applications inside the template
- Update CloudFormation stack from updated template containing green environment
- Route 53 Weighted DNS Switching! TTL: the amount of time your DNS server caches the responses to your requests and updates.
- Reaction time = (TTL x no of DNS caches) + Route 53 propagation time, up to 1 min. Beware of misbehaving DNS clients. Shifting traffic to green environment introduces some delays.
Swap Auto Scaling Groups
- Here AS group is outside the environment boundary. Start with blue current ASG, deploy & scale out with green ASG. Test green task, register green ASG with ELB.
- Least outstanding requests algorithm favours green ASG instances for new connections
- Connection draining - gracefully stop receiving traffic
- Scale out green ASG before ELB registration
- Put blue instances in standby,
Swap Launch Configurations
- Start with current blue ASG and launch configuration behind ELB. Attach the updated green launch configuration to the ASG. New instances came out from the new version of launch config. Grow the ASG gradually to 2x original size. Shrink the ASG back to original size.
EC2 Container Service
- Task Definition: Will declare your resource requirements
- ECS Service: Prepare a long standing process
- Similar to DNS Cutover…
- Swap ECS services with ELB
- Start with blue service composed of a task definition with ELB
- Create a new task definition based on a new version of Docker image
- Create green service with new task definition and map to existing ELB
- Scale up green service by incrementing number of tasks
- Decommission blue service by setting task count to 0
- ECS Service Update
- Start with blue task definition referenced by an ECS service
- Create a green revision of the existing task definition
- Update existing ECS service to use the updated task definition
- ECS will deploy the new task definition to a container instances in a rolling fashion
- ELB won’t restart a server!!!