1
00:00:00,050 --> 00:00:02,510
‫So now let's talk about AWS code deploy.

2
00:00:02,690 --> 00:00:08,330
‫So as the name indicates, it is a deployment service that will automate application deployment.

3
00:00:08,360 --> 00:00:09,340
‫What does that mean?

4
00:00:09,350 --> 00:00:14,240
‫Well, that means you have a version, one of an application running and somehow you want to upgrade

5
00:00:14,240 --> 00:00:15,770
‫it to version two.

6
00:00:15,800 --> 00:00:19,340
‫Now, where can we deploy version one and version two?

7
00:00:19,370 --> 00:00:26,270
‫Well, these application versions can be deployed either to EC2 instances on premises, servers or lambda

8
00:00:26,270 --> 00:00:28,850
‫functions or services.

9
00:00:28,850 --> 00:00:35,090
‫So three different kinds of targets because EC2 instances and on premises servers have the same methodology

10
00:00:35,390 --> 00:00:36,140
‫on top of it.

11
00:00:36,140 --> 00:00:40,880
‫Code deploy can allow you to update an application but also rollback.

12
00:00:40,880 --> 00:00:46,970
‫So in case your deployment is not working as expected, it is failing or there is an alarm that gets

13
00:00:46,970 --> 00:00:53,540
‫triggered, then we can automatically initiate a rollback that makes it a very safe automated deployment.

14
00:00:53,570 --> 00:00:57,980
‫On top of it, we can control how fast we want to deploy our application.

15
00:00:57,980 --> 00:01:04,350
‫We will see this later on, but we can say one instance at a time or all at a time or half at a time

16
00:01:04,350 --> 00:01:05,310
‫or bluegreen.

17
00:01:05,340 --> 00:01:11,250
‫Finally, to control how code deploy works, there is a file named app spec YAML that can help define

18
00:01:11,250 --> 00:01:12,930
‫how the deployment will happen.

19
00:01:13,170 --> 00:01:17,130
‫So now let's talk about the EC2 on premises platform.

20
00:01:17,130 --> 00:01:22,350
‫So this allows you to deploy to EC2 instances and on premises, servers, your application and your

21
00:01:22,350 --> 00:01:28,950
‫code and you can perform two kinds of deployments either in place deployments or bluegreen deployments.

22
00:01:28,950 --> 00:01:35,760
‫We'll see them both To understand the difference and to work, we must first deploy the code, deploy

23
00:01:35,760 --> 00:01:41,850
‫agent onto the target instances because the agent is the thing that will be performing the instance.

24
00:01:41,880 --> 00:01:45,960
‫The updates on the instances, we can define the deployment speed.

25
00:01:45,960 --> 00:01:48,240
‫So as I said, we can have a gradual deployment.

26
00:01:48,270 --> 00:01:53,400
‫For example, we can do all at once, which will update all the instances at once, but will give us

27
00:01:53,400 --> 00:01:58,530
‫the most amount of downtime because we will be down half at a time, for example, to reduce capacity

28
00:01:58,530 --> 00:02:04,380
‫by 50% or one at a time, which is going to be the slowest because we take down one instance at a time

29
00:02:04,380 --> 00:02:05,640
‫and update it.

30
00:02:05,640 --> 00:02:11,070
‫But of course it's going to give us the lowest availability impact because only one instance will be

31
00:02:11,070 --> 00:02:12,060
‫down at a time.

32
00:02:12,420 --> 00:02:16,470
‫Or you can define your own custom deployment speed if you wanted to.

33
00:02:16,650 --> 00:02:22,410
‫So let's have a look at how, for example, in place deployment works for half at a time setting.

34
00:02:22,410 --> 00:02:30,180
‫So here we have the V1 running on four EC2 instances because we're in a half at a time setting an in

35
00:02:30,180 --> 00:02:31,200
‫place deployment.

36
00:02:31,230 --> 00:02:38,280
‫Two instances are going to be taken down for maintenance so the agent will stop the application on two

37
00:02:38,280 --> 00:02:44,310
‫instances, which then are going to be upgraded again by the agent to version two.

38
00:02:44,310 --> 00:02:51,690
‫And once it is done, then the other half is going to be taken down for install and then upgraded to

