1
00:00:02,420 --> 00:00:05,650
Okay, so now with everything being set up

2
00:00:05,650 --> 00:00:09,260
with the EFS file system created on AWS

3
00:00:09,260 --> 00:00:11,530
and the volume configured and set up here

4
00:00:11,530 --> 00:00:15,850
in our configuration, I did change the code a little bit

5
00:00:15,850 --> 00:00:18,010
so that we actually do write

6
00:00:18,010 --> 00:00:21,150
to that users folder and read from it.

7
00:00:21,150 --> 00:00:25,580
And therefore attached you find a new user-actions.js,

8
00:00:25,580 --> 00:00:28,850
and a new user-routes.js file.

9
00:00:28,850 --> 00:00:33,040
And you should just replace your files with my files,

10
00:00:33,040 --> 00:00:35,610
because in there I changed the code a little bit.

11
00:00:35,610 --> 00:00:38,590
I added this new getLogs function,

12
00:00:38,590 --> 00:00:40,900
where I try to read a file.

13
00:00:40,900 --> 00:00:42,670
And I'm trying to read a file

14
00:00:42,670 --> 00:00:46,120
which is written whenever a new user is created.

15
00:00:46,120 --> 00:00:47,810
When a new user is created,

16
00:00:47,810 --> 00:00:52,350
I save log entries here with the date, the user ID

17
00:00:52,350 --> 00:00:54,350
and the email address of the user.

18
00:00:54,350 --> 00:00:57,110
I save that all to a users-log.txt file

19
00:00:57,110 --> 00:00:59,470
in the users folder in the app folder

20
00:00:59,470 --> 00:01:03,113
and that's the file which then gets read here with getLogs.

21
00:01:04,459 --> 00:01:07,590
And this getLogs function triggers

22
00:01:07,590 --> 00:01:12,590
whenever a get request is sent to the users API /logs.

23
00:01:14,330 --> 00:01:17,690
So with that, make sure you use these two files

24
00:01:17,690 --> 00:01:20,590
instead of the files you had originally there.

25
00:01:20,590 --> 00:01:22,750
And then once you updated your code,

26
00:01:22,750 --> 00:01:24,270
you of course needs to push

27
00:01:24,270 --> 00:01:27,170
that updated code to Docker Hub again.

28
00:01:27,170 --> 00:01:30,510
So let's go into that users API folder

29
00:01:30,510 --> 00:01:32,250
and build the image again,

30
00:01:32,250 --> 00:01:37,250
with that tag we use before as well, like this.

31
00:01:37,460 --> 00:01:39,993
And once the image is built, of course,

32
00:01:39,993 --> 00:01:44,993
also push the updated image to Docker Hub,

33
00:01:45,060 --> 00:01:48,560
so that this latest code is reflected there

34
00:01:48,560 --> 00:01:50,930
and so that our Kubernetes deployment

35
00:01:50,930 --> 00:01:52,743
is able to use that code.

36
00:01:55,140 --> 00:01:57,270
Now once that was pushed,

37
00:01:57,270 --> 00:01:59,760
let's cd into the Kubernetes folder

38
00:01:59,760 --> 00:02:01,610
and there I will first of all

39
00:02:01,610 --> 00:02:06,507
run cube control delete deployment users-deployment

40
00:02:08,220 --> 00:02:10,633
to completely remove and recreate it.

41
00:02:11,880 --> 00:02:14,520
So now that this is deleted,

42
00:02:14,520 --> 00:02:19,460
I'll apply the users.yaml file again,

43
00:02:19,460 --> 00:02:22,820
so that the latest image is pulled again

44
00:02:22,820 --> 00:02:26,190
and all these changes, also regarding the volumes,

45
00:02:26,190 --> 00:02:29,453
which we made to users.yaml are reflected.

46
00:02:30,470 --> 00:02:33,470
Deleting the old deployment, of course,

47
00:02:33,470 --> 00:02:35,010
wasn't really necessary,

48
00:02:35,010 --> 00:02:37,290
since I'd changed the volume configuration

49
00:02:37,290 --> 00:02:39,120
for this deployment anyways.

50
00:02:39,120 --> 00:02:42,250
But yeah, here I did it nonetheless.

51
00:02:42,250 --> 00:02:46,250
So now this new deployment is eventually starting up.

52
00:02:46,250 --> 00:02:49,170
And therefore once this did start up,

53
00:02:49,170 --> 00:02:51,250
we can again test this.

