It's the new virtualization. I'm happy to be here. I'm happy to be here. So if you guys know me, I've worked in copywriters for a number of years. I was involved in a copy project before that. And I've done a bunch of stuff. I've been involved in open source for about 15 years.

And this is my second or third Fosdam. I have a funny accent. This is one of the places where my funny accent is. I'm originally from Australia, but these days I live in the United States. Those of you who also know me know I have a long history of writing technical books. Usually for companies they end up working for.

One of the reasons I ended up working for Puppet Labs is I wrote a book about Puppet. And I started writing a book about Docker. And as it turns out, I end up working at Docker. The book will be available in a couple of months when Docker 1.0 comes out, which will soon be March, April or so. I've decided to wait until we've actually got a solid feature set before I finish it.

So, who are you folks here? Is anyone here a developer? Anyone here a sys admin? Anyone here both? Or a DevOps person? DevOps doesn't work that way. Oh, and there's bangs. Anyone here not one of those things? Anyone here a security person?

Anyone here just does everything in the shop because there's no one else? Okay, Jeff Wiesen. Jeff Wiesen's the rank manager. So, I'm going to talk a bit about what Docker is, why it exists, and then some accounts. So,

essentially, Docker is container virtualization. So, think about there's two types of virtualization. Traditionally, there's hypervisor virtualization, where each virtual machine is its own instance and it lives on top of the whole stack, or it lives on top of a hypervisor fake hardware box, I guess.

So, container virtualization is different than the other kind of virtualization, operating system virtualization, where essentially, every one of your virtualizing services shares the same kernel, shares the same CPU, it's separated by something in this case, we default to LHC virtualization, so it's separated by namespaces in the sequence. So, essentially, you get a chunk of the process, a chunk of the CPU, a chunk of

the system's resources all divided up into I guess what you best describe as little fences around it. So, it's not quite as separate as a hypervisor virtualization, but it is very fast and very lightweight. So, Docker is more than just LHC.

Docker is actually an abstraction framework built on top of LHC, so it's built, essentially, it says, we want to be able to talk to a container, a thing we think about as a little virtual instance, and we build an API and a series of a bunch of workflow tools around that to allow you to talk to it. It's designed so you can create standard images, we call them images,

you can build those images really easy, you can ship them around to different places and you can add them. And it's essentially designed to build once, build an image that does something and then run it in multiple places. And it's as isolated as we think you need, and it's sort of read through the content, you can also think about that, and it doesn't really care where it runs, it's not supposed to do it for them, but it's

what's really been independent. A lot of people I've talked to have gone, but this isn't new, LHC has been around for, they've just released version 1.0 beta 3 or something like that, and LHC has been around for a while. Those of you who have grey hair or no hair like me remember in Nodhar's logical partitioning on platforms like ZOS and AIX and

some people even remember Solaris Zones Sean up the back there I think talked earlier about Sean is that an old Solaris hack, there's not really a few of them around now. So this isn't a new concept, the idea of operating system virtualization is not new. And we don't claim it's a new thing that there's a lot of people, but we've already got stuff but what we claim is the way of

actually addressing containers and looking at them building workflow and an API around them. So making it easier this existing technology needs to be used. So why would I care? I think the key difference that we try and summarize is that it's virtualization

and it may be easier. I'm a big fan of tools like Vagrant I spend a lot of time living out of VirtualBox I hear VirtualBox with a deep and abiding passion I've yet to upgrade VirtualBox but I didn't fuck something on my system. So I've also been a VMware customer on a number of

different versions and I've received a number of VMware invoices usually with large numbers of zeroes at the back of them. I look at this as a much lighter and cheaper way of deploying virtualization. And it's a little bit I won't call it anti-dead-ops it's certainly not it has a moment where it's sort of like

it is trying to do a little bit of isolation where the stuff that inside the container the developers care about inside the container and the applications that people care about the operation systems that admin people care about what's outside the container. And so Luke Knees who is around at the conference somewhere but also is famous for having a written puppet