39
00:02:51,690 --> 00:02:52,410
‫version two.

40
00:02:52,410 --> 00:02:57,420
‫And so this is the process of in place deployment for half at a time setting.

41
00:02:57,690 --> 00:02:59,190
‫What about blue Green?

42
00:02:59,190 --> 00:03:04,470
‫Well, blue, green is the idea that you have, for example, an application load balancer pointing

43
00:03:04,500 --> 00:03:08,610
‫to version one and all your instances are in auto scaling group.

44
00:03:08,640 --> 00:03:13,380
‫What's going to happen is that we're going to create a new autoscaling group so this can be done either

45
00:03:13,380 --> 00:03:21,270
‫manually or automatically by code deploy and code deploy is going to create as many EC2 instances in

46
00:03:21,270 --> 00:03:22,590
‫this new auto scaling group.

47
00:03:22,590 --> 00:03:29,310
‫So we have V one and v two now running in parallel, and the load balancer through some process is going

48
00:03:29,310 --> 00:03:34,740
‫to be pointing now to the V two auto scaling group and the V one will be taken down.

49
00:03:34,740 --> 00:03:39,090
‫So this is a simplified version, but at least you see the process and it's called blue green because

50
00:03:39,090 --> 00:03:43,080
‫new instances are taken up and the old ones are terminated.

51
00:03:43,740 --> 00:03:49,590
‫So this code deploy agent I've been telling you about, it must be installed on the EC2 instances as

52
00:03:49,590 --> 00:03:50,730
‫a prerequisite.

53
00:03:50,730 --> 00:03:54,630
‫So we have the EC2 instance and we install the code deploy agent.

54
00:03:54,660 --> 00:04:01,740
‫Now you can install it directly using some Linux commands to install any software or if you wanted to

55
00:04:01,740 --> 00:04:03,120
‫have some kind of automation.

56
00:04:03,120 --> 00:04:09,690
‫If your EC2 instances are managed using systems manager, then you can automate the install of code

57
00:04:09,690 --> 00:04:11,760
‫deploy agent using systems manager.

58
00:04:12,030 --> 00:04:18,780
‫Now this EC2 instance with the code deploy agent will need sufficient IAM permissions to access Amazon

59
00:04:18,780 --> 00:04:19,410
‫S3.

60
00:04:19,440 --> 00:04:20,240
‫Why?

61
00:04:20,250 --> 00:04:24,660
‫Well, because in Amazon S3 will be stored the application revision.

62
00:04:24,660 --> 00:04:30,240
‫So when we want to update from version one to version two, then the code deploy agent with the proper

63
00:04:30,240 --> 00:04:36,990
‫IAM permissions attached to the ec2 instance will download the application revision from the S3 bucket

64
00:04:36,990 --> 00:04:40,440
‫and now you know enough for code deploy and EC2 instances.

65
00:04:40,470 --> 00:04:43,560
‫Now let's see how code deploy works with the lambda platform.

66
00:04:43,560 --> 00:04:48,060
‫So code deploy can help you automate traffic shift for lambda aliases.

67
00:04:48,060 --> 00:04:53,340
‫And the idea is that you can shift from V1 to V2 under and prod alias.

68
00:04:53,340 --> 00:04:54,570
‫I'll show you this in a second.

69
00:04:54,600 --> 00:04:59,640
‫Now this feature is fully integrated within the SAM framework that you will see soon.

70
00:04:59,830 --> 00:05:04,840
‫And so that allows us to just use the same framework and internally use code deploy.

71
00:05:04,930 --> 00:05:07,500
‫So how does that work for the traffic shifting function?

72
00:05:07,510 --> 00:05:09,490
‫We'll say we have a prod alias.

73
00:05:09,520 --> 00:05:10,060
‫Okay.

74
00:05:10,060 --> 00:05:16,150
‫And we have V one that we've deployed before and v two that we've deployed after and we want to shift

75
00:05:16,150 --> 00:05:21,160
‫the traffic between the V one version and the v two version under the prod alias.

76
00:05:21,160 --> 00:05:28,210
‫So the way it works is that code deploy is going to mix this x vary until x equals 100%.

77
00:05:28,210 --> 00:05:30,010
‫So at first x will be zero.

