1
00:00:24,900 --> 00:00:29,920
VAMSEE KANAKALA: Hello everyone. Very good
afternoon.

2
00:00:29,920 --> 00:00:32,880
I really enjoyed the lightning talks, thanks

3
00:00:32,880 --> 00:00:37,800
everyone. And I hope you guys are slightly
awake.

4
00:00:37,800 --> 00:00:41,960
So, this is slightly off the center topic,
so,

5
00:00:41,960 --> 00:00:45,220
this is more about dev-ops rather than Ruby
or

6
00:00:45,220 --> 00:00:46,620
Rails, per se. So I'd like to know who

7
00:00:46,620 --> 00:00:51,620
all are already familiar with Docker, have
tried out

8
00:00:51,620 --> 00:00:55,370
or just know what it does and stuff like

9
00:00:55,370 --> 00:01:02,370
that. OK, not too many. Sorry about that.
So

10
00:01:02,909 --> 00:01:05,760
I've been a web developer for eight, for quite

11
00:01:05,760 --> 00:01:08,229
some time. And a good part of it is

12
00:01:08,229 --> 00:01:12,000
Rails. Actually the, I actually remember the
days when

13
00:01:12,000 --> 00:01:16,479
the fifteen minute video came out. So all
through

14
00:01:16,479 --> 00:01:19,070
these years I have also kind of ended up

15
00:01:19,070 --> 00:01:21,049
setting up servers for the Ruby teams that
I

16
00:01:21,049 --> 00:01:25,619
worked with, and have been the Linux guy for

17
00:01:25,619 --> 00:01:27,540
as long as I can remember, as in the

18
00:01:27,540 --> 00:01:32,930
professional life of mine. And so I thought,
so

19
00:01:32,930 --> 00:01:37,540
lately I've been observing what's happening
on the production

20
00:01:37,540 --> 00:01:40,490
side of things, so I guess a bunch of

21
00:01:40,490 --> 00:01:43,050
you- so how many of you have set up

22
00:01:43,050 --> 00:01:48,040
your own Rails servers, maintained them? Oh,
quite a

23
00:01:48,040 --> 00:01:50,210
few. OK. Then, this should be relevent to
what

24
00:01:50,210 --> 00:01:53,210
you're doing. So the point of, so we're gonna

25
00:01:53,210 --> 00:01:56,870
talk about zero downtime deployments with
Docker. So the

26
00:01:56,870 --> 00:02:01,560
point of this is, so what is Docker? So

27
00:02:01,560 --> 00:02:03,909
the first thing that Docker does is it basically

28
00:02:03,909 --> 00:02:09,739
commoditizes LXC. LXC is Linux Containers.
So the containers,

29
00:02:09,739 --> 00:02:14,230
you can think of them as something like chroot

30
00:02:14,230 --> 00:02:17,280
jail, change root jail, you have in Linux.
So

31
00:02:17,280 --> 00:02:19,790
what it, what it basically does is it gives

32
00:02:19,790 --> 00:02:22,060
you a separate folder as a root, and you

33
00:02:22,060 --> 00:02:25,620
can run off your processes from there, and
all

34
00:02:25,620 --> 00:02:28,900
the children are only allowed to access that
part

35
00:02:28,900 --> 00:02:33,269
of the directory, as a root directory. A container

36
00:02:33,269 --> 00:02:38,439
extends this concept by giving you isolation
on the

37
00:02:38,439 --> 00:02:40,989
memory level, it gives you isolation on network
level,

38
00:02:40,989 --> 00:02:44,260
it gives you isolation on hard disk level.
So

39
00:02:44,260 --> 00:02:51,260
LXC is a fairly old technology in Linux, but

40
00:02:51,340 --> 00:02:54,599
it has been mostly in the realm of people

41
00:02:54,599 --> 00:02:58,469
who understand Linux pretty well, or sysadmins
who are

42
00:02:58,469 --> 00:03:01,549
trying to achieve something on the production
side. So

43
00:03:01,549 --> 00:03:06,620
Docker basically makes this accessible to
all of us.

44
00:03:06,620 --> 00:03:12,159
So it makes portable deployments across machines
possible, so

45
00:03:12,159 --> 00:03:16,870
you can basically have, you have, I have,
suppose

46
00:03:16,870 --> 00:03:21,239
a vagrant box, which runs Erlang?? [00:03:19]
install, but

47
00:03:21,239 --> 00:03:25,510
you can also, you can actually run production
systems,

48
00:03:25,510 --> 00:03:29,150
production installs of, out of, say at 12
point

49
00:03:29,150 --> 00:03:33,409
0 precise. So you get a lot of flexibility

50
00:03:33,409 --> 00:03:38,950
of moving your production images around. So
there is

51
00:03:38,950 --> 00:03:43,430
efficient and quick provisioning, so it saves
on a

52
00:03:43,430 --> 00:03:46,549
disk, how much disk it uses, by doing copy-on-write

53
00:03:46,549 --> 00:03:51,199
installs. I'll talk about it a little bit
later.

54
00:03:51,199 --> 00:03:57,059
There's, it's near-native performance, it's
basically process virtualization. So