54
00:02:51,250 --> 00:02:54,420
And I will start by saving a new user

55
00:02:54,420 --> 00:02:57,167
with an email address of test3@test.com.

56
00:03:00,090 --> 00:03:03,070
So sending this to the signup route.

57
00:03:03,070 --> 00:03:07,070
Now if we do this, it should work as it did before,

58
00:03:07,070 --> 00:03:09,110
and now this user was created.

59
00:03:09,110 --> 00:03:12,350
But now, we also should have an entry

60
00:03:12,350 --> 00:03:15,063
in a text file being stored.

61
00:03:16,050 --> 00:03:20,530
So let's try this by sending a request to that same URL,

62
00:03:20,530 --> 00:03:22,410
but this time a get request

63
00:03:22,410 --> 00:03:25,583
and let's send it to /logs at the end,

64
00:03:26,530 --> 00:03:29,840
which is this new route which was added here

65
00:03:29,840 --> 00:03:32,563
with one of the two files I provided.

66
00:03:34,370 --> 00:03:36,530
Click send and what you should get back

67
00:03:36,530 --> 00:03:39,410
is a list of log entries.

68
00:03:39,410 --> 00:03:42,190
Now you probably only see one entry,

69
00:03:42,190 --> 00:03:44,740
the test3@test.com entry.

70
00:03:44,740 --> 00:03:48,470
I have two here, because I tested this off screen

71
00:03:48,470 --> 00:03:50,280
before I started recording.

72
00:03:50,280 --> 00:03:52,360
You will only have one, but actually,

73
00:03:52,360 --> 00:03:54,860
this already proves that it works by the way,

74
00:03:54,860 --> 00:03:57,420
because I did create my first entry

75
00:03:57,420 --> 00:03:59,110
before I started recording,

76
00:03:59,110 --> 00:04:01,870
and therefore before I deleted the deployment.

77
00:04:01,870 --> 00:04:06,490
Since it's still there, it means that it was saved on EFS.

78
00:04:06,490 --> 00:04:08,550
But we can test this together.

79
00:04:08,550 --> 00:04:10,970
First of all, let's go back to EFS,

80
00:04:10,970 --> 00:04:13,480
and there, click into that file system

81
00:04:13,480 --> 00:04:15,530
and go to the monitoring area.

82
00:04:15,530 --> 00:04:17,630
And what you should see there

83
00:04:17,630 --> 00:04:20,750
is that once these metrics load up,

84
00:04:20,750 --> 00:04:23,570
we do have some right access here.

85
00:04:23,570 --> 00:04:25,540
It's very hard to see because

86
00:04:25,540 --> 00:04:30,170
the majority of access types are metadata access.

87
00:04:30,170 --> 00:04:33,130
But you see there are some rights here

88
00:04:33,130 --> 00:04:36,800
if you hover across some of these points here,

89
00:04:36,800 --> 00:04:40,200
some of these bullets you have in these charts.

90
00:04:40,200 --> 00:04:41,860
And you see that you also got

91
00:04:41,860 --> 00:04:45,430
a couple of client connections at the moment three,

92
00:04:45,430 --> 00:04:50,430
which makes sense since we got three replicas for this pod.

93
00:04:51,780 --> 00:04:56,260
Here three replicas for this pod which uses this volume.

94
00:04:56,260 --> 00:04:58,943
So having three connections makes a lot of sense.

95
00:05:00,180 --> 00:05:01,890
So that all seems to work

96
00:05:01,890 --> 00:05:04,740
and on metered size you also eventually,

97
00:05:04,740 --> 00:05:07,470
maybe after you add more and more entries,

98
00:05:07,470 --> 00:05:10,180
you should see that file size increase.

99
00:05:10,180 --> 00:05:14,410
So the data is definitely getting stored on EFS.

100
00:05:14,410 --> 00:05:16,330
Now let's also see if it survives

101
00:05:16,330 --> 00:05:19,230
if all our pods would be shut down.

102
00:05:19,230 --> 00:05:20,890
And we can test this

103
00:05:20,890 --> 00:05:24,480
by shrinking the number of replicas to zero,

104
00:05:24,480 --> 00:05:27,080
which will close all pods.

105
00:05:27,080 --> 00:05:31,880
If I now run apply-f=users.yaml,

106
00:05:31,880 --> 00:05:34,310
all the pods will be stopped.

107
00:05:34,310 --> 00:05:38,640
So if I run get pods now,

