Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2016 (Seattle), 16 Nov 2016

Previous Meeting

⏯

youtube image

►

From YouTube: rkt and the Open Container Initiative: Promoting Industry Standards by Derek Gonyeo, CoreOS, Inc.

Description

rkt and the Open Container Initiative: Promoting Industry Standards - Derek Gonyeo, CoreOS, Inc.

The container industry has come together and drafted the OCI specifications to define what a container runtime is and how they should package and share content. As a founding member of the OCI, CoreOS is dedicated to making rkt, our container runtime engine, compliant with these new specifications. This talk will describe the particulars of the OCI specifications as they relate to rkt, what we’ve done so far to bring rkt into compliance, what our next steps are, and how this benefits our users.

About Derek Parker
Derek Parker is a software engineer at CoreOS working on backend Go services and upstream Kubernetes. He is author of Delve, a debugger for the Go programming language, and contributor to various open source projects.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Okay, hi everyone, sorry we're starting a few minutes late had some technical difficulties. My name is derek gallo. An employee of core OS I am a rocket scientist and I am here today to talk to you about rocket and the open container initiative promoting industry standards. Just so you have an idea of what I'll be talking about today. Here's a short agenda, so we talked about the history of containers.

A

How it's grown over the years like you know, involved into what it is today we're talking about exactly what the current state of the container world is. You know the different things out there and like how they kind of a group grew off of each other, then we'll be talking about what is oci and what rocket is doing to support oci and so a quick couple of quick definitions rocket. It's a for those of you unaware it's a container runtime from core OS, so it fits the same role in your technology stack docker.

A

Would it can fetch container images from the docker hub or other registries, manage a local on store, a collection of them? It can execute them. So don't run the container images, and so on and OC I is a standards organization. It exists to define container standards I'll, be talking a lot more about that later and so now, quick history lesson so back at the dawn of time or donna UNIX epoch. Traver came for.

A

You know what should same thing really when you just ran a process or just run on the host, there's no way to separate it out into a consistent environment or to prevent processes from messing around with each other, and so we've had this idea for a long time now that we want the ability to take some job or some application and put it in slope, this little sandbox environment, where it as a matter what's going on the host or in other applications on on the on the host or you know if it goes bad I can't mess with other things going going around on around out there, and you can trace this idea back four and a half decades actually to the first virtual machine implementation in 1972, which was the vm 370 released by IBM.

A

And so you know this is forever ago at this point, but we now have the ability to have full isolation between machines that you are running and the host that is hosting them, and it's a relatively secure way of doing it. Some of the cons is that it's a really large overhead for running this, because you're virtualizing, all of the hardware need to run a machine, and it can be hard to manage these machines.

A

We got in tools over the years, get better at it like puppet and so on, and you also mind you dedicated hardware. It's like these days, pretty much everyone has hardware or until hardware virtualization, but if we start moving our laptops and like that who knows, if, like we'll, still have that- and this was cool in the day, because all of a sudden, you could support a lot more time. Shorter users were the same hardware.

A

Implementation was in that efficient, so you know, when you got to my too many users, things would kind of slowed down a lot and jumping forward seven years. We then see that route. This call- and this is an entirely different way of to approach this problem and that's there is no overhead at all processes that are running or the same as proof they would have been running before, but you can now change the route of an application, that's running and give it like separate libraries or configs or log files, or so on.

A

You know per application, but this is not much isolation beyond that. You don't have any process isolations. The processes can still see and talk to each other interact with each other as they see fit mess with the host there's no network isolation, so I can't be like web server. A you get a different IP address and web server be running on the same machine. There's no hardware restrictions, so I can't be like you know: application a you're only allowed to use up to 200 megabytes of RAM, and only one cpu core or anything like that.

A

So Shiming for a lil bit further in 2003 bsd for dex introduced jails. Now we have process isolation. I can make this little sandbox environment. I can put some processes inside of it. They can't see outside of this little sandbox. They can only interact with things their own little world I can get the sandbox its own network address. So I can have multiple like web servers running on port 80, for example, on different IP addresses, but there's still no, at least in the initial implementation of jails.

A

Hardware, restrictions I can apply on the different sandboxes and almost at the same time of year, later Linux Gatsby server, which is pretty much jails for linux, but it required a patched linux kernel to run, which is notable because you know II now we're carrying these patches against the Linux kernel, which can be a pain 2005. We get zones which was introduced in solaris, 10, they're kind of like Jill's, but they notably have hardware restrictions. So now I can be like the application.

A

A you are only allowed to use, coordinate number three on the CPU, oh and you can only have 500 megabytes of RAM RAM and you can also do some other cool things like apply. Colonel emulation layers like this zone is only like uses.

A

