 OK, so the next session will be by Tim Potter about advancing container support in Debian. Thanks. OK, thanks, everyone. So I'm just going to talk today about containers, a little bit about what they are in case you haven't heard of them. I'd be surprised if anyone hadn't. Kind of some of the reasons why people like them and what we are doing in Debian to try and let people use containers. So to start off, containers are actually not really, I guess, like everything under the sun. There's nothing new. Containers are a way of implementing very lightweight virtualization. So instead of having to emulate a complete server hardware down at the instruction set level, we're doing virtualization at a much higher level at the process level. So containers are sometimes referred to as process-based virtualization. And our containers are implemented using two kind of technological features in Bill and his kernel, control groups, and namespaces. So control groups are a way of having more fine-grained access to resources on the machine. So you can do a lot more in terms of restricting access to different CPUs or memory. You can, oh, thanks very much. You can place limits on the network use and IOU siege of a process or a group of processes. It's all about resource control. And namespaces is another feature in the Linux kernel and it allows processes to be isolated from one another at the operating system level. And this isolation can occur at several different levels, so at the process table level. So processes can't see other groups of processes on the machine. It looks like they're the only process running on the machine. For network, you can give a process or a group of processes their own networking IPv4 or IPv6 networking stack that's completely isolated from the rest of the machine. You can have a different mountain namespace between processes and user. You can have a different set of user IDs, group IDs, and IPC and UTS, so inter-process communications. And I believe that's kind of host name. UTS refers to host name and domain name type of things. So not only can you isolate processes from one another using all these methods, you can also share them as well. So you can have two different sets of processes sharing a network stack or it can be completely separate. So it's very fine-grained as well, like control groups. And it's the combination of these two things, control groups and namespaces that make containers work on Linux. Brief history of players here, there's probably more knowledge in the room here about this than I have. But I'm trying to give a general overview. You might remember OpenVz and Linux vServer. These were quite old in internet time, quite old systems for doing process virtualization. So again, the idea is you've got one server and you can run multiple kind of other containers, virtual private servers inside this one machine without having to do the full hardware virtualization. So it was a kind of predated virtualization as we know it today. So OpenVz and Linux vServer, I think, OpenVz is still going. They're still producing releases, which is pretty fantastic to see. And our containers, I guess as we know them today, kind of came into being mostly with LXC, LXC for Linux containers. They're, it takes the control groups and namespaces technologies that I mentioned, put some nice user space tools for managing them and creating and destroying containers. And then along came Docker. I think everyone here has probably heard of Docker. And Docker came along and I guess it didn't really introduce anything new technologically. It's still underlying bits and pieces are still the namespaces and control groups. But Docker came along with some really good user space tools and this kind of idea of being able to share container images very easily. So there's a image registry for Docker. You can say, you know, Docker pull Debian and it'll suck down Debian image and you can get going quite quickly. If you've ever used, personally, when I use LXC, I found it a bit clunky to try and create images and get started. But Docker, I think their innovation, one of their innovations was this being able to get started very quickly and having a shared image repository. And yeah, what's next? I don't know. Docker seems like it's invincible at the moment. They've got all the mind share and all the developer share but disruption in the industry is a way of happening and surprising people. So who knows what's gonna come next. So it seems to me that everyone's gone container crazy. You can't kind of read an IT magazine or something without someone talking about Docker. It's really quite amazing and it's even, I found this little graph here a while ago. But this graph was originally done in 2015 and I reproduced it here and it shows, I guess, okay, it's not a scientifically accurate graph. It's just a measure of the Google trends which is a number of searches for a particular topic. And the yellow line there is, sorry, the red line is, sorry, the yellow line is searching for a virtualization. Red is kind of open stack. I mean, if you thought open stack was crazy, I'd just look at the blue line there. So in 2015, the trend was kind of going upwards and then this year it's continued to go upwards at about the same rate. So that's kind of interesting. I'd, containers seem to be a bigger thing. I've got a question. Well, sorry, the microphone. Maybe people are searching for technologies they're having trouble with. Yeah, no, it's not very scientific. I mean, obviously it's, well, that would mean they're using it, wouldn't it? But anyway, it's not very scientific that I think, I thought it was interesting looking at the, comparing the graph from 2015 and I'm extending it to 2016. The trends are kind of continuing. So it's kind of interesting. Okay, so why has everyone gone container crazy? I don't know, I think Docker has just turned up at the right place at the right time with the right set of tools. And it's just kind of taken advantage of perhaps people's, I don't know, disillusionment with the complexity of OpenStack, I don't know. That's just a guess. Personally, I use containers, Docker a lot just for day-to-day development, being able to create a Debian image and then check some little thing about it. So where does this file come from? Anything like that and you can just destroy it again. So, well, I would have used virtualization. It's a lot quicker to use container. And there's so many application images as well, not just the operating system. So you can create a Jenkins server very quickly. You can make an elastic search cluster very quickly as well. It doesn't take anywhere near as much of time as it takes to build one up using virtual machines. So development, I think, absolutely fantastic. I use it all the time. And production, yeah, I've heard some, I haven't had any direct experience with HP customers using production, but I've heard lots of stories that people are out there doing lots of CI, CD with containers and using the isolation and reproducibility features of Docker. Okay, so a little bit about containers. I think that Debian is actually missing out on the chance to get a lot of new users and to have a lot of people use Debian that might not simply because we don't support containers very well at the moment. I think Debian's a great choice for containers because it's the qualities that we like of freedom and quality and security. And Debian, I've said Debian stable is stable, but what I mean is it makes a great host operating system. So if you have, I mean, ideally you want your host operating system running on bare metal to be really stable. It's got to have good kernel support, driver support, get security fixes, you know? And it turns out that it's a really, you want to have stable on your host and then something on your host as your guest as an unstable, sorry. You want to have something stable on your host and then your guest can do anything it likes and it's not gonna contaminate what's on the host and having helped run, build and run a kind of large public cloud, being able to separate your workload from your base operating system is just a really fantastic way of being able to run things without a lot of trouble. We can avoid operating system vendor lock-in by, you know, this host and guest thing. It's a, I mean, host and guest idea is something that virtualization has taught us. And yeah, we can avoid running, having to run Red Hat on our, I'm sorry, we can avoid to have, having run other operating systems on our host. And if you want to, and I guess what I'm trying to say, if you want to run, have everything free, you have to start from a free base. And so if running Debian as your base operating system for containers, I think this definitely helps. Avoid OS vendor lock-in. I'm probably meant to say you should buy lots of HP hardware so you can have hardware lock-in. That's fine with me. Okay, so Debian support for Docker. Yeah, the main problem here, well, not really a problem. For freedom anyway, Docker is available as a vendor package from docker.com and it's a binary deb file that you download and install, and security people might not be happy with that idea. What source code was it built from? None of us is, not only security people. Everyone, okay? Fantastic. Yeah, I mean, okay, so it's, yeah, I mean, we don't want to download random binary images from the internet and install them on a machine. I think that's a bad idea. Yeah, so vendor packages of open source and the commercial Docker are available, but we'd like to have it in Debian main. And this is something that the package Go and the Docker team and I have been working on. Yeah, we have fairly old versions in stable backports, 1.6, 1.8, 1.3 in testing, which is still pretty old, 1.8. And 1.11.2 just got uploaded a few days ago into unstable, which is fantastic. Yeah, so yeah, I guess, yeah, we're kind of struggling with this problem of, I guess you cannot be able to put new things into stable so you can use backports. Also, the Docker, yeah, they seem to be producing a lot of code in a very short time, every couple of months, there's a new version, which has more dependencies which need packaging. So it's quite a large effort to keep up with the sheer volume of coding that's going on, which is fantastic. It's great to see that we're getting new features and the whole industry is kind of moving along. But yeah, making sure this is in Debian is quite a bit of work. Another bit of software you might have heard about is Kubernetes. It's a kind of container orchestration platform that uses Docker as a backend. I think you can use other backends, but I believe most people use Docker. It's been going for a long time and it's very popular as basically as a pass. So as a platform for developing, we're distributing kind of large multi-node applications. And this is in Debian as well, but only in experimental. So we've done a lot of packaging work, getting Kubernetes. Yeah, interestingly, almost all of the container software is written in the Go language. So there seems to be this really interesting kind of, I wouldn't say it a renaissance, but there's really lots of interest in using Go as a language for writing system software. Yeah, so yeah, Kubernetes is an experimental, hasn't really been tested that much yet. Rocket is another interesting project. It's, I guess in some sense, it's another group of people who are not wanting, I mean, trying to avoid vendor lock-in from Docker. So we're writing, not a replacement for Docker, but a substitute or a complement for Docker. So it's still very much in incubation kind of development stage. And I don't think it's seen a lot of, I don't think it's seen a lot of uptake with all the March air being taken by Docker. Anyway, for interest in Rocket, we have it in testing and unstable. Okay, just to kind of close why I think we should be working on containers. So the fact is that containerization is driving a lot of computing at the moment. We have a lot of customers, a lot of our customers are very interested in using Docker in the development and in production. I've heard some stories from some of the sales people and HP that even very conservative customers like banks are very interested in this. You would not think of banks typically as being customers that would be adopting a lot of new technology that they've taken on this Docker and Kubernetes idea and are really running hard with it. So Debian risks, I believe Debian risks being left behind and losing growth through other distributions because quite frankly, we are not, we don't support containers at the level that I think we should be. So just the Debian packaging go team is a typical Debian team, 55 members with a kind of core team that works on Docker. So yeah, I think I don't want this to be a, we need assistance kind of pleading for help talk, but if you want to try out Docker in Debian, it's available in the main archive. So yeah, download it and try it out please. So thanks very much everyone and are there any questions? Yeah. All the other container to GCC go instead of Golang because the problem that we have with Golang is actually that it's not supporting too many architectures. Okay, yeah, good question. Yeah. I don't think that GCC go is the preferred go compiler at the moment by people in the go community, which is I guess is unfortunate because it's kind of what Debian is, I guess packaged it a lot. So yeah, it was actually quite difficult to bootstrap version 1.5 I think for ARM. Using GCC go, but as far as I know, I think everything's being built with the new go. So yeah, sorry, which platforms are you interested in? Okay, right. And another problem was that another problem with a Golang was recently that Golang upstream, they kind of wanted to drop power five support for power PC, big Indian. Okay. Which was kind of pointless because like no one was like, I mean, they wanted to raise the architecture level to power eight, which would have meant that, you know, that's the architecture that people can run the little engine port on. So no one would have been using Golang anymore on power PC, big Indian. So but luckily I was able to convince them to not to do that. Oh, great, okay, yeah. I guess we're somewhat of the mercy of upstream in this, because it's an entire language, I guess. There's not a lot of deep knowledge of going in Debian, I think, or at least some of the, myself included some of the packaging team don't have such a deep knowledge of go. So we're kind of following along. So we're running a bit out of time because we started late. We have one more question here. Cool. Tim, are there any plans to make official? Are there any plans on making official? Debian images for Docker? Oh, yeah, interesting, yeah. There are already official images. The images that you can pull from the Docker Hub built by some Debian team members already, sorry, some Debian developers already. So they're probably as official as you can get. Or you could go along to the cloud images bof, which I think is very shortly and find out. Yes, we had that discussion for various other cloud things too, and the Debian trademark team wants some sort of verification of those images before they are officially declared official Debian. Right, okay, sure. I mean, yeah, as I said, the images are generated by other Debian developers, so you can work directly with them. I'm not involved with that, so. Sorry. Okay. Guys, we're running out of time. Thanks, everyone. The next session starts in five minutes. So please talk to Tim after the talk, if you have any more questions. Yeah, sure. And I'm sorry about the delay. Thank you.