1
00:00:02,580 --> 00:00:07,010
So now that we saw how we can deploy a single container

2
00:00:07,010 --> 00:00:11,620
to AWS ECS, and use this more managed environment,

3
00:00:11,620 --> 00:00:14,410
let's do the same for multiple containers.

4
00:00:14,410 --> 00:00:16,840
And for that, again attached,

5
00:00:16,840 --> 00:00:20,200
you will find a project which I prepared for you.

6
00:00:20,200 --> 00:00:22,840
It's actually part of the project we used

7
00:00:22,840 --> 00:00:25,310
in a Docker compose section.

8
00:00:25,310 --> 00:00:27,890
The only thing which is missing at this point

9
00:00:27,890 --> 00:00:29,650
is the front end.

10
00:00:29,650 --> 00:00:32,479
Instead, here we have our backend API,

11
00:00:32,479 --> 00:00:35,080
which is this goals API

12
00:00:35,080 --> 00:00:40,080
where you can add and get and delete goals.

13
00:00:40,220 --> 00:00:43,010
And therefore the Docker compose yami file

14
00:00:43,010 --> 00:00:45,670
also just sets up Mongo DB.

15
00:00:45,670 --> 00:00:48,010
And then also this backend.

16
00:00:48,010 --> 00:00:50,253
So again, the front end is missing.

17
00:00:51,240 --> 00:00:53,270
Nonetheless, we got all of that.

18
00:00:53,270 --> 00:00:54,350
And therefore here,

19
00:00:54,350 --> 00:00:58,090
we got a project that utilizes two containers,

20
00:00:58,090 --> 00:00:59,840
the Mongo DB container,

21
00:00:59,840 --> 00:01:01,650
and this backend container.

22
00:01:01,650 --> 00:01:05,120
And now I wanna deploy these two containers

23
00:01:05,120 --> 00:01:06,700
to AWS ECS,

24
00:01:06,700 --> 00:01:10,040
to show you how that would work as well.

25
00:01:10,040 --> 00:01:11,460
For that, first of all,

26
00:01:11,460 --> 00:01:14,200
I will delete the existing resources

27
00:01:14,200 --> 00:01:17,010
we got here on AWS ECS.

28
00:01:17,010 --> 00:01:19,170
And that starts in my cluster,

29
00:01:19,170 --> 00:01:21,260
I got one service here,

30
00:01:21,260 --> 00:01:22,800
you might have a different one,

31
00:01:22,800 --> 00:01:24,960
I created this one off screen.

32
00:01:24,960 --> 00:01:26,690
But still I have one service here,

33
00:01:26,690 --> 00:01:27,690
which I don't want,

34
00:01:27,690 --> 00:01:30,681
so you can check it, click Delete,

35
00:01:30,681 --> 00:01:33,570
and then Enter, delete me here.

36
00:01:33,570 --> 00:01:35,550
And once the service is deleted,

37
00:01:35,550 --> 00:01:37,830
also delete the overall cluster

38
00:01:37,830 --> 00:01:39,550
by clicking on Delete cluster,

39
00:01:39,550 --> 00:01:42,650
and Enter delete me here as well.

40
00:01:42,650 --> 00:01:45,120
Now, this can take a couple of minutes, actually,

41
00:01:45,120 --> 00:01:47,230
until the cluster is deleted.

42
00:01:47,230 --> 00:01:50,060
So I will leave that like that.

43
00:01:50,060 --> 00:01:52,590
And already switch back to the code.

44
00:01:52,590 --> 00:01:55,520
Because here I got a couple of important points.

45
00:01:55,520 --> 00:01:57,360
And one of the most important things

46
00:01:57,360 --> 00:01:59,830
I wanna emphasize here is that we're not going

47
00:01:59,830 --> 00:02:01,990
to use Docker compose for deployment.

48
00:02:01,990 --> 00:02:05,300
And Docker compose is a great tool

49
00:02:05,300 --> 00:02:09,419
for running configurations to find four containers

50
00:02:09,419 --> 00:02:11,100
in a Docker compose file,

51
00:02:11,100 --> 00:02:13,620
possibly also for multiple containers

52
00:02:13,620 --> 00:02:14,892
on your local machine.

53
00:02:14,892 --> 00:02:19,460
But it's not really a great tool for deployment right now.

54
00:02:19,460 --> 00:02:22,020
And that makes sense by the way,

55
00:02:22,020 --> 00:02:24,550
if we keep in mind that with Docker compose,

56
00:02:24,550 --> 00:02:26,750
we can easily run multiple containers

57
00:02:26,750 --> 00:02:28,730
on our local host machine.