The Linux emulation layers, so anything running inside of there can use like Linux s calls and so on so the next year we start to see the Inklings of what like we consider to be the modern implementation of containers and Linux, and that see groups were introduced to the colonel in 2006 they're, originally called generic process containers, but they were renamed to see groups very shortly after tariffs like this, isn't the entire picture of what containers in CQC containers and Linux needs, but they were processed level in our process level.

A

Hardware restrictions, so I can be like see this process running right here. It and all of its children are restricted to like. So so much memory or you know some other resource, and this was pushed forward by Google actually when they were implementing Borg back in the day. So you know it fits very nicely into the whole urbanized world view we have the today and then couple years later we get Alex C, and now this is a true native. Don't doesn't need patches, container runtime for linux, you have the process, isolation, you want.

A

You have hardware restrictions, so you can prevent and processes from running amok. You have network isolation, so I can you know, run five different web servers all on port 80. You don't need a patch colonel, unlike be server, and for a while this was the state-of-the-art and containers and likes. This is how you did it. You know why would we ever need anything more than that? We all four bullet points here. Sound fantastic, well, five years later and docker comes along is like wait. There's there's something missing from this picture.

A

You can do you can do a lot more with this and they introduced the concept of a container image where container image is a tar file containing the resources needed to start a new container and up and up until this point, if you wanted to you, know, have an environment where you ran like engine X incited, for example, you need to deliver. You know from scratch on the host.

A

There were tools to help with this, but there was no like easy way to just reach out to the Internet and grab an environment for some application and just have it available on your system and that's what docker invented that that was there, those in marketing their big innovation here now, all of a sudden I could, as a user just be like. I made this cool web app. It does. This super awesome thing package it up into this little bundle put on the internet, and anyone can just run that as a container.

A

So now that we have container images work and what can we do with them? You can build them. So you know docker build like docker files is the common way to do this today. Put them in registries, pull them from registries and run them, which is the process of once I have a container image extracting it onto disk, and then using that to you know, be the environment.

A

For this little sandbox and creating so container is with this innovation we're now shareable I could make my web app put it up on the docker hub for everyone else to use. Containers were now tribulus duplicate, because, if we're running one apache container that came from a container image, it's very easy to take that container image hand to the runtime and say: please create another copy of this they're a trivial to make, as we've seen just the best prolific proliferation of docker files.

A

You know just through many projects and images available in the darker hub and they're downright convenient in a single command. I can be running a full Fedora sandbox on my laptop and that really wasn't easy to do before. So when you're later than Cora starts rocket, which is the team that I'm from encore s, and so it was really originally spelled. Roc ket, we later renamed it to our katie rocket, pronounced the same way and our big argument of why we created this was we wanted to be an early scoped.

A

We saw that doctor was, can continue. Inc was continually adding more features, more functionality, more value into docker the container engine, but we believe that the container runtime should be a very strictly defined like gnarly scoped thing, that is just a standard building block of the modern data center.

A

The idea being that, if you want all these fancy features like orchestration, that should be added to the layer above that which is the cabernet DS model. We want the run time to just be a reliable single components. The UNIX philosophy do one thing and do it well and to this end, before we created rocket, we sat down and create a specification for what is a container runtime. What does contain our image? How does how do the to interact with each other?

A

How do I discover container images, and that is the app c or app container spec? So if you want to use rocket, you want to make a build tool that builds rocket images or anything like that. You don't have to worry about the implementation. You can just go and read the specification of how does it work and the idea here there makes it much easier to improve interrupted projects but now's a problem, so let's say you're a post-crescent maintainer.

A

You want to release postgres container images to get make it easier for people to get up and running with the project which implementation do you release images for? Do you maintain post ghost emerges for and rakesh that's some duplicate work or, if you're, building an orchestration framework which implementation do you use the semantics between rocket and docker image are very different. You can't just easily write a shame to like add rock and support into docket into Cooper Nettie's. If you have dr.

A

support and vice versa or if there's new implementation like we made rocket, we have FC, we personally like it more, but everyone else is using docker images and the docker hub, which is a different spectrum. Hi rocket works. So how do we overcome that kind of locking or how do users also deal with that? Maybe you guys think rockets interesting. I want to try it out, but I entire CI workflow is. It produces docker images and they put them in the docker hub and so on, so and so on.

A

So there's a way to solve this problem. Let's all get together and talk about an agree on what exactly is container image. If I grab one put, tear tear it open. What do I see? How is the manifest formatted? How are the files and they're stored so on? How does one fetch and verify container image if a user requests? Please get me the engine X image? What's the process for that? How do I go out in the internet find that an engine X image? How do I download it?

A

How do I ensure that it was created by the people who it should have been wasn't modified in transit and what does it mean to run a container image? I have this tarbell on disk now how? What is it? The exact process by which I can extract that and start a processes from in there?

