1
00:00:06,540 --> 00:00:08,500
- Now let us review an introduction to

2
00:00:08,500 --> 00:00:11,700
Amazon Elastic Container Service, or ECS.

3
00:00:11,700 --> 00:00:16,700
With ECS, we have the
ability to manage containers.

4
00:00:16,960 --> 00:00:21,790
So, ECS is ultimately a
container management service or

5
00:00:21,790 --> 00:00:25,760
essentially a scheduler. And
it is, uh, it does support

6
00:00:25,760 --> 00:00:28,740
Docker containers And it's
basically analogous to

7
00:00:28,740 --> 00:00:33,020
Kubernetes if you are already
familiar with containers.

8
00:00:33,020 --> 00:00:35,130
If you've done any
deployments with containers,

9
00:00:35,130 --> 00:00:37,940
then you are probably
familiar with schedulers like

10
00:00:37,940 --> 00:00:42,240
Kubernetes, or Docker Swarm, uh, or Mesos.

11
00:00:42,240 --> 00:00:45,900
And so Elastic Container
Service, is essentially

12
00:00:45,900 --> 00:00:49,020
the same thing. It's, it's
fulfilling that same need,

13
00:00:49,020 --> 00:00:53,010
in that we have a collection of hosts,

14
00:00:53,010 --> 00:00:56,510
perhaps EC2 Instances,
and we want to deploy

15
00:00:56,510 --> 00:00:59,870
containers to that cluster of hosts.

16
00:00:59,870 --> 00:01:03,890
And so we need something
that can track the state

17
00:01:03,890 --> 00:01:08,720
of those Instances of those
hosts, track the available,

18
00:01:08,720 --> 00:01:12,860
uh, resources, such as
CPU and memory and DiskIO,

19
00:01:12,860 --> 00:01:17,860
uh, or, or, NetworkIo. And,
help us keep track of what, in-,

20
00:01:18,300 --> 00:01:21,020
what containers are
running on what Instances,

21
00:01:21,020 --> 00:01:25,020
and help us help us to
handle all of the low-level,

22
00:01:25,020 --> 00:01:29,040
um, minusha of getting, uh,
in a, a container running

23
00:01:29,040 --> 00:01:31,580
on a particular Instance
within that cluster.

24
00:01:31,580 --> 00:01:33,130
So that's what a scheduler does.

25
00:01:33,130 --> 00:01:34,693
That's what ECS does.

26
00:01:36,090 --> 00:01:40,430
And so, we can use this
to essentially schedule,

27
00:01:40,430 --> 00:01:43,380
uh, or ensure that
containers are running for,

28
00:01:43,380 --> 00:01:45,530
perhaps long-running applications.

29
00:01:45,530 --> 00:01:50,090
So if you are deploying
micro-services for an API,

30
00:01:50,090 --> 00:01:53,000
services that need to run
for a long period of time,

31
00:01:53,000 --> 00:01:55,650
listening for incoming connections.

32
00:01:55,650 --> 00:01:58,560
Those are well-suited for containers,

33
00:01:58,560 --> 00:02:01,450
as are other applications like batch jobs,

34
00:02:01,450 --> 00:02:05,200
right? So you can have one
cluster of, of Instances

35
00:02:05,200 --> 00:02:08,310
that run all kinds of
different applications

36
00:02:08,310 --> 00:02:13,290
side-by-side. And the, the
isolation between those

37
00:02:13,290 --> 00:02:16,950
processes is achieved through containers.

38
00:02:16,950 --> 00:02:20,300
So again, long-running
applications for API's,

39
00:02:20,300 --> 00:02:23,730
batch jobs, um, all kinds
of different things we can

40
00:02:23,730 --> 00:02:25,573
use containers for.

41
00:02:26,600 --> 00:02:31,040
ECS does integrate very well
with Elastic Load Balancing,

