 We are going to get started, people are still coming in the back, but the room is full. So, I guess people have heard of containment then, or everyone is here for cloud foundry, which is probably more, so containers versus cloud foundry. I am Julian Friedman, I work for IBM, George, and pivotal. We are gardeners. Rwy'n credu gwybod yw y 5 yma. Mae ystod 3 eisiau gwneud twfio. Mae ystod i—'r cwудdo— y gallwn fesweld i'w gweld i'w gweld i'w gweld i'w gweld i'w gweld i'w gweld i'w gweld i yw gweld i'w gweld i'w gweldol. Mae ystod i—'r fathau yng Nghymru, pe diddorol a'r cymdeithasol yma, wrth ingwydd i'w gweld i'w fathau yng ngyfaint a'r fathau cyrddeddol. Mae'r dweud yn cyhoeddaeth iawn, ei cofnod i'w cyfeith. y cwntainer? What is this container concept? And then we're going to try and suggest that Cloud Foundry is actually an amazing way to run containers. So everyone thinks that Cloud Foundry is this, you push code and containers is just an implementation detail at the bottom, but we're going to try and suggest that actually Cloud Foundry is a pretty great way to run containers too. And then we're going to situate Cloud Foundry and Garden against some of the other things. It's a kind of summary. So let's get started. So we need to talk about Cloud and to do that we have to go back in time a little bit. All now back in time, right? So when it is now the year 2000 or something and someone's had a brilliant idea for Clouds and what that meant was you're a user and you say to the Cloud, hey, give me a server, and the Cloud says, all right, here is a server, right? And that was actually pretty great, right? That's what we meant by Cloud for a little while, and that made lots of people those money and it made things way simpler, pretty awesome, but then we realised that actually there was a lot more that we could do for users, right? Hey, give me a server wasn't the end of that story, and what we actually wanted to do is build something on top that made life a lot simpler, that let people stop worrying about all the things that you have to do after hey, give me a server, right? And for the sake of argument, let's call that a foundry or a pass, right? The value add on top of Cloud. And it's a different abstraction, right? So a user, instead of saying, give me a server says, here's my code, and the Cloud says, great, I'll deal with that, right? It's a different direction. And behind the scenes, the Cloud could deal with packaging and middleware and OS management and logging and metrics and services and health checking and scaling and patching and on and on and on, right? All the things you need after hey, give me a server. But at the back end, what we were doing is we were saying hey, give me a server, right? And the Cloud was saying, right, here's your server. And we still had to figure out packaging and middleware and OS management and logging and metrics and services and on and on and on, right? There was still a lot of complexity for us to actually implement one of these things. So now we need to talk about containers, right? Because we needed to make this easier. We needed to figure out how to run this on the back end in a way that makes sense. So what is a container? Basically, container is an OS image, so a package bundled OS image, plus a metadata that tells you how to actually run that image, and you bundle those together into something that you can ship around and deploy, right? So then you can take that bundled OS image with the metadata that tells you what to run in that image and move it around and have it run. And what does that mean? It means we can now say to the Cloud, here is a container. And the Cloud can say, okay, and suddenly we've dealt with OS management and packaging and middleware. That's now simple. We can let that layer take care of that. But we do still need to worry about logging and metrics and services and health checking and scaling and patching and all those other things that you need after here is a container. Actually, I just want to point this out. What we're really talking about when we talk about push code and not containers, we didn't know the word yet, but that's serverless. So what we're talking about is you don't care about all this stuff back here. You're just pushing code. That's really what serverless means, but now the word has come back around. But maybe you actually do want to care, because for some applications you do want to go down to that lower level and you want to care about some of the lower level detail. So maybe you actually, I've no idea what just happened, never trust technology. Maybe you actually want to push containers, right? Maybe you do want to go to that bottom layer because that will solve the OS management packaging. Maybe you want to take care of those yourselves and you want the platform to still provide all those other things, the logging, the metrics, the services, the hell check, the scaling, the patching, all those other things that go along with the platform. But you want to deal with that top bit. You want to provide the container bit. Well, actually, it turns out we don't have to push code, right? We've built a really great system for moving around containers. We were just using it to implement the platform as a service bit. But CF is actually a great container orchestrator. We can use CF as a container orchestrator and have all of the advantages of CF. And that's what George is now going to demonstrate. He's the font size good for those in the back. Make it bigger. How is it now? Sure. All right. So let me see. So we're going to start by building a Docker image that can be used as a Cloud Foundry application. And oops, that's going to bust. I thought live demos were bad. I mean, pretty courted demos are also bad apparently. All right. So we're going to build a Docker image. And then we're going to use it to spawn containers in Cloud Foundry. And this is not a new feature. This is something that was shipped last year with Diego. And it's just useful to realise how you can basically run containers with Cloud Foundry. So, okay, I'm just having my own directory. And I'm going to start by showing you this Docker image I built. It's under my username so you can find it if you want. And this Docker image is basically having two main files. The first one is the app.py. This is a Python application. It's a very simple file. We'll see it right after. And the second one is a Docker file. So let's look at the app.py. As I said, it's a very simple Python application. The main important thing here is that it prints these two environment variables. So these are Cloud Foundry environment variables. The first one is the random unicad that Diego assigns to every application instance. The second one is the application index, the instance index, sorry. This is a zero-based index of the instance within the list of instances. The Docker file of this image is very simple as well. So a Docker file is basically describing a Docker image. The steps Docker will run, will execute in order to build your Docker image. And every line in this file is what Docker calls a layer. So the first layer of this simple image is a Python 3. We also call it a base layer. So it's using Python 3. The second one is installing Flask that's a web framework I'm using. And the third one is adding your code. So this is the step where I'm using only a single file, my code is a single file, but you could imagine that this is like your whole application there. And the last one, the last line, is defining the endpoint. This is what tells Diego what to run when it spawns a container. This is the whole CFP. There are no young files, there will be no source code uploading. This is it. So let's build and upload this image. So building is basically executing all these steps. There are four lines in the Docker file, so there are four steps in the building process. And uploading will upload all these different layers into Docker Hub. Docker Hub is a public registry for Docker images. And this is what Cloud Foundry also uses by default to download Docker images. The interesting thing here is that layers are cast. So if you change your application code, if you remember, we placed our application code in the third line. That's the third layer. So if you change your application code, you don't have to rebuild the whole image. And also you don't have to upload the whole image. You will only upload the layers that are changed. Next thing is I'm going to connect to my Cloud Foundry instance. I'm using PCF Dev for this demo. This is a vagrant virtual machine you can download and use in your laptop. It's free, although probably if you want to download it, you have to give people all your connected details, but you know, it's free. I'm using it in my laptop, but I'm using it with four gigabytes of memory, so it's not really heavy. So we logged into our CF installation, and we need to make sure that our CF installation supports running the occurrences. And there is this feature flag called Diego Docker, which you have to make sure it's enabled. This is not enabled in public installations. It's not enabled in pivotal web services, for instance, because running arbitrary documents is not a good idea if you're multi-tenant, but in PCF Dev it's fine. And we can then push our application. So we're running the usual CF push command. The difference here is that this is not uploading any source code. This is not including any YAML files, and the command line argument that specifies the image is minus all, and we don't need to tell it what's registered to use, as I said, it will use Docker Hub by default, so this is just creating a container using this image. So if you do CF hubs, we see there is a container, there is an application, it has a single instance, and it has a route assigned to it. Let's test the endpoint, so as we saw before, the application will just bring these two environment variables, so there are no surprises here. There's only one instance, so the application index, sorry, the instance index is zero. So let's scale it. Let's create five of them and see what's happening. So we're going to create five of them and hit the endpoint a couple of times, and we're going to get three different indexes. So zero, two, and one. So what we've seen so far is that you deploy Docker containers in the Igo in Cloud Foundry, and you get for free the load balancing, so there is a route, you send traffic throughout, and this route is then directed into different containers. There's one advantage of doing this with this idea. The advantage is that you get all the flexibility in managing your dependencies, so you don't have to depend on build packs, which in some cases is good. The first advantage is that you can easily derail yourself from the 12th factor up idea. So we all seen Docker images that they have multiple services, and they might write things, might write data in the container storage, and this is not 12 factors up. This is not what Cloud Foundry is about, and that can be problematic. And the second disadvantage is that since you are now in charge of building this Docker image, of maintaining it, of putting your code into it, and seeping it in Cloud Foundry, you are also in charge on patching it. So yesterday we heard Justin saying that software with known vulnerability is a big security threat, and this is true. And Cloud Foundry solves this with build packs, if you use Docker images, that's not going to be in charge of this. So let's go back to the original theme, and this is container registration in Cloud Foundry. So we saw how you can deploy containers, we saw how you can load balance the traffic within containers, and how you can scale them. What's missing? Well, in Docker and in Kubernetes and all these container orchestrators, you can attach to a container and look at its logs. You can look at its output and you can send some input and interactively and see what's happening. In Cloud Foundry, these are different things. You can attach to a process and look at its output using CF logs, as with ordinary applications. So I'm creating some background traffic here, just hitting the endpoint every second, and then running CF logs, which will give me back the output. This is the output of the application, so if you have multiple instances, you will get the output from all these instances. And attaching to the container, like trying to interactively debug and manipulate a running container, for that there is CFSSA. This is another not so new feature. It was enabled last year with Diego, with the release of Diego. But running that, you can jump into a container cell, and just to prove you that, I can just run PS. You will see all the container processes here. There is an S8D moon. There is the app.py. And there's a cell. And this cell has the environment, the CF environment that the application has. So I can refer to known environment variables, like the instances. This is zero by default. The CFSSA will attach to the first container, the first instance, but you can configure that. You can ask for a specific container. All right. So the last thing I want to show you is what we call CF Docker breach. So last year, Jules presented this idea of using Docker as a back end for Cloud Foundry. It was called Garden Docker, and the idea was that Garden would be the front end, it would create containers in Docker, and then the whole Cloud Foundry would use Docker to create containers. And this is something we've been discussing for a long time. CF Docker breach is a diverse idea. So CF Docker breach is actually using Docker as an interface, Docker CLI as an interface, and Cloud Foundry is a back end, because we just saw that Cloud Foundry is a container administrator. So I just installed CF Docker breach. This is a go application, so go get will do. And I have to start the CF Docker breach daemon. I have to define a socket. This is a socket that the Docker client will connect to, and to tell Docker client where to connect to, we have to export this environment variable. And then just Docker run. So I'm using the same image, the same Docker image that I used before. And as you can see in the background, what this is doing is CF push. It's creating a container, which is actually a Cloud Foundry application. And if you run CF apps, there it is. It's your Cloud Foundry application. It's your Docker container. It's your garden container. It's a container for Cloud Foundry. Thank you. So hopefully, I just want to underline what you just saw at the end of that, which is using the regular Docker client with a regular Docker command to push a container, but orchestrating it and scaling it as a regular app inside Cloud Foundry, which shows you just how similar the systems actually are, but you get for free all the Cloud Foundry stuff. So let's briefly do some comparisons to just talk about the differences between some of these things. So firstly, I just want to talk about the back end container technologies that are going on here. Because last year, we were talking about Garden Docker, and Garden Docker was an experimental back end for Garden, which instead of using Garden's own custom code, used Docker engine to run CF workloads. Now I'm happy to say that we're running on Garden Run C. So Garden Run C is the new back end that's currently moving through Diego's CI pipelines, which uses Run C. What is Run C? Well, Run C is the container engine part of Docker. So Docker has spun that out as a separate project. It's donated to a foundation that's also part of the Linux foundation with multiple companies owning it. And so we're now using that code. It's the same code that Docker's using. Because it's the same code Docker's using, it's the same code Kubernetes is using. So the only thing that wasn't using it was Garden Linux. But Garden Run C is now in Diego's CI pipeline, so hopefully Garden Linux will soon go away. And then actually, whichever container orchestrator you use, you're really just spinning up Run C containers. It's all exactly the same container technology at the back. So what really matters is the user experience, right? What does a user see? What does a user think about when they come to the system? Well, Docker is containers, right? Everything is containers, just push containers. Kubernetes has these declarative pod specs, which are actually more complicated than containers, but they're still really very low level things that you have to understand. Cloud Foundry is code, right? Push is your code. We'll figure out how to run it. But if you want to give us a container, that works too. We're not opinionated about that. We can actually do either one of those things. So what does that mean for the cell API? The thing that runs on each one of the nodes in a cluster? Well, the Docker thing is just containers, right? Containers of the node, containers of the host. That means you end up with quite a lot of complexity on the node that you didn't really need. Because you were doing all the stuff for the UX that you needed a user to see at the cluster level. And you now have to have that on every node. Again, Kubernetes, it's pod specs, it's this pod spec idea. Garden uses a container spec. What's a container spec? A container spec is a cut down simplified API that's built just to be a cell level API. It's not built for a user to use. We do that at the cluster level. And it's proven cross platform. So we have implementations for Windows. It doesn't have the features that aren't cross platform inside the API. And it can evolve along with the overall system. So now, garden run C is really a very small piece of glue that just wires run C into the rest of the system with an API that's extremely simple but tailored for Diego and tailored for an orchestrator to use, rather than for a user to use because they're fundamentally different things. So the summary. Okay. So yeah, we basically in reverse order, garden run C is a tiny wraparound run C. We're using a common code base, common code with Docker. And this means that this code base is maintained by his community, essentially. And the wrapper is small. It's easy to maintain. It's easy to secure. Sort of. And we're using the garden API, still, which is cross platform. It's proven. It's been in Cloud Foundry for some time now. And the second beat is Cloud Foundry. We have the haiku. Everyone sticks to it. Here's my code. But you can also really say here's my container. You can still deploy your container. You can still treat Cloud Foundry as a container orchestrator. The system is end to end either way. So the system is provided you with all the functionality you need, with metrics, with logging, with all this stuff, whether you're using the build tags or the containers. And you can use either or both. It doesn't really matter. Thank you. So I reckon we have about eight minutes if anyone has questions. So the question is whether this will be in the pivotal Cloud Foundry release or just in the open release. I think we'd have to ask pivotal. But I mean, it's going through Diego's CI pipe by now. So I think the intention for most people is that this will replace Garden Linux and will be the runtime that Diego uses. So my question is it's going to support the HTTP routing through GoRouter. So it's going to support the TCP routing as well. Because it's inside a container, I can listen to any port. Right. The question is, does this support HTTP routing and TCP routing? And yet that all happens higher up in the stack. So all of that stuff should work regardless of whether you use code or containers. All of the stuff should just work. So I can listen to any port. Yeah, I think so. I think we use the first exposed port in Docker by default at the moment. I don't know if we support multiple ports, but. So there's another talk which is about container to container networking, which I think is after this talk, which is talking about those plans for doing networking between containers.