many years ago wrote a blog post called about golden images. Those of you who have been sys admins for a while will remember the period of time where golden images existed essentially it was a you had a DVD and it had like a a long string of numbers on it usually like 2003-12 v2 RRR 777 release date.

And that DVD was the standard operating image for your environment. Maybe it was back in the day it was a 3 box or something. And you used really cool tools like Norton Ghost anyone who knows Norton Ghost and no short is going to put his hand up it's probably going to be the only person and you basically shipped around this image and you built your service from it.

And of course what happens is you wanted to upgrade the image then you needed to burn a new DVD and you needed to ship the DVD around. And guess what happens? It's very hard to read images in a way like that. It is a non-trivial port. It's like, I can't rebuild this configuration is not able to I can no longer install it and I end up doing things like getting on a machine manually upgrading packages manually making configuration changes.

And this was called the golden image port and you ended up having one single image that was in fact instantiated across multiple different forms across your environment and puppet came out of that essentially you wanted to actually manually have a base operating system in order to state manage your components you wanted to manage all these different things.

The issue that really struggled and why things like Confident Chef became quite interesting was that this was a much faster way of doing the configuration management. Docker being very lightweight and very fast building a new image is a matter of minutes and it's a very simple process, it's a very simple DSL that articulates how you build the

image. And then spawning a container from the image is like this so you don't have that couple of minutes of creating your new image or installing your new operating system or following some build steps you just have a Docker run, you have a container based on an image. So it sort of overcomes some of the problems you have with that golden image workflow

which is that you have that time to do protection building from just building. If it's very cheap for you to do that, why would you throw away the original build and build from scratch. I'll talk a bit later about why some ways we allow you to do this in Eclipse. This is sort of my summary of why developers care

and I'm not going to go through every single dot point, but I do a lot of we have a lot of people who are particularly interested in continuous integration, continuous deployment workflow, so their code starts in a Git checkout on their laptop, they do a bunch of development, if

they're a tool like Vagrant, and they have a local machine running, or they have an instance running out of an ESX cluster or on Amazon where they run their tests or they test and the code actually works. Then that code gets promoted up to another environment, maybe Jenkins gets run at that point, some test suite

stuff, some artifacts get built, war files get shoved into artifact and lots of stuff. That sort of lifecycle stuff is where we see Docker's initial bread and butter, which is that you can very cheaply and very simply create a run-time new environment that's isolated from your desktop or isolated from your environment and you can tweak that environment

and change it a little bit. So instead of having to wait for Vagrant, while it's extremely fast, it'll take a couple of minutes to run an instance, whereas Docker Run, a very simple part of the process where you instead of creating the container The other piece of magic we introduced is the concept of a image registry. So essentially what happens is you can create a new image like I would like to have application 1's image

and I can push that new image up to our new registry and then all of the developers in my environment have access to the registry and now all the new images down there don't have the ship. I worked in a company that shipped new vapor boxes around on USB keys, which I was like you people are mad. People do it. You don't have to wait to upload a new 100 meg image

until you get a very fast simple process. And the reason that a lot of developers find this really interesting is that you can actually because containers are so lightweight and I'll talk a little bit about how we do that lightweight asset for storage is that it's very easy to maintain multiple operating environments. So I can maintain

at a very cheap rate I can maintain a version of 60 different versions of Rails if I'm doing that or else they're gone. Or I can maintain Python 2 and Python 3 and so quite simple containers. Operations care about containers there's similar reasons that people care about configuration management which is that

it makes the lifecycle more efficient it's really easy to introspect on the container to say what state the container is and what it looks like they're very easily manageable and very easy to make change about and they have the same advantages that configuration management provides essentially the environment you know your developer is working in locally you know they're using this particular image you know what makes up that image

and you know that if you push that image through the various environments from the dev test to the production environment you're running the same bit of code which provides you that consistency knowing that the same puppet manifest built the test environment the same puppet manifest the production environment. They support a recently clean segregation of views