42
00:02:31,040 --> 00:02:35,900
with Elastic Block Store,
with, uh, Amazon VPC,

43
00:02:35,900 --> 00:02:39,740
and with the Identity and
Access Management Service.

44
00:02:39,740 --> 00:02:43,630
And so, I suppose that that
would be the nice thing,

45
00:02:43,630 --> 00:02:46,850
the great thing about ECS, as
oppose to running Docker Swarm

46
00:02:46,850 --> 00:02:51,030
or Kubernetes on EC2,
is that we have a native

47
00:02:51,030 --> 00:02:55,440
inherent integration with
other native Amazon services.

48
00:02:55,440 --> 00:02:58,040
Now when we take a look at this diagram,

49
00:02:58,040 --> 00:03:00,370
a few things I want to point out here,

50
00:03:00,370 --> 00:03:03,980
would be one, you notice
that we have, here,

51
00:03:03,980 --> 00:03:07,170
an auto-scaled fleet of EC2 Instances.

52
00:03:07,170 --> 00:03:09,720
And of course we will
talk about auto-scaling,

53
00:03:09,720 --> 00:03:11,910
uh, in more detail later on.

54
00:03:11,910 --> 00:03:15,460
But for now the idea here
is that if any one of these

55
00:03:15,460 --> 00:03:18,640
Instances were to fail,
for whatever reason,

56
00:03:18,640 --> 00:03:20,550
become unhealthy,

57
00:03:20,550 --> 00:03:22,200
or unusable,

58
00:03:22,200 --> 00:03:24,733
then auto-scaling could simply replace it.

59
00:03:25,660 --> 00:03:28,000
And if we needed to add more machines

60
00:03:28,000 --> 00:03:30,930
then we could do that
with auto-scaling as well.

61
00:03:30,930 --> 00:03:35,350
Now up here, we have the
cluster. And a cluster,

62
00:03:35,350 --> 00:03:39,210
in this regard, is within ECS,

63
00:03:39,210 --> 00:03:40,963
a logical grouping

64
00:03:40,963 --> 00:03:45,963
of EC2 Instances or hosts
that allow us to deploy

65
00:03:46,380 --> 00:03:48,090
a grouping of services.

66
00:03:48,090 --> 00:03:52,830
So, a cluster is a
collection of EC2 Instances

67
00:03:52,830 --> 00:03:54,320
that are being managed,

68
00:03:54,320 --> 00:03:59,320
and it is also a collection
of services that we deploy,

69
00:03:59,320 --> 00:04:03,230
uh, to that cluster. And
so, we create the cluster

70
00:04:03,230 --> 00:04:07,130
as it's own sort of resource within ECS,

71
00:04:07,130 --> 00:04:11,680
and then as these EC2
Instances come to life,

72
00:04:11,680 --> 00:04:15,550
using custom Amazon machine images using

73
00:04:15,550 --> 00:04:18,100
user data bootstrapping scripts.

74
00:04:18,100 --> 00:04:19,670
These Instances can then

75
00:04:19,670 --> 00:04:24,160
communicate to the ECS service
in order to join the cluster

76
00:04:24,160 --> 00:04:26,600
and then be managed by

77
00:04:27,640 --> 00:04:30,610
as, as essentially a single pool

78
00:04:30,610 --> 00:04:32,460
of resources, right?

79
00:04:32,460 --> 00:04:36,190
And so now that all of these
machines are essentially

80
00:04:36,190 --> 00:04:41,190
a part of the same
cluster, we can now use ECS

81
00:04:41,330 --> 00:04:44,350
to manage those machines
in deploy containers

82
00:04:44,350 --> 00:04:46,210
to those machines.

83
00:04:46,210 --> 00:04:50,260
So taking a closer look
at, or perhaps a different

84
00:04:50,260 --> 00:04:53,720
look at this diagram, you
can see here that we have

85
00:04:53,720 --> 00:04:56,860
our, we have our cluster
in, in that cluster