55
00:03:57,059 --> 00:04:00,659
you're not, you're not doing hardware virtualization,
or, you're

56
00:04:00,659 --> 00:04:04,189
not trying to support different OSs and stuff
like

57
00:04:04,189 --> 00:04:08,169
that, so the way you, the speed at which

58
00:04:08,169 --> 00:04:11,340
your Docker instant boots up is very quick.
So

59
00:04:11,340 --> 00:04:15,739
you almost have no overhead at all. It also

60
00:04:15,739 --> 00:04:20,339
has Git-like versioning of images. So you
have basically

61
00:04:20,339 --> 00:04:23,460
a base image, which is Ubuntu, and you can

62
00:04:23,460 --> 00:04:26,949
install something like emacs on it and you
can

63
00:04:26,949 --> 00:04:29,440
commit it and it'll save it and it'll make

64
00:04:29,440 --> 00:04:32,590
it into another image. Which'll also - I'll
show

65
00:04:32,590 --> 00:04:34,850
you a little bit more about that. So that

66
00:04:34,850 --> 00:04:39,240
enables a lot of reuse. So you can basically

67
00:04:39,240 --> 00:04:43,280
push these images to a public depository that
Docker

68
00:04:43,280 --> 00:04:46,800
maintains, index dot docker dot IO, so if
they're

69
00:04:46,800 --> 00:04:50,440
public, if they're open for sharing, so you
can

70
00:04:50,440 --> 00:04:53,139
push them out there and people can use your

71
00:04:53,139 --> 00:04:58,650
own configuration how you, however you configured
your image.

72
00:04:58,650 --> 00:05:03,409
And the major difference between how LXC operates,
or

73
00:05:03,409 --> 00:05:07,090
how LXC is talked about and how Docker encourages

74
00:05:07,090 --> 00:05:11,610
you to think about containers is that, so
LXC

75
00:05:11,610 --> 00:05:17,310
was initially thought of as, you know, lightweight
servers,

76
00:05:17,310 --> 00:05:19,960
which, where you install basically everything
and put them

77
00:05:19,960 --> 00:05:22,500
up and treat them as, just like any other

78
00:05:22,500 --> 00:05:25,759
server. Docker kind of encourages you to look
at

79
00:05:25,759 --> 00:05:30,139
containers as an application. So you install,
say your

80
00:05:30,139 --> 00:05:33,419
database mask in one container, you install
your app

81
00:05:33,419 --> 00:05:38,110
server as another container, you install your,
your RDB,

82
00:05:38,110 --> 00:05:45,110
you know, so, in another container. So, what
is

83
00:05:46,120 --> 00:05:49,310
LXC? I actually wanted to take out this slide,

84
00:05:49,310 --> 00:05:54,580
probably it's a little too advanced for this
talk.

85
00:05:54,580 --> 00:05:57,479
But let - I'll try to cover this quickly.

86
00:05:57,479 --> 00:06:01,680
So at the basic level, it provides OS-level
virtualization

87
00:06:01,680 --> 00:06:06,210
for Linux. So compared to, say, what virtual
box

88
00:06:06,210 --> 00:06:09,699
does for you, or KVM, or Zen, so these

89
00:06:09,699 --> 00:06:14,520
are all hardware virtualization, so OS-level
virtualization - much

90
00:06:14,520 --> 00:06:20,139
faster, much lightweight. Perfect for production
deployment, so. It

91
00:06:20,139 --> 00:06:24,900
basically does this. So LXC basically provides
you one

92
00:06:24,900 --> 00:06:29,439
process space, one network interface, and
your own init

93
00:06:29,439 --> 00:06:32,900
framework. So your, you can be running on
Ubuntu,

94
00:06:32,900 --> 00:06:37,560
which uses Upstart as- and your container
can use

95
00:06:37,560 --> 00:06:41,159
systemD. That's not a problem at all. So the

96
00:06:41,159 --> 00:06:44,389
basic isolation is achieved with cgroups.
Cgroups are control

97
00:06:44,389 --> 00:06:49,509
groups. So what cgroups gives you is that
it

98
00:06:49,509 --> 00:06:53,270
lets you put limits on the resource usage,
basically.

99
00:06:53,270 --> 00:06:56,500
Whether it's network or off your disk or your

100
00:06:56,500 --> 00:07:01,979
process usage, so cgroups gives you this nice
little

101
00:07:01,979 --> 00:07:04,449
interface where you can do - this is definitely

102
00:07:04,449 --> 00:07:06,280
the Linux geek- do not worry, you don't have

103
00:07:06,280 --> 00:07:09,469
to worry about that. So the only catch is

104
00:07:09,469 --> 00:07:12,560
that it shares the kernel with the host, so

105
00:07:12,560 --> 00:07:16,069
you can do stuff like having an x64 image

106
00:07:16,069 --> 00:07:20,310
and put it on i36 or vice versa. So

107
00:07:20,310 --> 00:07:23,319
that's pretty much the only catch here and
it's

108
00:07:23,319 --> 00:07:26,349
probably not very, not much of a catch at

109
00:07:26,349 --> 00:07:29,030
all. So a typical docker image kind of looks

110
00:07:29,030 --> 00:07:32,009
like this. At the most basic level you will