58
00:02:28,730 --> 00:02:31,520
Even containers that listen on different ports

59
00:02:31,520 --> 00:02:33,330
and therefore we could have our backend,

60
00:02:33,330 --> 00:02:35,960
our database and our front end container

61
00:02:35,960 --> 00:02:39,560
running all on the same machine with Docker compose.

62
00:02:39,560 --> 00:02:41,460
Now, if you deploy something,

63
00:02:41,460 --> 00:02:43,810
if you move it to a remote machine,

64
00:02:43,810 --> 00:02:45,400
things get more complex,

65
00:02:45,400 --> 00:02:49,340
you might need to define how much CPU capacity

66
00:02:49,340 --> 00:02:52,750
you should be provided for a given service.

67
00:02:52,750 --> 00:02:56,100
All of a sudden certain things start to matter,

68
00:02:56,100 --> 00:02:59,120
which play no role locally on your machine.

69
00:02:59,120 --> 00:03:01,440
And of course, it's depends heavily

70
00:03:01,440 --> 00:03:04,300
on the hosting provider you're using,

71
00:03:04,300 --> 00:03:07,400
which kind of extra information might be needed.

72
00:03:07,400 --> 00:03:11,400
So for example, AWS needs some extra information.

73
00:03:11,400 --> 00:03:14,400
Other cloud providers like Microsoft Azure

74
00:03:14,400 --> 00:03:17,020
might need other kinds of extra data,

75
00:03:17,020 --> 00:03:20,170
which would not be part of the Compose file.

76
00:03:20,170 --> 00:03:23,523
So that's why a compose file can be great for managing

77
00:03:23,523 --> 00:03:27,830
and running multiple containers on one at the same machine.

78
00:03:27,830 --> 00:03:31,220
But as soon as you start moving that into the cloud,

79
00:03:31,220 --> 00:03:34,130
where potentially you also got multiple

80
00:03:34,130 --> 00:03:36,420
different machines working together,

81
00:03:36,420 --> 00:03:38,440
it reaches its limits.

82
00:03:38,440 --> 00:03:39,530
But that's no problem,

83
00:03:39,530 --> 00:03:42,566
you will see that deploying these individual containers

84
00:03:42,566 --> 00:03:44,517
will still be super easy.

85
00:03:44,517 --> 00:03:48,452
And that we can use this compose file as an inspiration.

86
00:03:48,452 --> 00:03:51,700
To understand which deployment settings

87
00:03:51,700 --> 00:03:55,227
we need to set in this case when using AWS.

88
00:03:56,610 --> 00:03:59,370
So therefore, we'll just use this as

89
00:03:59,370 --> 00:04:02,280
you could say an inspiration of what we need to do

90
00:04:02,280 --> 00:04:06,000
and manually deploy these individual containers,

91
00:04:06,000 --> 00:04:09,340
these services to AWS ECS.

92
00:04:09,340 --> 00:04:11,810
Since that is the example a hosting provider

93
00:04:11,810 --> 00:04:13,690
we're using this module.

94
00:04:13,690 --> 00:04:16,370
And I will start with the backend here.

95
00:04:16,370 --> 00:04:18,540
For this we first of all need

96
00:04:18,540 --> 00:04:20,550
to create a backend image

97
00:04:20,550 --> 00:04:22,950
which we can then push to Docker Hub,

98
00:04:22,950 --> 00:04:24,060
so that we can use

99
00:04:24,060 --> 00:04:29,060
this Docker Hub backend image in AWS ECS later,

100
00:04:29,310 --> 00:04:32,320
so therefore, we can open up the terminal

101
00:04:32,320 --> 00:04:35,100
or Command Prompt on our local host machine

102
00:04:35,100 --> 00:04:36,600
and this project folder

103
00:04:36,600 --> 00:04:40,380
and run Docker build to build our backend image.

104
00:04:40,380 --> 00:04:42,700
However, there is another important note

105
00:04:42,700 --> 00:04:47,590
we have to be aware of before we built this image.

106
00:04:47,590 --> 00:04:51,330
Unfortunately for AWS ECS

107
00:04:51,330 --> 00:04:55,220
we will not be able to use this automatic

108
00:04:55,220 --> 00:04:59,410
find the container IP by container name feature

109
00:04:59,410 --> 00:05:02,350
which works so nice locally

110
00:05:02,350 --> 00:05:05,730
in app JS when I connect to Mongo DB,

111
00:05:05,730 --> 00:05:10,730
I did refer to Mongo DB as my domain address so to say.

112
00:05:11,700 --> 00:05:13,580
And since my container,

113
00:05:13,580 --> 00:05:16,030
my service here was named Mongo DB,

