1
00:00:02,200 --> 00:00:03,260
So, as I mentioned,

2
00:00:03,260 --> 00:00:05,090
there are different kinds of data,

3
00:00:05,090 --> 00:00:08,330
and we need to understand which kinds of data we have,

4
00:00:08,330 --> 00:00:12,060
in order to understand which problems we might be facing,

5
00:00:12,060 --> 00:00:15,860
and which problems we'll be solving throughout this modules.

6
00:00:15,860 --> 00:00:18,150
Of course, we have our application.

7
00:00:18,150 --> 00:00:21,160
So our source code and the environment in which

8
00:00:21,160 --> 00:00:23,140
this application runs.

9
00:00:23,140 --> 00:00:25,890
This is what we talked about a lot

10
00:00:25,890 --> 00:00:28,030
in the last modules.

11
00:00:28,030 --> 00:00:31,170
Now, of course, this code is written by us.

12
00:00:31,170 --> 00:00:34,657
Maybe we also use some third party packages,

13
00:00:34,657 --> 00:00:38,900
like the dependencies our Node applications used,

14
00:00:38,900 --> 00:00:41,950
that were specified in the package.json file.

15
00:00:41,950 --> 00:00:44,020
But overall, we got a package of code,

16
00:00:44,020 --> 00:00:46,393
which is set up and written by us.

17
00:00:47,240 --> 00:00:48,570
Now, this code

18
00:00:48,570 --> 00:00:50,480
and the entire environment,

19
00:00:50,480 --> 00:00:53,920
is added to the image during the build phase.

20
00:00:53,920 --> 00:00:55,610
So when we build an image,

21
00:00:55,610 --> 00:00:58,038
our code is copied into the image.

22
00:00:58,038 --> 00:01:01,240
That was what we used the Dockerfile for,

23
00:01:01,240 --> 00:01:03,320
to set up these instructions.

24
00:01:03,320 --> 00:01:05,660
And when we then run a container based

25
00:01:05,660 --> 00:01:07,470
on an image, of course,

26
00:01:07,470 --> 00:01:09,791
that container also uses our code

27
00:01:09,791 --> 00:01:12,640
end the provided environment.

28
00:01:12,640 --> 00:01:15,400
Now, since it's copied into an image,

29
00:01:15,400 --> 00:01:17,520
that code is fixed.

30
00:01:17,520 --> 00:01:20,580
It can't be changed once the image is built.

31
00:01:20,580 --> 00:01:21,970
So this data,

32
00:01:21,970 --> 00:01:25,040
if you wanna call it like this, our source code

33
00:01:25,040 --> 00:01:27,700
and everything related to that,

34
00:01:27,700 --> 00:01:32,500
is unchangeable if we copied it into an image.

35
00:01:32,500 --> 00:01:35,690
Because images are read-only,

36
00:01:35,690 --> 00:01:38,810
once all the instructions finished executing,

37
00:01:38,810 --> 00:01:40,630
the image is locked in

38
00:01:40,630 --> 00:01:41,720
and it's closed,

39
00:01:41,720 --> 00:01:43,240
and you have to rebuild it,

40
00:01:43,240 --> 00:01:45,470
and therefore build a new image,

41
00:01:45,470 --> 00:01:47,820
if you want to change something about it.

42
00:01:47,820 --> 00:01:50,560
You can't go into an existing image

43
00:01:50,560 --> 00:01:52,690
and start changing things in there,

44
00:01:52,690 --> 00:01:54,820
that won't work.

45
00:01:54,820 --> 00:01:58,537
But that's no problem here because our application code

46
00:01:58,537 --> 00:02:01,260
and the environment, should be read-only.

47
00:02:01,260 --> 00:02:04,130
And that is why we store it in an image.

48
00:02:04,130 --> 00:02:07,110
The running application should not start

49
00:02:07,110 --> 00:02:08,930
editing the source code, right?

50
00:02:08,930 --> 00:02:11,360
That's not something you do typically

51
00:02:11,360 --> 00:02:13,640
and not something you wanna do.

52
00:02:13,640 --> 00:02:16,548
So that's the kind of data we thoroughly covered

53
00:02:16,548 --> 00:02:19,200
in the last modules.

54
00:02:19,200 --> 00:02:21,700
Now, there are two other kinds of data.

55
00:02:21,700 --> 00:02:25,300
For example, we got temporary application data.

56
00:02:25,300 --> 00:02:28,120
And with that, I don't mean our source code,

57
00:02:28,120 --> 00:02:30,270
but I mean, data generated,

58
00:02:30,270 --> 00:02:32,750
whilst the application is running.