78
00:05:30,010 --> 00:05:35,680
‫So that means that all the prod alias points to the v one function and then x will gradually increase

79
00:05:35,680 --> 00:05:37,240
‫until it reaches 100%.

80
00:05:37,240 --> 00:05:42,940
‫So that's all the traffic on the prod alias is redirecting to the v two function.

81
00:05:42,940 --> 00:05:49,840
‫Now we have several strategies to make X evolve so we have linear where we grow the traffic every n

82
00:05:49,840 --> 00:05:51,580
‫minutes until 100%.

83
00:05:51,580 --> 00:05:57,850
‫So in this example, Lambda linear 10% every three minutes, that means that every three minutes 10%

84
00:05:57,850 --> 00:05:58,780
‫will be added.

85
00:05:58,880 --> 00:06:05,390
‫So we'll have ten and then 20 and then 30% after nine minutes and so on until we reach 100%.

86
00:06:05,690 --> 00:06:09,770
‫And so you have different strategies, for example, 10% every ten minutes and so on.

87
00:06:09,770 --> 00:06:11,060
‫So this is linear.

88
00:06:11,090 --> 00:06:17,750
‫Then we have canary, which is to have a small amount of traffic on the V two function and then ramp

89
00:06:17,750 --> 00:06:18,920
‫up to 100%.

90
00:06:18,920 --> 00:06:22,460
‫So here we have Lambda Canary 10%, five minutes.

91
00:06:22,460 --> 00:06:28,490
‫So that means that for five minutes the new V two function is going to receive 10% of the traffic.

92
00:06:28,490 --> 00:06:33,950
‫And then if everything goes well, then all of a sudden we switch to 100% of the traffic.

93
00:06:33,980 --> 00:06:35,060
‫That's why it's called canary.

94
00:06:35,060 --> 00:06:41,240
‫So we have, for example, the 10%, five minutes or the 10% 30 minutes strategy and finally all at

95
00:06:41,240 --> 00:06:44,510
‫once, which immediately jumps from v one, two, v two.

96
00:06:44,510 --> 00:06:47,570
‫But we don't have the time to test it if it's working.

97
00:06:48,260 --> 00:06:52,100
‫Now could deploy for the platform is actually similar.

98
00:06:52,100 --> 00:06:56,570
‫So we can automate the deployment of a new ECS task definition.

99
00:06:56,570 --> 00:06:59,300
‫And this only works for blue green deployments.

100
00:06:59,300 --> 00:07:00,770
‫So let's take an example.

101
00:07:00,770 --> 00:07:07,610
‫So we have an application load balancer and it's related to a target group where our ECS task are running

102
00:07:07,610 --> 00:07:13,040
‫under an ECS cluster and we'll use code deploy to do a blue green deployment.

103
00:07:13,040 --> 00:07:21,410
‫So very similarly to EC2 instances, there will be a new target group with the V2 version of our application,

104
00:07:21,410 --> 00:07:27,290
‫and this V2 version comes from the new ECS task definition that will be run with the same capacity as

105
00:07:27,290 --> 00:07:33,680
‫before and then can deploy is going to affect the load balancer and so it's going to redirect the traffic

106
00:07:33,680 --> 00:07:39,710
‫from the V1 target group, the blue target group into the V2 target group, the green target group.

107
00:07:39,710 --> 00:07:44,600
‫And what's going to happen here is that we're going to shift traffic again between the first one and

108
00:07:44,600 --> 00:07:48,020
‫the second one with similar strategies as before.

109
00:07:48,020 --> 00:07:54,500
‫So we have the linear strategy and this is just like before we gradually increase until we reach 100%,

110
00:07:54,530 --> 00:08:00,770
‫we have the canary strategy to test a small amount of traffic on the new target group and then all of

111
00:08:00,770 --> 00:08:06,020
‫a sudden we switch everything to the new target group or we have the all at once to immediately switch

112
00:08:06,020 --> 00:08:08,630
‫from the blue to the green target group.

113
00:08:08,630 --> 00:08:11,660
‫So that's it for an overview of code deploy.

114
00:08:11,660 --> 00:08:15,020
‫I hope you liked it and I will see you in the next lecture.