0
1
00:00:01,300 --> 00:00:05,770
So first up we had Charles who posted his Docker file
1

2
00:00:12,860 --> 00:00:13,610
area go
2

3
00:00:19,430 --> 00:00:23,900
and let me let me pull up the green screen so we can
3

4
00:00:34,260 --> 00:00:35,900
so let's look at this Docker file shall we.
4

5
00:00:36,800 --> 00:00:43,430
And of course the reality is here is that once you get to real world files everything gets messier.
5

6
00:00:43,430 --> 00:00:43,730
Right.
6

7
00:00:43,760 --> 00:00:49,820
We all learn in courses like the ones I have and we learn from blog articles and documentation and then
7

8
00:00:49,820 --> 00:00:52,490
once we get to the real world it always seems to be harder than that.
8

9
00:00:52,520 --> 00:00:58,220
So I'm always trying to add more of that complexity to courses but it's a lot of work to get that in
9

10
00:00:58,220 --> 00:01:00,740
the courses because you have to it's very context.
10

11
00:01:00,740 --> 00:01:04,600
It's very much about your environment and your setup and your particular app.
11

12
00:01:04,940 --> 00:01:08,630
So I thought last night Hey why don't we talk about this in the show tomorrow.
12

13
00:01:08,630 --> 00:01:11,030
So if you really like this give this a thumbs up.
13

14
00:01:11,030 --> 00:01:15,890
Tell me in chat or in the comments that you would like more of these and we'll make this a regular thing
14

15
00:01:15,900 --> 00:01:22,160
we'll actually review more Docker files and compose files and pull out some of the good gems there.
15

16
00:01:22,870 --> 00:01:23,110
All right.
16

17
00:01:23,140 --> 00:01:32,330
So first up is Charles and it looks like he's coming from his own account he's got a P HP Apache image.
17

18
00:01:32,330 --> 00:01:36,030
Based on that that name I'm going to just assume that that's what that is.
18

19
00:01:36,260 --> 00:01:40,850
And it's got a date and it knows it's got a version and a date in the name there.
19

20
00:01:40,850 --> 00:01:47,210
So that's pretty common as you start to get to your own custom from images you'll start to do things
20

21
00:01:47,210 --> 00:01:51,790
like version them or date them or use commit ideas in them.
21

22
00:01:51,800 --> 00:01:56,470
And that's a way to guarantee that you're using the exact same image right.
22

23
00:01:56,480 --> 00:02:01,250
Again here you don't only use latest in any real production setup you can always use latest for playing
23

24
00:02:01,250 --> 00:02:02,150
around and testing.
24

25
00:02:02,150 --> 00:02:08,120
But when you go to real stuff you're always going to want to use those real versions.
25

26
00:02:08,290 --> 00:02:10,220
Well that's Azure HP image Charles says.
26

27
00:02:10,240 --> 00:02:11,810
OK cool.
27

28
00:02:12,010 --> 00:02:15,640
And then he's got here an interesting set up that I've not seen before and I think I know why you're
28

29
00:02:15,640 --> 00:02:16,510
doing it.
29

30
00:02:16,540 --> 00:02:22,720
So in this run line here you're doing an app to get update and then you're saying if that doesn't you're
30

31
00:02:22,990 --> 00:02:27,270
giving an OR in bash which means if this doesn't succeed do this.
31

32
00:02:27,280 --> 00:02:28,450
And so you're repeating it.
32

33
00:02:28,480 --> 00:02:34,900
So I'm guessing that may be either you're on a network or someplace where you potentially have a it's
33

34
00:02:34,900 --> 00:02:40,210
a common issue to have to get update problems or maybe you've had some quirks in the past where it's
34

35
00:02:40,210 --> 00:02:43,630
randomly failed and if you just did it a second time it would work.
35

36
00:02:43,630 --> 00:02:45,810
That's what I'm guessing you're doing there.
36

37
00:02:46,870 --> 00:02:50,620
And it's an effective solution to that problem if that's what it that's that's that's what it's for.
37

38
00:02:50,620 --> 00:02:58,040
Otherwise I don't normally see this kind of setup this normally is not what I would see there.
38

39
00:02:58,040 --> 00:02:58,240
All right.
39

40
00:02:58,250 --> 00:03:04,130
Next up you export and which is just a tiny little metadata change.
40

41
00:03:04,130 --> 00:03:08,110
So it's not going to take much Oh look at that Charles says at
41