111
00:07:32,009 --> 00:07:35,539
see the kernel, and you have cgroups, you
have

112
00:07:35,539 --> 00:07:41,919
name spaces and device mapper. So Docker kind
of

113
00:07:41,919 --> 00:07:45,909
achieves this git-like portioning through,
through a unioning file

114
00:07:45,909 --> 00:07:52,490
system. Right now, debian-based installs use,
a UFS, which

115
00:07:52,490 --> 00:07:55,249
is quite popular, but it has some limitations,
which

116
00:07:55,249 --> 00:08:00,180
is, it's integrated into a debian kernel,
a debian-based

117
00:08:00,180 --> 00:08:03,930
distros kernels, but it's not really available
in others,

118
00:08:03,930 --> 00:08:06,469
like Santos and dev-hats ?? of the world.
[00:08:06]

119
00:08:06,469 --> 00:08:11,110
So recently they have switched, created a
storage IO

120
00:08:11,110 --> 00:08:13,729
which kind of lets you swap out AUFS with

121
00:08:13,729 --> 00:08:17,449
the device-mapper, and has plans for integrating
RFS and

122
00:08:17,449 --> 00:08:22,009
BTRFS and stuff like that. So beyond that,
you

123
00:08:22,009 --> 00:08:24,379
see the base image, which is shipped out of

124
00:08:24,379 --> 00:08:29,150
docker registry, and you also have images.
So I

125
00:08:29,150 --> 00:08:33,240
installed emacs and, committed, it becomes
a read-only- so

126
00:08:33,240 --> 00:08:37,669
bootSF is basically read-only, and once you
boot up

127
00:08:37,669 --> 00:08:41,529
that container you'll get a writable part.
So once

128
00:08:41,529 --> 00:08:45,650
you commit it, it'll become, again, read-only.
We'll go

129
00:08:45,650 --> 00:08:49,340
through that. Workflow class- So the basic
workflow, I

130
00:08:49,340 --> 00:08:52,630
will do it now again, so you basically pull

131
00:08:52,630 --> 00:08:56,340
docker images from the public registry and
you run

132
00:08:56,340 --> 00:08:59,420
it on your host, and you add your own

133
00:08:59,420 --> 00:09:01,480
changes on top of it, push it back to

134
00:09:01,480 --> 00:09:04,190
share them, or you could also build it from

135
00:09:04,190 --> 00:09:09,000
the ground up using debootstrap and tools
like that.

136
00:09:09,000 --> 00:09:10,830
So you also have a docker file which lets

137
00:09:10,830 --> 00:09:15,520
you build your own images. Apart from that,
you

138
00:09:15,520 --> 00:09:18,960
can set up a private regist- repor- registry
-

139
00:09:18,960 --> 00:09:22,810
sorry. So the idea of private registry is
that

140
00:09:22,810 --> 00:09:24,460
you have your own work groups and you want

141
00:09:24,460 --> 00:09:27,350
to share these images within your company
and they're

142
00:09:27,350 --> 00:09:31,630
not really useful for the public usage. So
this

143
00:09:31,630 --> 00:09:34,510
is a very public registry, private registry
comes in

144
00:09:34,510 --> 00:09:37,570
and, this is just a simple Python app, you

145
00:09:37,570 --> 00:09:39,610
can run it on your own server and set

146
00:09:39,610 --> 00:09:42,320
it up. So, oh, you can also sign up

147
00:09:42,320 --> 00:09:45,250
for something like quail dot IO, which also
lets

148
00:09:45,250 --> 00:09:48,230
you push, well, you can have your own account,

149
00:09:48,230 --> 00:09:50,890
pay for it, and push your private images there,

150
00:09:50,890 --> 00:09:54,540
and it's locked up. So before we go, go

151
00:09:54,540 --> 00:09:57,230
into the Docker file part, so let me show

152
00:09:57,230 --> 00:10:04,230
you a simple - workflow. So you have images,

153
00:10:07,290 --> 00:10:11,470
so you can probably ignore a bunch of these.

154
00:10:11,470 --> 00:10:13,820
Look at the last ones, which is basically
-

155
00:10:13,820 --> 00:10:20,820
should I move that a little bit? OK. So

156
00:10:24,150 --> 00:10:26,210
at the most basic level, when you pull from

157
00:10:26,210 --> 00:10:33,210
Docker, say, so it will try to, so, it's

158
00:10:36,580 --> 00:10:39,400
not gonna pull anything really, it'll just
check for

159
00:10:39,400 --> 00:10:42,470
the layers that are available on my system,
and

160
00:10:42,470 --> 00:10:47,290
it'll just, adjust itself. So you see several
layers

161
00:10:47,290 --> 00:10:51,290
there, so if you look at the Ubuntu part,

162
00:10:51,290 --> 00:10:55,090
it's actually, the Ubuntu images actually
comprised of precise

163
00:10:55,090 --> 00:10:57,280
and quantiles, and you can use any of those

164
00:10:57,280 --> 00:11:00,650
to take of your container. So kicking off
a

165
00:11:00,650 --> 00:11:07,650
container is probably as simple as - 
the end.