59
00:02:32,750 --> 00:02:35,610
For example, if we're talking about a website,

60
00:02:35,610 --> 00:02:39,090
a user might be entering something in a forum,

61
00:02:39,090 --> 00:02:42,670
and when we then fetch that data and handle it

62
00:02:42,670 --> 00:02:43,640
on the server,

63
00:02:43,640 --> 00:02:45,640
which might be running into container,

64
00:02:45,640 --> 00:02:49,430
then this entered user data, is temporary data.

65
00:02:49,430 --> 00:02:52,580
We might store it in variables, in our code,

66
00:02:52,580 --> 00:02:55,580
and therefore it's in the end, only stored in memory,

67
00:02:55,580 --> 00:02:58,070
or maybe we even store it in a database

68
00:02:58,070 --> 00:02:59,460
or in a file.

69
00:02:59,460 --> 00:03:03,560
But we are absolutely fine with losing that data

70
00:03:03,560 --> 00:03:06,260
when the containers shuts down, right?

71
00:03:06,260 --> 00:03:08,070
Because it's just temporary.

72
00:03:08,070 --> 00:03:09,360
It's not data that needs

73
00:03:09,360 --> 00:03:11,113
to be stored long term.

74
00:03:11,960 --> 00:03:13,330
So that would be data,

75
00:03:13,330 --> 00:03:15,000
which is not read-only,

76
00:03:15,000 --> 00:03:17,180
we actually also want to write it,

77
00:03:17,180 --> 00:03:19,470
whilst our application is running,

78
00:03:19,470 --> 00:03:20,730
but it is temporary.

79
00:03:20,730 --> 00:03:22,230
It's okay if we lose it.

80
00:03:22,230 --> 00:03:25,390
And eventually we do want to clear it.

81
00:03:25,390 --> 00:03:27,700
But therefore, since it's read-write,

82
00:03:27,700 --> 00:03:29,520
it's stored in containers

83
00:03:29,520 --> 00:03:31,040
and not in images

84
00:03:31,040 --> 00:03:33,740
because images are read-only.

85
00:03:33,740 --> 00:03:36,400
And when I say stored in containers,

86
00:03:36,400 --> 00:03:40,330
not in images, I'm talking about this extra layer,

87
00:03:40,330 --> 00:03:44,610
which is added by Docker on top of our image,

88
00:03:44,610 --> 00:03:47,440
which then actually makes up that container.

89
00:03:47,440 --> 00:03:50,850
And this extra layer basically is a bit

90
00:03:50,850 --> 00:03:52,250
of a logic you could say,

91
00:03:52,250 --> 00:03:54,000
that is aware of the image,

92
00:03:54,000 --> 00:03:56,880
is aware of the file system of the image,

93
00:03:56,880 --> 00:03:59,570
and kind of mirrors that file system

94
00:03:59,570 --> 00:04:01,110
without copying it.

95
00:04:01,110 --> 00:04:02,960
But then that's the extra thing,

96
00:04:02,960 --> 00:04:07,960
here, Docker then actually also has read-write access,

97
00:04:08,170 --> 00:04:11,990
and is able to manipulate that file's system.

98
00:04:11,990 --> 00:04:14,120
Without changing it in the image,

99
00:04:14,120 --> 00:04:17,450
just by changing it in that extra layer.

100
00:04:17,450 --> 00:04:18,550
And behind the scenes,

101
00:04:18,550 --> 00:04:21,050
this is managed in a very efficient way,

102
00:04:21,050 --> 00:04:23,480
where Docker basically keeps track

103
00:04:23,480 --> 00:04:25,850
of the changes made by the container,

104
00:04:25,850 --> 00:04:28,840
and derives the final file system,

105
00:04:28,840 --> 00:04:31,190
by taking the file system in the image,

106
00:04:31,190 --> 00:04:33,650
and combining it with the changes stored

107
00:04:33,650 --> 00:04:35,390
in that read-write layer.

108
00:04:35,390 --> 00:04:37,230
That's how you can think about that,

109
00:04:37,230 --> 00:04:39,060
but that's also what happens behind the scenes.

110
00:04:39,060 --> 00:04:40,820
What isn't too important to us.

111
00:04:40,820 --> 00:04:42,090
But that is what I mean.

112
00:04:42,090 --> 00:04:44,490
When I say stored in the container,

113
00:04:44,490 --> 00:04:47,160
the container stores this information,

114
00:04:47,160 --> 00:04:49,188
stores files, whatever it is,

115
00:04:49,188 --> 00:04:51,580
in this read-write layer,