A

What what does it mean to like you know, do I need to make some calls what what environment variables should be set so and so on and whatever our answer, these questions should not be tied to a specific run, timer orchestration framework, because that'll just prevent new runtimes that are better new orchestration frameworks that are better from coming in being able to compete and also shouldn't be tied to a specific commercial entity, because if there's one business that is driving this their business, things won't necessarily be aligned with whatever is best for the ecosystem here.

A

So this was the motives and the reason why the open container initiative was created and starred in 2015, so oci defines an image specification, which is what is a container image and defines a runtime specification or how do I run an image, and this is a open thing. Everyone in this room everyone this conference, all people in this community are welcome to participate, is just up on github. Everything is open source and the specifications that oci is defining are based on proven technologies.

A

The runtime spec is based on Dockers lib container, which is now called run c, and the image spec is based on docker images, so everyone uses docker, it's great. Many companies are using it in production. It's a viable thing. Many registries have been built that use the dock. Respek we've seen that it's it's a specification implementation that scales it works for a lot of people, a lot of different situations.

A

So, if we're going to build this shared standard, let's based it on something we know works so both weren't times back in numerous back are largely extensions of our darker works today, and so just some details on how oci is set up and how it's structured but operates under the linux foundation. So it's a non-profit everything they do is open source.

A

It's all up on github and it's made up of a lot of companies like docker chorus Google at Red, Hat huawei, and you know- and the list goes on- and this is only a short sampling that I pulled off their website, and so as of today, both of these specifications that oci is defined, have released candidates out for version 1 point 0 and docker and I brought this slide a week or so ago. I forgot to check if this has changed since I last looked at it leases of week ago, dr.

A

had a pull request open for adding support for building addressing oci images, so docker is closed during support and registries like away from core OS, for example, are working on adding support for oci images, so once once the release candidates are released, will have a stable specification all of us and start to build against and support. So we're really close to having this a group shared an agreed-upon, think all of us and start to use. So what is the rocket team doing? You know this? This is this.

A

Is the part where I commend what what is? What are? We at core OS and the rocket team doing to make this a reality. How or we are pulling our part of it. So I'm going to talk about this in two parts, supporting the runtime spec and supporting the image spec the runtimes back. In order to explain how we're going to support it. Requires you guys to understand a little bit more about rockets architecture, so I'm going to explain that quickly so rocket is this is a multi-stage rock split into three stages?

A

You know the stage 0 stage, 1 and stage 2 stage 0. It does a lot of things that one beefy thing is image management when you call a rocket command on your system stage. 0 is the binary that you just started. It's the binary exists in your path. It'll, do things like tell you about in containers, are running it'll, fetch container images for you delete images and when it comes time to actually run your application, it starts an entirely different component called the stage one. The stage one is packaged up just as a normal container.

A

It's just espesh thing inside of rocket, and this is an entirely swappable component and it's responsible for setting up the isolation. So in the default case, that's making the troops. This calls making the namespaces calls and setting up you know mounts and network interfaces for your application and stage two is the user application? That's the thing provided by you guys, it's whatever app container, you told rocket to run, and so current stage ones we have. There is the default one. It's called chorus under the hood.

A

It uses system DN spawn to do all the heavy lifting for it. There's also the fly stage one. This is notable because when the task of the stage one is just set up the isolation, you don't need to follow the typical container like Linux containers, security model, so fly just. Does a change reach this call? It doesn't set up any namespaces for you. Doesn't you know really much in the way of security? This is useful if you want to run something like the grenades cube.

A

'let that needs to set up a lot of mount, set up a lot of network interfaces and do a lot of things like that in the host. But you still just want to consistent environment to be able to ship it and run it inside of or you can go, the opposite direction be like I. Don't trust this application at all? If someone's going to break it, it's going to do something: malicious I, don't trust containers either they're newfangled thing, there's breakout of ulnar abilities every other day.

A

Let's use kvm I'll just use the root of s from the container image start up. A new kvm process use the root of s, one container image as the VMS root filesystem and start up a process inside of there, and so if we want to support the runtime spec, that's really easy because just add a run see stage. One just have a stage, one that calls out to run, see to set up everything and then it'll do whatever the runtime specs defines because run c is complying with the runtime spec. Ok, so that's easy!

A

Let the image spec so rocket for a long time now supported docker images by internally can ring them to have see images you tell rocket, you want to run docker Kong, / Ubuntu rocket goes out to the docker hub, pull us down the Ubuntu in which converts it into an FC image and puts it into store, uses it. So the OSD I spec is based on the the oci image.

A

Spec is based on the dock respect, so it should be really easy to just you know, add support for this, which I is exactly I did last summer. So rocket is at OC. I support since last summer, where they're quotes around support, because it's internally converting an oci image to something is not OC a compliant. So you know we can't really communicate compliant with this, but it does still work. So what do we need to do to remove those air quotes? Then? Well, that's.