166
00:11:11,280 --> 00:11:13,530
You can give it, you have to give it,

167
00:11:13,530 --> 00:11:16,950
I'm taking the Ubuntu image, a basic image,
and

168
00:11:16,950 --> 00:11:20,580
I have to give it an entry point. So

169
00:11:20,580 --> 00:11:25,510
it will drop me into a root prompt, and

170
00:11:25,510 --> 00:11:31,190
basically I can do, I can run app, get

171
00:11:31,190 --> 00:11:33,880
updates, and I can install my own stuff. I'll

172
00:11:33,880 --> 00:11:36,860
just install a small, a very tiny package,
so,

173
00:11:36,860 --> 00:11:43,860
in the interest of time. Wow. That takes-
So

174
00:11:47,570 --> 00:11:51,020
the basic starter image is pretty much very
stripped

175
00:11:51,020 --> 00:11:53,340
down, you don't have most of the components
that

176
00:11:53,340 --> 00:11:54,950
you would need. So the idea is that it

177
00:11:54,950 --> 00:11:57,370
should be very lightweight to deploy, and
you can

178
00:11:57,370 --> 00:12:01,960
basically add your own, your own software
on top

179
00:12:01,960 --> 00:12:05,270
of it and commit and push it up. So

180
00:12:05,270 --> 00:12:12,270
let's say I install nano. There you go, right.

181
00:12:15,110 --> 00:12:18,860
That shouldn't take too long. Yeah. So you
have

182
00:12:18,860 --> 00:12:22,180
nano here, and if I switch to the other

183
00:12:22,180 --> 00:12:29,180
window, you can see. Docker ps. So among the

184
00:12:35,380 --> 00:12:37,800
other ones, are you- you can see the last

185
00:12:37,800 --> 00:12:40,120
one, which is being run here, and if I

186
00:12:40,120 --> 00:12:46,940
actually switch, use nano there, you can see
-

187
00:12:46,940 --> 00:12:53,750
docker - So each of the, each of the

188
00:12:53,750 --> 00:12:57,390
containers will have its own name, so you
can

189
00:12:57,390 --> 00:13:00,020
do - cranky - you can also set the

190
00:13:00,020 --> 00:13:03,130
names, which is a recent feature. But otherwise
it'll

191
00:13:03,130 --> 00:13:10,130
just regen- it'll just generate - oh, sorry.
So

192
00:13:14,470 --> 00:13:16,590
it, it gives you what is happening inside
the

193
00:13:16,590 --> 00:13:18,970
container. So you have a basic idea of what's

194
00:13:18,970 --> 00:13:24,400
running inside the container. So you can also
commit

195
00:13:24,400 --> 00:13:30,260
this. So you exit it, and you see, so

196
00:13:30,260 --> 00:13:32,380
cranky curie is on there, so you can do

197
00:13:32,380 --> 00:13:39,380
something like docker commit cranky curie.
Sorry. So you

198
00:13:53,300 --> 00:13:55,300
can commit it, and it'll show up in your

199
00:13:55,300 --> 00:14:02,300
images. Oh, I have to give it a name.

200
00:14:04,050 --> 00:14:11,050
Cranky_curie as varsee nano. So, docker images.
You'll see

201
00:14:14,180 --> 00:14:16,780
the one on top. It has fancy name. And

202
00:14:16,780 --> 00:14:18,790
you can push it, you can push it to

203
00:14:18,790 --> 00:14:23,270
the public registry, the public registry kind
of looks

204
00:14:23,270 --> 00:14:30,270
like this. So you can search for your own,

205
00:14:33,390 --> 00:14:36,290
whatever images that you might need for your
deployment

206
00:14:36,290 --> 00:14:41,700
and stuff like that. So I've, you know, I've

207
00:14:41,700 --> 00:14:43,290
been playing around with it a little bit and

208
00:14:43,290 --> 00:14:46,070
stuff like that. So this is the public depository.

209
00:14:46,070 --> 00:14:48,940
You can install the same thing on your private

210
00:14:48,940 --> 00:14:52,870
servers and secure it from outside. And you
can

211
00:14:52,870 --> 00:14:56,300
have your own image. So that's basically the
workflow

212
00:14:56,300 --> 00:14:58,880
that you would work with. And there's a second

213
00:14:58,880 --> 00:15:00,890
part to it. What I've done so far is

214
00:15:00,890 --> 00:15:04,670
the manual, so I've logged into a container
and

215
00:15:04,670 --> 00:15:07,430
I've installed stuff in it. So you basically
automate

216
00:15:07,430 --> 00:15:14,430
it with something called a Docker file. Oh,
sorry.

217
00:15:23,570 --> 00:15:27,390
So Docker file, so is, it's very similar to

218
00:15:27,390 --> 00:15:31,100
what you have reg file or make files in

219
00:15:31,100 --> 00:15:35,430
your projects. So it's a default way to build

220
00:15:35,430 --> 00:15:38,560
it from base image. Basically upload a file
script,

221
00:15:38,560 --> 00:15:42,970
but definitely easier to maintain. And you
have directives

222
00:15:42,970 --> 00:15:47,720
like from, run, command, expose. So from is
basically

