0
1
00:00:00,270 --> 00:00:00,780
So
1

2
00:00:03,630 --> 00:00:05,230
we're gonna go fast.
2

3
00:00:05,240 --> 00:00:05,640
All right.
3

4
00:00:09,280 --> 00:00:11,970
And then we're going to end the show because we're past our hour.
4

5
00:00:11,970 --> 00:00:15,240
But I want to get you guys some feedback.
5

6
00:00:15,240 --> 00:00:15,480
All right.
6

7
00:00:15,810 --> 00:00:17,860
So the first one up is Jacob.
7

8
00:00:18,030 --> 00:00:23,480
And there's a whole lot documentation here and I love documentation Doctor files by the way.
8

9
00:00:23,580 --> 00:00:25,620
It's totally fine to put as much as you want.
9

10
00:00:25,620 --> 00:00:30,420
This is actually a demo file so now we're talking about compose but documentation in Doctor files or
10

11
00:00:30,420 --> 00:00:31,980
compose files either way.
11

12
00:00:31,980 --> 00:00:34,550
Always a good thing.
12

13
00:00:34,680 --> 00:00:34,920
All right.
13

14
00:00:34,920 --> 00:00:39,530
So he's using a version 3.0 7 which means it's probably for swarm or something in production like 
14

15
00:00:39,530 --> 00:00:43,680
Kubernetes using the compose on Kubernetes feature set.
15

16
00:00:43,800 --> 00:00:53,150
He's using the official elastic images from the elastic there.
16

17
00:00:54,780 --> 00:00:56,880
Let's see you've got your health check.
17

18
00:00:56,880 --> 00:00:57,690
Fantastic.
18

19
00:00:57,690 --> 00:01:00,140
You've got health checks it's great you've got configs.
19

20
00:01:00,210 --> 00:01:01,220
That's great.
20

21
00:01:01,290 --> 00:01:05,610
You're setting in on a specific network and you're doing host mode on the port.
21

22
00:01:05,640 --> 00:01:12,930
So you're giving us direct access to the Knick instead of going through the overlay networks and the
22

23
00:01:13,560 --> 00:01:14,220
routing mesh.
23

24
00:01:14,220 --> 00:01:15,300
That's good.
24

25
00:01:15,300 --> 00:01:17,420
And then let's see.
25

26
00:01:20,020 --> 00:01:21,420
We've got to deploy down here.
26

27
00:01:21,420 --> 00:01:24,750
Oh and you're doing endpoint mode DNS round robin.
27

28
00:01:24,750 --> 00:01:26,310
So kudos to you.
28

29
00:01:26,310 --> 00:01:29,320
This is something that a lot of people don't realize.
29

30
00:01:29,490 --> 00:01:37,200
But whenever you're running something in swarm and you want to disable the virtual IP that sits in front
30

31
00:01:37,200 --> 00:01:44,190
of every overlay service you want to do that for databases where you only have one node right which
31

32
00:01:44,190 --> 00:01:48,660
is a lot of times even if you're doing a mirror of a database you're usually running each one of those
32

33
00:01:48,660 --> 00:01:49,820
in their own service.
33

34
00:01:49,890 --> 00:01:56,760
And so there's one instance in a service and that that task of that instance of a container you don't
34

35
00:01:56,760 --> 00:02:01,140
usually want that virtual IP in front of it because it's now an extra hop it's another Nat translation
35

36
00:02:01,340 --> 00:02:03,250
it's more potential problems.
36

37
00:02:03,270 --> 00:02:10,230
So if you set endpoint mode DNS round robin here that effectively turns off the Veep and has direct
37

38
00:02:10,230 --> 00:02:11,460
access to that container.
38

39
00:02:11,460 --> 00:02:12,820
So kudos to you.
39

40
00:02:12,900 --> 00:02:18,300
I don't see that very often because people don't catch that one and then you're also using replicas
40

41
00:02:18,300 --> 00:02:18,820
too.
41

42
00:02:19,320 --> 00:02:25,090
And resource limits of 4G for a gig that's great.
42