86
00:04:56,860 --> 00:04:59,650
is essentially managing, in this example

87
00:04:59,650 --> 00:05:01,830
a couple of EC2 Instances.

88
00:05:01,830 --> 00:05:05,530
And within those Instances,
we have containers

89
00:05:05,530 --> 00:05:06,910
that are running, right?

90
00:05:06,910 --> 00:05:09,620
So each one of these is a container.

91
00:05:09,620 --> 00:05:10,453
And

92
00:05:11,370 --> 00:05:15,840
those containers are
deployed by the ECS service.

93
00:05:15,840 --> 00:05:19,000
The ECS service is able to create

94
00:05:19,000 --> 00:05:22,910
those containers by
pulling container images

95
00:05:22,910 --> 00:05:27,020
from ECR, the Elastic Container Register.

96
00:05:27,020 --> 00:05:29,820
So very much like virtual machines,

97
00:05:29,820 --> 00:05:33,090
containers are also based on an image.

98
00:05:33,090 --> 00:05:36,660
The primary difference
being: that a container image

99
00:05:36,660 --> 00:05:40,020
does not need the operating system.

100
00:05:40,020 --> 00:05:43,680
All of these containers that
are running on a, on a host,

101
00:05:43,680 --> 00:05:46,950
they all share the same
underlying operating system.

102
00:05:46,950 --> 00:05:50,650
And so the benefit of
containers, is that, as,

103
00:05:50,650 --> 00:05:54,963
if we are deploying containers
as our deployment artifact,

104
00:05:56,350 --> 00:06:00,500
then the container image,
in many cases I've seen

105
00:06:00,500 --> 00:06:05,500
many container images,
be far less than 100 meg.

106
00:06:05,810 --> 00:06:08,480
Whereas virtual machine images could be

107
00:06:08,480 --> 00:06:10,660
upwards of 8 gigs or more, right?

108
00:06:10,660 --> 00:06:13,070
So that's, uh, that's a
pretty good difference,

109
00:06:13,070 --> 00:06:15,240
a very noticeable
difference between the size

110
00:06:15,240 --> 00:06:16,570
of the actual artifact.

111
00:06:16,570 --> 00:06:20,010
And so by having small
artifacts, it means that

112
00:06:20,010 --> 00:06:22,910
they can upload faster,
they can download faster,

113
00:06:22,910 --> 00:06:26,830
uh, and they can deploy faster. So

114
00:06:26,830 --> 00:06:30,630
again we have our, our registry where we

115
00:06:30,630 --> 00:06:33,830
would publish our container images.

116
00:06:33,830 --> 00:06:38,300
We have the ECS service,
and so in our deployments

117
00:06:38,300 --> 00:06:40,227
we essentially tell ECS:

118
00:06:40,227 --> 00:06:43,360
"Hey I want this particular

119
00:06:43,360 --> 00:06:45,120
image to be used

120
00:06:45,120 --> 00:06:47,100
for this particular service".

121
00:06:47,100 --> 00:06:50,740
So, ECS will pull the image

122
00:06:50,740 --> 00:06:53,830
from the container registry.

123
00:06:53,830 --> 00:06:58,620
ECS will then instruct this
cluster, it will choose

124
00:06:58,620 --> 00:07:02,550
a particular Instance to
launch that container on.

125
00:07:02,550 --> 00:07:06,230
Now, when we launch
what we call a service,

126
00:07:06,230 --> 00:07:10,780
we may say that we want
uh, a certain number of

127
00:07:10,780 --> 00:07:13,450
containers to be replicated.

128
00:07:13,450 --> 00:07:15,740
Meaning that we will take the same image,

129
00:07:15,740 --> 00:07:18,260
and replicate it some
number of times across

130
00:07:18,260 --> 00:07:20,790
a different number of
containers for the sake

131
00:07:20,790 --> 00:07:22,770
of fault-tolerance and high availability.

