 Hello, everyone. I'm happy and proud to be here today. Thank you for coming. My name is Maxim Zhilinsky, and I work as an engineer in Altaurus. And my talk called Who Lives in Our Garden? And it's about containers. And precisely, it's about containers in Cloud Foundry. What actually containers are? Well, a container is a combination of operating system primitives that allows separate-out set of processes and make them pretend like they are in own operating system. Containers offer high-level isolation with many applications running under the host operating system. All of them sharing certain operating system libraries and OS kernel. So basically, containers are just processes in your operating system. Well, and since they don't have to load up operating system and provides almost no overhead, you can create containers in a split second rather than minutes for virtual machines. That makes containers perfect technology for different use cases like platform as a service, Cloud Foundry. Let's talk about history of containers implementation in Cloud Foundry. Containers was first-class citizens from the very beginning of Cloud Foundry existence. So in 2011, first implementation of container manager was introduced and its name was Borden. It was written mostly in Ruby with the bits of C code. In order to provide a process isolation from host operating system and from other processes was used Linux namespaces feature. It's a kernel feature. C groups for resource limiting and management. It's also a kernel feature and pivot root system call to file system isolation. So that's how it was designed. It was quite monolithic. Warden server, which was providing service to Warden clients, DA droplet execution agents, talking to Warden by Pratabov-based protocol was coupled in a single application with a container manager, which was responsible for container lifecycle routines. So in about 2014, brand new Cloud Foundry runtime was introduced called Diego instead of good old DA. It has a lot of cool features like smart orchestration and so on, but I will not go into details as far as my topic is about containers, not the whole runtime. And yeah, as a part of new Diego runtime, new container manager was introduced Warden. I mean garden, sorry. So what has changed? Garden was re-implemented in Go programming language as many other components of Cloud Foundry. Well, basically, garden stands for Go Warden. But what most important, garden was designed in a modular way. What does it mean? Oops, sorry. Yeah. Okay, here is a garden architecture. Still, garden clients, which now is Diego cells, talk to a garden server by protocol. It's still protocol based, but also garden provides HTTP RESTful API for like debugging purposes. But in order to provide flexibility, garden server was decoupled from container manager, which now lives in separate component called back-end. So garden provides unified contracts that does not depend on underlying container implementation. Okay, what back-ends are available today? It's a garden Linux. At the moment, default Linux container back-end for Cloud Foundry and for garden greenhouse. It's a Windows container back-end. And one more Linux back-end called garden. Garden Linux back-end. Well, it's just a successor of Warden's container implementation. It uses same features to provide process isolation like Linux namespaces, cgroups, layered file system, and so on. But there is a killer feature was added to garden Linux. Back-end, in addition to default native build pack lifecycle, is a ability to run docker containers. Well, how does it work? First of all, let's dig a bit how garden works. Garden, as well as Warden, was used as layered file systems. During the default build pack lifecycle, container manager takes root FS, basically Linux root file system, and mounts it together with another layer with application bits, using AEU FS by default, its layered file system, or optionally overlay FS, to create a single file system, single mount point to pivot root to. Okay. And about docker images. Docker images themselves consist out of layers, each containing a difference applied on top of a previous layer. Well, probably many of you have seen docker files. You've seen, for example, from Ubuntu latest, from Ubuntu 14.04, and a couple of comments to install some software. So these comments creates new layers. Okay. So in order to run docker image, garden just mounts docker images, image layers instead of built-in root FS, keeping the rest pretty much the same. Garden uses libraries from docker, actually. Docker is also implemented in Go programming language, so it's quite easy. So contents of container exactly match the contents of the association docker image. There are caveats of running docker images in Cloud Foundry. You can use only docker registry API of version 2, which is fine, I think. It doesn't support private repos you can't provide credentials, you can use only public ones. And so Diego doesn't cache pulled docker images, so you need access to docker registry every time you, for example, scale up your application. For each new instance, it has to pull docker image. So if, for example, docker registry is unavailable, you can get into trouble. So I took these three points from Piotl's documentation, actually. But I have to argue about point two and point three, because, well, there is a project in Cloud Foundry incubator, which calls Diego docker cache release. It's a Borscht release. And what actually it does, it caches docker images pulled from docker hub, for example. And, well, if you use this release, you no longer rely on docker hub availability, for example, and you can provide credentials for your private repos. Well, downside is that, first of all, it's still in incubator, so it might be not really production ready. And it's not supported by Cloud Foundry CLI, actually. But actually, we deployed this release for one of our customers, and, well, he was happy. Well, it's what we do, making our customers happy. So, all right. Well, Linux is the most popular operating system to deploy applications to. Still, it's not the only one. And .NET applications are widely spread, especially in enterprise area, and it's mandatory to support them in modern platform as a service. So there is one more backend for Garden that actually manages containers in Windows. So the trick is that Windows does not support containers as Linux does. So, but Cloud Foundry runtime team managed to deal with it with a couple of tricks. So in order to create sort of containers in Windows, following features are used. For file system isolation, they create a user for every container to use default Windows ACLs for file access, and so on. Okay, for disk usage limiting, they use NTFS quotas. For CPU and memory limiting, there is a Windows job objects. And for network isolation, application launched inside a container bind directly to external IP of the VM. Okay, and the last backend available is called Guardian. Why need for another one Linux container backend? Well, there are plenty of containers implementation nowadays. Famous known Docker, LXC, that has been for years already. Container implementation from Google. Let me contain that for you, or something like that. Open VC, of course, Garden and many more, which are not compatible with each other. So in 2015, open containers initiative appeared to create industry standards around containers to build open, portable, platform, cloud, and hardware independent containers and runtime format. So the OCI currently provides two specifications, the container image specification and container runtime specification. But actually, image specification describes how images should be created and stored, and runtime specification describes how to run these images, actually. So it's a list of companies that are in OCI, and most of containers, world players are here, I think. And it's huge. So I kind of believe in OCI. And, well, I was looking for Internet just a couple of days ago, and saw this tweet. Kelsey Hightower from Kubernetes wrote that they added support of OCI containers. So it looks good. Back to Cloud Foundry. Garden already supports OCI containers for a while, actually. It's a Guardian backend, also called RunC backend. It's not yet the default backend for Cloud Foundry, and the current version is 0.9, but from the mailing list, version 1.0 is just about to come, and Guardian will become default backend for containers. Okay. I have a bit of practical slides here about debugging tips. So for those of you who are having trouble with your applications in Cloud Foundry containers, sometimes, well, logs aren't enough. For example, your application doesn't work, and you can't figure it out why. Maybe some file is missing, or a file permission is wrong, or I don't know. And you want to go into a container and check it out what happens to see your processes, and so on. With new Diego runtime and Garden, there is a CF SSH command that actually brings you inside of container, and it looks like this. Actually, I see we have a bit of time, probably I'll show you some live demo. Okay, here I have two applications. One of them... Oh, sorry. I see you don't. Now you do, and I don't. Okay, much better. Okay, here I have two applications. One is deployed to DA using old Word and Container Manager, and one deployed to Diego Cell with Garden. In this deployment, I have both of them deployed. So, for example... Okay. I want to go into Word on Application. I'll try to do this. It doesn't work, because Word doesn't support this feature. Are there any people who are trying to do such things to the bug containers? Okay. Well, so I'll show you the way how it was before Garden. Okay, I add CF Trace here, and lots of information here. Okay, here I see IP address of actually VM. Now I look at Bosch VM's list. Okay, I can see it's runner Z1 slash 1. I can SSH to it. I have to be actually the operator of my Cloud Foundry deployment to do this. Okay, I'm here. What next? I know that containers live in where we kept data, Word and Devils. Okay, I have six... Oh, no, seven containers here. Which one is mine? I don't know how to figure it out. Usually I just go to... Oops, sorry, CD. Yeah, go to first, and then try to run shell. Okay, I'm inside of container. Okay, no, that's not mine. It's a Java application. Yeah, that's how it was, actually. Okay. But now I can just do CF SSH. Yes, I did. And that's it. I'm inside of container without any of these Bosch crazy stuff. And I don't have to have access to Bosch and so on. All right, back to slides. Sorry, one moment, please. Okay, for those of you who wants to debug container manager itself, not application inside of container, I recommend to take a look at these two. It's basically CLI for garden. You can create and delete containers, shell into it, and many other things that Diaga does. For example, if you have a single Diaga cell and garden doesn't work, you can just use this tool to connect to and debug it. So, all right. A couple of words about container security. How secure containers are? Well, if we are talking about Linux-based containers provided by Garden Linux and Guardian backends, well, they are based on namespaces and C-groups, Core Linux kernel features that have been around for years already, and used as a basis for many popular projects like Docker and lots of them. So, I believe that you can trust Cloud Foundry containers as much as you can trust Linux kernel itself. Well, of course, as far as garden is just a software, there are bugs and there are security issues, and I've seen a couple of them, but not too much actually. Another point about security is this diagram. I mean, each container in Cloud Foundry, in Garden, actually uses its own subnet with interfaces, access limited by firewall. Well, it's a benefit from point of view of security, but also it makes it hard to interconnect containers between each other, but it doesn't really fit the platform as a service ideology. So, for example, in Docker, you have a single subnet for your containers, and you can create links between them in Garden and you can't. So, what's the Garden users' projects that use Garden now? Well, obviously, it's Cloud Foundry itself, and it's ConcourseCI. It's a continuous integration and continuous delivery tool with a more modern approach built by actually the same team, I mean, Cloud Foundry community. It supports pipelining, and it's cool if I recommend to try it, actually. Also, Bosch Lite. Bosch Lite is actually Bosch, deployed in a single VM. It uses Garden containers as its infrastructure to create jobs instead of creating VMs. It creates jobs inside of Garden containers. And I don't know. You can use Garden in your project, for example. It's not so hard. I tried to just compile and run Garden. It took me about half an hour. So, if it fits your needs, you can try it. That's it from my side. Thank you. Maybe you have any questions?