223
00:15:47,720 --> 00:15:51,240
which, based on which image do I want to

224
00:15:51,240 --> 00:15:54,030
build my docker. And you have run, basically
has,

225
00:15:54,030 --> 00:15:57,210
or app to get install commands, whatever is
done

226
00:15:57,210 --> 00:16:00,180
manually. And command and entry point are
very similar.

227
00:16:00,180 --> 00:16:03,440
So I've entered into the container through
bin bash,

228
00:16:03,440 --> 00:16:07,110
so I've basically put that in entrypoint.
And the

229
00:16:07,110 --> 00:16:10,700
command is what passes, you pass some options
into

230
00:16:10,700 --> 00:16:12,780
that. So I'll show you a docker file anyway,

231
00:16:12,780 --> 00:16:16,440
so that will, that should put this, all this

232
00:16:16,440 --> 00:16:19,030
in context. So you have, you can even add

233
00:16:19,030 --> 00:16:22,320
files, you can copy config files from your
host

234
00:16:22,320 --> 00:16:27,210
system into your container. You can have volumes,
volumes

235
00:16:27,210 --> 00:16:31,670
are basically mount points. You just mount
a whole

236
00:16:31,670 --> 00:16:35,990
directory as either read-only or read-write,
it's up to

237
00:16:35,990 --> 00:16:38,760
you. And on the whole there are about a

238
00:16:38,760 --> 00:16:42,490
dozen commands. It's very simple to get started
with.

239
00:16:42,490 --> 00:16:48,160
No nonsense. And doesn't need a lot of time

240
00:16:48,160 --> 00:16:51,060
to learn the whole thing. So, and you can

241
00:16:51,060 --> 00:16:55,100
create your own base images using debootstrap
in centOS,

242
00:16:55,100 --> 00:16:57,810
it's, debootstrap is basically a building
tool with how

243
00:16:57,810 --> 00:17:01,630
you build a base image. But in that other

244
00:17:01,630 --> 00:17:04,409
distros you have, you know you can do it

245
00:17:04,409 --> 00:17:08,970
with other tools So zero downtime deployment.
So why,

246
00:17:08,970 --> 00:17:12,720
why do we need that? So the most important

247
00:17:12,720 --> 00:17:17,650
part being, you have, you know, things like
continuous

248
00:17:17,650 --> 00:17:22,669
delivery and continuous deployments, right.
So they're subtly different

249
00:17:22,669 --> 00:17:25,140
from each other, they're very similar concepts,
of course

250
00:17:25,140 --> 00:17:30,100
you have continous delivery where you send
stuff, you

251
00:17:30,100 --> 00:17:33,690
deliver your software on a regular basis and
you

252
00:17:33,690 --> 00:17:36,860
have tight communication loops with your clients
and all

253
00:17:36,860 --> 00:17:38,920
that good stuff - ?? and stuff. [00:17:38]
And

254
00:17:38,920 --> 00:17:42,050
continous deployment is basically taking it
one step, and

255
00:17:42,050 --> 00:17:45,270
I think Chad did a really good example of

256
00:17:45,270 --> 00:17:50,950
that yesterday. So you know instead of making
your

257
00:17:50,950 --> 00:17:53,440
deployments, say, once a week, or you know,
once

258
00:17:53,440 --> 00:17:56,480
every few days, the idea is to make them

259
00:17:56,480 --> 00:18:00,400
as continuously as possible with least amount
of angst

260
00:18:00,400 --> 00:18:05,390
around making deployments. So you basically
have, I'm sure

261
00:18:05,390 --> 00:18:07,920
you're all used to long deploys in Rails.
Migrations,

262
00:18:07,920 --> 00:18:11,310
you know, when migrations are happening, you're
changing the

263
00:18:11,310 --> 00:18:14,650
schema, other requests, you usually put in
a maintenance

264
00:18:14,650 --> 00:18:18,910
page and when other requests comes in you,
if

265
00:18:18,910 --> 00:18:22,100
you don't put up a maintenance page, you already,

266
00:18:22,100 --> 00:18:24,890
you can get some errors and stuff like that.

267
00:18:24,890 --> 00:18:28,280
And obviously you know about asset compilation,
it takes

268
00:18:28,280 --> 00:18:30,810
way too long. So but these problems are not,

269
00:18:30,810 --> 00:18:34,260
really not limited to Rails, per se. I'm sure

270
00:18:34,260 --> 00:18:37,140
you have the same issues when you're deploying
Jangle

271
00:18:37,140 --> 00:18:40,710
container, so Docker is basically a framework
diagnostic you

272
00:18:40,710 --> 00:18:44,000
can run any apps on it, and. So I'm

273
00:18:44,000 --> 00:18:47,740
trying to lay out a problem, so there are

274
00:18:47,740 --> 00:18:50,220
two parts to this problem. So one is with

275
00:18:50,220 --> 00:18:54,290
migrations and without migrations. Without
migrations it's usually a

276
00:18:54,290 --> 00:18:57,880
little easier because you don't have to worry
about

277
00:18:57,880 --> 00:19:01,630
making sure the databases are in sync and
stuff

278
00:19:01,630 --> 00:19:03,770
like that. So with databases it's a more complex