42
00:03:10,920 --> 00:03:14,670
yeah he says it's a as happy HP image.
42

43
00:03:14,670 --> 00:03:17,870
And he spoke to mucks up Azure support and it fixes a bug.
43

44
00:03:17,910 --> 00:03:19,380
So very cool
44

45
00:03:24,770 --> 00:03:26,090
I'm going to change that
45

46
00:03:30,050 --> 00:03:30,560
see
46

47
00:03:33,510 --> 00:03:34,350
let's do this
47

48
00:03:37,400 --> 00:03:39,910
changing the fonts here so it looks a little easier
48

49
00:03:47,750 --> 00:03:47,970
yeah.
49

50
00:03:48,030 --> 00:03:55,150
A look better.
50

51
00:04:00,670 --> 00:04:01,010
Yeah.
51

52
00:04:01,060 --> 00:04:01,260
All right.
52

53
00:04:05,420 --> 00:04:06,800
So here's an interesting thing.
53

54
00:04:06,800 --> 00:04:12,730
So you're download so you're doing some downloads and you're installing a package which is normal.
54

55
00:04:12,950 --> 00:04:17,390
And you're also doing a bunch of APP get installs here.
55

56
00:04:17,390 --> 00:04:23,060
So unless this is something you're testing and you're just trying to figure out how this workflow works
56

57
00:04:23,420 --> 00:04:28,550
there's lots of opportunity for for optimization especially when it comes to size.
57

58
00:04:28,670 --> 00:04:32,360
And you also have a situation here we can get yourself in a little bit of trouble.
58

59
00:04:32,930 --> 00:04:39,410
So notice up here that we have a separate run line that's doing the app to get update.
59

60
00:04:39,980 --> 00:04:45,030
So you don't have that line down here where you're doing all the install.
60

61
00:04:45,040 --> 00:04:47,060
So you've broken these all these steps out.
61

62
00:04:47,200 --> 00:04:50,710
Now if you start going and look at it official images you will notice that they never do this.
62

63
00:04:50,710 --> 00:04:56,190
They always put it all in one huge run line and there's a couple of reasons for that.
63

64
00:04:56,260 --> 00:04:58,870
The biggest reason here is cash busting.
64

65
00:04:58,870 --> 00:05:03,100
So when you think about when you build an image there's a cash behind it.
65

66
00:05:03,100 --> 00:05:08,470
Now if you're using something like Jenkins or a CCD runner and you have disabled caching where it's
66

67
00:05:08,530 --> 00:05:16,600
always going to build every time from scratch without without caching then this may not be that issue
67

68
00:05:16,660 --> 00:05:20,710
that kind of issue but it will certainly be an issue if you build locally or you build on any system
68

69
00:05:20,890 --> 00:05:22,570
more than once.
69

70
00:05:22,570 --> 00:05:27,690
And this is what's going to happen the the run line.
70

71
00:05:27,760 --> 00:05:28,920
Let's say it's there.
71

72
00:05:28,940 --> 00:05:29,190
OK.
72

73
00:05:29,200 --> 00:05:30,430
And it never changes.
73

74
00:05:30,430 --> 00:05:30,760
Right.
74

75
00:05:30,760 --> 00:05:33,790
So the first time you build this image everything's fine.
75

76
00:05:33,790 --> 00:05:35,750
Let's say you build three days later.
76

77
00:05:35,890 --> 00:05:40,390
It's not going to cache this line because this line didn't change remember and on the on the standard
77

78
00:05:40,420 --> 00:05:44,730
docker build command cache busting is when you've changed a line.
78

79
00:05:44,740 --> 00:05:49,270
And when you change that line everything in that line is rerun and every line after it.
79

80
00:05:50,020 --> 00:05:55,810
And what happens here is if you have this run line up here and it never changes but then you add let's
80

81
00:05:55,810 --> 00:06:01,450
say another package down here in the run line or maybe you change the versions and you hard code your
81

82
00:06:01,450 --> 00:06:06,250
versions which you should also be doing you should hard code the versions of all these tools and maybe
82

83
00:06:06,250 --> 00:06:08,690
not zip and unzip and curl.
83

84
00:06:08,770 --> 00:06:14,740
But if your security team is strict they will expect you to have reliable versions and that's another
84

85
00:06:14,740 --> 00:06:16,200
thing you would want to do here.
85

86
00:06:16,300 --> 00:06:17,670
But let's get back to this point.
86