114
00:05:16,030 --> 00:05:18,250
Docker compose set up a network

115
00:05:18,250 --> 00:05:20,952
where Docker was able to replace

116
00:05:20,952 --> 00:05:24,670
this placeholder name in this connection string

117
00:05:24,670 --> 00:05:27,900
with the actual IP of the Mongo DB container.

118
00:05:27,900 --> 00:05:32,230
Unfortunately, this won't work like that on AWS ECS.

119
00:05:33,870 --> 00:05:36,140
Now, you might wonder why we can't use

120
00:05:36,140 --> 00:05:39,240
this container name and Docker networks

121
00:05:39,240 --> 00:05:41,840
when deploying our dockerized app.

122
00:05:41,840 --> 00:05:44,170
The reason for that is rather simple.

123
00:05:44,170 --> 00:05:47,830
When you run Docker locally on your local machine,

124
00:05:47,830 --> 00:05:49,760
then everything of course happens

125
00:05:49,760 --> 00:05:51,860
on just one machine, right?

126
00:05:51,860 --> 00:05:53,560
Your local machine,

127
00:05:53,560 --> 00:05:56,490
and Docker runs to different containers there.

128
00:05:56,490 --> 00:05:58,840
And when you create a Docker network

129
00:05:58,840 --> 00:06:00,790
with the Docker network command

130
00:06:00,790 --> 00:06:02,640
or with Docker compose,

131
00:06:02,640 --> 00:06:05,780
then all these containers can be put into the same network

132
00:06:05,780 --> 00:06:07,780
on your local machine.

133
00:06:07,780 --> 00:06:10,700
Now, as soon as you deploy something, for example,

134
00:06:10,700 --> 00:06:13,280
here to AWS ECS,

135
00:06:13,280 --> 00:06:15,660
it'll not be that simple anymore,

136
00:06:15,660 --> 00:06:18,460
your containers and the different instances

137
00:06:18,460 --> 00:06:20,980
of your containers will be executed

138
00:06:20,980 --> 00:06:23,720
and managed by this cloud provider.

139
00:06:23,720 --> 00:06:28,710
And they don't necessarily always run on the same machine.

140
00:06:28,710 --> 00:06:31,880
Of course, after all, there's a huge data center out there

141
00:06:31,880 --> 00:06:35,980
managed by AWS, actually multiple data centers,

142
00:06:35,980 --> 00:06:38,766
with the thousands and 10s of thousands

143
00:06:38,766 --> 00:06:41,230
of machines and servers.

144
00:06:41,230 --> 00:06:43,240
And therefore, it's not guaranteed,

145
00:06:43,240 --> 00:06:44,810
and it's indeed very unlikely

146
00:06:44,810 --> 00:06:47,070
that your containers will always run

147
00:06:47,070 --> 00:06:50,110
on the exact same machine all the time.

148
00:06:50,110 --> 00:06:54,260
That's why this Docker network approach won't work anymore.

149
00:06:54,260 --> 00:06:57,240
Now, still there is an exception though,

150
00:06:57,240 --> 00:07:01,110
if your containers are added in the same task

151
00:07:01,110 --> 00:07:04,010
in AWS ECS case,

152
00:07:04,010 --> 00:07:06,540
which is exactly what we're going to do,

153
00:07:06,540 --> 00:07:10,440
then they are guaranteed to run on the same machine.

154
00:07:10,440 --> 00:07:14,916
Still then AWS ECS will not create a Docker network

155
00:07:14,916 --> 00:07:18,550
for them instead it allows you to use localhost

156
00:07:18,550 --> 00:07:22,890
as an address inside of your container application code.

157
00:07:22,890 --> 00:07:26,570
So we can use localhost instead of Mongo DB here

158
00:07:26,570 --> 00:07:28,513
when deploying this with AWS ECS,

159
00:07:29,710 --> 00:07:31,330
because these two containers,

160
00:07:31,330 --> 00:07:34,160
which we wanna connect the node app container

161
00:07:34,160 --> 00:07:37,350
and Mongo DB will be part of the same task,

162
00:07:37,350 --> 00:07:39,410
and therefore will be guaranteed to run

163
00:07:39,410 --> 00:07:40,550
on the same machine.

164
00:07:40,550 --> 00:07:45,430
And then AWS ECS gives us access to the network

165
00:07:45,430 --> 00:07:47,740
on that machine and to the other containers,

166
00:07:47,740 --> 00:07:49,420
which are part of the task,

167
00:07:49,420 --> 00:07:51,720
through the local host address.

168
00:07:51,720 --> 00:07:53,283
That's how this works here.

169
00:07:54,210 --> 00:07:55,920
So here unfortunately,