132
00:07:22,770 --> 00:07:25,900
If one container fails,
we still have another

133
00:07:25,900 --> 00:07:29,670
two or three, or however
many containers we need.

134
00:07:29,670 --> 00:07:30,503
And so,

135
00:07:31,450 --> 00:07:34,140
again ECS is responsible for ensuring

136
00:07:34,140 --> 00:07:38,150
tracking the state of,
of the EC2 Instances that

137
00:07:38,150 --> 00:07:42,850
are within this cluster.
And knowing how much CPU,

138
00:07:42,850 --> 00:07:47,250
and memory, and disc, and
NetworkIo are available.

139
00:07:47,250 --> 00:07:49,810
So that when we go to
deploy more containers,

140
00:07:49,810 --> 00:07:53,310
it knows where those
containers can be placed.

141
00:07:53,310 --> 00:07:58,310
Where the um, resource
requirements can be fulfilled.

142
00:07:58,670 --> 00:08:01,470
Another thing that we
can do with ECS that's

143
00:08:01,470 --> 00:08:04,380
really powerful, especially
for microservices,

144
00:08:04,380 --> 00:08:07,560
is that if we wanted to
create, you know, microservices

145
00:08:07,560 --> 00:08:11,420
and offer, you know, different
services at different URL's,

146
00:08:11,420 --> 00:08:14,730
we can leverage the
application load-balancer.

147
00:08:14,730 --> 00:08:18,530
So here we have a forum of
the Elastic Load-Balancer

148
00:08:18,530 --> 00:08:21,200
called the Application Load-Balancer.

149
00:08:21,200 --> 00:08:25,290
And what we can do with
this is both host name,

150
00:08:25,290 --> 00:08:28,480
and path-based routing. We could say if

151
00:08:28,480 --> 00:08:33,370
we had uh, a series of
microservices, we might say that,

152
00:08:33,370 --> 00:08:37,030
um, perhaps this
container, this container,

153
00:08:37,030 --> 00:08:40,800
and this container, belonged
to a particular service.

154
00:08:40,800 --> 00:08:43,820
And that a certain URL, should be routed

155
00:08:44,660 --> 00:08:45,790
to

156
00:08:45,790 --> 00:08:50,740
those particular, uh, containers like so.

157
00:08:50,740 --> 00:08:55,733
In order to satisfy the routing
for a particular service.

158
00:08:57,130 --> 00:08:59,943
And, and, so we could, we could group,

159
00:09:01,100 --> 00:09:02,060
containers

160
00:09:02,060 --> 00:09:05,520
um, essentially container
replicas for a particular

161
00:09:05,520 --> 00:09:08,350
service. We can group them
as what we call "targets"

162
00:09:08,350 --> 00:09:12,280
within target groups. And
so, again, we can use,

163
00:09:12,280 --> 00:09:15,880
use path-based routing from
the Application Load-Balancer

164
00:09:15,880 --> 00:09:20,150
to get us to the containers
for a particular service.

165
00:09:20,150 --> 00:09:22,570
And so in this example,
we may have, you know,

166
00:09:22,570 --> 00:09:26,870
three containers, running
for a microservice available

167
00:09:26,870 --> 00:09:31,370
through the load-balancer.
We may have several other

168
00:09:31,370 --> 00:09:34,410
containers doing some type
of background processing,

169
00:09:34,410 --> 00:09:36,410
or batch processing.

170
00:09:36,410 --> 00:09:40,810
Either way, the deployment,
the underlying, um,

171
00:09:40,810 --> 00:09:44,360
you know, all of the steps it
takes to get that container

172
00:09:44,360 --> 00:09:49,270
running on those Instances,
is all managed by ECS.

173
00:09:49,270 --> 00:09:52,220
And we will take a closer look at that and

174
00:09:52,220 --> 00:09:55,593
how that all works, in an upcoming lesson.