279
00:19:03,770 --> 00:19:07,280
scenario where you have to take a master DB

280
00:19:07,280 --> 00:19:11,170
slave, DB, make sure they're sync, and you
have

281
00:19:11,170 --> 00:19:15,360
something like ZooKeeper kind of keeping track
of who's

282
00:19:15,360 --> 00:19:17,410
master, who's slave, and you switch. So I'll
try

283
00:19:17,410 --> 00:19:22,180
to walk you through the simpler case, so we

284
00:19:22,180 --> 00:19:26,070
can extend this to, you know, DB level. I

285
00:19:26,070 --> 00:19:29,040
don't think I can cover other DB stuff here.

286
00:19:29,040 --> 00:19:33,960
So you basically have a HaProxy. HaProxy is
basically

287
00:19:33,960 --> 00:19:37,830
a reverse proxy but on steroids. So it's a

288
00:19:37,830 --> 00:19:41,130
load balancer, to be exact. But what it does

289
00:19:41,130 --> 00:19:43,070
is very similar to what engine x does for

290
00:19:43,070 --> 00:19:46,430
you, you have like multiple instances, and
you are,

291
00:19:46,430 --> 00:19:49,610
they're running on different multiple instances
of your app

292
00:19:49,610 --> 00:19:54,020
server, they're running on different ports.
And basically enginex,

293
00:19:54,020 --> 00:19:55,930
once a request comes enginex will do a round

294
00:19:55,930 --> 00:19:58,790
up and allotment of you know the servers.
So

295
00:19:58,790 --> 00:20:01,650
HaProxy does that, but also a lot more. It

296
00:20:01,650 --> 00:20:05,030
also lets you do funky stuff like what I'm

297
00:20:05,030 --> 00:20:07,300
gonna talk about, there's a back-up server,
and active

298
00:20:07,300 --> 00:20:11,250
server, which you can use cleverly to do zero-downtime

299
00:20:11,250 --> 00:20:15,030
deployments. But it also has, if you have
time,

300
00:20:15,030 --> 00:20:17,700
I would suggest you go through the configuration
file,

301
00:20:17,700 --> 00:20:20,010
which is very dense and long, but very interesting

302
00:20:20,010 --> 00:20:24,320
stuff. So what we're gonna use, in HaProxy
here,

303
00:20:24,320 --> 00:20:28,220
is that you have basically two types of, you

304
00:20:28,220 --> 00:20:31,320
can set up two types of servers. And the

305
00:20:31,320 --> 00:20:33,550
like, a bunch of active servers and there
are

306
00:20:33,550 --> 00:20:36,320
like a bunch of back-up servers, and the idea

307
00:20:36,320 --> 00:20:40,210
is that the back-up servers are not used until

308
00:20:40,210 --> 00:20:42,830
all the active servers are down, right. So
the

309
00:20:42,830 --> 00:20:45,490
request won't come through to back-up servers
until all

310
00:20:45,490 --> 00:20:49,680
the active servers are down. So what we are

311
00:20:49,680 --> 00:20:53,360
gonna, how we are gonna use that, sorry, the

312
00:20:53,360 --> 00:20:59,090
slides are very basic, so. So, you basically
kick

313
00:20:59,090 --> 00:21:02,770
off the deploy, kick off the image build with

314
00:21:02,770 --> 00:21:06,610
docker, and you take down the back-up servers.
At

315
00:21:06,610 --> 00:21:10,030
this point your HaProxy is still serving from
your

316
00:21:10,030 --> 00:21:15,020
active servers, right. So now you bring up
the

317
00:21:15,020 --> 00:21:18,000
new back-up server, new back-up servers with
your new

318
00:21:18,000 --> 00:21:20,070
image, which is just being build when the
deploy

319
00:21:20,070 --> 00:21:24,390
happened. So, and then you take down the active

320
00:21:24,390 --> 00:21:28,790
servers. So after all the active servers are
down,

321
00:21:28,790 --> 00:21:30,990
the requests will come in to the back-up ones,

322
00:21:30,990 --> 00:21:34,130
right, so which is now serving your new code,

323
00:21:34,130 --> 00:21:36,780
which has just been deployed. So after that
you

324
00:21:36,780 --> 00:21:39,820
restart your active servers, you're back to
normal again.

325
00:21:39,820 --> 00:21:44,040
So at the most basic level, so at least

326
00:21:44,040 --> 00:21:47,200
you will definitely won't be able to do migrations

327
00:21:47,200 --> 00:21:49,420
with this set-up. You have to go a little

328
00:21:49,420 --> 00:21:51,980
bit advanced for that. But at least you'll
be

329
00:21:51,980 --> 00:21:56,240
able to avoid frustrations with stuff like
long asset

330
00:21:56,240 --> 00:22:02,130
recompilation, you know, long deploys that
you usually get.

331
00:22:02,130 --> 00:22:05,270
So let me walk you through the whole thing,

332
00:22:05,270 --> 00:22:11,970
quickly. So I was actually quite upset that
the

333
00:22:11,970 --> 00:22:14,600
talk, the pamphlet which is being given, which
had