87
00:06:17,710 --> 00:06:21,790
So if you're going to do these installs and you change a tool and add it here.
87

88
00:06:21,790 --> 00:06:27,700
Think about that and get update that had to get update downloads a cache of all of the metadata about
88

89
00:06:27,700 --> 00:06:32,200
all these packages and then you're going to install these packages later and if the second line here
89

90
00:06:32,230 --> 00:06:35,340
gets busted by changing it's going to rerun.
90

91
00:06:35,350 --> 00:06:41,130
But it's going to be running based on that old cache of your app to get update.
91

92
00:06:41,680 --> 00:06:47,920
So you over time will start to experience problems because your packages will always be installing those
92

93
00:06:47,980 --> 00:06:54,480
old versions a much better way to do this is to take all your app to get stuff right.
93

94
00:06:54,520 --> 00:06:58,060
And that's not necessarily related to downloading this package here.
94

95
00:06:58,060 --> 00:06:59,500
This is a custom package.
95

96
00:06:59,500 --> 00:07:01,100
We'll talk about that a minute.
96

97
00:07:01,600 --> 00:07:08,260
But when it comes to these lines right here this line is going to have no effect on size because this
97

98
00:07:08,260 --> 00:07:15,970
line has to run in the same line as this one or it's not going to work.
98

99
00:07:16,000 --> 00:07:20,140
Now this is all maybe not true.
99

100
00:07:20,150 --> 00:07:25,940
If you have another Okay so you're not doing multi-stage.
100

101
00:07:26,180 --> 00:07:30,140
One way to get away with the size problem is do you do multi-state but you're not doing what the state
101

102
00:07:30,200 --> 00:07:30,740
and that's OK.
102

103
00:07:30,770 --> 00:07:31,880
You don't have to do a multi-stage
103

104
00:07:36,690 --> 00:07:38,250
so let's see
104

105
00:07:42,200 --> 00:07:46,400
so what's gonna happen here is that you would recommend taking these right here taking all this right
105

106
00:07:46,400 --> 00:07:48,730
here bumping it all up to this line.
106

107
00:07:49,130 --> 00:07:55,700
I would take this export line and put it above so I would I would just put it up here so that way it's
107

108
00:07:55,850 --> 00:07:56,330
set.
108

109
00:07:56,330 --> 00:07:57,590
And it never needs to change.
109

110
00:07:57,590 --> 00:08:01,160
And you don't have to worry about it in the middle of all you're out to get stuff right.
110

111
00:08:01,190 --> 00:08:07,340
And in general it's good that you're having all your at get stuff near the top because you want those
111

112
00:08:07,340 --> 00:08:10,940
dependencies which usually take a long time to install you want them to be high up as possible so you
112

113
00:08:10,940 --> 00:08:12,460
don't have to rerun them very often.
113

114
00:08:12,590 --> 00:08:15,770
But I'm what I'm going to recommend that you take all this stuff right here
114

115
00:08:18,230 --> 00:08:29,040
and put it up here now you can do this next because this is a manual package download and install.
115

116
00:08:29,070 --> 00:08:31,200
So when you do this
116

117
00:08:33,870 --> 00:08:36,670
there's a couple of things you can do.
117

118
00:08:36,670 --> 00:08:38,500
One is this.
118

119
00:08:38,500 --> 00:08:45,130
This line right here is going to be a layer and that layer is always going to include the db file even
119

120
00:08:45,130 --> 00:08:45,880
if you don't need it.
120

121
00:08:46,210 --> 00:08:49,930
So when you clean up later it's not cleaning up these previous layers.
121

122
00:08:49,930 --> 00:08:55,360
That's one of the problems here is that it's a file that's downloaded into a layer and then you go to
122

123
00:08:55,360 --> 00:08:59,950
the next line which is a or the next Docker command I should say the next Docker command will be a new
123

124
00:08:59,950 --> 00:09:00,510
layer.
124

125
00:09:00,640 --> 00:09:07,060
Think of that as a separate it's up once you stopped a line or a docker command.
125

126
00:09:07,060 --> 00:09:09,430
You can not change that you can't go back in time and change that.
126

127
00:09:09,430 --> 00:09:13,510
So the next line or command and docker file will just add stuff to it.
127

128
00:09:13,510 --> 00:09:17,200
Now if it deletes files it's just going to delete them in that layer.
128