43
00:02:25,140 --> 00:02:31,350
Always I recommend always setting resource limits and reservations if you can because that's going to
43

44
00:02:31,350 --> 00:02:34,920
help things all get along inside your cluster.
44

45
00:02:35,040 --> 00:02:35,330
Yeah.
45

46
00:02:35,340 --> 00:02:38,820
Looks like it's running on docker swarm suite and
46

47
00:02:40,910 --> 00:02:42,120
coordination
47

48
00:02:44,090 --> 00:02:45,110
M.
48

49
00:02:48,080 --> 00:02:48,420
All right.
49

50
00:02:48,420 --> 00:02:50,220
More more of the same.
50

51
00:02:50,490 --> 00:02:51,030
More the same.
51

52
00:02:51,030 --> 00:02:52,210
Good stuff good stuff.
52

53
00:02:52,350 --> 00:02:58,810
You're buying mounting a volume or you're not by management by Manning you're using a named volume and
53

54
00:02:59,170 --> 00:03:05,170
you've got placement constraints here so you're putting this on a node that is hardcoded to a specific
54

55
00:03:05,170 --> 00:03:08,950
name so you know you want this one to run that node only.
55

56
00:03:09,040 --> 00:03:15,130
And of course the weakness here is that that if that node goes down it won't be able to place it anywhere
56

57
00:03:15,130 --> 00:03:15,390
else.
57

58
00:03:15,400 --> 00:03:20,040
But hopefully you've taken that into consideration.
58

59
00:03:20,260 --> 00:03:20,950
All right.
59

60
00:03:20,950 --> 00:03:22,840
Master 2 so that's how you're doing this.
60

61
00:03:22,840 --> 00:03:29,110
It looks like you have master one master to hardcoded in as separate services and master three and a
61

62
00:03:29,110 --> 00:03:34,750
lot of people have to do it this way that when you have a multi no database cluster it's usually easier
62

63
00:03:34,990 --> 00:03:37,290
to put each one of these as their own service.
63

64
00:03:37,300 --> 00:03:42,550
And so you've done that and it would be nice if we could just make one service with three replicas and
64

65
00:03:42,550 --> 00:03:50,530
you can find that with some examples using the autopilot pattern if you look up auto pilot pattern Io
65

66
00:03:50,860 --> 00:03:56,650
or if you just google your database technology with the word autopilot sometimes you can find configurations
66

67
00:03:56,650 --> 00:04:00,270
and automation scripts that will help you do it all in one service.
67

68
00:04:00,340 --> 00:04:02,360
There's pros and cons to each.
68

69
00:04:02,380 --> 00:04:05,080
I personally tend to just do it the way you're doing it.
69

70
00:04:05,680 --> 00:04:10,180
I feel like it's simpler even though it's more Jamel and so a little bit more verbose.
70

71
00:04:10,180 --> 00:04:11,490
One thing you could do here.
71

72
00:04:11,620 --> 00:04:16,710
One huge improvement is if these are all all the same parts here.
72

73
00:04:16,710 --> 00:04:17,080
Right.
73

74
00:04:17,080 --> 00:04:23,710
All the same stuff you can template that shorten this file significantly by only putting that in a template
74

75
00:04:23,710 --> 00:04:24,400
block.
75

76
00:04:24,580 --> 00:04:29,490
And I talk more about that in this.
76

77
00:04:29,740 --> 00:04:33,450
This right here Jacob I'll put this in chat.
77

78
00:04:33,490 --> 00:04:38,610
This is three different advanced Docker composed features that a lot people don't use.
78

79
00:04:38,710 --> 00:04:42,310
And one of them is on templating.
79

80
00:04:42,370 --> 00:04:49,490
And so if you see the example here you can you can throw the templating right there.
80

81
00:04:49,810 --> 00:04:52,530
Basic what you're saying is this is what I want in the template.
81

82
00:04:52,540 --> 00:04:57,810
And this is where I want you to put it over and over in each image or in each service rather.
82