and they essentially for a lot of little cases they provide a lot of much faster workflow So I talked a bit before about virtual chains in the cloud and why they're the sort of got-goes that attract you I talked a bit about the speed of things, but there's a couple of other aspects

I want to share. One is that containers are relatively portable like the container images are easily easy to move around and the way that it's easy to move around portable is because we create them with a layered human file system so what happens is that each image is built with a set of instructions that say install this our base image is the one off of

Docker, it says like build another every instruction I give you build another human layer on top of that container. So what happens is that made up with a single image for example like a image and I want to build on top of it so I go I would like to build and store rails

so I run, you know, general store rails or I do an app get and store rails and my preference If I then want to make another change for example I want to create a new image which has a new version of rails I don't need to change that base image all I need to do is make the change to the instruction on top of it so the single layer is changed so instead of having a change

and basically there's a very good box for a new one and it makes a 600mm box file I only have to change the one layer so that one step is the only thing I need to change which means that it's very fast The other thing is because it's so lightweight you get a far higher density so like we've got a number of customers for whom the number of images, the number of

virtual machines they have they can get double the number of containers to a single box and if you're talking to a CTO or CIO about that they're going to be happy with the idea of the fact that they can cut their virtualization and so cheap things

The technology stack is really simple it runs on most of these distributions the idea behind the initial model release was supported in LMC which was recently offered so it's going to be included in Red Hat and Red Hat enterprise will have Docker 1.0 natively

and in the support of Red Hat similarly in Debian the next step of the release and the next step of the tool is release it relies heavily currently on namespaces and signatures those are familiar with that it's a way of providing separation of processes and resources in the network system

and underneath the lay-in file system we talk about it supports things like the device map system, provisioning model and paper face which is a really good file system but the really interesting thing about the next one is the major or perhaps a feature is this going to be a problem so if you like the Solaris zones then you can run the Solaris zones

underneath that as another execution feature so essentially you get the benefits of the Docker API and the workflow this is a very fast tool process and the APIs are associated with that but you can run LMC or XAMPP or KVM currently our base plugin which we're using for testing is a separate JIRA job which means you can then

start to run a bunch of different platforms BSD is the first one we've seen somebody is actually building a sales implementation right now for BSD which you can start to think about solutions you can do like networking and stuff like that running on firewalls and switches but we're also starting to see support for

discussion about support for Solaris OS X and a bunch of other platforms this is a visual representation of how the model works essentially it's a very simple kernel you have the

first piece of signature space move file system have a base image and each of these layers is built on top and I'll talk about each of those components this is what we call a doc file a very widgetly named configuration file it basically contains the same instructions

we're building out by the base that one of those contains from our images you see it from Ubuntu this is our base image this might be say a Ubuntu 12.4 this image is available, we have a public registry which can contain things like a Minimal Builder or a Minimal Builder

or a Minimal Builder or a Minimal Builder or a bunch of other platforms I specify the information this is on the maintainer of it and then I have a series of instructions in this case this container this image creates an Apache 2 image so I say, I want to install Apache I want to set some environment variables I want to say, when I run a container

from this, I want to set up the networking to make sure that port A is available and then I want to say, when the container that I build from this image is run I want to run some default commands this is essentially like a boot up script like a little container so let's say I'm a developer and this is going to be this is going to be how we build our baseline Apache 2 containers

I create this image I build it and the build process essentially takes that base image downloads it and then runs those commands and builds each layer on top and basically publishes the end of it and here's my image and it gives you a little chart and it says this is the version of the image and I can give it an alias

I'm giving it a namespace alias saying this is my image this is my namespace and this is my Apache 2 image and if you have a look on our index.docker.io site you'll see this actually images available and then push that image upstream so I push that image to a registry we make a public registry available but you can also run the registries over the source so you run it privately inside behind your firewall

and from this point in time anyone else can then take that image and do something with it so in this case I'm going to say I'm now a developer and I've got an email saying there's a new version of the Apache image available so I say I'm going to run Docker I'm going to run it in it's demonized mode