334
00:22:14,600 --> 00:22:18,370
shortcuts for sublime and whim, but it doesn't
have

335
00:22:18,370 --> 00:22:24,910
shortcuts for emacs. Which is, I object! So
the

336
00:22:24,910 --> 00:22:27,250
idea is, OK let me start you off with

337
00:22:27,250 --> 00:22:30,010
the simple docker file. So this should, this
should

338
00:22:30,010 --> 00:22:37,010
- oh, OK. Yeah. Let me restart it. I'll

339
00:22:51,450 --> 00:22:57,480
just show you on my- I think this is

340
00:22:57,480 --> 00:23:04,480
a lot more easier to show you. So app

341
00:23:04,640 --> 00:23:11,640
server, you have docker file. So at the most

342
00:23:17,809 --> 00:23:20,380
basic level, I am picking it up from the

343
00:23:20,380 --> 00:23:25,080
Ubuntu image, and basically running some adaptation
of my

344
00:23:25,080 --> 00:23:30,440
source's list, and you have app-get update,
app-get install,

345
00:23:30,440 --> 00:23:33,180
y. So let me run the deploy first, and

346
00:23:33,180 --> 00:23:35,250
then I will talk about this, because I don't

347
00:23:35,250 --> 00:23:42,250
think we'll have enough time to actually wait
afterwards.

348
00:24:00,680 --> 00:24:05,300
OK. So this will, this will run the deploy

349
00:24:05,309 --> 00:24:09,370
process in the background. Let me talk about
what

350
00:24:09,370 --> 00:24:16,370
it actually does out here. OK. So let's get

351
00:24:28,670 --> 00:24:31,400
back to our docker file. So what it does

352
00:24:31,400 --> 00:24:33,600
- this is almost like the shell script that

353
00:24:33,600 --> 00:24:37,600
you use for everyday automation, so, but it
adds

354
00:24:37,600 --> 00:24:41,700
a little bit more fun to it, I guess.

355
00:24:41,700 --> 00:24:45,580
So what I'm doing is pretty straightforward.
I'm installing

356
00:24:45,580 --> 00:24:49,820
chruby, I hate RBM, especially for production
it sucks,

357
00:24:49,820 --> 00:24:53,980
I mean, yeah. There are other opinions about
it.

358
00:24:53,980 --> 00:24:55,900
But at least I have, I've thought it's the

359
00:24:55,900 --> 00:24:58,340
easiest way to get started. So I'm basically
installing

360
00:24:58,340 --> 00:25:03,290
some default gems, like bundler and puma,
and I'm

361
00:25:03,290 --> 00:25:06,370
installing other dependencies. So the reason,
I am actually

362
00:25:06,370 --> 00:25:10,710
splitting this into two docker files. So you'll
also

363
00:25:10,710 --> 00:25:17,710
have stuff like, so. What I'm doing here is

364
00:25:21,440 --> 00:25:24,150
that, so when I'm doing actually a deploy,
I

365
00:25:24,150 --> 00:25:27,240
am only running this. So I'm picking up, I'm

366
00:25:27,240 --> 00:25:30,220
installing all my dependencies in my earlier
image, and

367
00:25:30,220 --> 00:25:32,610
I'm just reusing it for deploys I want, because

368
00:25:32,610 --> 00:25:35,690
I want them to be pretty fast. So what

369
00:25:35,690 --> 00:25:37,630
this does is pretty simple. It copies over
the

370
00:25:37,630 --> 00:25:43,059
database configurations and it does a bundle,
and it

371
00:25:43,059 --> 00:25:47,500
does a db migrate. I'm just using sqlite here,

372
00:25:47,500 --> 00:25:52,380
so yeah. It exposes a port. So how the

373
00:25:52,380 --> 00:25:55,460
containers talk to each other within a docker,
in

374
00:25:55,460 --> 00:26:00,540
your host, is that through exposing these
ports. And

375
00:26:00,540 --> 00:26:04,290
like I mentioned earlier, my entrypoint is
basically I'm

376
00:26:04,290 --> 00:26:10,350
starting Puma there. And I'm running it in
a

377
00:26:10,350 --> 00:26:16,070
?? [00:26:07]. Yeah. So if you look at the,

378
00:26:16,070 --> 00:26:23,070
if you. If you look at the deployment, I'm

379
00:26:29,480 --> 00:26:36,220
sorry- Yeah. So I don't know how much of

380
00:26:36,220 --> 00:26:39,080
this actually makes sense. I'll just show
you the,

381
00:26:39,080 --> 00:26:42,910
our deployment code. Sorry, the cap file,
so that

382
00:26:42,910 --> 00:26:49,910
should make a little bit of more, yeah. OK.

383
00:27:01,620 --> 00:27:06,429
So if you see at the bottom, you'll see

384
00:27:06,429 --> 00:27:10,179
that I am just doing a bunch of stuff

385
00:27:10,179 --> 00:27:15,480
there, so I'm linking from my current deploy
to

386
00:27:15,480 --> 00:27:22,410
the vagrant, sorry, the docker container build
directory. And

387
00:27:22,410 --> 00:27:25,240
I'm starting from the back-end servers. So
I'll, I

388
00:27:25,240 --> 00:27:29,679
should also show you the, my HaProxy configuration.
So