83
00:04:57,850 --> 00:05:02,290
And so a lot of that boilerplate stuff like you could template the whole thing or you could just template
83

84
00:05:02,290 --> 00:05:06,550
parts of them and have multiple templates and docker has documentation on that.
84

85
00:05:06,550 --> 00:05:10,890
So that would help make your file smaller and we call it dry.
85

86
00:05:10,900 --> 00:05:11,170
Right.
86

87
00:05:11,170 --> 00:05:16,030
Doing it doing things once you don't repeat yourself.
87

88
00:05:16,030 --> 00:05:16,950
These are why.
88

89
00:05:17,180 --> 00:05:18,710
And you could do that.
89

90
00:05:18,710 --> 00:05:22,730
So that would help you alleviate a lot of this repetitive stuff especially around the health checks
90

91
00:05:23,150 --> 00:05:25,940
and the deployment stuff.
91

92
00:05:25,940 --> 00:05:30,740
So then you've got your data nodes everything's looking good there you're using your health checks you've
92

93
00:05:30,740 --> 00:05:42,250
got your network set your volumes and let me go down pass some of this your hard coding stuff to each
93

94
00:05:42,250 --> 00:05:44,800
node and I and I really wish
94

95
00:05:49,140 --> 00:05:53,220
that we had a way to tell it don't run like here's a placement constraint.
95

96
00:05:53,220 --> 00:05:54,920
Run don't run it on one.
96

97
00:05:55,020 --> 00:05:57,270
That is where the other ones run.
97

98
00:05:57,300 --> 00:06:02,730
So there's some hope for you there's two things you can do here you can look at placement preferences
98

99
00:06:03,180 --> 00:06:08,340
and if you have your different nodes in availability zones and you simply want your database to make
99

100
00:06:08,340 --> 00:06:15,270
sure that it has one copy in each availability zone like an of us or something then you can add labels
100

101
00:06:15,270 --> 00:06:23,910
to each node and then you just go in here and say I would prefer you to spread these out over my label
101

102
00:06:23,940 --> 00:06:28,770
and you just give it a label and a placement preference instead of a constraint will allow it to put
102

103
00:06:28,770 --> 00:06:33,220
those on the different different servers in the different zones.
103

104
00:06:33,270 --> 00:06:40,080
But the cool thing here is if one zone or one server goes down it will still be able to reassign that
104

105
00:06:40,080 --> 00:06:41,490
somewhere else.
105

106
00:06:41,490 --> 00:06:47,520
Now the worst case here is that two of these are running on the same server but that's probably not
106

107
00:06:47,520 --> 00:06:53,220
so bad if you're able to I mean one thing might be the data getting the data from one zone over the
107

108
00:06:53,220 --> 00:06:56,080
other but once you've saw some of those problems.
108

109
00:06:56,110 --> 00:06:56,940
Yeah.
109

110
00:06:57,030 --> 00:07:01,050
Yeah you're saying so I can use constraint and allowed to lose one of the physical nodes.
110

111
00:07:01,050 --> 00:07:01,260
Yeah.
111

112
00:07:01,290 --> 00:07:07,050
So the thing is you're you're making it a little bit more brittle by assigning it to Node late host
112

113
00:07:07,050 --> 00:07:11,760
names and you have to those specific host up and ideally like if you're an eighth of U.S. or something
113

114
00:07:11,760 --> 00:07:14,460
where you can have your servers auto create.
114

115
00:07:14,460 --> 00:07:17,340
So if a server dies it all creates a new one.
115

116
00:07:17,840 --> 00:07:18,150
Yeah.
116

117
00:07:18,180 --> 00:07:22,680
So if you've accounted for all that great there's nothing wrong with placement constraints in this way.
117

118
00:07:22,680 --> 00:07:26,490
It just means that those nodes have to be there or those containers die.
118

119
00:07:26,490 --> 00:07:33,030
The other thing is there is a new feature coming in 1983 and the way you learn about these new features
119

120
00:07:33,450 --> 00:07:43,950
is if you go to Docker on github and you go to Docker C releases and I will post this in chat and you
120