so I'm going to create a demonized container I say I want to make sure port 80 is open what happens is on your system it says open up port 80 and it's going to assign me a random port like a high level port on my local machine so I can run multiple containers I'm then mounting my application so this mounts, literally mounts

the application as a file system inside the strategy inside the container this means that I can do things like I have my web application or I have my database or I have my data itself in some sort of storage system NFS, we're going to support a bunch of other storage platforms shortly and I can make whatever changes I want there and the container runs on top of it

and it treats it very much like a shared file system or a shared file system you can think about in the virtualization world and then I'm told this is the image I want to run it takes about some second performance to create to launch the container from here and this is now available I have my slide

I was managing it last night but essentially from here I can then just point my I can identify which, I'll get all the same what port is available, I can then point my browser at that port, I can make all my changes to my application hit refresh, see what my web application will be developed then I'll watch the database run we've got a bunch of

we're seeing a bunch of really interesting use cases for Docker Gilt in New York for a fashion startup a very service architecture company they run everything in microservices they're replacing their entire execution environment with microservices running on this lab they have an Erlang Scala shop and they have Redis and WeApp and a bunch of other services

they're just going to put each of those in several containers link all of those containers together and build environments and use that as their service architecture we're seeing lots of people doing this local development there's Jenkins development a good example is there's some stuff published recently about how to use Docker as an execution in new Jenkins, so

if you imagine it takes a couple minutes to run a virtual machine or if you're using EC2 it takes a few minutes to create an EC2 instance to run your tests on, in this model some second availability for a machine, incredibly easy to rebuild that image so every time you upgrade the image, build a new baseline image, you can then recreate that and then run your tests on top of the

works for containers from that we've seen people whose previously their provisioning time in Jenkins might be 5-10 minutes to actually get just the boxes running, you get a clean, fresh build of the instance in a matter of seconds and from here there's a bunch of other things we're looking at, which is integration with things like configuration management, orchestration

if you have lots of containers running and multiple data centers, how we share the talk and talk about that and see some things published in the last couple of weeks about how you can use those tools to keep GCD and things like that to actually share configuration information across multiple environments questions?

This is one of those things where I keep putting up these signs in the documentation saying here be dragons

I think we're just about to release 1.8 and it's pretty stable but the 8 guys are reasonably solid I'd be very surprised if it changed automatically between now and then my sort of don't-use-a-brush-all-of-those-lives-are-not-support-related like I can't provide you with any support from the 5.0 but

Red Hat is replacing its container model for OpenShift with Docker Docker is currently the workman's staff flavor of containers the largest install I know is Waidu in China and Yandex in Russia and they're both running Waidu has a Google App Engine

like product that uses Docker they have tens of thousands of containers in Yandex so people are using it for action my biggest concern is the anti-stability and that's heading towards I think that's

more on portability if you look at sort of you want to have that workflow and then say the API did not address these multiple virtualization platforms

and several people have tried to do this Dave Lotter called it the delta cloud product and it's essentially designed to abstract away the differences between virtualization products and with FOB and tools like that they've not been used in successful so I don't think they address the workflow piece of it they provide an API but they don't provide a mechanism for the lifecycle of the virtual machine particularly they don't provide mechanisms to recognize that

virtual machines have a much faster lifecycle so they manage it using Docker with different exclusives as you can say I can run locally on LSE and we have a portal to Docker which runs, creates a local Docker daemon on ISX and allows you to do local development, I can then take that exact same unit in the same way

and I can promote it into a VMWare environment, I can promote it into a Zener environment I can get it promoted to but it happens to me it's the workflow there

I think it comes down to the sort of classic

you know, how I think the containers are recently the Galaxy is a reasonably solid technology in most cases I would say any sort of fast changing data probably should be mounted into a container any sort of static there are thousands of things if you are

doing a web front end with Docker in a way where it's actually serving static content you know, back to an app server then yeah, just include it if it's a stable microservice like some sort of API input or something like that just include that inside the container