129
00:09:17,210 --> 00:09:23,350
It essentially put some metadata that says hey that file should no longer exist or look like it exists
129

130
00:09:23,560 --> 00:09:27,700
but those files are still going to exist and those read only layers because every layer above it is
130

131
00:09:27,700 --> 00:09:33,670
now read only and that's the way that these layers guarantee that they're identical to what you expect.
131

132
00:09:33,670 --> 00:09:35,940
So no layer can go back in time.
132

133
00:09:36,100 --> 00:09:48,150
So that's what you need to do is go check out some of the docker default images and so let's do this
133

134
00:09:48,150 --> 00:09:50,280
actually go look at one of mine because it'll be a little more
134

135
00:09:55,220 --> 00:09:57,410
it might be a little easier to understand.
135

136
00:09:57,440 --> 00:09:58,160
So
136

137
00:10:11,690 --> 00:10:12,350
yeah I'm not sure.
137

138
00:10:12,380 --> 00:10:12,650
OK.
138

139
00:10:12,680 --> 00:10:20,240
So Docker file yes there's an AP Kay but you'll notice here how it's all in one line that's kind of
139

140
00:10:20,240 --> 00:10:25,470
a bad example but let's do a hub and let's go look at Ghost.
140

141
00:10:25,470 --> 00:10:25,720
So
141

142
00:10:29,980 --> 00:10:32,280
look at this Debian Docker file.
142

143
00:10:33,270 --> 00:10:34,540
All right here we go.
143

144
00:10:34,540 --> 00:10:41,890
So you'll notice that in this situation it's downloading some stuff it's dealing with that stuff and
144

145
00:10:41,890 --> 00:10:45,460
then it's getting rid of that stuff all in one run line.
145

146
00:10:45,610 --> 00:10:49,110
So that way those files never stick around.
146

147
00:10:49,120 --> 00:10:53,080
Once that layer is sealed and marked read only.
147

148
00:10:53,080 --> 00:10:55,090
And that's pretty key to keeping your images small.
148

149
00:10:55,090 --> 00:11:00,940
I bet once you make this stuff of efficient and combine this stuff together that you'll you'll be saving
149

150
00:11:00,940 --> 00:11:02,910
hundreds of megs and your image size.
150

151
00:11:02,940 --> 00:11:10,460
All right and the other thing here on this one is I would also add that to one single line and another
151

152
00:11:10,460 --> 00:11:17,270
thing I would do there is you maybe don't need w get you maybe can do an ad an ad will automatically
152

153
00:11:17,300 --> 00:11:18,700
download a file from the Internet.
153

154
00:11:19,250 --> 00:11:25,070
And if you're very curious about the difference in copy and ad really nowadays our standard is copy
154

155
00:11:25,070 --> 00:11:29,780
is really only for copying files out of the repo that you're in right.
155

156
00:11:29,780 --> 00:11:36,500
So just copy files and ad does the same thing but we tend to only want to use ad when we're either downloading
156

157
00:11:36,500 --> 00:11:44,180
something from the Internet or whatever we're copying and we want it to unzip or UN tar and that that's
157

158
00:11:44,180 --> 00:11:45,430
really going to reason to use ad.
158

159
00:11:45,440 --> 00:11:51,080
But the nice benefit of using ad there is you wouldn't need to do w w get you could use basically doctors
159

160
00:11:51,080 --> 00:11:57,610
internals we'll go get that file and download it the negative of that though is that when you do that
160

161
00:11:57,610 --> 00:11:59,440
line and then you go to the next line.
161

162
00:11:59,620 --> 00:12:01,750
That package will still exist.
162

163
00:12:01,780 --> 00:12:07,020
So even though ads really cool there in your case because you're downloading a package that you're good
163

164
00:12:07,020 --> 00:12:10,600
they're going to install and then you don't need that package in that anymore.
164

165
00:12:10,630 --> 00:12:16,000
I would maybe just put all three of those lines into one line that way at the very end you can actually
165

166
00:12:16,000 --> 00:12:20,650
delete that dot D.B. file and save additional space in your final event.
166

167
00:12:20,670 --> 00:12:22,690
So you would do all of that in one run.
167

168
00:12:22,690 --> 00:12:23,550
All right.
168

169
00:12:23,590 --> 00:12:24,670
That helps.
169

170
00:12:24,670 --> 00:12:30,180
So looks like you're copying in some other files great that you're using copy not add.
170

