Docker is the future of shipping our code
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50626 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Data managementConfiguration spaceServer (computing)Programmer (hardware)BlogComponent-based software engineeringPatch (Unix)System programmingPhysical systemComputer-generated imageryConfiguration managementServer (computing)Patch (Unix)Configuration spaceThermodynamisches SystemSoftware testingMedical imagingProduct (business)MereologyMathematicsFunctional (mathematics)Web 2.0Asynchronous Transfer ModeOrder (biology)Data typeShared memoryOpen sourceBuildingFunctional programmingFile systemPhysical systemCartesian coordinate systemMultiplication signState of matterStack (abstract data type)Kernel (computing)DampingLogical constantSoftware developerINTEGRALThomas BayesPlastikkarteVideo gameCellular automatonBlogProgrammer (hardware)Software maintenanceService (economics)Open setVirtual machineCodeConnectivity (graph theory)Mobile appCuboidFile formatPoint (geometry)Table (information)System callWordGroup actionWindowInstallation artContinuous integrationCloud computingGoodness of fit
06:56
Virtual machineSanitary sewerVirtual realityMiniDiscServer (computing)Host Identity ProtocolAdditionFunction (mathematics)BootingComputer-generated imageryCodeMaxima and minimaQueue (abstract data type)Physical systemBuildingComputer hardwareComputer networkScaling (geometry)Software developerServer (computing)Computer hardwareCartesian coordinate systemMedical imagingSoftwareIntegrated development environmentFile systemMereologyCuboidComputer fileLevel (video gaming)File formatMechanism designOverhead (computing)Operator (mathematics)Different (Kate Ryan album)Analytic continuationCodeOperating systemSoftware developerPlastikkarteWritingMobile appMultiplication signPhysical systemStapeldateiAnalogyFunction (mathematics)WindowDrop (liquid)Encapsulation (object-oriented programming)DigitizingProcess (computing)Configuration managementOpen sourceGreatest elementMatrix (mathematics)Fitness functionContent (media)Computing platformElectronic meeting systemStructural loadForcing (mathematics)Right anglePhysical lawCycle (graph theory)Scaling (geometry)Game theoryException handlingCore dumpWordCommitment schemeHeat transferService (economics)INTEGRAL
13:43
Computer-generated imageryInstance (computer science)CuboidRepository (publishing)Medical imagingProcess (computing)Server (computing)Revision controlWindows RegistryCartesian coordinate systemMathematics
14:34
Repository (publishing)Windows RegistryVacuumInstallation artComputer-generated imageryComputer fileWindows RegistryCuboidMedical imagingRight angleRepository (publishing)MathematicsSource codeComputer animation
15:30
Computer-generated imageryHacker (term)Installation artCurvatureCAN busMathematicsElectronic mailing listNetwork topologyMilitary operationSpacetimeMiniDiscPublic key certificateDatabaseStandard Generalized Markup LanguageAcoustic shadowCore dumpProcess (computing)SoftwareComputer programmingMathematicsServer (computing)Medical imagingCuboidVideo gameWordIdentity management2 (number)Parameter (computer programming)Electronic mailing listInformationData analysisWindows RegistryCartesian coordinate systemRevision controlEntire functionDifferent (Kate Ryan album)ECosAreaComputer fileBinary fileState of matterArithmetic meanMessage passingWindowStapeldateiVideo game consoleRootkitMobile appComputer animation
19:38
Computer-generated imageryInstallation artHacker (term)EmpennageCurvaturePublic key certificateMilitary operationAcoustic shadowRun-time systemBitFerry CorstenDrop (liquid)Computer animationSource code
20:35
Hacker (term)Public key certificateTerm (mathematics)Front and back endsDivisorUsabilityComputer-generated imageryDatabaseCore dumpAcoustic shadowSoftware maintenanceProcess (computing)Repository (publishing)IcosahedronInstallation artMilitary operationWindows RegistryMultiplication signFlagRepository (publishing)Process (computing)Revision controlPlanningWindows RegistryInformationCartesian coordinate systemComputer fileMedical imagingPairwise comparisonMathematicsScripting languageMetropolitan area networkCuboidTemplate (C++)Uniform resource locatorThermodynamisches SystemStability theoryBlock (periodic table)BuildingEquivalence relationState of matterCASE <Informatik>Vertex (graph theory)WordFerry CorstenDifferent (Kate Ryan album)2 (number)Computer animation
24:23
Line (geometry)CodeComputer-generated imageryElectronic visual displayBlogCore dumpDatabaseLink (knot theory)Uniform resource locatorLetterpress printingRevision controlAliasingInstallation artIntegrated development environmentVideo game consolePrice indexDependent and independent variablesDenial-of-service attackCloningLoginDemo (music)Conditional-access moduleObject (grammar)Dirac delta functionConnectivity (graph theory)StatisticsData compressionThread (computing)BuildingRange (statistics)Physical systemVertex (graph theory)Formal languageModul <Datentyp>Directory serviceRun time (program lifecycle phase)Type theoryProcess (computing)Cartesian coordinate systemPhysical systemSign (mathematics)CodeComputing platformRemote procedure callContinuous integrationDemo (music)Plug-in (computing)TestbedTemplate (C++)Scripting languageService (economics)Equivalence relationCuboidRevision controlInstallation artConfiguration spaceServer (computing)Software repositoryVertex (graph theory)DatabaseWeb browserMobile appPairwise comparisonCASE <Informatik>Right angleQuicksortDifferent (Kate Ryan album)Address spaceState of matterLine (geometry)Figurate numberUltraviolet photoelectron spectroscopyOntologyOnline helpGame theoryMedical imagingWebsiteTraffic reportingProduct (business)Software testingInformation securityReading (process)Similarity (geometry)
28:27
Configuration spaceDenial-of-service attackCloningDirectory serviceUser profileType theoryProcess (computing)Integrated development environmentRun time (program lifecycle phase)BuildingPrice indexStatisticsDemo (music)Raster graphicsInsertion lossObject (grammar)Vertex (graph theory)Range (statistics)Revision controlCache (computing)Modul <Datentyp>BitCartesian coordinate systemMathematicsWeb browserBuildingVertex (graph theory)Mobile appProcess (computing)Pattern languageOffice suiteEndliche ModelltheorieDemo (music)Computer animation
29:35
Demo (music)CloningConfiguration spaceObject (grammar)BuildingVertex (graph theory)Range (statistics)Revision controlDirectory serviceCache (computing)User profileIntegrated development environmentRun time (program lifecycle phase)Type theoryProcess (computing)Video game consoleDependent and independent variablesPrice indexRaster graphicsRepository (publishing)Field (computer science)Real numberVariable (mathematics)Key (cryptography)System callRevision controlEquivalence relationMathematicsIntegrated development environmentConfiguration spaceCartesian coordinate systemRight angleVarianceSubject indexingDemo (music)Computer animationSource code
31:40
Menu (computing)Connected spaceRight angleIntegrated development environmentCodeSubstitute goodProduct (business)Configuration spaceCartesian coordinate systemSoftware developerVariable (mathematics)Process (computing)Set (mathematics)NumberString (computer science)IP addressComputer animation
32:28
User profileObject (grammar)BuildingDemo (music)Vertex (graph theory)Range (statistics)Revision controlDirectory serviceCache (computing)Run time (program lifecycle phase)Type theoryProcess (computing)Integrated development environmentDatabaseComputer-generated imageryMereologyPasswordNumberVariable (mathematics)Office suiteMereologyMedical imagingDatabaseConfiguration spaceCartesian coordinate systemPasswordRevision controlProduct (business)Data managementBuildingPrototypeUniform resource locatorGoodness of fitVertex (graph theory)WindowComputer clusterSource codeComputer animation
35:12
Software testingInstance (computer science)DatabaseConfiguration spaceData storage deviceShared memoryProduct (business)PhysicalismComputer architectureDifferent (Kate Ryan album)BitCartesian coordinate systemUniform resource locatorPhysical systemWeb browserWindowStorage area networkBootingGoodness of fitMedical imaging
38:27
BuildingHacker (term)Computer-generated imageryParameter (computer programming)Configuration spaceTwin primeLoginLibrary (computing)Revision controlLevel (video gaming)Error messageMessage passingDirectory serviceInternet service providerDefault (computer science)InformationIntegrated development environmentVirtual machineLogic gateMedical imagingVirtual machineComputer animationSource code
39:30
Parameter (computer programming)Computer-generated imageryConfiguration spaceChemical equationVacuumComputer fileInternet service providerPhysical systemImplementationSynchronizationDenial-of-service attackInstallation artData structureDirectory serviceEvent horizonOpen setRevision controlRepository (publishing)Finite element methodGamma functionBinary fileInformation securityDefault (computer science)Interface (computing)Link (knot theory)Variable (mathematics)MultiplicationData storage deviceMedical imagingScripting languageRight angleSheaf (mathematics)Computer filePlug-in (computing)Vertex (graph theory)Software2 (number)Software testingDirectory serviceTwitterMobile appEntire functionPhysical systemStructural loadProcess (computing)Data managementRevision controlDatabasePhysicalismMessage passingEvent horizonData storage deviceCodeWebsiteComputer virusSequelComputer animation
42:43
LoginWebsiteSoftware frameworkSoftware repositoryCloningIntegrated development environmentAxiom of choiceComputer configurationInstallation artAndroid (robot)Standard deviationServer (computing)Configuration spaceSoftware developerCone penetration testOracleFreewareVirtual machineExtension (kinesiology)MathematicsInsertion lossDirectory serviceDebuggerOpen sourceFigurate numberEndliche ModelltheorieMathematicsCartesian coordinate systemMultiplication signApplication service providerSource codeJSON
43:42
Thermodynamisches SystemService (economics)InferenceCache (computing)Control flowFile formatArc (geometry)Maß <Mathematik>Loop (music)InfinityRevision controlDefault (computer science)WhiteboardType theoryProcess (computing)TrailWebsiteOpen sourceWindowGoodness of fitPower (physics)Pattern languageServer (computing)Data managementMedical imagingParameter (computer programming)Windows RegistryLevel (video gaming)Thermodynamisches SystemComputer fileConfiguration spaceCodeOverhead (computing)Mobile appProduct (business)Operator (mathematics)Multiplication signMathematicsCartesian coordinate systemOnline helpPlastikkartePrototypeConfiguration managementPhysical systemProcess (computing)Vertex (graph theory)Revision controlService (economics)Computing platformDirection (geometry)Demo (music)Core dumpWeb 2.0DebuggerStack (abstract data type)Error messagePoint (geometry)Software testingForestRule of inferenceSoftware developerBit rateData miningCalculus of variationsSource codeJSONComputer animation
51:35
Raster graphicsNormed vector spaceExecution unitValue-added networkWebsiteConfiguration spaceUniform resource locatorRadical (chemistry)Software engineeringDemo (music)LaptopBitComputer animationSource code
53:05
Data structureVacuumTerm (mathematics)BlogSummierbarkeitInformation securityInformation privacyDefault (computer science)Interface (computing)Raster graphicsLine (geometry)Medical imagingCodeMultiplication signProduct (business)WordSoftware testingComputer animation
54:57
Computer animation
Transcript: English(auto-generated)
00:02
Excellent. Good morning. Find yourselves a seat. Everyone hungover? No? Anyone hungover, apart from me? No? Okay. Thank you all for coming to my talk. I know it's quite early. What time is it? 20 past 10.
00:20
So it's not too early. We're going to be talking about Docker today. Anyone know what Docker is? A quick show of hands. Does anybody understand it when I say the word Docker? Or do they just think I'm saying something completely different? Okay. So my name's Paul Stack. I'm an infrastructure engineer for a company called OpenTable. Now OpenTable are a US-based company that provide restaurant reservations.
00:44
I am a DevOps extremist. So I've been through a journey over the past few years of going continuous integration to continuous delivery now in the DevOps and trying to understand how it helps everyone and how it's very good for the business and that's how I discovered a tool like Docker. And I'm also a conference junkie.
01:00
This is like my eighth conference of the year so far. And it's only in June. He's excited. Configuration management tooling is awesome at the minute. Does anybody use a configuration management tool? Puppet, Chef, CF Engine, SaltStack, Ansible. Anyone use them? A few, not many. So these are tools that you tell the tool the state of the system
01:25
or the state that you want the system to be at and it will maintain that constant state. So if you have to have a user or a group or a piece of a file system or something there and it's not there, these tools will make that work happen to bring that up.
01:41
Configuration management is really, really good. But what it means is it means making changes to live systems. So if you have a server in production and you have a configuration management change that you need to make that is changing a live web server.
02:02
Some people feel that that's not very good. A guy called Chad Fowler, who's the CTO of 6Wunderkind who created the app Wunderlist. Fantastic app. And he wrote a blog post back in June last year that said trash your servers and burn your code. Immutable infrastructure and disposable components.
02:22
And it's a fascinating blog post. I'm not going to rehash it here, but there's three main points. People do make manual changes to systems during outages. Who here has been in firefighting mode where you've got a phone call and you're like, your app's not working.
02:40
And you log into an app and you're like, run a command. And then you're like, oh, that worked. Let's run another command and see if that works. But then if you have four web servers in a cluster and you have run that command on one web server, then you've got a cluster that's very imbalanced. It can be very dangerous. Developers who have pseudo access to servers run pseudo commands.
03:06
Pseudo app get install. The worst, worst thing that you can run because you have no idea what it may or may not do. Sometimes it will actually ask you for a Linux kernel update and it will start to download the word.
03:21
And the third part is operating systems get patches applied to them even in production. Anyone have patch nights or maintenance windows in their company? So every fourth... Is that me? That's just my rough beard.
04:15
I need to learn how to speak. So when you change live systems,
04:21
what you're effectively doing is what was once your pretty healthfully managed cluster with a configuration management tool is now potentially a house of cards waiting to fall over. We're not 100% sure what's going to happen. We don't know how our app is going to react in those situations. How many people when they do make operating system updates
04:42
or Microsoft updates have you tested your application on those updates first? A few. That's a lot less than I thought. So this does get you into the situation of it works on my machine and it worked before.
05:00
What patch would it have done? So this leads us to the idea of immutable deployments. This is a concept derived from the functional programming community. Any functional programmers here? So if there was no functional programmers here I would usually make a joke so I'm not going to. So what they've actually derived here is that
05:23
immutable data or what they believe or what they claim I don't know, I'm not a functional programmer is that immutable data types lead to systems that are harder to screw up. And I see nods. So we can apply the same principles from functional development to functional infrastructure.
05:42
So a question. If you need a system change, what do you do? You build a new image and you deploy that image. You build it from scratch every time. You need an application change? You build a new image and as part of that image you ship the application. It's already embedded. Is anybody mental enough to do this?
06:02
Netflix. Netflix, this is exactly how Netflix do it. They do not change any infrastructure. Anybody work for Netflix? They don't change infrastructure in production. They ship new images every time. I heard at a conference two weeks ago, three weeks ago that the average lifespan of a server in the Netflix cloud platform
06:22
is up to 36 hours. They're continually changing their images inside 36 hour increments. That's crazy. But this is all well and good when you're in a panacea world and the Nirvana sucks comments are going to come, right?
06:41
So obviously we've got the Windows versus Linux debate. It's much more difficult to build Windows servers than it is to build Linux servers. It's much more time consuming to build Windows servers than it is for Windows servers. We use a tool called Packer at OpenTable, which is an open source tool. And you basically write in JSON format
07:02
how you want a box image to look like. And Packer has got three pieces to it. It's got builders. It basically builds the app and it runs all your configuration management on the app and then it actually packages the app into whatever format you want.
07:21
When it goes to package it, it just takes an array of post processors and you can have vagrant boxes, Amazon AMIs, digital ocean droplets. You can write all of these different outputs off the end just using the same exact image every time. Amazon AWS don't use this. They have their own tool. But what we discovered is that
07:42
when we were packaging Linux or Ubuntu servers, they were like three or four hundred megabytes. When we were packaging Windows servers, Windows servers 2012, 2008, they're like four or five gig. Now transferring four or five gig up to AWS or whatever cloud platform you want every time
08:01
is very time consuming. So where does Docker fit in? So you can have a matrix like this, where you have pieces of your application on the left and you can have pieces of your infrastructure along the bottom. And what we essentially do is we have to check probably in a manual way
08:21
that our application works at every stage because we have different deployment mechanisms every time. Who deploys the same to QA as they do to production? Only a few people as well. This is what happens. It's very difficult to see what's going to happen
08:40
when we put code in these different environments. So we're going to call the analogy, please. This is what Docker actually use as their analogy. Cargo transport pre-1960. What you had to do was you had to load individual items on and off boats, on and off lorries, et cetera.
09:01
Things got damaged. Things were not repackaged in a very good way. And every time, at every leg of the journey, it could be packaged completely differently. Then they brought in the shipping container. You package everything in the shipping container once, and that goes the whole way to the destination.
09:21
Anybody see what's coming next? Docker is the shipping container. Docker is a shipping container for code. And it claims that you build once, or one, build once, that should say, and you run anywhere. Because you are not changing the system. You have built it, and you've packaged it,
09:41
and that same package can be delivered at all pieces. You configure it once, and it will run anything. Run on any piece of infrastructure that has the Docker engine on it. It encapsulates the application and dependencies. What does that mean? That's a really flowery statement.
10:00
As part of your deployment, you would bring any dependencies that it needs into the system. You think of Docker as a complete encapsulation of your application and its surrounding processes. Don't let it talk out to this piece, or this piece, or this piece. They would be encapsulated as other containers,
10:21
and you can do cross-container talking. It can run on any hardware without modification. That's actually not strictly true. It can't run on Windows. Resources, network, and content are all isolated. The application is key, because the way the Docker engine works
10:42
is that it doesn't have to worry about the network. It doesn't have to worry about resources, because they're all managed using the file system underneath, the readable file system. This avoids dependency hell. It's perfect for continuous integration, continuous delivery, autoscaling, et cetera, because they're standard operations to run, start, commit, search.
11:02
All of these pieces of the puzzle are already there. Lightweight, virtually no performance or startup penalty. It takes under a second for a Docker container to start. Now, some people in the big data world, they'll spin up hundreds of VMs at night,
11:20
and they'll do lots of batch processing on jobs, and then spin the VMs down. You can do the same thing in Docker containers, but you don't have the overhead of actually starting an entire VM. Developers can write code. Who cares about infrastructure? Who's an infrastructure engineer? Who actually deals with infrastructure in their day-to-day jobs?
11:43
Who hates dealing with infrastructure in their day-to-day job? We're software developers, right? Sometimes software developers don't care about the servers. They don't care about the network. They don't get into all these pieces. What they want to do is write code. They want to write applications and ship applications.
12:02
So containers versus VMs is always something that comes up right now. What is the difference between a container and a VM? So let's start on the left. So this is a typical hypervisor infrastructure. So you have a base server, and that base server has a host OS. And then on top of the host OS, you'll have a hypervisor.
12:22
So you'll run VMware or Hyper-V, whatever you want. But that has to sit on a base server. And then you have VMs. But each VM has its own operating system as well. This seems very wasteful. So Docker has taken this idea of being able to tap into the resources of the host.
12:47
So you would do something very easy, and you would say, I have a base server. I have a host OS, something like Core OS or Smart OS, something very, very lightweight. And then you would have the Docker engine that sits on top of that. Docker engine, right?
13:01
It's a simple, if you're on Ubuntu 14, apt-get-install-docker.io. They've even packaged it for us, which is great. And then you have applications or containers that sit on top. And those containers are just the applications themselves, nothing else. So they're very lightweight.
13:22
You can get thousands of containers on the same server where you could get hundreds of VMs. So you could instantly start to scale up your infrastructure when you need to. So there are many pieces to Docker. Actually, let's go and have a look at how the Docker works.
13:47
Can you read me? Anybody not read that? Excellent. So we can go, and I just spun up some EC2 instances this morning, just to show people what's there. And there's a very few simple commands.
14:02
So docker ps will show you all the Docker processes currently running. This is a brand-new Docker process. And what we can do, and we can say, give me all the Docker images that are available on the server. The only Docker image that we have on the server is Ubuntu.
14:21
The latest version, the latest tagged release of Ubuntu. Now, what's an image? An image is somebody has already created packages that you can run your application inside. Now, you can go. They have what's called the Docker registry. And if you make changes to packages, or you make your own packages,
14:41
you can upload them for public consumption. But there are official repositories. So Ubuntu, CentOS, Debian, Fedora, BusyBox, registry. There's a ton of people that are actually creating physical boxes. And you can go in and you can have a look at these boxes. And you can go to the source.
15:02
And at the heart of it, there'll be a Docker file right there. This is what makes the image. And what you can see is you say, from Ubuntu 14.04. Take that base Docker image, do these things to it, and then make my own image out of the back of that.
15:23
So you can take and you can apply on top of Docker images. Anyway, we'll go back in. And then you can search. So you can say, across the entire list of images,
15:42
search for Ubuntu. And it should return Ubuntu. It should return Ubuntu. There we go. And it goes off and it checks all the different versions of Ubuntu that's on the Docker registry and brings all that information back and you can see it.
16:02
It's not formatted very well because I've had this scroll in my window more than life itself, but it's there. So what can we do with them? So we can execute a single program. What you can do is you can pass Docker a command. And that command can be anything. It can be start this application, install this piece of software,
16:21
or just execute this job. So we're just going to do something like Docker run, starts the container, the name of the container, and then the command. So echo hello ndc-oslo. What you'll do is it's started the container, it's ran the hello ndc-oslo, and it's immediately stopped.
16:41
And somebody was like, well, it just looks as though you're echoing on the same console. So let's do something else. So this is the same server. The two green tabs means it's the same. Just they prove it's the same. So Docker ps, nothing running.
17:01
Sleep 20. You can now see that there is a container in place and that that command is sleep 20. It was created three seconds ago. The status of it is there, and it gives it a random name. But the important thing is it now is an actual live container. I've just launched a container,
17:20
and that is just stupidly fast to do. So if we go hello ndc-oslo again, you can see if you can count less than a second to spin that app up and execute that program. Now, obviously, echo is the simplest thing that you can possibly do. And notice that I changed hello word to hello ndc-oslo. But I'm making it relevant.
17:42
But the important thing is that that can be anything. That can be a batch process job. That can be the data analysis job. It can be whatever you want. So let's do something else. So all I was doing there was I was spinning up the docker container and actually getting it to execute a job in echo back.
18:03
You can attach interactively to the docker container itself. And what you do is you'll say docker run, and then you'll pass in some command line arguments like int, which means interactively. The image again will be Ubuntu, and when I go into Ubuntu, put me in bin bash.
18:23
Now, you'll see that currently it says root at ip 10, 89, 16, 39. As soon as I do that, I'm not inside a container. F1dc e54. And I can go across, and I can see f1d whatever.
18:40
I can't even read that. But you can see that that container is there and that the command that it's running is bin bash. Now, you can go and you can say apt get not life, of course. You would never change live software. apt-get install puppet. In fact, let's just prove that puppet is not on the box. Puppet version.
19:00
No command puppet. So you can do apt-get install puppet, and it'll download the word. But what you're actively doing is you've changed the state of your container. So you can then package that container, and you can let it go. You can do a job inside. That container is completely disposable.
19:21
You're not actually doing anything. You can all throw it away. Or you can keep it, of course. So let's stop that. Awesome. We can't stop that. So we can take this one further. So we saw the docker file, and we took from a base.
19:40
You can run apt-get update, and so before learning how to write a docker file, you can do something as simple as docker run ubuntu apt-get install dash y puppet. So that will actually spin up a container, and as well as spin the container up, it will install puppet on that container,
20:01
and it will make a new container. It's still installing. There we go. Docker ps. And then you can exit out of the container. So that container is now gone.
20:22
If I say docker ps, f1dce is no longer there. So I immediately spin up, immediately drop. Now, this is just going to do a little bit of installation,
20:47
but because I've changed the state of a box, I can now save that state of a box. So once this is finished, we'll show you that we actually have a different process running.
21:02
We can say docker ps l. Show me the latest change, the latest container that was running. And we can see that we had a container. It was built from the Ubuntu latest image,
21:20
and it had a command installed on it about a minute ago, and it had an exit of zero, which was good. So we can then say docker commit 13a92. Because these are all unique values, you can only put in the first few characters, like you can in git, and it'll work.
21:41
And we can call it Ubuntu puppet. What that's doing is that's saving the state of the box now, and that is actually an image that's now available for me to use. So I ran the command docker images before, and the only image that was available was Ubuntu. If I run the same command now,
22:01
you can now see that there is actually a repository called Ubuntu puppet. So you can start to see where you can go with this, because you can create these awesome build files that create your containers that your applications can run inside. It's all scriptable, and because it's all scriptable, you can test it anywhere, which is really good.
22:20
So let's try and do something. We're going to pull down Node.js. Docker pull Bowery node. This is something that's currently in the Docker registry. And if you download it, it will actually go off. It will download all the different layers, and it will make that available as an image.
22:41
And then what I'm going to do is I'm going to, when it finishes downloading, I'm actually just going to run a Node.js application, just the equivalent of just a node version, just to get something back to make sure that you're connecting the node itself. If this works, any time today?
23:05
Just thinking about it. Any questions while we're waiting on that?
23:26
Docker push. And then you can say usage docker push name, push an image or repository back to the registry. The commands are very like Git, aren't they? They've almost ripped them off.
23:42
It's a public registry. Now, of course, there's always private plans. I don't work for these people, so I'm not selling any tools. I'm trying to just show you that it's actually pretty cool, but you can buy private repositories and stuff like that, or you can just set up your own Docker registry inside your company and just share them inside company, and then that way you don't even have to push them public.
24:01
If you've got sensitive information that you don't want to put public, then that's maybe a better way. This is downloading the word. What it does is it goes off, and by layer by layer by layer, it recreates the image for you, so it's going off and getting all the pieces, including all the tags. So we'll come back to that one in a second. So this is super fast moving
24:24
in comparison to the old way of doing things. We would have had to wait before on VMs to spin up or packages to be made available in our system so that we could build templates from. Now, there are hundreds and hundreds of use cases for Docker.
24:43
So there's lots and lots of platforms as a service. I've actually seen hosted Postgres using Docker, but it has a big sign across the website saying this is not production-ready. This is just a test bed for them. There's drone.io, which is a continuous integration system
25:00
built on top of Docker. That's perfect, right? Spin up CI boxes or CI images, run your tests, destroy it. Don't leave long-running images around. But there's also one called Doku. Doku is that they claim to be the smallest platform as a service ever. It's actually written in a hundred lines of code. Now, Doku sounds like Heroku.
25:24
And it actually works in a similar way. Heroku spins up dynos. Doku spins up Docker containers. But the reason it's so small and so lightweight is it takes advantage of Docker. It takes advantage of the build steps and the build packs that were open-sourced amazingly by Heroku.
25:40
And it also uses git receive. So it takes hooks, and then you can have commands like git push Heroku master. You can do the same thing with Doku. It builds a container on the fly. When it's ready, it swaps that new container into place of your application, and it triggers immediately across. So you don't need to wait for warm-ups
26:00
or anything like that. But you can build that into your script. So we are going to look at Doku. That's still downloading. Fire. No JS. So here is another server that I've got spun up.
26:20
And as well as Docker. So you can say docker ps. Damn, pseudo. Docker ps. You can see all the different containers and applications I currently have hosted on this one. And it's got all sorts of things like Redis on there. It's got Postgres on there, because these are all available to install.
26:41
Now, Doku is a plug-in in its own right for Docker, and you can install Doku. So if I say Doku help, it will give you all the commands that it's available. So you can back up. You can set configuration. You can link apps. You can create a Postgres database, create a Redis database. You can use Elasticsearch. I'll show you a lot of the plug-ins that are available.
27:04
So we are going to go to a Git repo that I have cloned called ndc-demo. And this is the simplest demo ever. It's got hello word. That's all it returns. It doesn't do anything.
27:24
Let me just... So when you set up Doku, you effectively have the equivalent of a Git server. If you think of it as you have an endpoint,
27:40
a Git remote that you can push to. And the Git remote, I'm going to call playground, and it has that address. Doku at. And at the end, we give it the application name. The application name that we wanted to run in Doku is ndc-demo. So I'm just going to go git push playground master.
28:06
So it's realized it's a Node.js app. It knows that the version is 10.28. It goes off and does npm update and npm install. And at the end, it says application deployed. And then it gives me an address. OK, ndc-demo at an ip.zipio.
28:25
So I can go and I can take that and put it in the browser. And it will say hello word. Now, we can go a little bit further here. If it moves.
28:40
There we go. So we can go vim index.js. So there's a change. git add index, git cm, added an ndc-demo, git push playground-master.
29:04
And of course, you can alias this command. And what it'll realize, it'll realize that there's an application change. And it's going off. It's made the application change. It's built the application. It's Node.js. You don't need to build anything. But it still thinks it goes through the process of build
29:21
because that's the pattern. And then it releases the app. It cleans up after itself. Now, when it says release the app, it swaps the app across to a new container ID. And then it cleans up after itself. And I'll show you that in a sec. And then we go back to the browser. And you can say hello ndc-oslo. So what we can do in the background here.
29:45
So we can say docker ps. And the container ID is 537028. Now, we'll make another small change. So we're going to create the equivalent of an environment variable.
30:01
Something that I can tap into. So we're gonna create the configuration for the application ndc. And then we're gonna create an environment variable called conference. And inside the key for conference is ndc-oslo. And that's actually got some real configuration data right here.
30:22
So that can be used only from the ndc demo application. Because the configuration is bucketed specifically for ndc demo. And then we can go back and we can see what the configuration is. So the config variables for ndc. Conference is the variable. ndc-oslo is the actual value.
30:44
Now, if I go back,
31:02
so I'm just gonna change this to now say hello and then process.m.conference. So I can tap into the environment variable right here. 2014, this conference rocks. And then we can go git add index git cm
31:21
config var Oh. It's not pom. git push playground master.
31:40
And hopefully, it's substituted the environment variable in here. Now, somebody asked me in Kansas two weeks ago, they were like, yeah, it's an environment variable, so what does that do? Connection strings are an environment variable. IP addresses to talk to outside world is an environment variable. What I'm showing you is that you can encapsulate
32:02
the configuration for your application and then your application doesn't have to know anything about it. So remember this mentality of build it once runs anywhere? Same thing right here. Because the developers all they have to do is go m.process.conference and then depending on the environment,
32:20
if it's production, it'll have one set of configuration. If it's development, it'll have another set. And they just don't care. They're just writing the code. That's the main thing. So what we can also do is we can create a Postgres database.
32:41
How long have I got? 40, like 25 minutes. Nope, wrong window. So it's going off and it's creating a Postgres database. And then it's going to give me some configuration variables at the end. It gives me a host, it gives me a port, it gives me a user, it gives me a password,
33:00
it gives me a database and a URL. You can take all those and set those as configuration values and you can make those, embed them inside your application. Does this make sense to anyone? Does anyone care? This is, you care? Good. I'm actually quite pleased that someone cares. So this is awesome in the fact that
33:24
I would never advocate this for this style of git push Playground Master for production use. But what I would advocate this for is if you have a prototype to build inside your company. If you work in one office and your product manager works in another office, you can make a simple application and push it live very fast
33:42
without having to worry about build pipelines. So this one, the download is complete now if we just go back to Node.js for an example. And if I just show you,
34:08
oh, I'm inside the container, sorry. And I can say node version. And I can actually see that I have a Node.js application
34:22
that I can install. Now if I go out of that and I can say spin up the node app, the node image but run the command node version, you actually get it up and you see exactly the same thing. So whatever image you want to use out there you can use and spin it up exceptionally fast.
34:40
Now there was just one more thing I wanted to show you on the docu stuff. And it was that, remember I said that the number of the container was an actual number before? You can see it's actually changed. It's no longer 928.
35:01
It's D5F. So as part of the deployment, it's swapping in the new container. So what that actually gives us is that gives us the ability to do something like this. You can have... My drawing skills are phenomenal. They're so good. They really are. You can have a Docker system
35:23
that has six applications. And then on a different Docker instance that you would call your database Docker instance or whatever you want to call it. Naming is hard. You can have individual configuration and individual databases for each of those six applications. So immediately, you're decoupling your applications
35:43
away from your database. So the question is,
36:00
if the containers are disposable, what do you do about backing up your data and so on? Yeah. So what people would do there is you would probably not run a simple Docker instance
36:22
just like I've run a docu-style instance for your data. And that Postgres create was for a very simple test application. When you're running in production, maybe people won't even use Docker for their database. It purely depends on the style of data. But if you have a back store like a NAS or a SAN
36:44
or something like that, your data can go in there and all your container is is just actually reading the data out of that. It's just providing that portal from that physical storage across to your application. So it's not that you would just spin up an instance and that would be your storage engine. You would have to have proper architecture behind it.
37:01
You have to put in the database engine instead of Docker. The actual storage would be elsewhere. Yes, yes. Any other questions on that? Okay, cool. So you can start very quickly to be able to create very small pieces of the puzzle. Now, I used to hate shared databases.
37:20
I hated them with a passion. I still am not sold on shared databases. I like my application to have its own database that I look after myself and that if it goes down, it doesn't affect anyone else. That's where the beauty of containers comes in. Because if a container goes down, it doesn't affect anyone else. It only affects your application.
37:40
But of course, if the data store goes out at the back, then everyone's in trouble. Any other questions? Everyone's sleepy. You can use the boot to Docker image.
38:04
It's not the most stable yet, I agree. It's great to see that people are actually trying to put Docker on Windows. That's actually fantastic. And there's also, locally, you've also got Vagrant Docker.
38:23
Actually, you know what? Let me just show you this in the browser. So, anybody know Vagrant? Okay, so there's a tool that you can have on your local machine called Vagrant.
38:41
And you can actually get Vagrant to bring up Docker images. Okay, so locally, I have...
39:00
You'll see that I've got what's called a Docker host. So I continually have a VM running that's a simple Docker engine. And then I can bring up VMs on top of that. So let's go and create one.
39:39
And we can actually say, buyer node.
39:41
And that'll go off and it'll build the image buyer node. And I'm not going to run this right now because it'll take like ten minutes to bring up because it'll have to download the image first. But you can very quickly start to go, I can pull in all these images and I can test my Docker scripts first. And if you go back to it, you can actually...
40:03
There is an entire section about Docker itself. Before I just show you the basic commands. So you can build an image. Or you can actually say, the image I want you to use is this image. You can give it a directory.
40:21
And that directory will look for a Docker file inside the directory. And a Docker file is just that simple file that I showed you earlier. This one, where you just put all that code in place. And the last piece of the usage is is that you can actually give it a path to a Vagrant file.
40:41
So you can get Docker to spin up Vagrant in itself. This is hugely useful. Now, people are actually starting to release Docker images for pieces of software. So we saw that there's a Node.js one. We saw that there's official Ubuntu and Debian and so on. Sorry.
41:09
OK, so we'll get into my rant in a second. That's how I was going to finish. But we'll get there, I promise you. People are starting to release software. So actual, physical scripts that you can spin up pieces of software.
41:23
I actually found this a few days ago. I remember a tweet from Greg Young who runs GetEventStore. And somebody has created a GetEventStore Docker file so that you can take that file and you can spin it up and you have a container that runs GetEventStore. Now, you start to look at...
41:40
I bet there's one out there for Hadoop. There's definitely one out there for Elasticsearch. And all of these are available that you can just spin up on the fly and test out loads of little things locally. And it's some interesting stuff. And then at the end, you can expose ports so that there's physical ports that your app can go out on
42:02
and the other apps can discover them. So Docker as a system is really starting to wake up. And Doku. All the plugins that are available for Doku. Half of these databases I haven't even heard of. So MariaDB. PostGIS.
42:22
RethinkDB. There's MySQL. There's Memcache. There's Neo4j. There's Rabbit. There's other versions of Postgres. There's Varnish. There's Memcache. You've got process managers. You've got... Every single day you go back to this site, there's nearly a new plugin that's available. And the buildpacks are fantastic
42:42
because we can take a really simple... So I have already set up a remote for Playground here just because we're experimenting. This feature dashboard is an ASP.NET MVC application
43:03
that runs under Mono. And we can say... Why just make a change to read me?
43:33
Fourth time lucky. So Git push Playground master. And what it's realized, if you see it, it says build an MVC.
43:40
It's actually doing a build on the fly. So this is using an open source buildpack for Mono. A Heroku buildpack for Mono. And at the end, it's actually said build success. And it's trying to deploy it. Now, I can't get the application running on the front end because I haven't got it configured correctly just because this is a brand new container that I spun up this morning. But you can really start to see that if you tap into the power of Mono,
44:02
you can really start to put Windows apps on here as well. Now, when Microsoft announced about Roslyn and all that amazing stuff that's going to allow us to run apps on Mac, I was super excited because we can just start porting our applications across to Docker, which is awesome.
44:21
Okay, so the question was asked, and I wanted to take like five minutes at the end to talk about this, of how can a config management... What is the benefit of this over a config management tool? Is that right? Pretty much? Pretty much. So configuration management is obviously required.
44:40
You need to build images. You need to manage that the images are available on your server. You would not run Puppet or Chef or Salt inside a Docker image because it would just be crazy if the overhead of running one of those apps inside a container would far outweigh the need for the container itself. But you can still run Docker or run your configuration management
45:02
on the base server itself. You can manage that the applications that are required are there. You can build your containers with these applications. You can manage the different tags and the different versions and push them back and pull them down from the registry with these systems.
45:20
This does not negate the need for configuration management in my opinion. Some people believe it does. But my argument to that is, is that, am I going to really want to log on to 20 Docker servers and go Docker pull and the image name? Because by the time I got to the 20th server, the tag may have changed. That manual is bad.
45:41
Manual is extremely bad. So we don't want to do that. Does anybody disagree? Does anybody care? Docker is not officially a 1.0 application yet.
46:01
But it's not like Node. I don't even know when Node is going to go 1.0. But Docker actually say they would not suggest it for public use, for production use. There are lots of companies already using this in production. We have Docker running in some of our production infrastructure
46:21
in AWS. I believe I know the date when it's going to go 1.0, but I'm not supposed to say. But it's soon. Very soon. Not today. But it would have been really nice if it was 1.0 for this talk today just because I could actually say, look, this is, go off and use it.
46:40
It's certainly worth experimenting with. Certainly worth experimenting with. It's got a lot to offer against the traditional way of doing things. And if you're a startup and you don't have any operations people or you just want to ship prototypes really fast for people to try, this is just perfect. This is really useful. Any questions before we finish?
47:02
Yes. Smart. Smart OS. So, I have Docker sitting on top.
47:21
Smart. That's geeky, right? Yes, I would give that a shot. Again, it comes back to the fact that because it's not 1.0, there's still changes every day. So this version of Docker I installed just this morning is 9.091, and already that's tagged as 0.10.
47:41
So, you know, it's moving at such a fast rate. And they've got a lot of core committers right now as well. And they're taking a huge amount of interest in the product and they've got some very well-known people starting to push the product in the right direction. It's going to be pretty good
48:00
very soon. Any other questions?
48:23
well, first I wouldn't let developers go on and do what I've been doing. But it happens. You're right, it does happen. So we have to separate the idea of Doku being Docker. Doku is an application engine that sits on top of it that will allow you to do platform as a service.
48:40
So like, simple Heroku style, very very simple Heroku style hosting. But Docker itself we use a well, we don't currently use Puppet to manage it because there's only a couple of things on there but I'm trying to get the company to realize that we don't want to be going on any web servers and touching anything. We don't for any of our
49:00
infrastructure stack that's not on Docker. So what we would actually want to do is we would certainly want Puppet or Chef or whatever. I'm not getting into that argument. But we would want all of these systems to be managing those containers for us. You would have a proper pipeline for your containers. You would build it. You would test that your
49:22
container works, your image works and only then would you push it and make it available for your production system. So it's about putting the correct I hate process so I'm not going to say it's putting process around it, but it's about following good patterns good guidelines. We're good at following these patterns
49:42
and these well-known ways of doing things when we develop code, like actual application code. We should very much follow the same when we're doing infrastructure code. Why do people need pseudo access in production?
50:04
I agree with you there. Maybe that's a legacy thing. We control all our users that go out on all the levels in a simple YAML file and we can tell who has what level access to what servers. Because the argument is that
50:21
if you have pseudo access then you are going to be tempted to go and change the image. It's what we do. It's not that we're trying to break any rules, it's just we like to tinker with things. And when we tinker with things we break things. So yes is the answer to it doesn't
50:41
help immutability in itself that you can go on and change the containers. But once the application is actually running inside the container you can't change that image. What you would have to do is you would have to spin up a new image or a new container. Yes I think maybe
51:01
Do you have trust issues? I'm just joking. I'm just kidding. I'm just joking. Yes is the answer. You can always change things. We can do it on any server. But it does help that they're all disposable and they can be thrown away. Any other questions?
51:29
No. No. It's completely secure. I don't know if this guy still has his demo working.
51:42
This is not a bad site by the way. This is actually not a bad site. So this is a guy I met in Kansas called Britt. And he was like one of the smartest people I've met. And he has actually been experimenting with Docker. And he wanted to share his Vim configuration with everyone.
52:01
So this is his site. Brittg.sexy And this is his actual official this is his actual Vim configuration. But this is running inside a Docker container. He has actually got this working. And you can interact with it and you can change it
52:22
and all these bits and pieces. But it's sandboxed. I can't do anything. So he had another demo that he immediately took down. After my talk he was like oh, have a look. Here's a URL. Go and have a look. And it was an actual live terminal. And I was on my phone. He was on his laptop. I could see what he was typing and he could see what I was typing.
52:42
And immediately I was like rm-rf/. And he was like it's okay. It's a Docker container. It doesn't matter because he just killed the container, brought a new one up and it was all fresh again. But I did try it. Because you do. It's what we do. It's what we as software engineers do. We like to mess around with things.
53:01
So yes, you are completely sandboxed off. And how you know that is when you need to expose a port or something for the outside world, you actually have to put it in your Dockerfile. Expose 2.1.1.3 on 2.1.1.3. That can be exposed 8080 on port 80.
53:22
Or 443 on whatever you want. So you would maybe have internal ports that map to external ports that then you can control inside your infrastructure. Any last questions? At atomic?
53:42
I'm not, I'm afraid. I thought you were going to tell me about it. I was getting excited there. I'd like another talk straight away. But if I start looking at it now, I'll not turn up to my next talk. Any last questions?
54:00
Okay. Any last questions? Guys, go and have a look at Docker. Docker is actually very cool. It's got a lot that's happening for it. It's got a huge movement. It's got tons of images that are currently out there. And more and more companies every day are starting to think containers are really simple. Containers are much better that we can do it.
54:21
I showed you that you can create a container. That container is available. And because it's a container, you can have Vagrant Docker run in exactly the same container. So you know that your code works locally, QA, production, all you need is the Docker engine every time. You can be testing, you can be doing as much as you want for that code.
54:41
Thanks for coming, guys, and enjoy the rest of the conference.