170
00:07:55,920 --> 00:08:00,920
we have to adjust our code to work with AWS ECS,

171
00:08:01,450 --> 00:08:04,610
which of course is a bit against the idea

172
00:08:04,610 --> 00:08:08,610
of having the same environment locally and in production.

173
00:08:08,610 --> 00:08:10,090
Nonetheless, we can fix this

174
00:08:10,090 --> 00:08:12,940
and ensure that we have the same environment again,

175
00:08:12,940 --> 00:08:15,700
by leveraging environment variables here.

176
00:08:15,700 --> 00:08:19,543
So here, we could expect a process.env MongoDB URL,

177
00:08:23,280 --> 00:08:26,320
or something like that variable.

178
00:08:26,320 --> 00:08:28,325
And then we just need to make sure that

179
00:08:28,325 --> 00:08:32,380
we provide this variable in the backend env file.

180
00:08:32,380 --> 00:08:36,230
And this could be MongoDB here locally,

181
00:08:36,230 --> 00:08:39,549
so the name of the container to which you want to connect.

182
00:08:39,549 --> 00:08:43,610
And when we then run this container through AWS ECS,

183
00:08:43,610 --> 00:08:46,120
we could provide a different value here,

184
00:08:46,120 --> 00:08:49,150
so that this again is flexible and works

185
00:08:49,150 --> 00:08:52,030
in both our local development environment,

186
00:08:52,030 --> 00:08:54,320
as well as in production.

187
00:08:54,320 --> 00:08:56,683
It's a little adjustment we have to make here.

188
00:08:57,750 --> 00:09:00,380
With that, however we can build this image.

189
00:09:00,380 --> 00:09:03,160
And since I'm currently in the main project folder,

190
00:09:03,160 --> 00:09:05,000
not in the backend folder,

191
00:09:05,000 --> 00:09:07,570
I will build./backend,

192
00:09:07,570 --> 00:09:09,650
which means I will build the Docker file

193
00:09:09,650 --> 00:09:12,610
which can be found in the backend folder.

194
00:09:12,610 --> 00:09:14,480
I also wanna give my image a name

195
00:09:14,480 --> 00:09:16,200
with the -t flag,

196
00:09:16,200 --> 00:09:19,690
and I will name it node goals

197
00:09:21,630 --> 00:09:25,790
or maybe goals node and hit Enter

198
00:09:25,790 --> 00:09:27,600
and this creates the image

199
00:09:27,600 --> 00:09:29,210
and with the image created,

200
00:09:29,210 --> 00:09:32,350
we now have to push it to Docker Hub.

201
00:09:32,350 --> 00:09:33,980
So for that on Docker Hub,

202
00:09:33,980 --> 00:09:38,980
I'll create a new repository and name this gold stash node,

203
00:09:40,180 --> 00:09:42,660
just like my local image,

204
00:09:42,660 --> 00:09:44,960
but this will now be a repository

205
00:09:44,960 --> 00:09:48,163
so it will be named academind/goals node.

206
00:09:49,150 --> 00:09:51,723
Created as a public repository here.

207
00:09:52,740 --> 00:09:55,680
And then use this name here

208
00:09:55,680 --> 00:09:58,030
as a name for my image locally.

209
00:09:58,030 --> 00:10:02,270
So I can retag my goals node image here

210
00:10:02,270 --> 00:10:04,470
to academind/ Gold's node

211
00:10:04,470 --> 00:10:06,413
with the Docker tag command.

212
00:10:07,370 --> 00:10:11,610
And then we can Docker push academind/goals node

213
00:10:11,610 --> 00:10:15,883
to push this locally built image to Docker Hub.

214
00:10:17,850 --> 00:10:19,890
And one thing I want to emphasize here is

215
00:10:19,890 --> 00:10:22,690
that we're really just pushing the image right now.

216
00:10:22,690 --> 00:10:25,200
So things like the environment variables

217
00:10:25,200 --> 00:10:27,040
are not getting used at the moment.

218
00:10:27,040 --> 00:10:30,240
These are being fed in when we run containers

219
00:10:30,240 --> 00:10:31,740
based on the images.

220
00:10:31,740 --> 00:10:34,650
That's also what we did with Docker compose

221
00:10:34,650 --> 00:10:38,230
There we also just pointed at the end file,

222
00:10:38,230 --> 00:10:42,063
which then was only used when the images were executed.

223
00:10:43,350 --> 00:10:48,030
Now with that this image was pushed to Docker Hub,

224
00:10:48,030 --> 00:10:50,360
and now we can use it on ECS.

225
00:10:50,360 --> 00:10:54,063
Once the deletion of all these resources is done,

