WEBVTT 99:59:59.999 --> 99:59:59.999 called the Sunlight Foundation. 99:59:59.999 --> 99:59:59.999 I do government transparency and accountability. 99:59:59.999 --> 99:59:59.999 Who's paying whom how much, who's voting which way, stuff like that. 99:59:59.999 --> 99:59:59.999 I'm been doing Ubuntu stuff for a while, 99:59:59.999 --> 99:59:59.999 Debian stuff for a little while, since 2009. 99:59:59.999 --> 99:59:59.999 I'm on the FTP Team 99:59:59.999 --> 99:59:59.999 and I'm like whatever else 99:59:59.999 --> 99:59:59.999 I've got other stuff that I'm doing 99:59:59.999 --> 99:59:59.999 but that's not really as important. 99:59:59.999 --> 99:59:59.999 Oh great, link not found! Cool! 99:59:59.999 --> 99:59:59.999 That is a giant beautiful picture of the Sunlight logo 99:59:59.999 --> 99:59:59.999 this is just the generic intro to any of my slides, 99:59:59.999 --> 99:59:59.999 so I apologise but if anyone's interested in Sunlight, 99:59:59.999 --> 99:59:59.999 feel free to talk to me. 99:59:59.999 --> 99:59:59.999 I will gladly tell you all about how awesome Sunlight is 99:59:59.999 --> 99:59:59.999 and how much fun I have working there. 99:59:59.999 --> 99:59:59.999 Right, so, Docker. 99:59:59.999 --> 99:59:59.999 What is Docker? 99:59:59.999 --> 99:59:59.999 This is sort of like the existential question 99:59:59.999 --> 99:59:59.999 No one quite knows, right? 99:59:59.999 --> 99:59:59.999 Everyone is using Docker for all these different things 99:59:59.999 --> 99:59:59.999 and it's kind of super confusing 99:59:59.999 --> 99:59:59.999 and that's really disappointing. 99:59:59.999 --> 99:59:59.999 Basically, Docker is a process-level isolation framework. 99:59:59.999 --> 99:59:59.999 That's all it is. 99:59:59.999 --> 99:59:59.999 It uses the Linux kernel namespacing to isolate a process, 99:59:59.999 --> 99:59:59.999 a single process and tracks the processes inside the container using cgroups. 99:59:59.999 --> 99:59:59.999 Also I forgot to mention this because I dove right in, 99:59:59.999 --> 99:59:59.999 this talk is going to be on the short side, 99:59:59.999 --> 99:59:59.999 because I'm hoping that we're going to have a bit of discussion 99:59:59.999 --> 99:59:59.999 about Docker's role in Debian 99:59:59.999 --> 99:59:59.999 and in what ways, us as the docker maintenance team, can help Debian 99:59:59.999 --> 99:59:59.999 and in what ways this can flow back and forth 99:59:59.999 --> 99:59:59.999 Also, I do work at Docker, I'm just the Debian hacker. 99:59:59.999 --> 99:59:59.999 I do this for fun, so I will cover some of the cons 99:59:59.999 --> 99:59:59.999 that maybe people don't talk about as much. 99:59:59.999 --> 99:59:59.999 Right, so Docker provides a whole bunch of tools 99:59:59.999 --> 99:59:59.999 used to manage and wrap these processes. 99:59:59.999 --> 99:59:59.999 For instance, docker run, which let's you run code inside a container. 99:59:59.999 --> 99:59:59.999 Remember, it's for a single process, it's not a virtual machine 99:59:59.999 --> 99:59:59.999 You just spawn it up and it wraps a process and keeps it semi-isolated 99:59:59.999 --> 99:59:59.999 so that it runs properly 99:59:59.999 --> 99:59:59.999 or stuff to pull images, if you have images on a central location on the index 99:59:59.999 --> 99:59:59.999 So if you docker pull paultag/postgres then you get my particular Postgres flavour 99:59:59.999 --> 99:59:59.999 Docker is higher-level than lxc, 99:59:59.999 --> 99:59:59.999 but lower level than something like ansible, vagrant or fabric 99:59:59.999 --> 99:59:59.999 Docker provides these primitives to work on the system, 99:59:59.999 --> 99:59:59.999 these things to allow you run processes in kind of a sane and normal way 99:59:59.999 --> 99:59:59.999 but it's not there to solve all of the configuration management problems 99:59:59.999 --> 99:59:59.999 and there's definitely configuration management to do, 99:59:59.999 --> 99:59:59.999 once a Docker install is on your system. 99:59:59.999 --> 99:59:59.999 So, one technique that I have is: 99:59:59.999 --> 99:59:59.999 all my containers are read-only, and then any data that changes in the container 99:59:59.999 --> 99:59:59.999 so for instance Postgres you have /var/lib/postgres 99:59:59.999 --> 99:59:59.999 that's volume mounted, which is like a bind mount out of the container. 99:59:59.999 --> 99:59:59.999 and that's on the host system in /srv 99:59:59.999 --> 99:59:59.999 and then I can just snapshot that and keep that backed up. 99:59:59.999 --> 99:59:59.999 I often use ansible, to provision the stuff that's in /srv 99:59:59.999 --> 99:59:59.999 So I won't provision anything inside the container, 99:59:59.999 --> 99:59:59.999 because it's only running a single process, you can't ssh in there 99:59:59.999 --> 99:59:59.999 but using something like ansible, vagrant or fabric 99:59:59.999 --> 99:59:59.999 you can coordinate a whole bunch of Docker containers 99:59:59.999 --> 99:59:59.999 to do some stuff that's pretty powerful. 99:59:59.999 --> 99:59:59.999 Originally Docker wrapped lxc, 99:59:59.999 --> 99:59:59.999 just to kind of give you a place of where it is on the stack, 99:59:59.999 --> 99:59:59.999 but that ended up getting reimplemented, just sort of in raw Go 99:59:59.999 --> 99:59:59.999 So it no longer uses the lxc backend by default. 99:59:59.999 --> 99:59:59.999 I think you might be able to still turn that on. 99:59:59.999 --> 99:59:59.999 You can but don't do it. 99:59:59.999 --> 99:59:59.999 [laughs] 99:59:59.999 --> 99:59:59.999 It's probably going to end up breaking stuff in a nasty way. 99:59:59.999 --> 99:59:59.999 There were a whole bunch of incompatibilities after a couple of versions. 99:59:59.999 --> 99:59:59.999 So basically Docker is slightly above lxc, 99:59:59.999 --> 99:59:59.999 but not quite at the level of vagrant or anything like that. 99:59:59.999 --> 99:59:59.999 [question]: Is Docker in jessie at the moment 99:59:59.999 --> 99:59:59.999 [Paul]: Docker is currently in jessie, yeah. Docker 1.0, 99:59:59.999 --> 99:59:59.999 which upstream assured me was stable 99:59:59.999 --> 99:59:59.999 but they've never released security or patch-fixes 99:59:59.999 --> 99:59:59.999 So, we're probably going to upload 1.2 pretty soon 99:59:59.999 --> 99:59:59.999 because there was a bug in golang 1.3 which affected us until then 99:59:59.999 --> 99:59:59.999 I'm waiting on a package in the NEW queue, ironically. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Yeah, it's embarrassing. 99:59:59.999 --> 99:59:59.999 What Docker is not: 99:59:59.999 --> 99:59:59.999 Docker is not a virtual machine, and I cannot beat this point home enough 99:59:59.999 --> 99:59:59.999 It should be a single process, if you start stressing that 99:59:59.999 --> 99:59:59.999 weird stuff's going to start to happen and you're going to be in for a bad time 99:59:59.999 --> 99:59:59.999 Some people use supervised, or whatever else, 99:59:59.999 --> 99:59:59.999 to manage a whole bunch of different stuff 99:59:59.999 --> 99:59:59.999 and if you're careful, that's fine. 99:59:59.999 --> 99:59:59.999 If you know what you're doing, fine.. 99:59:59.999 --> 99:59:59.999 but in general, if you're just trying to "Dockerize" something, 99:59:59.999 --> 99:59:59.999 use a single process per container. 99:59:59.999 --> 99:59:59.999 So I have a Postgres container, then a webapp container 99:59:59.999 --> 99:59:59.999 and they're linked so they can talk to one another. 99:59:59.999 --> 99:59:59.999 So that's usually the architecture of standard by the book deployments. 99:59:59.999 --> 99:59:59.999 It's not a process for the entire application. 99:59:59.999 --> 99:59:59.999 It's not like I 'docker run', what do people run nowadays, etherpad? 99:59:59.999 --> 99:59:59.999 That might be kind of outdated. 99:59:59.999 --> 99:59:59.999 Yeah, there was a question. 99:59:59.999 --> 99:59:59.999 [question]: do you mean a single process or? 99:59:59.999 --> 99:59:59.999 [Paul]: So the question was, "Single process, question mark?" 99:59:59.999 --> 99:59:59.999 and the answer is "yes". Single PID. 99:59:59.999 --> 99:59:59.999 Actually sorry, no, actually that's wrong. 99:59:59.999 --> 99:59:59.999 The Docker instance should be starting a single PID 99:59:59.999 --> 99:59:59.999 but that can spawn other things. Perfectly fine. 99:59:59.999 --> 99:59:59.999 If for instance you have wsgi 99:59:59.999 --> 99:59:59.999 and that has a whole bunch of workers, spawning off a whole bunch of workers 99:59:59.999 --> 99:59:59.999 Totally reasonable if that's how it operates. 99:59:59.999 --> 99:59:59.999 But not for something like etherpad 99:59:59.999 --> 99:59:59.999 and you're having a database and the application in the same container. 99:59:59.999 --> 99:59:59.999 Sort of like logically the same stuff. 99:59:59.999 --> 99:59:59.999 Docker is not perfect isolation from the host, 99:59:59.999 --> 99:59:59.999 the goal is to isolated processes and not prevent exploits. 99:59:59.999 --> 99:59:59.999 The docker group is root-equivalent, 99:59:59.999 --> 99:59:59.999 so if you're part of the docker group 99:59:59.999 --> 99:59:59.999 and you can launch docker containers, it is trivial to get root on the host. 99:59:59.999 --> 99:59:59.999 Because you can just start a new container with the root of the filesystem 99:59:59.999 --> 99:59:59.999 mounted inside the container which you can chroot into and then be root. 99:59:59.999 --> 99:59:59.999 So don't think of this as a one size fits all security system, 99:59:59.999 --> 99:59:59.999 it's just providing basic wrapping around the process 99:59:59.999 --> 99:59:59.999 to make sure it's running in an environment that you can hold down for a minute. 99:59:59.999 --> 99:59:59.999 Basically this let's my unstable server run Postgres from stable. 99:59:59.999 --> 99:59:59.999 The web-apps that I'm really tightly controlling, 99:59:59.999 --> 99:59:59.999 because they're all running on python 3.4, are in unstable containers. 99:59:59.999 --> 99:59:59.999 So I can have different things for different daemons, which is kind of neat. 99:59:59.999 --> 99:59:59.999 So, why? Which is the bigger question. 99:59:59.999 --> 99:59:59.999 Why are we wasting all of our time with wrapping all of this stuff in Docker containers. 99:59:59.999 --> 99:59:59.999 and that's a good question. 99:59:59.999 --> 99:59:59.999 Basically it lets you abstract the idea of process 99:59:59.999 --> 99:59:59.999 and really not care about the host environment too much. 99:59:59.999 --> 99:59:59.999 So when I test something locally, on my local machine 99:59:59.999 --> 99:59:59.999 and deploy it to one of my VPSs, I can be pretty sure that 99:59:59.999 --> 99:59:59.999 that process is going to run in roughly the same way. 99:59:59.999 --> 99:59:59.999 Obviously there might be differences in the kernel, 99:59:59.999 --> 99:59:59.999 if there are difference in the kernel, okay fine 99:59:59.999 --> 99:59:59.999 that's going to have some problems 99:59:59.999 --> 99:59:59.999 But basically it lets you contain and abstract these processes 99:59:59.999 --> 99:59:59.999 and it lets my trivially move stuff between servers 99:59:59.999 --> 99:59:59.999 or test on my local machine. 99:59:59.999 --> 99:59:59.999 Reproduce the environment with a very lightweight environment. 99:59:59.999 --> 99:59:59.999 Contrasted to something like a virtual machine, 99:59:59.999 --> 99:59:59.999 where you have the entire overhead of the entire operating system 99:59:59.999 --> 99:59:59.999 and you're actually virtualizing the entire OS 99:59:59.999 --> 99:59:59.999 and all of the daemons included with that, 99:59:59.999 --> 99:59:59.999 and that's not entirely necessary in a lot of situations. 99:59:59.999 --> 99:59:59.999 Essentially it doesn't matter what- 99:59:59.999 --> 99:59:59.999 that's a typo, yeah "containenr" [laughs] 99:59:59.999 --> 99:59:59.999 I definitely wrote these kind of late, so I apologise 99:59:59.999 --> 99:59:59.999 Essentially it means I can deploy my stuff on whatever host I'm given 99:59:59.999 --> 99:59:59.999 because I'm cheap and I really don't like paying for servers 99:59:59.999 --> 99:59:59.999 So if someone decides they want to give my access to a Fedora host, 99:59:59.999 --> 99:59:59.999 I can host my stuff inside a stable containers 99:59:59.999 --> 99:59:59.999 and not stress about it too much, 99:59:59.999 --> 99:59:59.999 there's a little bit of stuff you have to worry about 99:59:59.999 --> 99:59:59.999 but yeah essentially this let's me run stable Postgres, 99:59:59.999 --> 99:59:59.999 using Python 3.4, play around with code, isolate it, move it around. 99:59:59.999 --> 99:59:59.999 That sort of thing. 99:59:59.999 --> 99:59:59.999 The comparison that upstream makes a lot, 99:59:59.999 --> 99:59:59.999 where the name comes from, 99:59:59.999 --> 99:59:59.999 is ISO containers that you see on trucks, 99:59:59.999 --> 99:59:59.999 the big metal things, they're super cool. 99:59:59.999 --> 99:59:59.999 Hipsters are living in them now. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Basically you can just put stuff in them, 99:59:59.999 --> 99:59:59.999 just pack it full of whatever, seal it up 99:59:59.999 --> 99:59:59.999 and it doesn't matter if you put it into a boat or a truck, 99:59:59.999 --> 99:59:59.999 it's just going somewhere, you don't really care. 99:59:59.999 --> 99:59:59.999 The comparison here, is that these are the ISO containers of the future 99:59:59.999 --> 99:59:59.999 with processes and computers. 99:59:59.999 --> 99:59:59.999 Docker itself, is the big docker ship full of ISO containers 99:59:59.999 --> 99:59:59.999 So you can basically create hosts that host all of your code, 99:59:59.999 --> 99:59:59.999 without really caring what's inside, because they all look the same to you. 99:59:59.999 --> 99:59:59.999 They all have the same docker run interface, 99:59:59.999 --> 99:59:59.999 they all have the same docker pull interface. 99:59:59.999 --> 99:59:59.999 Then inside the container you can just be concerned about how you pack it 99:59:59.999 --> 99:59:59.999 but the host doesn't care, and that ends up being pretty important. 99:59:59.999 --> 99:59:59.999 For super complex and hard to setup software, 99:59:59.999 --> 99:59:59.999 this can help remove a lot of complexity in actual initial setup. 99:59:59.999 --> 99:59:59.999 Because sometimes setting up processes like these, can be extremely difficult. 99:59:59.999 --> 99:59:59.999 As I'm sure everyone here knows. 99:59:59.999 --> 99:59:59.999 So if you have this weird historic way of setting up this application 99:59:59.999 --> 99:59:59.999 or it requires some weird configuration files but they're mostly kind of standard, 99:59:59.999 --> 99:59:59.999 then you can just make sure that's all in place. 99:59:59.999 --> 99:59:59.999 In fact at work, I've Dockerized a whole bunch of scrapers. 99:59:59.999 --> 99:59:59.999 So a large part of my day job is scraping terrible government websites, 99:59:59.999 --> 99:59:59.999 that have about 3 or 4 tags, I'm not joking! 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 We're all laughing, but this is my life! 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 The sites are all complicated 99:59:59.999 --> 99:59:59.999 and one of them times out every five minutes, 99:59:59.999 --> 99:59:59.999 so even if you're a human browsing it, it kicks you back to the main page. 99:59:59.999 --> 99:59:59.999 Augh, it's terrible! 99:59:59.999 --> 99:59:59.999 A lot of the scrape infrastructure is kind of gnarly, 99:59:59.999 --> 99:59:59.999 and setting up the actual scrapers can be a bit of a pain. 99:59:59.999 --> 99:59:59.999 Making sure that those scrapers run the same way in development and production 99:59:59.999 --> 99:59:59.999 is super handy 99:59:59.999 --> 99:59:59.999 and while it's easy for me to get them going, 99:59:59.999 --> 99:59:59.999 because I wrote a huge chunk of code, 99:59:59.999 --> 99:59:59.999 it's not as accessible for other people. 99:59:59.999 --> 99:59:59.999 So one of the things I did recently, is all of the scrape infrastructure, 99:59:59.999 --> 99:59:59.999 I'm currently working on a daemon that will run the scrapers inside Docker containers. 99:59:59.999 --> 99:59:59.999 So essentially I've packaged up the particular scrapers they have; 99:59:59.999 --> 99:59:59.999 so I have state scrapers, which are state legislative scrapers 99:59:59.999 --> 99:59:59.999 and so nightly it will 'docker run paultag/scrapers-us-state-alabama' 99:59:59.999 --> 99:59:59.999 and it'll go off the Alabama, scrape all of the data down and insert into Postgres 99:59:59.999 --> 99:59:59.999 This let's us build continuously from git, so as soon as I push, 99:59:59.999 --> 99:59:59.999 it'll rebuild the image and that image will be used 99:59:59.999 --> 99:59:59.999 in the actual run later on in the day. 99:59:59.999 --> 99:59:59.999 So it doesn't require mucking around, with like- 99:59:59.999 --> 99:59:59.999 I don't know if anyone's used bamboo, which is some non-free Atlassian stuff. 99:59:59.999 --> 99:59:59.999 which is what we're using, what I guess we're still using. 99:59:59.999 --> 99:59:59.999 Essentially it makes you rebuild an AMI, one of the Amazon images, 99:59:59.999 --> 99:59:59.999 everytime you update the environment, which is horrendous. 99:59:59.999 --> 99:59:59.999 And it has a 30 minute, like Indiana Jones, wall that's coming down 99:59:59.999 --> 99:59:59.999 After 30 minutes it shuts the machine down, because it thinks it's idle. 99:59:59.999 --> 99:59:59.999 So you have to make the change in 30 minutes, and then it shuts down 99:59:59.999 --> 99:59:59.999 and then you're like "God, gotta do it again" 99:59:59.999 --> 99:59:59.999 Before that we used Jenkins which was good enough, but kind of a pain too. 99:59:59.999 --> 99:59:59.999 It's just everything's running in the same environment, it can be a bit of a pain. 99:59:59.999 --> 99:59:59.999 So by Dockerizing all of this, essentially I can give anyone this scraper 99:59:59.999 --> 99:59:59.999 and if they're interested in having the data, they can just docker run this command 99:59:59.999 --> 99:59:59.999 and everything just kind of works. 99:59:59.999 --> 99:59:59.999 It's like OpenGov in a box. Which is pretty awesome. 99:59:59.999 --> 99:59:59.999 I've been working on trying to Dockerize 99:59:59.999 --> 99:59:59.999 more and more of the periodic jobs that get run. 99:59:59.999 --> 99:59:59.999 and so far, it's pretty thrilling 99:59:59.999 --> 99:59:59.999 and the results are really really promising 99:59:59.999 --> 99:59:59.999 and I hope that we're going to continue to develop Docker 99:59:59.999 --> 99:59:59.999 to that point that becomes a better use case. 99:59:59.999 --> 99:59:59.999 Because I think it's a really good one. 99:59:59.999 --> 99:59:59.999 Now for the fun part, my opinions! 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Docker can let you get away with murder, 99:59:59.999 --> 99:59:59.999 you can do some pretty gnarly stuff 99:59:59.999 --> 99:59:59.999 and people do some pretty gnarly stuff. 99:59:59.999 --> 99:59:59.999 So I'm just going to brand up a couple of the things I care about. 99:59:59.999 --> 99:59:59.999 For instance, I only run my Docker containers off systemd unit files, 99:59:59.999 --> 99:59:59.999 actually I do use upstart on a couple of machines. 99:59:59.999 --> 99:59:59.999 Essentially they look like this, here's the spec file for one of them. 99:59:59.999 --> 99:59:59.999 Basically, the spec file declares that this is for my nginx config 99:59:59.999 --> 99:59:59.999 and so right there we've got 'docker start nginx' if it already exists 99:59:59.999 --> 99:59:59.999 otherwise it has the set up of the actual Docker container, 99:59:59.999 --> 99:59:59.999 so it says mount that into /serve, play around with /srv/pault.ag/nginx/serve 99:59:59.999 --> 99:59:59.999 with the image, which is paultag/nginx, 99:59:59.999 --> 99:59:59.999 and the binary it is running, /usr/sbin/nginx, with a couple of flags 99:59:59.999 --> 99:59:59.999 the stop command is 'docker stop -t 5 nginx' which means terminate after 5 seconds. 99:59:59.999 --> 99:59:59.999 That's kind of a lot and it's kind of ugly, 99:59:59.999 --> 99:59:59.999 I understand that but that's okay. 99:59:59.999 --> 99:59:59.999 This basically let's the nginx in Docker be treated like any other system level process 99:59:59.999 --> 99:59:59.999 This means that nginx inside Docker is treated identically in nearly 99:59:59.999 --> 99:59:59.999 everything else that I do, because I just do 'sudo service nginx restart' 99:59:59.999 --> 99:59:59.999 What does it matter, it's just launching commands? 99:59:59.999 --> 99:59:59.999 And the commands are happening to isolate it in Docker. 99:59:59.999 --> 99:59:59.999 Basically the same thing here for upstart, 99:59:59.999 --> 99:59:59.999 slightly cleaner actually, which is awesome 99:59:59.999 --> 99:59:59.999 But basically start on filesystem and start Docker 99:59:59.999 --> 99:59:59.999 source the file to do some work and launch essentially the same thing 99:59:59.999 --> 99:59:59.999 and these are nearly identical 99:59:59.999 --> 99:59:59.999 I really don't like deploying Docker unless there's a start up script in place 99:59:59.999 --> 99:59:59.999 I want all of my machines to be able to hard-shutdown 99:59:59.999 --> 99:59:59.999 in the middle of whatever they're doing - 99:59:59.999 --> 99:59:59.999 sometime in the transient ether, have all of my Docker containers disappear 99:59:59.999 --> 99:59:59.999 and when the machine starts up, have it be back up in which I can use it. 99:59:59.999 --> 99:59:59.999 And having unit files and spec files like this, really saves you a lot. 99:59:59.999 --> 99:59:59.999 As for whether or not systemd will replace Docker, I have no idea. 99:59:59.999 --> 99:59:59.999 I'm sure the systemd people think that. 99:59:59.999 --> 99:59:59.999 So 'sudo service docker restart' plays around with the Docker containers. 99:59:59.999 --> 99:59:59.999 Any questions on that part in particular, because I feel like I moved a little fast. 99:59:59.999 --> 99:59:59.999 Asheesh, yes 99:59:59.999 --> 99:59:59.999 [Asheesh]: How did you put nginx into that Docker instance, 99:59:59.999 --> 99:59:59.999 and what is running in there, Debian something? 99:59:59.999 --> 99:59:59.999 [Paul]: Yeah, totally. Thanks Asheesh. 99:59:59.999 --> 99:59:59.999 Essentially- let's see if I have my Docker files around. 99:59:59.999 --> 99:59:59.999 Ah yes, right fonts. 99:59:59.999 --> 99:59:59.999 Unfortunately xfce-terminal does not let me use Ctrl++, which is disappointing. 99:59:59.999 --> 99:59:59.999 That's too big, that should be pretty good. 99:59:59.999 --> 99:59:59.999 Okay, this is gigantic, but we should be able to do something. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Aah, that's a little bit too big 99:59:59.999 --> 99:59:59.999 (inaudible) 99:59:59.999 --> 99:59:59.999 CoC. Come on man, CoC. This is a little bit better, 99:59:59.999 --> 99:59:59.999 I'm just going to go a little bit smaller, sorry. Right, this'll do. 99:59:59.999 --> 99:59:59.999 So essentially, you declare from what base image you start from. 99:59:59.999 --> 99:59:59.999 This can be any arbitrary image. 99:59:59.999 --> 99:59:59.999 So I'm saying, FROM the debian:unstable image. 99:59:59.999 --> 99:59:59.999 The debian:unstable image is maintained here by tianon, upstream. 99:59:59.999 --> 99:59:59.999 It's roughly similar to what you get from a debootstrap, 99:59:59.999 --> 99:59:59.999 There are some differences, the differences are documented in the creation script, 99:59:59.999 --> 99:59:59.999 that's also shipped with Docker itself, it you want to create yourselves. 99:59:59.999 --> 99:59:59.999 The actual modifications, we've talked about moving them into a .deb before 99:59:59.999 --> 99:59:59.999 but nothing really came of that yet. 99:59:59.999 --> 99:59:59.999 It anyone's interested in making sure the differences in the Debian Docker image are better documented, 99:59:59.999 --> 99:59:59.999 I'm sure the Docker upstream, tianon in particular 99:59:59.999 --> 99:59:59.999 and myself would love to talk to you about how to make that possible. Thumbs up! 99:59:59.999 --> 99:59:59.999 So I haven't said anything entirely wrong. Great! 99:59:59.999 --> 99:59:59.999 So I'm saying, FROM the debian:unstable image. 99:59:59.999 --> 99:59:59.999 The first part is the name of the image, the second part is a tag. 99:59:59.999 --> 99:59:59.999 They are very similar to how git tags work, except you're encourage to change them often 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Tags essentially point to a given layer 99:59:59.999 --> 99:59:59.999 and you essentially can use them for nearly whatever you want 99:59:59.999 --> 99:59:59.999 MAINTAINER, useless bit of metadata, not really important here 99:59:59.999 --> 99:59:59.999 RUN means when you're creating this image, run the following command 99:59:59.999 --> 99:59:59.999 'apt-get update' and then 'apt-get install -y nginx' 99:59:59.999 --> 99:59:59.999 which will actually install nginx into the container, that we're currently building in 99:59:59.999 --> 99:59:59.999 and then I 'rm -rf' all of the nginx/sites-*/* stuff 99:59:59.999 --> 99:59:59.999 because that gets volume mounted in, from my filesystem. 99:59:59.999 --> 99:59:59.999 So that when I configure a new app, 99:59:59.999 --> 99:59:59.999 I just drop the file in the hosts' /srv/docker/nginx 99:59:59.999 --> 99:59:59.999 and then I just kick the container and then it sees it 99:59:59.999 --> 99:59:59.999 in its /etc/nginx/sites-enabled/ 99:59:59.999 --> 99:59:59.999 and then the CMD, which is the default command that's run if no arguments are given 99:59:59.999 --> 99:59:59.999 there's also ENTRYPOINT, ENTRYPOINT is sort of like RUN 99:59:59.999 --> 99:59:59.999 except it is a little bit harder and it's also put before RUN 99:59:59.999 --> 99:59:59.999 Confusing these two can get confusing [laughs] 99:59:59.999 --> 99:59:59.999 Essentially it's this declarative style, 99:59:59.999 --> 99:59:59.999 it's sort of a declarative style 99:59:59.999 --> 99:59:59.999 and it's powerful enough to basically do what you want 99:59:59.999 --> 99:59:59.999 you can actually do this stuff manually in a container 99:59:59.999 --> 99:59:59.999 and then tag the resulting container 99:59:59.999 --> 99:59:59.999 but it's generally good practice to use docker files 99:59:59.999 --> 99:59:59.999 so that you can create what are known as automated builds. 99:59:59.999 --> 99:59:59.999 They used to be called 'trusted builds' but that name's terrible 99:59:59.999 --> 99:59:59.999 and automated builds are basically builds that are being done on the Docker index routinely. 99:59:59.999 --> 99:59:59.999 [question]: Just a quick question for those who haven't played around with Docker yet 99:59:59.999 --> 99:59:59.999 Does that mean if your machine crashes and you boot up again, 99:59:59.999 --> 99:59:59.999 it'll detect "Okay, I need this image" so you get new versions of packages 99:59:59.999 --> 99:59:59.999 from unstable and all hell breaks loose, or is it fixed at some point? Somehow. 99:59:59.999 --> 99:59:59.999 [Paul]: Yes, there are two different concepts here 99:59:59.999 --> 99:59:59.999 that I think I've failed to delineate, 99:59:59.999 --> 99:59:59.999 essentially there's a concept of an image 99:59:59.999 --> 99:59:59.999 and there's a concept of a container. 99:59:59.999 --> 99:59:59.999 A container is an instance of an image, 99:59:59.999 --> 99:59:59.999 so container's always started from an image. 99:59:59.999 --> 99:59:59.999 So this declarative style of build things 99:59:59.999 --> 99:59:59.999 is building an image and the resulting image here is called paultag/nginx 99:59:59.999 --> 99:59:59.999 When I run this with a 'docker run paultag/nginx', 99:59:59.999 --> 99:59:59.999 it's assigned a pseudo-random name built on words 99:59:59.999 --> 99:59:59.999 so like, "feisty_turing" or "angry_stallman" 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 'stallman' was added recently, it's amazing! [laughs] 99:59:59.999 --> 99:59:59.999 The actual individual containers are given these opaque names. 99:59:59.999 --> 99:59:59.999 So you start an image and your given a container that's from that image. 99:59:59.999 --> 99:59:59.999 If my machine was to shutdown and everything was to start up again, 99:59:59.999 --> 99:59:59.999 it would still be using the same image unless I rebuild it in the meantime 99:59:59.999 --> 99:59:59.999 in which case, that's probably expected behaviour. 99:59:59.999 --> 99:59:59.999 Any other questions about this stuff so far? 99:59:59.999 --> 99:59:59.999 [question]: So how do you deal with security updates? 99:59:59.999 --> 99:59:59.999 [Paul]: Yes, security updates. That's great. 99:59:59.999 --> 99:59:59.999 Best practice here is to continuously rebuild your images 99:59:59.999 --> 99:59:59.999 and the Docker index has support for this, 99:59:59.999 --> 99:59:59.999 give it a repo and it'll watch for changes, post-commit hooks. 99:59:59.999 --> 99:59:59.999 When you change something, it'll rebuild the image and put it up on the index 99:59:59.999 --> 99:59:59.999 At which point you just pull it and kick your containers. 99:59:59.999 --> 99:59:59.999 If you don't use something like that, you're building it locally, 99:59:59.999 --> 99:59:59.999 you can have something on a cron that rebuilds the images 99:59:59.999 --> 99:59:59.999 and kicks the containers that are currently active. 99:59:59.999 --> 99:59:59.999 So the idea is that by using something declarative like this, 99:59:59.999 --> 99:59:59.999 that every time that debian:unstable image updates, 99:59:59.999 --> 99:59:59.999 it's going to have the latest security fixes 99:59:59.999 --> 99:59:59.999 so that when we rerun this and retag the image locally 99:59:59.999 --> 99:59:59.999 then we're going to get the security updates as well. 99:59:59.999 --> 99:59:59.999 Essentially containers should be, in my opinion, always read-only ephemeral. 99:59:59.999 --> 99:59:59.999 So you shouldn't be making any changes inside the containers, 99:59:59.999 --> 99:59:59.999 if you're writing anything that should be mounted onto the host. 99:59:59.999 --> 99:59:59.999 So that at any point, I can just trash all of the containers, 99:59:59.999 --> 99:59:59.999 start them up again and they then have the latest version. 99:59:59.999 --> 99:59:59.999 With minor interruptions. Which is similar enough. 99:59:59.999 --> 99:59:59.999 It's sort of the difference immutable versus mutable 99:59:59.999 --> 99:59:59.999 think of virtual machines as sort of mutable, 99:59:59.999 --> 99:59:59.999 you can update them, you can change their state. 99:59:59.999 --> 99:59:59.999 Docker container, really, they should be immutable. 99:59:59.999 --> 99:59:59.999 When you replace them, they should be an atomic replace. 99:59:59.999 --> 99:59:59.999 So Lisp versus Python, who's ready? 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Any questions about this so far? 99:59:59.999 --> 99:59:59.999 Okay cool, I'm going to continue talking. 99:59:59.999 --> 99:59:59.999 Basically the only reason I gave this talk 99:59:59.999 --> 99:59:59.999 was to use the Unicode heart (âĽ), to see if any of the software would crash. 99:59:59.999 --> 99:59:59.999 It didn't, which was a huge disappointment, 99:59:59.999 --> 99:59:59.999 so hopefully this turns into more of a discussion pretty soon 99:59:59.999 --> 99:59:59.999 Again, another strong opinion from myself: 99:59:59.999 --> 99:59:59.999 that you should really only use container linking, 99:59:59.999 --> 99:59:59.999 SkyDock used to be something that I was preferring 99:59:59.999 --> 99:59:59.999 but it ended up being really buggy 99:59:59.999 --> 99:59:59.999 and ate up all of the free memory on my system 99:59:59.999 --> 99:59:59.999 and OOM-killed nearly everything, 99:59:59.999 --> 99:59:59.999 which was not fun, it ended up taking about 2GB. 99:59:59.999 --> 99:59:59.999 That kind of was a bad day. 99:59:59.999 --> 99:59:59.999 So I generally use container linking, 99:59:59.999 --> 99:59:59.999 all Docker containers when they're spawned 99:59:59.999 --> 99:59:59.999 are given a private IP address on a docker0 interface 99:59:59.999 --> 99:59:59.999 so they all can talk to each other behind the docker0 interface 99:59:59.999 --> 99:59:59.999 and when you bind to a port in a container it's bound to a container-local IP. 99:59:59.999 --> 99:59:59.999 Container linking basically rewrites the /etc/hosts, 99:59:59.999 --> 99:59:59.999 which is a bit of a hack, but it works. 99:59:59.999 --> 99:59:59.999 It essentially rewrites the /etc/hosts to point to another container's IP address. 99:59:59.999 --> 99:59:59.999 So it has the other 127.xx.xx.xx IP address, 99:59:59.999 --> 99:59:59.999 and this let's two containers talk to each other 99:59:59.999 --> 99:59:59.999 So my Postgres container's up but it's not bound to my public IP, 99:59:59.999 --> 99:59:59.999 it's bound to it's container IP. 99:59:59.999 --> 99:59:59.999 Then other containers will talk to it, using container linking. 99:59:59.999 --> 99:59:59.999 So it'll mean my web-apps know about Postgres, 99:59:59.999 --> 99:59:59.999 so you can connect to postgres://postgres@postgres:postgres.postgres.postgres/ 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 The Docker API. 99:59:59.999 --> 99:59:59.999 I have so many things to say about it, it's not great. 99:59:59.999 --> 99:59:59.999 Essentially, more and more stuff has been duct-taped to it, as time has been going on. 99:59:59.999 --> 99:59:59.999 So to correctly tell it what ports to map, I think you need to find it in two places, 99:59:59.999 --> 99:59:59.999 which is the host config and the run config. 99:59:59.999 --> 99:59:59.999 Which you need to pass during 2 different POSTs 99:59:59.999 --> 99:59:59.999 And it's kind of a pain with mounting stuff in volumes. 99:59:59.999 --> 99:59:59.999 The API that Docker exposes is very much an implementation detail 99:59:59.999 --> 99:59:59.999 more than a public facing thing you should be playing around with. 99:59:59.999 --> 99:59:59.999 I've written plenty of Docker API clients, they are not fun. 99:59:59.999 --> 99:59:59.999 So if I could basically dissuade you in any way, I really want to. 99:59:59.999 --> 99:59:59.999 If you really want to play with on, put on a helmet. 99:59:59.999 --> 99:59:59.999 It's seriously good advice, this API can probably- 99:59:59.999 --> 99:59:59.999 for a while 'id' was spelt 3 different ways: 99:59:59.999 --> 99:59:59.999 there was all uppercase 'ID', 'Id' and 'id' all lower case. 99:59:59.999 --> 99:59:59.999 Docker images are super cheap, they're all built on each other. 99:59:59.999 --> 99:59:59.999 Essentially you have different layers on an image. 99:59:59.999 --> 99:59:59.999 Every time you perform an action, you're pulling from all of the images below it 99:59:59.999 --> 99:59:59.999 So when I say FROM debian:unstable, it's basing all of your changes from the 99:59:59.999 --> 99:59:59.999 debian:unstable layer 99:59:59.999 --> 99:59:59.999 So if you only make a couple of minimal changes, it's really cheap. 99:59:59.999 --> 99:59:59.999 So the more and more layers you add, it's not really that bad. 99:59:59.999 --> 99:59:59.999 So if you extend FROM debian:unstable in a couple of places, 99:59:59.999 --> 99:59:59.999 it's not actually duplicating that material on disk, 99:59:59.999 --> 99:59:59.999 it's just all in that one place, that one layer. 99:59:59.999 --> 99:59:59.999 You should definitely use images for as much as you can. 99:59:59.999 --> 99:59:59.999 Having good images is definitely a huge improvement over trying to do this stuff raw. 99:59:59.999 --> 99:59:59.999 Asheesh has a question. 99:59:59.999 --> 99:59:59.999 [Asheesh]: How are they cheap? 99:59:59.999 --> 99:59:59.999 Is it using copy-on-write, is it using aufs? 99:59:59.999 --> 99:59:59.999 Is it using a custom block layer? What? Huh? 99:59:59.999 --> 99:59:59.999 [Paul]: Great. Thanks, Asheesh. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Yes, so they are written to the filesystem 99:59:59.999 --> 99:59:59.999 and mounted on top of each other in a variety of fun ways. 99:59:59.999 --> 99:59:59.999 You can either use device-mapper, 99:59:59.999 --> 99:59:59.999 you can use aufs or you can use btrfs. 99:59:59.999 --> 99:59:59.999 device-mapper should not be used under any circumstances. 99:59:59.999 --> 99:59:59.999 I don't know why it's still in the tree, it's pretty bad. 99:59:59.999 --> 99:59:59.999 I used it on my- 99:59:59.999 --> 99:59:59.999 What's that? 99:59:59.999 --> 99:59:59.999 [comment]: (inaudible), aufs 99:59:59.999 --> 99:59:59.999 Compared to-, yes- 99:59:59.999 --> 99:59:59.999 aufs is not great, but it is much better than device-mapper. 99:59:59.999 --> 99:59:59.999 So it is what I'm using until btrfs becomes a bit more stable 99:59:59.999 --> 99:59:59.999 I want to switch to it, but I haven't had the chance to switch my VPS to 99:59:59.999 --> 99:59:59.999 btrfs. 99:59:59.999 --> 99:59:59.999 So right now the most stable backend, in my opinion is aufs, 99:59:59.999 --> 99:59:59.999 yes, it's deprecated and there are plenty of operating systems that don't ship 99:59:59.999 --> 99:59:59.999 aufs bundled anymore, like Arch. 99:59:59.999 --> 99:59:59.999 So that turns out to be a problem. 99:59:59.999 --> 99:59:59.999 But whatever you do, avoid device-mapper. 99:59:59.999 --> 99:59:59.999 So essentially it uses copy-on-write for everything, 99:59:59.999 --> 99:59:59.999 including the containers. 99:59:59.999 --> 99:59:59.999 Everything is mounted on top of each another 99:59:59.999 --> 99:59:59.999 using a variety of different methods 99:59:59.999 --> 99:59:59.999 So it's definitely definitely cheap. 99:59:59.999 --> 99:59:59.999 Yes basically ensure you can hard reboot your machine, 99:59:59.999 --> 99:59:59.999 kill all the offline containers and start everything back up 99:59:59.999 --> 99:59:59.999 and have it work. 99:59:59.999 --> 99:59:59.999 [Russ]: So there's a question on IRC: 99:59:59.999 --> 99:59:59.999 If everything layered on top of a base layer, 99:59:59.999 --> 99:59:59.999 what happens when you upgrade the base layer? 99:59:59.999 --> 99:59:59.999 Does everything on top of it break? 99:59:59.999 --> 99:59:59.999 [Paul]: Yes, so this is- 99:59:59.999 --> 99:59:59.999 No, this is great. 99:59:59.999 --> 99:59:59.999 So every time that you create a new image, 99:59:59.999 --> 99:59:59.999 it's given a new hash, it's given a new layer ID. 99:59:59.999 --> 99:59:59.999 So you're recreating the image from something new, 99:59:59.999 --> 99:59:59.999 so essentially the immutability principle holds, 99:59:59.999 --> 99:59:59.999 you'll have the old layers, which you'll still be based on. 99:59:59.999 --> 99:59:59.999 But they'll basically unreferenced tags, commits that are hanging out that 99:59:59.999 --> 99:59:59.999 aren't being referenced by anything. 99:59:59.999 --> 99:59:59.999 They are given a super descriptive name in the Docker images output, 99:59:59.999 --> 99:59:59.999 which is "" [laughs] 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 and these are essentially layers that are sitting around that have kind of moved on. 99:59:59.999 --> 99:59:59.999 So if you FROM debian:unstable and debian:unstable updates, 99:59:59.999 --> 99:59:59.999 then you're going to have an image based on IDs that aren't referenced 99:59:59.999 --> 99:59:59.999 by debian:unstable in a couple of weeks, 99:59:59.999 --> 99:59:59.999 which is why people like to continuously upgrade these things. 99:59:59.999 --> 99:59:59.999 Hopefully that answers the question. 99:59:59.999 --> 99:59:59.999 OK, be sure you can start everything back up and have everything just work. 99:59:59.999 --> 99:59:59.999 The easiest way of doing this, is treating them all as ephemeral read-only 99:59:59.999 --> 99:59:59.999 process wrappers. 99:59:59.999 --> 99:59:59.999 Some of the most interesting stuff- 99:59:59.999 --> 99:59:59.999 That was just a small review of Docker for anyone who doesn't know. 99:59:59.999 --> 99:59:59.999 Now this is the good part. 99:59:59.999 --> 99:59:59.999 Docker is totally installable by running 'sudo apt-get install docker.io' 99:59:59.999 --> 99:59:59.999 All of you guys should do that, it's great. 99:59:59.999 --> 99:59:59.999 Upstream, tianon in particular, has a super stripped down Debian image 99:59:59.999 --> 99:59:59.999 which is really good to base stuff off of, 99:59:59.999 --> 99:59:59.999 it's super lightweight and it's pullable from stock Docker. 99:59:59.999 --> 99:59:59.999 If you're interested in the changes from debootstrap, 99:59:59.999 --> 99:59:59.999 again they're documented in a shell script: 99:59:59.999 --> 99:59:59.999 /usr/share/docker.io/contrib/mkimage-debootstrap.sh 99:59:59.999 --> 99:59:59.999 Which I think might be the deprecated version, I can't remember. 99:59:59.999 --> 99:59:59.999 If you're doing a lot with Docker, feel free to check out what that's doing 99:59:59.999 --> 99:59:59.999 and make your own image. 99:59:59.999 --> 99:59:59.999 For Debian development, because I feel like this is going to start coming up, 99:59:59.999 --> 99:59:59.999 don't use the Docker image from the index. 99:59:59.999 --> 99:59:59.999 Don't dput stuff that you build with that image. 99:59:59.999 --> 99:59:59.999 If you're really trying to use Docker to package stuff, 99:59:59.999 --> 99:59:59.999 build the base image yourself. 99:59:59.999 --> 99:59:59.999 I think that's pretty sane advice. 99:59:59.999 --> 99:59:59.999 Just like pbuilder or sbuild, you wouldn't trust a chroot that you wget, 99:59:59.999 --> 99:59:59.999 don't just trust a Docker image that you're pulling from the Internet. 99:59:59.999 --> 99:59:59.999 Which brings me to another fun point. 99:59:59.999 --> 99:59:59.999 dbuilder, or something like that. 99:59:59.999 --> 99:59:59.999 Someone should totally do that. 99:59:59.999 --> 99:59:59.999 Having a backend that's as flexible as Docker would be really interesting. 99:59:59.999 --> 99:59:59.999 Having something with a pbuilder like interface 99:59:59.999 --> 99:59:59.999 that uses Docker containers on the backend is something I've been interested 99:59:59.999 --> 99:59:59.999 for a long time. 99:59:59.999 --> 99:59:59.999 You can even tag images with build-deps installed, 99:59:59.999 --> 99:59:59.999 so you don't have to have that warm-up time everytime. 99:59:59.999 --> 99:59:59.999 All sorts of crazy stuff. 99:59:59.999 --> 99:59:59.999 If anyone's interested in doing that, I'd love to talk with you about how to 99:59:59.999 --> 99:59:59.999 do that. 99:59:59.999 --> 99:59:59.999 Essentially I want to turn this BoF into, 99:59:59.999 --> 99:59:59.999 "What can Docker do with Debian? What can Debian do with Docker?" 99:59:59.999 --> 99:59:59.999 Because that's sort of what I'm interested in, 99:59:59.999 --> 99:59:59.999 I see a potential and hopefully other people do too. 99:59:59.999 --> 99:59:59.999 A quick overview of some future plans before we start more discussion, 99:59:59.999 --> 99:59:59.999 nightly builds, check-ish. 99:59:59.999 --> 99:59:59.999 We have nightly builds going to PPAs. 99:59:59.999 --> 99:59:59.999 I need to set up a debile cluster, to get nightly builds for Debian. 99:59:59.999 --> 99:59:59.999 These are mostly useful for myself and other people interested in testing 99:59:59.999 --> 99:59:59.999 nightlies, and making sure packaging works continuously. 99:59:59.999 --> 99:59:59.999 That's something I've been interested in, 99:59:59.999 --> 99:59:59.999 something that's mostly kind of working, 99:59:59.999 --> 99:59:59.999 props to tianon. 99:59:59.999 --> 99:59:59.999 Backports, we have a lot of stuff backported in a PPA. 99:59:59.999 --> 99:59:59.999 We need to upload that to pretty Debian soon, 99:59:59.999 --> 99:59:59.999 but it involves backporting Go. 99:59:59.999 --> 99:59:59.999 Which means that we need to commit to maintaining Go in stable. 99:59:59.999 --> 99:59:59.999 So as you can probably guess, I'm not super on top of that. 99:59:59.999 --> 99:59:59.999 I would love to see more Debian people push for content-based IDs of layers. 99:59:59.999 --> 99:59:59.999 So those layers I was talking about aren't actually given IDs based on the 99:59:59.999 --> 99:59:59.999 content of the layer, they're just IDs. 99:59:59.999 --> 99:59:59.999 If we had content based IDs, then we could do better stuff 99:59:59.999 --> 99:59:59.999 such as verifying the integrity of an image, 99:59:59.999 --> 99:59:59.999 or signing of images, which would be really cool 99:59:59.999 --> 99:59:59.999 so that we could gpg sign an image 99:59:59.999 --> 99:59:59.999 and then assert that it's the image that we have. 99:59:59.999 --> 99:59:59.999 Or set up a Docker daemon somewhere that only runs images that are pgp signed. 99:59:59.999 --> 99:59:59.999 Which would be awesome. 99:59:59.999 --> 99:59:59.999 Basically limit the stuff, to only stuff I've signed. 99:59:59.999 --> 99:59:59.999 Potentially trusted Debian image, somehow? 99:59:59.999 --> 99:59:59.999 I'm not sure what that would look like, 99:59:59.999 --> 99:59:59.999 what the logistics of that would look like. 99:59:59.999 --> 99:59:59.999 For now I think decentralising this and pushing it to all the people probably 99:59:59.999 --> 99:59:59.999 makes sense. 99:59:59.999 --> 99:59:59.999 Docker 1.2.0 has been released this week 99:59:59.999 --> 99:59:59.999 and I plan to upload it into unstable 99:59:59.999 --> 99:59:59.999 as soon as md2man is through NEW. 99:59:59.999 --> 99:59:59.999 So that should be really soon now. [laughs] 99:59:59.999 --> 99:59:59.999 OK, right. Who's ready to flame. 99:59:59.999 --> 99:59:59.999 [question4]: I've kind of been following Docker upstream development 99:59:59.999 --> 99:59:59.999 and I've noticed the version numbers were 9 months ago 0.2, 0.3, 0.4 99:59:59.999 --> 99:59:59.999 just jumping and we're already at 1.2 we're talking about a jessie freeze 99:59:59.999 --> 99:59:59.999 maybe this year. 99:59:59.999 --> 99:59:59.999 How do you plan to maintain that going forward 99:59:59.999 --> 99:59:59.999 or keep up with upstream, do you have any thoughts there? 99:59:59.999 --> 99:59:59.999 [Paul]: I don't think there's a good answer for that. 99:59:59.999 --> 99:59:59.999 The 1.0 release was supposed to be something a little more stable 99:59:59.999 --> 99:59:59.999 and more maintained, it's not turned out that way. 99:59:59.999 --> 99:59:59.999 1.2 is much more stable and much better supported than 1.0 right now. 99:59:59.999 --> 99:59:59.999 I can't imagine that's true in the future, 99:59:59.999 --> 99:59:59.999 but I'm hoping if we can sync Ubuntu and Debian on a particular version, 99:59:59.999 --> 99:59:59.999 the collected user base will be enough to pressure upstream. 99:59:59.999 --> 99:59:59.999 Which I think would be something worthwhile. 99:59:59.999 --> 99:59:59.999 The Docker upstream is super friendly and they're all really awesome. 99:59:59.999 --> 99:59:59.999 I love them all dearly. 99:59:59.999 --> 99:59:59.999 I poke fun at them plenty 99:59:59.999 --> 99:59:59.999 and I've definitely poked fun at them in this talk 99:59:59.999 --> 99:59:59.999 and I'm sure I'm going to hear about it. 99:59:59.999 --> 99:59:59.999 They're definitely amazing and want good things for the world. 99:59:59.999 --> 99:59:59.999 So I think if there was definitely a use case in which this made sense 99:59:59.999 --> 99:59:59.999 and I think a stable release of Debian and a couple of versions of Ubuntu maybe 99:59:59.999 --> 99:59:59.999 then I think we could probably pull off some support. 99:59:59.999 --> 99:59:59.999 It's a good point, fair point. 99:59:59.999 --> 99:59:59.999 But Docker 1.2 outclasses 1.0 in nearly every way. 99:59:59.999 --> 99:59:59.999 So it's definitely not worth keeping us on a "stable" version, 99:59:59.999 --> 99:59:59.999 that's not better in any way. 99:59:59.999 --> 99:59:59.999 Oh come on. Flame! 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 [question5]: So you said it's not suitable to prevent exploits 99:59:59.999 --> 99:59:59.999 Is it basically the design of Docker as in the tool 99:59:59.999 --> 99:59:59.999 or is it rather the underlying interfaces provided by the kernel 99:59:59.999 --> 99:59:59.999 that are not sufficient to run, say student admissions when assessing student work? 99:59:59.999 --> 99:59:59.999 [Paul]: I'm trying to live-exploit Docker in front of you. 99:59:59.999 --> 99:59:59.999 [question5]: I guess I wasn't quite clear. 99:59:59.999 --> 99:59:59.999 Something running inside a Docker container 99:59:59.999 --> 99:59:59.999 [Paul]: Oh inside Docker. 99:59:59.999 --> 99:59:59.999 See, now I'm root on the host. 99:59:59.999 --> 99:59:59.999 [question5]: Yes but you screwed up by calling Docker. 99:59:59.999 --> 99:59:59.999 So if I'm calling Docker in a sensible way 99:59:59.999 --> 99:59:59.999 is it reasonable to run untrusted code inside a well-prepared Docker container? 99:59:59.999 --> 99:59:59.999 [Paul]: Oh I see. 99:59:59.999 --> 99:59:59.999 Yes, if you change the user off root in the Docker container 99:59:59.999 --> 99:59:59.999 there is much less of an attack surface. 99:59:59.999 --> 99:59:59.999 And yes, if you're not a user with permissions, 99:59:59.999 --> 99:59:59.999 it's a lot harder to do this. 99:59:59.999 --> 99:59:59.999 and it definitely provides some level of isolation, 99:59:59.999 --> 99:59:59.999 it's just the kernel namespacing stuff 99:59:59.999 --> 99:59:59.999 I don't think was meant to provide bullet-proof security. 99:59:59.999 --> 99:59:59.999 It was meant to provide rough security. 99:59:59.999 --> 99:59:59.999 And I think it definitely does that pretty well 99:59:59.999 --> 99:59:59.999 and if you keep users as non-root 99:59:59.999 --> 99:59:59.999 it's pretty trivial to exploit this. 99:59:59.999 --> 99:59:59.999 So yeah, you're right, this particular exploit 99:59:59.999 --> 99:59:59.999 is because I can run Docker 99:59:59.999 --> 99:59:59.999 and the docker group is root-equivalent. 99:59:59.999 --> 99:59:59.999 But yeah, you should be fine. 99:59:59.999 --> 99:59:59.999 [question6]: Just a quick comment on that. 99:59:59.999 --> 99:59:59.999 If you are running developer's code on production systems, 99:59:59.999 --> 99:59:59.999 you probably want to use SELinux in combination with Docker 99:59:59.999 --> 99:59:59.999 [Paul]: Yeah, that's good advice. 99:59:59.999 --> 99:59:59.999 [question7]: With OpenShift, they use SELinux 99:59:59.999 --> 99:59:59.999 to isolate the containers from other things. 99:59:59.999 --> 99:59:59.999 [Paul]: Awesome. Yes, SELinux sounds like it could be a solution. 99:59:59.999 --> 99:59:59.999 [question8]: As somebody who helped maintain SELinux for a while, 99:59:59.999 --> 99:59:59.999 please don't trust SELinux for a single source of security. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 I don't recommend it, it's a great thing 99:59:59.999 --> 99:59:59.999 as a part of a defence and dev strategy 99:59:59.999 --> 99:59:59.999 But if it's the only thing lying between you and remote root, 99:59:59.999 --> 99:59:59.999 you're going to have a bad day. 99:59:59.999 --> 99:59:59.999 [Paul]: So all software's terrible. [laughs] 99:59:59.999 --> 99:59:59.999 [Russ]: So have you experimented any with the various privilege isolation, 99:59:59.999 --> 99:59:59.999 system call limitation and similar privilege separation stuff in systemd? 99:59:59.999 --> 99:59:59.999 Because you're using unit files around Docker, 99:59:59.999 --> 99:59:59.999 have tried playing with adding that stuff in to do the containerisation. 99:59:59.999 --> 99:59:59.999 [Paul]: I have not, and that's a great idea. 99:59:59.999 --> 99:59:59.999 That would be awesome. 99:59:59.999 --> 99:59:59.999 Who else has great ideas on how to break Debian with Docker? 99:59:59.999 --> 99:59:59.999 [question9]: aufs backend for Docker has a 42 layer limit 99:59:59.999 --> 99:59:59.999 [Paul]: Well that's fun 99:59:59.999 --> 99:59:59.999 [question9]: Yeah, you obviously haven't hit that one yet. 99:59:59.999 --> 99:59:59.999 [Paul]: 127? 99:59:59.999 --> 99:59:59.999 [question9]: 127 now 99:59:59.999 --> 99:59:59.999 [Paul]: I'm so confused. [laughs] 99:59:59.999 --> 99:59:59.999 So I guess, it it hurts, don't poke it. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 [question?]: Trying to attract more flames. 99:59:59.999 --> 99:59:59.999 Would it be reasonable to expect all Debian infrastructure to have Docker run commands? 99:59:59.999 --> 99:59:59.999 So we could run them on all machines easily and develop on them? 99:59:59.999 --> 99:59:59.999 [Paul]: So I've been playing around with Dockerizing dak. 99:59:59.999 --> 99:59:59.999 Yeah right, um. [laughs] 99:59:59.999 --> 99:59:59.999 I haven't spent too much time on it, 99:59:59.999 --> 99:59:59.999 but it's definitely a goal of my to 'docker run' 3 containers 99:59:59.999 --> 99:59:59.999 and have a working dak/debile set up. 99:59:59.999 --> 99:59:59.999 That will let you dput packages in source form, 99:59:59.999 --> 99:59:59.999 to a directory and end up with an apt-get able .deb directory 99:59:59.999 --> 99:59:59.999 somewhere else. 99:59:59.999 --> 99:59:59.999 It's something I'm definitely interested in, 99:59:59.999 --> 99:59:59.999 Dockerizing more of Debian infrastructure 99:59:59.999 --> 99:59:59.999 so people can run it, test it locally. 99:59:59.999 --> 99:59:59.999 and have the steps it takes to set it up in a Docker file, 99:59:59.999 --> 99:59:59.999 is like perfect. 99:59:59.999 --> 99:59:59.999 It's exactly what I love Docker for. 99:59:59.999 --> 99:59:59.999 Having something like that, where you can make some changes 99:59:59.999 --> 99:59:59.999 and then do a 'docker build' of the current directory that you're working in 99:59:59.999 --> 99:59:59.999 and being able to test it, without worrying about setting it up on the host. 99:59:59.999 --> 99:59:59.999 That would be key, that would be awesome. 99:59:59.999 --> 99:59:59.999 I'd love to play with that. 99:59:59.999 --> 99:59:59.999 [Asheesh]: Just to make the flame temperature increase. 99:59:59.999 --> 99:59:59.999 It seems like Docker, by promoting a world of process-based isolation, 99:59:59.999 --> 99:59:59.999 decreases the importance of things like Debian Policy 99:59:59.999 --> 99:59:59.999 which are all about having programs be co-installable and not step on each others toes 99:59:59.999 --> 99:59:59.999 and this seems sort of consistent with, I don't know, 99:59:59.999 --> 99:59:59.999 the way that the San Francisco bay area based development community operates 99:59:59.999 --> 99:59:59.999 (of which I'm now a part) 99:59:59.999 --> 99:59:59.999 where we just sort of install some sort of base operating system 99:59:59.999 --> 99:59:59.999 and then just pour files all over the system 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 But I guess I'm supposed to ask a question, 99:59:59.999 --> 99:59:59.999 so the question is: 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 [Paul]: Please form your flame in the form of a question. 99:59:59.999 --> 99:59:59.999 [Asheesh]: Yeah, but the question is really 99:59:59.999 --> 99:59:59.999 Should Debian take more seriously the idea that things like Policy 99:59:59.999 --> 99:59:59.999 may be less important over the next 2-15 years 99:59:59.999 --> 99:59:59.999 and alter Debian packaging accordingly? 99:59:59.999 --> 99:59:59.999 Russ! 99:59:59.999 --> 99:59:59.999 [Russ]: So there- [laughs] 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 So there are several pieces to what Policy does for you. 99:59:59.999 --> 99:59:59.999 What I would say is, there's a set of problems that Debian has tried to deal 99:59:59.999 --> 99:59:59.999 with for many years 99:59:59.999 --> 99:59:59.999 that are a bunch of the things that are in Policy 99:59:59.999 --> 99:59:59.999 which are you say, are about being able to install a bunch of stuff that 99:59:59.999 --> 99:59:59.999 prior to Debian putting a bunch of work into it, 99:59:59.999 --> 99:59:59.999 would have actually conflicted with each other 99:59:59.999 --> 99:59:59.999 and given all that Debian did, now they don't conflict with each other. 99:59:59.999 --> 99:59:59.999 There's a bunch of stuff like alternatives and diversions 99:59:59.999 --> 99:59:59.999 and all that kind of thing. 99:59:59.999 --> 99:59:59.999 I think that stuff is still going to be useful in a lot of cases, 99:59:59.999 --> 99:59:59.999 it's possible that will not be useful inside the little Docker containers 99:59:59.999 --> 99:59:59.999 that you're using to run production infrastructure. 99:59:59.999 --> 99:59:59.999 I think we'd all be pretty happy to see that happen, 99:59:59.999 --> 99:59:59.999 those are often workarounds for problems 99:59:59.999 --> 99:59:59.999 that are not as good as just having the one thing installed. 99:59:59.999 --> 99:59:59.999 Like for example, one of the things I want to use Docker for 99:59:59.999 --> 99:59:59.999 is to set up test MIT KDC and Heimdal KDC, 99:59:59.999 --> 99:59:59.999 so I can test Kerberos code against both of them 99:59:59.999 --> 99:59:59.999 and right now the packages conflict because of a bunch of reason. 99:59:59.999 --> 99:59:59.999 and you can kind of fix that with alternatives, 99:59:59.999 --> 99:59:59.999 except you can't really fix that with alternatives, 99:59:59.999 --> 99:59:59.999 because kadmin index is completely different 99:59:59.999 --> 99:59:59.999 and then you get into a big argument. 99:59:59.999 --> 99:59:59.999 So there are parts of Policy like that that will be less important 99:59:59.999 --> 99:59:59.999 I think that even when you put everything inside Docker, 99:59:59.999 --> 99:59:59.999 having all of the binaries in /var/tmp is still not useful 99:59:59.999 --> 99:59:59.999 when something goes wrong and you want to find the command that went wrong 99:59:59.999 --> 99:59:59.999 and you didn't think to look in /var/tmp for the command. [laughs] 99:59:59.999 --> 99:59:59.999 So I think there's still some role for, 99:59:59.999 --> 99:59:59.999 "I installed this thing, now where the hell did all the bits of it go?" 99:59:59.999 --> 99:59:59.999 and I want to configure this thing, I would like all of the configuration 99:59:59.999 --> 99:59:59.999 files to be in the configuration file directory 99:59:59.999 --> 99:59:59.999 and not scattered off in root's home directory. 99:59:59.999 --> 99:59:59.999 So that part of Policy I don't think really changes. 99:59:59.999 --> 99:59:59.999 [question?]: So what Paul gave us, was a bunch of recommendations 99:59:59.999 --> 99:59:59.999 on top of what Docker, if you can calls it that, describes. 99:59:59.999 --> 99:59:59.999 Isn't that something that would be useful as part of a Debian Docker policy 99:59:59.999 --> 99:59:59.999 as in, how do you Dockerize applications for Debian 99:59:59.999 --> 99:59:59.999 and in that case, what you can have is 99:59:59.999 --> 99:59:59.999 you can still have alternatives and diversions and everything else 99:59:59.999 --> 99:59:59.999 that actually allows you to have packages co-exist inside that debian unstable base image 99:59:59.999 --> 99:59:59.999 and you still need that to build your base images, or any images for Docker. 99:59:59.999 --> 99:59:59.999 You could have some sane recommendations 99:59:59.999 --> 99:59:59.999 on how to lay things out with Docker on top of that. 99:59:59.999 --> 99:59:59.999 [Paul]: Yeah, interesting. 99:59:59.999 --> 99:59:59.999 I hadn't really thought about that too much. 99:59:59.999 --> 99:59:59.999 If people would be happy with documenting best practices in Debian with Docker, 99:59:59.999 --> 99:59:59.999 I'd be happy to spend time and effort 99:59:59.999 --> 99:59:59.999 I don't know if me dictating that kind of thing is the best idea 99:59:59.999 --> 99:59:59.999 I think if other people want to try coherent thoughts around this 99:59:59.999 --> 99:59:59.999 that would be a lot of fun. 99:59:59.999 --> 99:59:59.999 Oh come on, you've got more than that! 99:59:59.999 --> 99:59:59.999 [question?]: Within the next 20 minutes, can we Dockerize Subsurface? 99:59:59.999 --> 99:59:59.999 [Paul]: I've got 5 minutes left. 99:59:59.999 --> 99:59:59.999 [question?]: There's a man here in 20 minutes who's going to be upset about 99:59:59.999 --> 99:59:59.999 the fact that Surface isn't using static linking 99:59:59.999 --> 99:59:59.999 [Paul]: Run 'sudo apt-get install subsurface' 99:59:59.999 --> 99:59:59.999 Should be good. 99:59:59.999 --> 99:59:59.999 [question?]: We solve all of our static linking problems that way? 99:59:59.999 --> 99:59:59.999 [laughs] 99:59:59.999 --> 99:59:59.999 [question?]: You said that you were using, Docker was using aufs 99:59:59.999 --> 99:59:59.999 Did you have some problems with the stability of aufs? 99:59:59.999 --> 99:59:59.999 [Paul]: I have not. 99:59:59.999 --> 99:59:59.999 Most of my problems have been using non-aufs backends. 99:59:59.999 --> 99:59:59.999 As a matter of fact, I can't even get the kernel to run on Linode 99:59:59.999 --> 99:59:59.999 because the kernel is built without aufs on it. 99:59:59.999 --> 99:59:59.999 I actually have a blog post where 99:59:59.999 --> 99:59:59.999 I load from Xen grub, to grub 0.9 to grub 2.0 to the Debian kernel 99:59:59.999 --> 99:59:59.999 because the old grub Xen doesn't support .xz compression. 99:59:59.999 --> 99:59:59.999 Which is great. 99:59:59.999 --> 99:59:59.999 [laughter] 99:59:59.999 --> 99:59:59.999 Yeah it is, so if someone wants to get aufs working on Linode, 99:59:59.999 --> 99:59:59.999 there's a blog post somewhere. 99:59:59.999 --> 99:59:59.999 Alright, I think I'm out of time 99:59:59.999 --> 99:59:59.999 but we can keep talking about Docker stuff. 99:59:59.999 --> 99:59:59.999 Cool. 99:59:59.999 --> 99:59:59.999 [applause] 99:59:59.999 --> 99:59:59.999