116
00:04:51,580 --> 00:04:54,450
or with help of that read-write layer.

117
00:04:54,450 --> 00:04:56,440
But it's all inside of the container.

118
00:04:56,440 --> 00:04:58,850
It's not on our local file system,

119
00:04:58,850 --> 00:05:00,430
on our local machine,

120
00:05:00,430 --> 00:05:02,150
and it's not in the image.

121
00:05:02,150 --> 00:05:03,393
It's in the container.

122
00:05:04,630 --> 00:05:07,610
And that's something we haven't done up to this point.

123
00:05:07,610 --> 00:05:11,060
We haven't really tried to write data

124
00:05:11,060 --> 00:05:13,280
inside of a container.

125
00:05:13,280 --> 00:05:15,763
We haven't tried to create a file there,

126
00:05:15,763 --> 00:05:19,010
and store it in the container file system.

127
00:05:19,010 --> 00:05:21,510
That's not something we did up to this point,

128
00:05:21,510 --> 00:05:25,293
but that is something we are going to do in this module.

129
00:05:26,140 --> 00:05:28,760
And, then we got a third kind of data,

130
00:05:28,760 --> 00:05:31,460
and you might be able to guess which kind of data that is.

131
00:05:31,460 --> 00:05:34,210
It's permanent application data.

132
00:05:34,210 --> 00:05:36,840
For example, if we got an application,

133
00:05:36,840 --> 00:05:38,680
where users can sign up

134
00:05:38,680 --> 00:05:40,280
and lock themselves in,

135
00:05:40,280 --> 00:05:42,980
then, we got these user accounts,

136
00:05:42,980 --> 00:05:45,550
which we wanna store in files

137
00:05:45,550 --> 00:05:48,210
or typically in a database.

138
00:05:48,210 --> 00:05:51,920
And of course that data needs to persist.

139
00:05:51,920 --> 00:05:54,200
We're fetching and producing that data

140
00:05:54,200 --> 00:05:55,500
in a running container.

141
00:05:55,500 --> 00:05:58,320
So in the application running in the container,

142
00:05:58,320 --> 00:06:01,120
but then the data, as I mentioned should be stored,

143
00:06:01,120 --> 00:06:04,140
because if the container stops and restarts,

144
00:06:04,140 --> 00:06:06,900
the data should still be there, right?

145
00:06:06,900 --> 00:06:09,353
We don't wanna lose all the user accounts,

146
00:06:09,353 --> 00:06:12,706
or any other kind of permanent data,

147
00:06:12,706 --> 00:06:15,610
our application might be generating,

148
00:06:15,610 --> 00:06:18,810
just because the container has stopped.

149
00:06:18,810 --> 00:06:21,030
After all, we might just be deploying

150
00:06:21,030 --> 00:06:23,560
a new version of our application,

151
00:06:23,560 --> 00:06:25,630
and therefore we stop the container,

152
00:06:25,630 --> 00:06:27,432
and deploy a new one.

153
00:06:27,432 --> 00:06:29,080
That's all fine.

154
00:06:29,080 --> 00:06:32,680
But our application data should not be lost because of that,

155
00:06:32,680 --> 00:06:35,340
because if it would be, that would mean

156
00:06:35,340 --> 00:06:37,420
that we're never allowed to change

157
00:06:37,420 --> 00:06:39,940
and update the code in our container.

158
00:06:39,940 --> 00:06:42,060
And that's definitely not what we want.

159
00:06:42,060 --> 00:06:44,900
So there will be data which must not be lost

160
00:06:44,900 --> 00:06:46,820
when a container shuts down.

161
00:06:46,820 --> 00:06:48,930
And for the temporary app data,

162
00:06:48,930 --> 00:06:51,100
that would be the problem.

163
00:06:51,100 --> 00:06:53,860
So permanent app data is read-write data.

164
00:06:53,860 --> 00:06:56,810
We wanna write it whilst the application is running,

165
00:06:56,810 --> 00:06:58,840
but it must be stored permanently.

166
00:06:58,840 --> 00:07:02,030
And therefore we store it in containers,

167
00:07:02,030 --> 00:07:05,320
but with help of volumes.

168
00:07:05,320 --> 00:07:08,280
And volumes are one of the key concepts

169
00:07:08,280 --> 00:07:11,910
we are going to cover in this course module.

170
00:07:11,910 --> 00:07:14,450
It's a key concept baked into Docker.

171
00:07:14,450 --> 00:07:16,660
And we're going to take a closer look at it,

172
00:07:16,660 --> 00:07:17,943
throughout this module.