389
00:27:29,679 --> 00:27:34,700
it starts with your ports set up and you

390
00:27:34,700 --> 00:27:37,550
actually search for those docker containers
and take them

391
00:27:37,550 --> 00:27:40,309
down. So the build takes a- a little long,

392
00:27:40,309 --> 00:27:42,300
so I've kind of commented it out for now,

393
00:27:42,300 --> 00:27:44,330
but I can show you outside if you want

394
00:27:44,330 --> 00:27:47,440
to see how that works. And it's pretty simple.

395
00:27:47,440 --> 00:27:49,520
So at the end of it I'm just restarting

396
00:27:49,520 --> 00:27:52,660
all my containers, so you can basically look
at

397
00:27:52,660 --> 00:27:58,510
them here. Docker ps a. You'll see that these

398
00:27:58,510 --> 00:28:00,770
top ones are only up for two minutes. These

399
00:28:00,770 --> 00:28:04,950
are recently deployed. So all through, if
you look

400
00:28:04,950 --> 00:28:09,830
at your HaProxy page, so you basically have
two

401
00:28:09,830 --> 00:28:14,630
active ones here, and two back-up servers
here. So

402
00:28:14,630 --> 00:28:21,630
like, and I also should show you the HaProxy

403
00:28:28,470 --> 00:28:35,470
stuff, right. So you can pretty much ignore
all

404
00:28:36,620 --> 00:28:39,700
this stuff. The most important part is the
last

405
00:28:39,700 --> 00:28:42,260
two ones. So as you can see the web

406
00:28:42,260 --> 00:28:46,720
01 and web 02 are active servers, and web

407
00:28:46,720 --> 00:28:49,740
03 and web 04 are back-up servers. So that's

408
00:28:49,740 --> 00:28:53,900
all it takes. So you can basically segment
your,

409
00:28:53,900 --> 00:28:58,030
the servers like that and go at it. So

410
00:28:58,030 --> 00:29:05,030
that's basically it. So I hope- and, a couple

411
00:29:05,049 --> 00:29:09,200
of helpful links if, sorry if it's not very

412
00:29:09,200 --> 00:29:11,640
visible. There's docker dot io, where you
can find

413
00:29:11,640 --> 00:29:15,110
all of the documentation and stuff, there's
haproxy -

414
00:29:15,110 --> 00:29:17,470
go look at it if you are doing deployments

415
00:29:17,470 --> 00:29:21,370
through your regular day-to-day developer
life. This is a

416
00:29:21,370 --> 00:29:25,990
lifesaving tool to learn well. And there's
dockerbook, if

417
00:29:25,990 --> 00:29:28,250
you're - it's written by James Turnbull one
of

418
00:29:28,250 --> 00:29:32,600
my favorite technical authors. He's written
Pro Puppet, which

419
00:29:32,600 --> 00:29:36,490
is still quite one of my favorite books. And

420
00:29:36,490 --> 00:29:38,420
if you want to know a little bit more

421
00:29:38,420 --> 00:29:43,270
about the Linux part of what Docker does,
like

422
00:29:43,270 --> 00:29:46,620
the internals of Docker, you can listen to
Jerome

423
00:29:46,620 --> 00:29:49,390
Petazzoni, who is part of the Docker team.
So

424
00:29:49,390 --> 00:29:51,530
he's given a really good talk, in-depth talk
about

425
00:29:51,530 --> 00:29:53,840
it, at our next conference you should look
at

426
00:29:53,840 --> 00:29:56,410
the video. And there are like a bunch of

427
00:29:56,410 --> 00:29:59,360
tools you can probably look at. There's Dokku
which

428
00:29:59,360 --> 00:30:02,730
is a PaaS. PaaS is a platform as a

429
00:30:02,730 --> 00:30:05,170
service, what- essentially what HaDokku does,
you can build

430
00:30:05,170 --> 00:30:08,600
your own HaDokku [00:30:06] with the Docker.
And Flynn

431
00:30:08,600 --> 00:30:12,080
dot io, CoreOS is also very import- very interesting

432
00:30:12,080 --> 00:30:15,320
tool. CoreOS kind of bundles Docker with a
service

433
00:30:15,320 --> 00:30:18,480
disovery thing, like, kind of like ZooKeeper,
but it

434
00:30:18,480 --> 00:30:22,130
is called ATCD. And it bundle system ??[00:20:21]
in

435
00:30:22,130 --> 00:30:24,950
its framework, so if you're into deployments
this is

436
00:30:24,950 --> 00:30:29,000
a very interesting ecosystem to look at. And
Quay

437
00:30:29,000 --> 00:30:32,970
dot io I mentioned. It's, you can basically
upload

438
00:30:32,970 --> 00:30:36,780
your private images there and get started.
So they're

439
00:30:36,780 --> 00:30:39,450
like a bunch of tools. I don't know if

440
00:30:39,450 --> 00:30:42,390
I have any time for questions, but you can

441
00:30:42,390 --> 00:30:47,390
catch me. Sorry, but I'm available, you can
catch

442
00:30:47,390 --> 00:30:54,390
me at any time. Thanks a lot.