171
00:12:31,390 --> 00:12:35,530
You're also doing some makers and copying and certificates.
171

172
00:12:35,530 --> 00:12:38,570
That's exactly how I would do it.
172

173
00:12:39,040 --> 00:12:43,810
You might to make this more optimized you might put
173

174
00:12:46,540 --> 00:12:52,830
all of these into a single run command usually because the basically it's a little bit faster to build
174

175
00:12:52,830 --> 00:12:57,910
it will give you maybe a second faster in your bill because every single one these lines it has to stop
175

176
00:12:57,910 --> 00:13:03,730
the container or create a new container mount the rest of the image and run that command then save that
176

177
00:13:03,730 --> 00:13:06,060
to a new container image and then start a new container.
177

178
00:13:06,070 --> 00:13:06,280
Right.
178

179
00:13:06,280 --> 00:13:09,720
So it's got to do a lot more work than just run three quick commands.
179

180
00:13:09,910 --> 00:13:11,850
So I might just have those in one.
180

181
00:13:11,920 --> 00:13:17,230
There's no safe space savings or anything there but it's just a matter of three commands really would
181

182
00:13:17,230 --> 00:13:23,890
turn into one long shell command their and yeah all right yeah.
182

183
00:13:23,910 --> 00:13:24,630
We've got the gates.
183

184
00:13:24,640 --> 00:13:31,120
I would probably do the same thing make those one just for efficiency by the way.
184

185
00:13:31,120 --> 00:13:35,850
So right here you're copying in two different copy lines you can make that one line.
185

186
00:13:35,860 --> 00:13:41,950
You could actually say copy and then the path to the CRT and then the path to that got to that key.
186

187
00:13:42,030 --> 00:13:49,800
Kay Kay you why and have those two files and then put in the path to the SSL directory.
187

188
00:13:49,810 --> 00:13:54,460
So as long as they're both going to the same directory you can have multiple files in the single copy
188

189
00:13:54,460 --> 00:13:57,960
line that'll help you make it a little easier.
189

190
00:13:57,970 --> 00:14:02,060
Fewer lines it tends to be better as long as they're not too complicated.
190

191
00:14:02,510 --> 00:14:02,850
Yeah.
191

192
00:14:02,860 --> 00:14:09,550
You've got some standard Apache stuff there on configurations you might also.
192

193
00:14:09,790 --> 00:14:10,690
I don't know how much.
193

194
00:14:11,170 --> 00:14:11,320
Yeah.
194

195
00:14:11,450 --> 00:14:13,610
These are these are actually these are good.
195

196
00:14:13,610 --> 00:14:14,120
I think those are good
196

197
00:14:17,290 --> 00:14:23,590
yeah do it some more copying of config files in some of these you also might consider that these are
197

198
00:14:23,590 --> 00:14:27,820
standard config files but if you need to overwrite these and you're using an orchestrator whether using
198

199
00:14:27,820 --> 00:14:33,430
Cuban or swarm realize that you can use that config or in communities called config map you can use
199

200
00:14:33,430 --> 00:14:38,950
the config feature and swarm to mount these files in at runtime so that way you're not hard coding any
200

201
00:14:38,980 --> 00:14:40,420
configurations.
201

202
00:14:40,420 --> 00:14:46,390
Ideally you're not hard coding SSL is into your image either really if you're you have custom SSL as
202

203
00:14:46,660 --> 00:14:52,540
you want to store that in your orchestrator or in Docker and mount those and when you run because ideally
203

204
00:14:52,540 --> 00:14:56,170
there shouldn't be anything secret in an image when you save it.
204

205
00:14:56,200 --> 00:15:03,500
So hopefully you're going to be doing that same thing here as you could combine these two into one line
205

206
00:15:04,190 --> 00:15:10,550
you could combine some of these into one line you could probably you know if this is all the x small
206

207
00:15:10,540 --> 00:15:16,180
files that directory you could copy the directory asterisk dot X amount and then you could copy all
207

208
00:15:16,180 --> 00:15:21,610
four into there it's pros and cons to that because then if an X extra excel file shows up it might accidentally
208

209
00:15:21,610 --> 00:15:28,990
get copied in but it just depends on how verbose you want to be and how whether you want literal line
209

210
00:15:28,990 --> 00:15:34,770
for lines kind of stuff versus keeping the darker file small and simple.
210

211
00:15:34,800 --> 00:15:35,070
All right.
211

