 Hello garden fans This is by far The most normal talk title I have ever given Which makes me Frustrated and angry But I couldn't come up with anything better than garden project update because I'm going to update you on garden But I could have called it Why gardens great and What's new and cool and What's next because that's what we're really going to talk about Primarily with lots of slide about how great garden is so I hope you're sitting comfortably Why is garden great so what is garden we probably all know what garden is does everyone actually know What garden is has anyone come to the complete wrong talk? So garden is cloud foundry's container engine. I Used to joke that it's an open-source version of Docker It's a cross-platform abstraction So one of the original goals of garden was that we would have an API that we can make work on Windows and Linux and anything else Originally it was based on our own code Which actually predated Docker, but it doesn't really matter now. It's actually based on run C Which is the same code that runs in Docker on Kubernetes and everywhere else So it's just a small piece of glue Around this shared piece of code that's the same in every container platform. So why is that good? Basically most importantly because garden is tiny garden is now this really small simple wrapper around Run C which is what we like because that means it's really easy for us to support and to maintain and Because it's totally focused on cloud foundries use case and not on any other use cases We can keep it small and simple and keep it optimized and secured for what crowd foundry needs Right, we're not messing around with other stuff when we need a feature We don't have to plummet through lots of layers. We just have a small simple wrapper around run C So that's the idea of garden This is visually what I just said. So if you think about Docker Docker is this large blue thing whale-like thing if you like And there's now this little component inside Docker, which is been open-sourced by Docker called run C Which is the container engine right in the corner of Docker and then around that. There's the CLI as the orchestration There's all of that stuff More recently this work has been started on container D Which is a smaller subset without some of the orchestration stuff But it doesn't quite it isn't quite ready yet, but it's kind of interesting Garden looks something like that, right? It's like a much smaller Rapper it just does three things really. It's an API. So an API that's exactly tailored to what the rest of the system needs It has same defaults, which is probably the most important thing out of the box It's configured to run a multi-tenant secure pass You don't need to do anything to make it be a secure multi-tenant pass. It's just all set up correctly And it has a really simple plug-in model Which I'll talk about later that lets us do the interesting things in their own projects. So What we're trying to do is create the most secure and the most maintainable Container engine for multi-tenant platforms as a service. That's the garden mission and By default we want to be secure But actually when we say secure by default We don't just mean that we enable everything that you need to be secure out of the box We also mean and I'm quite proud of this We don't give you options that will make you insecure There's one flag which is privileged that we use so we can test garden inside garden But apart from that you can't twiddle things which will actually make your container Insecure in a multi-tenant environment and that's what gardens about right garden is create me a container Which is secure and which will work in a multi-tenant world? I'll talk about some of these security things that we do in a minute By the way, it's also really fast because it's super small It has really low overhead and it's actually really fast. We run performance tests in CI under load We make sure it's always Under a second creating containers and we run comparative tests against the other container engines And as you probably expect and we're quite a bit faster than all the big container engines And a really small overhead over just using raw run C. She's exactly what we want so Let me talk about how we got here. This is like the history lesson That's the only slide with a good animation by the way, so I hope you enjoyed the good animation So we started with a d8 and warden that was the original piece of crowd foundry functionality, right? It was our own custom code Originally it wrapped this LXC library then we realized we didn't need LXC It was faster to just call the kernel API's ourselves a little later docker popularized containers and did some amazing things In getting the whole Community to learn about containers rather than it just being something we used to build passes. It was something people used in its own right We then created a new version of of warden called garden, which was our go version originally garden Linux And then in 20 well just before 2015 we started thinking about whether we should do a version of garden that was based on Docker And if you were here two years ago, you would have seen my talk If you were here you saw my talk right Which was on garden docker, which was a prototype We did to wrap the whole docker in garden and because actually the garden API can let you do that sort of thing But we were hesitant to do that in production because that meant we had a whole docker dependency Which we didn't really want to have we didn't need it. It was a big dependency to take in And then in 2015 docker released run C announced the OCI initiative So then we had this component run C which did just exactly what we needed and nothing that we didn't need So we quickly created garden run C. That's what's in production today And that's what's been running successfully for the last year or so How do we get that this so I just want to say quickly how do we get there? We basically have really good tests around Garda Linux We ran those tests with the new run C runtime until they all consistently went green We ran it in production with half the load on Ghana run C and half on Garda Linux And it worked really really well and we really only had a very small number of problems When we ran them side by side, which we quickly fixed and so we just got rid of Garda Linux We've been running on Ghana and see if I think about a year now So Garden and OCI so I think this is kind of interesting. So by adopting run C Garden is now much more part of the OCI community, which is the actual community around run C and around container technologies We've been able to get run C to give us some of the features that we needed to do some of the Cloud Foundry use cases One of the big ones is to create start splits, which means we can create a container Without starting the first process within the container because in the Cloud Foundry model We like to create the container and then decide what to run run health checks run all the other things inside it Whereas in the docker model the two things are linked together So we've got agreement to split that up which makes it much easier for us to standardize the command line API And recently we've started to do stuff Which is actually new within the OCI community So one of the big things we've been doing recently is working on being able to run the whole garden server without needing roots Which if you know about containers is just magic and amazing I'll talk more about that in a minute But that's sort of using the bleeding edge stuff in run C which we can now do in garden. So Basically garden is totally folks in the CF use case. It's really small and minimal And that means we have just maximum power while also being easy to maintain Allow me to demonstrate. So Some of the things we've got for free from run C. So by moving over to run C We for free get now the same exact runtime environment. So whether you're running in docker or cube or cloud foundry If you do a CF push with a container image, you're going to get the same runtime environment It's the same exact code that's going to be running it in all of those things You're going to set comp out of the box app armor out of the box All the new Pid C group stuff and the ability to use all the standard tooling that you would have with run C or any You know any other container tech? How do you get this? You do nothing, right? This is just for free out of the box. It just works, right? You can't not have it We also now have a rootless mode CPU maximums plugins and window support And I'll quickly talk about each one of those new features because they're all really very cool. So rootless this is really experimental and but this is Extremely exciting if you're a container nerd like I am I will try to tell you why it's good even if you're not a nerd like I am It's good because it's massively more secure and it gives us much more ways to deploy the container engine So we already have user namespace support and what that means is roots inside of a container isn't really roots on the host rootless containers means the server itself the garden container engine also isn't running as roots, right? So user namespaces mean your your user in the container isn't really roots. So if you break out of the container, you're still not roots rootless rootless garden means if you Hack the actual garden server itself Even the garden server isn't really roots and doesn't have elevated privileges on the host. It's incredibly cool That means it's more secure more deployment options And it also means for the bleeding edge of containers, which is where we want to be right? We want to be ready to get all the new latest features into Cloud Foundry How do you use it today this you will actually have to do something you'll have to set a Bosch property Until we get rid of that Bosch property once it's all ready In the meantime, I wouldn't actually do this in production. It's not actually more secure yet right now It's less secure and because there's some security features. We can't turn on without roots yet but we're getting there and Hopefully eventually you will just get this for free like everything else. You won't have to do anything You'll just get the security improvement But if you do want to try out and tell us what breaks that would be awesome Yeah, so CPU maximums this is like a long-standing request people have been asking for this for ages And we've always had CPU sharing that means if you have a 64 meg app You'll get CPU in proportion to how much memory you've asked for so if you've got two apps on the platform You can't have one that takes all of the CPU But historically that meant fair sharing only when there wasn't enough CPU to go around So if you had a lightly used box you could get all of the CPU on that box Which meant sometimes you would get lucky and your app would get a huge amount more CPU than you'd paid for That's bad for a couple of reasons. It's bad firstly Because it attracts a lot of Bitcoin miners and things like that because they can just keep pushing until they get like a fast server Which isn't great It also means it's really hard to do things like auto-scaling because you never know how fast the machine you're gonna get is right And the worst thing is people start to rely on getting more CPU than they paid for So when they happen to land on a host where they only get as much CPU as they actually have paid for Because it happens to be a busy host all their stuff breaks and they think the platform is broken So what we allow now Is a single property you can set it in garden. It's extremely well named its CPU quota per share in us If you set that and then we take the existing fair share number and Set a maximum amount of milliseconds nanoseconds rather that your process can run per thousand milliseconds before it will get stopped So for example If you set it to 100 and give a 64 meg container that means 64 times 100 equals 64,000 You'll get that number of nanoseconds per thousand milliseconds before the container can't have any more until the next slice Right and this allows you to to set a maximum so you can still let people burst and use some of the extra CPU But you can make it a little less crazy This is quite experimental. This is quite new. It hasn't been used massively in production yet But you can just set it with a Bosch property And tell us if you need more or less so we've started out just doing a very simple thing that we hope will fix it And we're looking for feedback on if that works for people Finally plug-ins So plug-ins we have this pluggable system So we're a small wrapper around run C and then the bits that cloud foundry actually wants to innovate on and do different things image management networking alternate run times We have a little plug-in API and it's incredibly simple. We just run binaries, right? So we just run a binary and we say we've created a container Please configure the network and we pass the argument to that binary of what the network namespaces Same with image management. We say we're about to create a container. Here's the URL of What image we want to run in it? Please create me a root FS and you can just set those as Bosch properties and replace them It looks like this So this is a basic diagram. You've got the garden API at the top Gardener is our implementation of the garden API Which then has three modules. It's got the network component It has the image management component and it has what we've lovingly called run DMC Which is the small wrapper around run C, right? That's the containerizer component You'll see that Kawasaki is our inbuilt networker. That's like the default out of the box networking Later today You'll see a talk about the container networking component, which is one plug-in There is also groups which replaces our built-in image management and does full OCI support with overlay file systems Can run as roots and I'll talk later About the new windows version Of the runtime plug-in which lets you use a different runtime plug-in instead of run C on windows so Briefly those plug-ins this container networking Which is policy-based app-to-app networking, but it actually supports CNI Which means we now have pluggable proper container networking. You can plug in your own things However, you want there's a talk on that at 225 in this room here There's then our new image management tool, which is Groot I would like to explain the name of Groot now We call garden guardian internally the new code is guardian Groot is a character In guardians of the galaxy Groot is a tree. She will find in a garden Garden roots FS Groot FS get it So that gives us proper OCI support. It's based on the latest code. It uses Containers image and it can pull down all the the standard OCI and docket images And instead of being based on a ufs, which has been a long-running problem for us It isn't kernel supported. There's our current file system learning technology It can use both better FS and overlay FS which are actually built into the the kernel so much better supported one small problem It turns out file systems are really hard It doesn't actually work yet It works great until you run it at scale and then it turns out better FS blows up and overlay FS blows up But we're gonna get there Just finding the right tuning for file systems at scale is just really hard and even though a ufs is awful We know the ways in which a ufs is awful now And so we have all the workarounds and so when we move to the new file system It turns out there's all sorts of new things that we have to fix so we aren't quite there with Groot FS yet But that will come along soon Finally this is probably what I'm most excited about so We've been discussing how to do container support on Windows now that Windows 2016 has Proper container support We discussed how to do it How to have that support in Cloud Foundry so previously we had a whole custom Version of garden called garden windows, which was just a garden API, but a total different implementation What we hope to be able to do Because of this OCI support because we now have a standardized Plug-in-based container system is Ideally since run C is just a standard in interface that implements the OCI standard You would hope we could just replace run C on Windows with a Windows implementation of run C and have everything work I'm pleased to say that that's actually is what has happened so we can now run garden on Windows It all compiles it all runs and we just use a different run C a custom-based win C And I got this message just before I gave this talk It says if you're doing the garden update, we've got the rep house passing CF push should be working soon Which is pretty awesome, right? That's that's exactly what you want from using the standards, right? We should be able to reuse the same code on Windows and Linux and everything should just work and the container layer should be abstracted That's pretty great What we're doing next so next this is already available if you go to our releases page To make it much used to deploy and use things with garden There's a standalone garden binary that you can just download it and run it on Linux So it's just an all-in-one go binary. You just run it and you now have the garden container engine We're starting to properly use file system layers So trying to replace some of the droplets Extraction that we currently do which is quite slow with using file system layers to actually make it faster And then we're doing some experiments on properly using the OCI image spec throughout the Cloud Foundry stack to have some really big improvements There's a talk about that tomorrow In CD so ground-borrowing CD About all the about how we plan to use the OCI image spec and to make some really big advances to how the current build pack flow works And this is very Prototypy and we don't know if it's all gonna work yet and it's Experimental, but there's some really cool stuff there and basically our mission as we see it now Is instead of being about garden because garden is just a noun, right? It's a little bit of glue code now. It doesn't really do anything. It's just a little wrapper around run C The garden team thinks now its mission is to use the container tech that exists Use the latest container tech to make the whole platform better And so we're getting the features that we need into run C We're taking the features available in the container community and using them to make cloud foundry as good as it can be There are more talks by me they are better than this one There's the office hours tomorrow My favorite talk I've ever given just because of the number of Trump jokes Which is nine to nine problems, but a container ain't one Which is where I? Having spent all the other talks telling you about how containers are great Argue that you should never see a container again And then the OCI for build packs talk which was about how we can use the OCI image spec to make Cloud foundry better And I'm a dr. Jules if you want to tweet me and with that any questions Right, so garden today actually supports that But Diego chooses just for simplicity to always set your CPU based on how much memory you have So this is actually a question for Eric. This is actually question for Zach. Yes cloud controller does it? I'm blaming the wrong person So the question is what happens when you push a docker image to garden? The interesting thing is as far as garden is concerned There's almost no difference between a build pack app and a docker image app The only difference is how we get the root file system downloaded So if you give us a docker image, we use the group component or our internal Garden and shed components to pull that down from docker hub Otherwise you just give us the path locally where the root file system is Once we've got the path where the root file system is the rest is identical So we're just running the exact same Code to containerize and it just tells us the only difference a docker image as far as we're concerned is where to get the image from Awesome. I think that's All I have