we also have a concept of linking containers together essentially I can say here's a container I want to link to this other container that runs my database and it creates an encrypted tunnel between the two containers and it doesn't expose any ports it allows you to say, address using inside your application if you want to consume data from the database

or store something over here then go after that that's pretty basic at the moment for the moment, yeah, I think there's only one form of, we only do for a mount currently that's all we do so at the moment that's probably

the simplest thing when we have more storage options then there might be and when we can directly address different options

sorry, what's that, sorry? so my yeah, my argument is that the golden image is that the technology wasn't fast enough to make the change and that in a lot of the use cases that now that you can actually very quickly recreate the image

and very quickly spawn containers from that image the golden image probably is not as large as it used to be, I think it still exists and you can still end up with multiple hierarchies of images you can get yourself in any rabbit hole you like to say there's been a recline of this we all know this, right? somebody realized something's been really like, bashed I know we're not being sarcastic and all but it's pretty true there's still a lot of hacky slashy scripty stuff

so I look at I look at this workflow as at the moment there's a certain percentage of tasks you would do that Docker makes a lot of sense for in its current field and as we sort of expand, you make that main role or change, you make it more use cases out of it several people have posted using Docker with Chef

examples of how you build a Chef powered Docker image and then running it over Google to cover that, same, I published a lot of those recently about doing the same thing with puppet and puppet modules I don't know where it would go I think there's going to be huge expanse of use cases I'm certainly not saying you should throw your puppet manifest away

but I think in certain cases where the workflow is much faster I would seriously look at whether you would how you would, whether you would use puppet further I guess you would first drive upstream and then downstream you would be building images and running containers from that there's much different ways you can slice it I don't think the future is yet even in the district

so there's a very, there's a couple of very at the moment there's a couple of API's that might change a little bit but there's an events API that essentially says you know, you can basically poke in and see the logs and see the standard input output logs you can also poke in and inspect the container

see a bunch of running metrics you can also see events that happen inside the container and we're going to build a stronger introspection API over the top of that so you can do things like if you see this event inside the container then trigger a hook you know, here's a hook that came off that hook or here's an API call you should make or if I want to be able to

manipulate the container and sort of way, so that's something that we come with in our variables Ok, fair enough No, I'm actually, I'm probably in a minority

at Docker actually, I think most of the most of, I don't know what the best would be but I'm Solomon and about 50-60% of the development team are French and there are there's lots of Linux desktops I'm a hipster, I live in Brooklyn so you know, I have to have a Mac I can't, you know, I have to explain

I have to explain to people what Linux is but I don't want to recommend it So we have two things to mitigate that

so the image has a concept called trusted builds trusted builds are essentially someone's published an image and it's linked via to a GitHub repo and you have to actually link your GitHub account to the index and essentially it says this is the repository this is the repository this is where this came from and here is the Dockerfile that builds this so you can actually get introspect on that

and see that this build came from this repository at this commit, using this particular Dockerfile and the second thing we're adding to the index on top of that is we're adding crypto so essentially you'll be able to sign images so what we're looking at from my Red Hat example we'll take their base CE their base certificates and they will sign their JBoss image each OpenShift container will be signed

so it has provenance back to a all the way up to the chain trust to say this comes from I will keep talking until Walter tells me to shut up So CoreOS

some of you guys might know Alex Wolby who cloud was a cloud matrix company that he's got a new venture called CoreOS and essentially it's an operating system

built around Docker so essentially it's an operating system just enough operating system that allows you to spawn Docker containers and it's really designed I can't speak for too much but it's really designed so if you're a PaaS and you want to run an operating system that is tuned and built to just spawn high density containers

I think the big challenge with that is that it is an operating system replacement and if you're doing something that's not PaaS-like then it's kind of I think the utility of it if you're a RHEL customer the idea of throwing away your RHEL and replacing anything outside of a particular opposite use case They have also released a product called ETCD

ETCD which is like Zookeeper except it's usable I love Zookeeper but it's a pain in the arse to set up and ETCD is so much nicer This is what I would have wished for when I was operating system production

Thank you very much everyone Really appreciate it