A

That's a little more complicated I'm going to talk about this in a few parts. So, let's, let's look at fetching specifically first fetching osgi container images, so ab c image discovery, which is the process by which you give it a container name and it finds actually we're in the internet needs going. You know, pull that image from is very different from dr ain't, much bullying, apps, the images can be hosted, static files.

A

If you want to host app sea containers, you can just put them in an s3 bucket fetch it over https call it a day, whereas with docker you need much. You need to contain back in. That has more logic really to be able to do the casts, work and stuff like that. Apps, the images are fetch. My name, dr. layers are pretty much fetch by hash. So if I go and fetch you know ubuntu, I can just specify good registry named ubuntu and docker.

A

It's more like the bunch of refers to a hash that will have a series of hashes. It needs to fetch so they're reference differently, which is kind of the with the next bullet points getting into each FC images, one layer, each docker image as many layers so like. If I pull in python, for example, it might have a dependency on ubuntu and that that link to a bunch, you won't specify a hash you'll, just specify the name like weighted io / upon two.

A

So you know there's different semantics there that will need to effectively re-engineer rocket to be able to handle, but once you get these images- and we also then need to store them, so we're not going to drop FC support for a very long time. We have users that rely on it every day and it's not something we can just you know abandon so we'll need to support both of these image formats. So rock will need to store to two types of images.

A

Then FC images no see I images and dependencies and layers, depending on which world's terminology you're using work differently between oci and app CE. O CI layers are a linked list. I specify Python respects rise up onto which, just probably it or you know it's just a directed it's a very much just a chain. Fc dependencies are directed acyclic graph, so I can like say I want image a image. A can have a dependency on image, be and image, see an image sea can ever dependency on image, DNA majee and you can have the so.

A

If I can we build this tree? But thankfully oci model is just a very specific form of AB C's models. Hopefully we can reuse a lot of the logic there and you know just render the same way and getting information about stored images will also change. Epstein oci manifests are inherently different by nature of their different standards.

A

So then we also needed to talk about building container images and so in docker. If you want to build an image, this is something you just do with the dock or to own a rocket. There's a separate utility called AC build so AC build was the app container build tool, and now it's going to be the awesome container, build tool yeah.

A

So this is actually something specifically I'm working on adding in support for a siebel to be able to produce both apps E&O CI images that when you start a build you'll specify which format you want it to build and then during the build you'll only have specific commands available to you, depending on which mode you're operating under and at the end, it'll spit out either an OC IM internap, see image based on you know what you said at the beginning, in the build and yeah that's pretty much my talk, a blue kotori company slide.

A

We're hiring come talk to us our booth for your curious yeah, so hoping to have time for questions now. Yeah.

B

Hi thanks for the talk um we really like rocket at my company, but it does.

B

It really hasn't been much in the way of a development environment story for it in the same way, that docker has all this machinery for docker for mac and docker for compote docker compose and things that target the development experience, whereas core OS seems to have come from the other way and say what's the ideal solution for production deployment with Kuber Nettie's in mind, and that is where we're deploying is it on the radar at all for the rocket or core OS teams to develop parallel or something? That's.

B

You know equivalent tooling, that will allow Mac users and Linux users, or just anyone in the presence of not necessarily having system TN spawn to be able to use rocket entirely in place of docker across the entire stack of what you know. A company needs to use containers for yeah.

A

That's definitely something we would love to have and we'd love to see us get there one day right now, it's just a question of manpower. We were just one team inside of core OS, whereas Dockers entire company behind it.

A

If someone came along, contributed the work I guarantee, you would be happy to accept it, but, as of today were more focusing on getting the production worth, as you said, we're more focused on any production work like use case really solid, but with the advent of oci, there's no reason you can't use docker in your development environment, build OC I'ma just from that than hannah to rock in your production environment.

A

To use it like the whole promise of OC is that you can now start to mix and match, like you like this build tool that red had made. For example, the produces oci images will then pop dropping into docker for your developers and like oci, workflow, CI workflow and then put it in like a rocket production of I'm like that. That would be. That would be a possible. You know scenario in the future.

A

Yeah I'd, like the answer, question more or less okay, anyone else, okay, okay, you mean replace rock of docker okay, so the question for the recording was: is the goal in the future to replace rocket with docker on replaced docker with rock and encore au s? Sorry, um and the answer is we don't care which one you use chorus for foreseeable future? Will ship both and if you want to use docker use, docker c'mon use, rack and youths rocket. You like we don't we don't want to force your hand into using one of the other.

A

In this situation we just want provide the option of using either one okay, any other questions. Okay, thanks everyone. You.