121
00:07:43,950 --> 00:07:48,510
can look up new swarm features and there is a new swarm feature version version that will allow you
121

122
00:07:48,510 --> 00:07:56,130
to run replicas but tell it never run more than X of these replicas on the same node super cool feature
122

123
00:07:56,160 --> 00:08:01,590
and helps people ensure that their databases don't all get assigned the same node so you might want
123

124
00:08:01,590 --> 00:08:07,020
to check that out as a more flexible way to ensure they're not on the same note.
124

125
00:08:07,980 --> 00:08:12,910
I think if I scrolled down down the swarm.
125

126
00:08:13,510 --> 00:08:20,320
Yeah added support for maximum replicas per node So that's a new feature in the forthcoming 19 0 3 release
126

127
00:08:20,320 --> 00:08:25,750
that's already in prerelease now so we should be seeing this within the next few weeks or months and
127

128
00:08:25,750 --> 00:08:26,560
then you can check that out.
128

129
00:08:26,560 --> 00:08:29,490
That might help you with the constraints.
129

130
00:08:29,600 --> 00:08:30,170
All right.
130

131
00:08:30,360 --> 00:08:31,590
I want to move ahead a little bit.
131

132
00:08:31,590 --> 00:08:34,610
Sorry I can't review all this I moved it down at the bottom.
132

133
00:08:34,650 --> 00:08:40,430
You got your networks detachable true and proxy.
133

134
00:08:40,770 --> 00:08:41,940
All looks good there.
134

135
00:08:41,940 --> 00:08:48,150
You got volume so you're using the default volume driver so that that way that means that all of this
135

136
00:08:48,150 --> 00:08:50,220
data is stuck on the node that it's on.
136

137
00:08:50,910 --> 00:08:57,120
If you have any shared storage you might consider Rex Ray or another volume driver so that you can get
137

138
00:08:57,120 --> 00:09:01,680
that storage off that disk and that way when one of the notes fails and it wants to create that somewhere
138

139
00:09:01,680 --> 00:09:04,950
else it will reattach that database volume.
139

140
00:09:04,950 --> 00:09:05,850
On the other note.
140

141
00:09:05,920 --> 00:09:06,390
All right.
141

142
00:09:06,480 --> 00:09:14,800
So you may be aware we looked at that and you got traffic certificates so I could talk about that for
142

143
00:09:14,800 --> 00:09:19,720
a while but we're gonna run out of time so I'll I'll leave the traffic certificate stuff for another
143

144
00:09:19,720 --> 00:09:23,970
day and then you've got can figs and other files.
144

145
00:09:23,980 --> 00:09:27,750
This is great all use and all the can figs.
145

146
00:09:29,340 --> 00:09:30,390
As you should.
146

147
00:09:30,390 --> 00:09:34,800
And then I don't see secrets in here but I'm assuming at some point you need secrets and you might need
147

148
00:09:34,800 --> 00:09:42,780
to store those in secret somewhere so other than that great UML definitely one of the better ones I've
148

149
00:09:42,780 --> 00:09:43,200
seen.
149

150
00:09:43,200 --> 00:09:45,750
I think there's very little to do here.
150

151
00:09:45,750 --> 00:09:51,300
I think in terms of making it sort of using all the perfect features the templating is a thing considering
151

152
00:09:51,300 --> 00:09:56,580
different volume drivers and considering the new feature if not placement preferences the new feature
152

153
00:09:56,580 --> 00:10:19,110
for Max replicas per No.
153

154
00:10:19,120 --> 00:10:20,620
Thanks for watching.
154

155
00:10:20,620 --> 00:10:26,050
You can click SUBSCRIBE AND the notification bell to get an alert when I go live so you can join and
155

156
00:10:26,050 --> 00:10:28,110
ask your dev ops and darker questions.
156

157
00:10:28,150 --> 00:10:32,980
You can watch some of my other videos over there and you can do what I'm about to do and just go take
157

158
00:10:32,980 --> 00:10:33,460
a nap.