108
00:05:38,640 --> 00:05:41,300
you will see that they're all terminating.

109
00:05:41,300 --> 00:05:44,060
And once they are stopped, if we then recreate them,

110
00:05:44,060 --> 00:05:46,690
if we then change that number of replicas again,

111
00:05:46,690 --> 00:05:49,150
brand new pods will be created

112
00:05:49,150 --> 00:05:52,100
and traditionally, that would mean that all the data

113
00:05:52,100 --> 00:05:54,230
in the containers would be lost.

114
00:05:54,230 --> 00:05:58,790
Now if our volume works, the data should still be there.

115
00:05:58,790 --> 00:06:00,810
And since it's a persistent volume,

116
00:06:00,810 --> 00:06:03,180
as you learned earlier in the course,

117
00:06:03,180 --> 00:06:05,620
it's also independent of this specific pod

118
00:06:05,620 --> 00:06:07,050
to which it was attached.

119
00:06:07,050 --> 00:06:10,050
So launching new pods should still give us access

120
00:06:10,050 --> 00:06:12,550
to the same data we saved before

121
00:06:12,550 --> 00:06:14,653
with different pod instances.

122
00:06:15,780 --> 00:06:19,060
So let's wait until this is all terminated.

123
00:06:19,060 --> 00:06:21,520
And then let's maybe set replicas to two

124
00:06:22,710 --> 00:06:25,920
and apply the updated users.yaml file

125
00:06:25,920 --> 00:06:28,530
so that these new pods are launched.

126
00:06:28,530 --> 00:06:30,600
And once they are up and running,

127
00:06:30,600 --> 00:06:32,980
we can try sending our requests again

128
00:06:32,980 --> 00:06:34,830
and we should then be able

129
00:06:34,830 --> 00:06:38,490
to still see that data which we saved before.

130
00:06:38,490 --> 00:06:40,360
So they are up and running now.

131
00:06:40,360 --> 00:06:44,340
So for now, I send this get requests to /logs,

132
00:06:44,340 --> 00:06:47,360
I still get that data from before.

133
00:06:47,360 --> 00:06:49,340
So using that volume works,

134
00:06:49,340 --> 00:06:51,100
and therefore this is now

135
00:06:51,100 --> 00:06:55,360
how you could add a volume when using EKS.

136
00:06:55,360 --> 00:06:58,080
Again, you applied just what you learned before

137
00:06:58,080 --> 00:07:00,590
with the persistent volume and so on,

138
00:07:00,590 --> 00:07:02,080
but then in this case,

139
00:07:02,080 --> 00:07:06,110
you can for example, use this EFS specific driver

140
00:07:06,110 --> 00:07:09,730
to use this as a volume for this deployed application.

141
00:07:09,730 --> 00:07:11,930
And now to just clarify this again

142
00:07:11,930 --> 00:07:13,490
and make this really clear,

143
00:07:13,490 --> 00:07:17,170
you could of course use other volume types as well.

144
00:07:17,170 --> 00:07:20,320
You could use any of the volume types supported here,

145
00:07:20,320 --> 00:07:23,170
for example, all the built-in specific types

146
00:07:23,170 --> 00:07:25,440
like the awsElasticBlockStore,

147
00:07:25,440 --> 00:07:27,720
which is a different storage than EFS

148
00:07:27,720 --> 00:07:29,340
which we are using.

149
00:07:29,340 --> 00:07:31,890
But with the CSI implementation here,

150
00:07:31,890 --> 00:07:35,640
you can also use any third party kind of volume,

151
00:07:35,640 --> 00:07:37,800
which supports this interface.

152
00:07:37,800 --> 00:07:41,170
The AWS EFS driver is just one example

153
00:07:41,170 --> 00:07:44,800
since it makes a lot of sense as we're using AWS anyways,

154
00:07:44,800 --> 00:07:48,400
but you could use any third party CSI driver,

155
00:07:48,400 --> 00:07:50,653
which works in this application.

156
00:07:51,640 --> 00:07:53,070
And that's therefore it.

157
00:07:53,070 --> 00:07:55,330
That's how we can add a volume, how we can use it.

158
00:07:55,330 --> 00:07:57,710
And the most important takeaway of course is

159
00:07:57,710 --> 00:08:01,560
that it just works as shown for the last sections,

160
00:08:01,560 --> 00:08:03,450
but here with the special twist

161
00:08:03,450 --> 00:08:06,863
of being deployed on a real EKS cluster.