212
00:15:35,190 --> 00:15:40,440
And then you got another copy run your change in the working directory and then you've got your entry
212

213
00:15:40,440 --> 00:15:41,350
point.
213

214
00:15:41,390 --> 00:15:45,020
Now typically so you don't have a CRM D.
214

215
00:15:45,030 --> 00:15:52,500
So my guess is you are using the CRM D from this root image and that's totally fine.
215

216
00:15:52,500 --> 00:15:53,960
There's nothing real wrong with that.
216

217
00:15:54,060 --> 00:16:01,290
One of the challenges I have with that though is that people who are using my images if I have a team
217

218
00:16:01,290 --> 00:16:04,410
of people they won't know how to go get to see them D.
218

219
00:16:04,980 --> 00:16:11,730
So I tend to just repeat the CMT even though it's unnecessary down here at the bottom because they're
219

220
00:16:11,730 --> 00:16:16,710
gonna get this and sort of a repo and they're gonna look at it and if they're not super savvy on Docker
220

221
00:16:16,980 --> 00:16:19,710
they're not going to realize Oh I need to go find that Docker file for the.
221

222
00:16:19,740 --> 00:16:25,320
From that it's coming from or use the history and go back and look at the history and time to find that
222

223
00:16:25,320 --> 00:16:25,880
CMT.
223

224
00:16:25,910 --> 00:16:31,830
So you could even maybe throw it into just a comment to help people that are maybe looking at this Docker
224

225
00:16:31,830 --> 00:16:37,650
file but I tend to find that because the entry point in the CMT are just so important to what does this
225

226
00:16:37,740 --> 00:16:44,250
Docker image do that I tend to add those n even though it might be repetitive to a previous image.
226

227
00:16:44,250 --> 00:16:50,610
Again all that's just metadata so it doesn't really add any real time or bloat to your build rather
227

228
00:16:50,610 --> 00:16:52,890
than the other file changes and the run commands you do.
228

229
00:16:52,890 --> 00:16:57,810
But other than that it looks like a great nice quality production Docker file that you have spent a
229

230
00:16:57,810 --> 00:17:02,700
lot of time on but I think definitely overall you could combine a lot of those and get stuff to save
230

231
00:17:02,700 --> 00:17:09,540
a lot of space in your image and a lot of bloat and also avoid the update issue of having an old update
231

232
00:17:09,870 --> 00:17:14,220
that basically an old app to get cash when you try to install new stuff.
232

233
00:17:14,220 --> 00:17:18,660
I would recommend you version these and you can basically inside this install command you can specify
233

234
00:17:18,660 --> 00:17:23,130
the version of each maybe some of these tools it doesn't really matter but when you start getting down
234

235
00:17:23,130 --> 00:17:24,660
to libraries that you need for.
235

236
00:17:24,990 --> 00:17:30,180
For Apache for your actual app these are just so more utilities for managing it not really stuff that
236

237
00:17:30,180 --> 00:17:32,370
you would use on a production running app.
237

238
00:17:32,370 --> 00:17:32,640
Right.
238

239
00:17:33,240 --> 00:17:39,780
But this live Apache down here I would definitely version that I have been bit by this bug and HP because
239

240
00:17:40,260 --> 00:17:49,110
a mongo D.B. driver and HP changed versions inside of my image and it broke it had a bug and it broke
240

241
00:17:49,110 --> 00:17:55,320
my production apps because I didn't pin it in the docker file and I basically went to production I just
241

242
00:17:55,500 --> 00:18:01,470
one day I rebuilt the image it went it worked fine on my machine because my machine had a different
242

243
00:18:01,470 --> 00:18:05,220
version because there is no it says there's no versions there you're basically getting whatever the
243

244
00:18:05,220 --> 00:18:10,590
newest version is when you built the image so it's kind of a random hope that you get a good version
244

245
00:18:10,590 --> 00:18:11,130
that works.
245

246
00:18:11,190 --> 00:18:16,560
So you definitely get a pin that one I personally would pin them all and just update on once a month
246

247
00:18:16,560 --> 00:18:18,950
or something or whatever your security team requires.
247

248
00:18:18,960 --> 00:18:21,240
But that's a great Docker file.
248

249
00:18:21,240 --> 00:18:23,490
Thank you so much.
249

250
00:18:23,520 --> 00:18:28,040
Of course there's always room for improvement and I'm glad you showed up to help with that.