Check my 2 min audio theory on Containers
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
Well sure, but you have a Windows kernel. Why would a Linux kernel be expected to be required to run a Go app? The Windows kernel has a Linux compatibility layer to mimic Linux calls. So we'd expect it to be able to run anything that can run on Linux.
I assume you are using Go as an example because normally you need to compile Go to the platform and if you compile against Linux, then Windows would not be able to run it? But is Docker handling the translation here, or is Windows? What if you ran it on BSD? Or a different architecture, like ARM?
Go statically links the compiled code. Same source code is compiled for Linux or Windows or Mac or BSD. You're making my point with the first statement. There are no kernel dependencies, external libraries, etc with a Go app in the container. The same source could be run across most operating systems (excluding AIX and some other UNIX).
But your point was that Docker was including a kernel to run a full VM. My point was that it doesn't have to, it uses a shared kernel. So this makes my point, that Go doesn't require a full VM, therefore can use whatever kernel is already there. So it is a shared kernel.
OMG. It was not. My point is you can run Docker containers with NO SHARED KERNEL.
Right, so Docker is a type 2 hypervisor.
If you believe this statement is wrong, please explain how? Because to me, you just screamed "DOCKER IS A TYPE 2 HYPERVISOR" while seemingly trying to say it is not.
Shared Kernel = Contrainerization
No Shared Kernel = Type 2 Hypervisor (when an OS is needed beneath, like with Docker.)You're being purposefully obtuse. Your last sentence would mean KVM is a type 2. Docker creates a KVM VM on bare metal, type 1 end of story.
No, I'm not being obtuse at all. KVM doesn't run ON an OS, it IS the OS, making it a TYpe 1 (or Type 0 some call it.) We've covered this a lot and is unrelated here.
Docker is using KVM? So Socker is EXACTLY like ProxMox now? Just using Docker as the container and KVM for the virtualization? So Docker is NOT able to do full VMs, but just provides an interface to a hypervisor?
That's not at all the same as what you had said, that Docker was doing it itself. Any tool can automate something that already exists. I can write a script to manage KVM, it doesn't make the resulting VMs a script, or part of my script. It's just a management tool to the real thing.
It was obtuse to say it like Docker had this power and was doing things itself. Docker runs on top of an OS, so if Docker itself is virtualizing a full VM by definition it is a type 2. If Docker requires KVM, it can be a management tool for a type 1.
They use kubernetes to orhestrate docker brining up KVM VMs for OpenStack. Sure you can write scripts but you don't get anywhere near the power you have with k8s.
It's not a type 2 you're looking at this incorrectly. Docker is ensuring the VM runs on the host. The VM isn't running in a shared kernel at all. Again docker manages namespaces and cgroups. The it doesn't "contain" things like LXC. You can write your own SELinux policies and such to do this but it doesn't by default.
But when running a "normal" Docker workload, it is a container just like LXC (but not LXC any more) and does this stuff. That Docker was containerization was its bread and butter purpose from day one, just one focused on a very specific usage, for app isolation.
Docker still does all that, right? That K8s can orchestrate KVM seems great, but is Docker in play when doing that?
-
Like, can I just use K8s and KVM, and skip Docker if I only want that orchestration of KVM?
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
So assuming it is correct that Docker itself can't handle full VMs, and uses KVM instead for this task...
Then let's back up. How does Docker use KVM to build full VMs and maintain the utility that Docker is meant to provide? How do things work in this way?
Does Docker just act as a tool for downloading OS imagines in this case? Does Docker automate something inside of the VM? How is the maintenance of the VM get handled?
For example, with real Docker containerization, kernel patches are handled by patching the kernel on the host and this patches the kernel in the container (because it is shared.) But with KVM, we have to maintain the VM itself, rather than the host.
Because again it's only leveraging namespaces. You manage the VMs the same way you do any other way. Theadvantage with k8s is you say I need 100 compute instances and 50 storage instances and k8s/Docker make sure there is always that number running. It has nothing to do with VM management internally unless you want to run other containers inside of the VMs.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
Well sure, but you have a Windows kernel. Why would a Linux kernel be expected to be required to run a Go app? The Windows kernel has a Linux compatibility layer to mimic Linux calls. So we'd expect it to be able to run anything that can run on Linux.
I assume you are using Go as an example because normally you need to compile Go to the platform and if you compile against Linux, then Windows would not be able to run it? But is Docker handling the translation here, or is Windows? What if you ran it on BSD? Or a different architecture, like ARM?
Go statically links the compiled code. Same source code is compiled for Linux or Windows or Mac or BSD. You're making my point with the first statement. There are no kernel dependencies, external libraries, etc with a Go app in the container. The same source could be run across most operating systems (excluding AIX and some other UNIX).
But your point was that Docker was including a kernel to run a full VM. My point was that it doesn't have to, it uses a shared kernel. So this makes my point, that Go doesn't require a full VM, therefore can use whatever kernel is already there. So it is a shared kernel.
OMG. It was not. My point is you can run Docker containers with NO SHARED KERNEL.
Right, so Docker is a type 2 hypervisor.
If you believe this statement is wrong, please explain how? Because to me, you just screamed "DOCKER IS A TYPE 2 HYPERVISOR" while seemingly trying to say it is not.
Shared Kernel = Contrainerization
No Shared Kernel = Type 2 Hypervisor (when an OS is needed beneath, like with Docker.)You're being purposefully obtuse. Your last sentence would mean KVM is a type 2. Docker creates a KVM VM on bare metal, type 1 end of story.
No, I'm not being obtuse at all. KVM doesn't run ON an OS, it IS the OS, making it a TYpe 1 (or Type 0 some call it.) We've covered this a lot and is unrelated here.
Docker is using KVM? So Socker is EXACTLY like ProxMox now? Just using Docker as the container and KVM for the virtualization? So Docker is NOT able to do full VMs, but just provides an interface to a hypervisor?
That's not at all the same as what you had said, that Docker was doing it itself. Any tool can automate something that already exists. I can write a script to manage KVM, it doesn't make the resulting VMs a script, or part of my script. It's just a management tool to the real thing.
It was obtuse to say it like Docker had this power and was doing things itself. Docker runs on top of an OS, so if Docker itself is virtualizing a full VM by definition it is a type 2. If Docker requires KVM, it can be a management tool for a type 1.
They use kubernetes to orhestrate docker brining up KVM VMs for OpenStack. Sure you can write scripts but you don't get anywhere near the power you have with k8s.
It's not a type 2 you're looking at this incorrectly. Docker is ensuring the VM runs on the host. The VM isn't running in a shared kernel at all. Again docker manages namespaces and cgroups. The it doesn't "contain" things like LXC. You can write your own SELinux policies and such to do this but it doesn't by default.
But when running a "normal" Docker workload, it is a container just like LXC (but not LXC any more) and does this stuff. That Docker was containerization was its bread and butter purpose from day one, just one focused on a very specific usage, for app isolation.
Docker still does all that, right? That K8s can orchestrate KVM seems great, but is Docker in play when doing that?
No it's not. Default docker is namespaces and cgroups. They call it "containerization" but it is namespaces and cgroups.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
Like, can I just use K8s and KVM, and skip Docker if I only want that orchestration of KVM?
No. K8s uses docker.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
Well sure, but you have a Windows kernel. Why would a Linux kernel be expected to be required to run a Go app? The Windows kernel has a Linux compatibility layer to mimic Linux calls. So we'd expect it to be able to run anything that can run on Linux.
I assume you are using Go as an example because normally you need to compile Go to the platform and if you compile against Linux, then Windows would not be able to run it? But is Docker handling the translation here, or is Windows? What if you ran it on BSD? Or a different architecture, like ARM?
Go statically links the compiled code. Same source code is compiled for Linux or Windows or Mac or BSD. You're making my point with the first statement. There are no kernel dependencies, external libraries, etc with a Go app in the container. The same source could be run across most operating systems (excluding AIX and some other UNIX).
But your point was that Docker was including a kernel to run a full VM. My point was that it doesn't have to, it uses a shared kernel. So this makes my point, that Go doesn't require a full VM, therefore can use whatever kernel is already there. So it is a shared kernel.
OMG. It was not. My point is you can run Docker containers with NO SHARED KERNEL.
Right, so Docker is a type 2 hypervisor.
If you believe this statement is wrong, please explain how? Because to me, you just screamed "DOCKER IS A TYPE 2 HYPERVISOR" while seemingly trying to say it is not.
Shared Kernel = Contrainerization
No Shared Kernel = Type 2 Hypervisor (when an OS is needed beneath, like with Docker.)You're being purposefully obtuse. Your last sentence would mean KVM is a type 2. Docker creates a KVM VM on bare metal, type 1 end of story.
No, I'm not being obtuse at all. KVM doesn't run ON an OS, it IS the OS, making it a TYpe 1 (or Type 0 some call it.) We've covered this a lot and is unrelated here.
Docker is using KVM? So Socker is EXACTLY like ProxMox now? Just using Docker as the container and KVM for the virtualization? So Docker is NOT able to do full VMs, but just provides an interface to a hypervisor?
That's not at all the same as what you had said, that Docker was doing it itself. Any tool can automate something that already exists. I can write a script to manage KVM, it doesn't make the resulting VMs a script, or part of my script. It's just a management tool to the real thing.
It was obtuse to say it like Docker had this power and was doing things itself. Docker runs on top of an OS, so if Docker itself is virtualizing a full VM by definition it is a type 2. If Docker requires KVM, it can be a management tool for a type 1.
They use kubernetes to orhestrate docker brining up KVM VMs for OpenStack. Sure you can write scripts but you don't get anywhere near the power you have with k8s.
It's not a type 2 you're looking at this incorrectly. Docker is ensuring the VM runs on the host. The VM isn't running in a shared kernel at all. Again docker manages namespaces and cgroups. The it doesn't "contain" things like LXC. You can write your own SELinux policies and such to do this but it doesn't by default.
But when running a "normal" Docker workload, it is a container just like LXC (but not LXC any more) and does this stuff. That Docker was containerization was its bread and butter purpose from day one, just one focused on a very specific usage, for app isolation.
Docker still does all that, right? That K8s can orchestrate KVM seems great, but is Docker in play when doing that?
No it's not. Default docker is namespaces and cgroups. They call it "containerization" but it is namespaces and cgroups.
Namespaces and cgroups were how the first containerization was done. That's the core of containers. That's how LXC does it, more or less.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Like, can I just use K8s and KVM, and skip Docker if I only want that orchestration of KVM?
No. K8s uses docker.
And Docker uses KVM sometimes for certain conditions? So K8s can use KVM through Docker?
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Like, can I just use K8s and KVM, and skip Docker if I only want that orchestration of KVM?
No. K8s uses docker.
And Docker uses KVM sometimes for certain conditions? So K8s can use KVM through Docker?
K8s only does Docker orchestration. I guess you could say that in a weird way like saying Bash uses KVM through libvirt.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
Well sure, but you have a Windows kernel. Why would a Linux kernel be expected to be required to run a Go app? The Windows kernel has a Linux compatibility layer to mimic Linux calls. So we'd expect it to be able to run anything that can run on Linux.
I assume you are using Go as an example because normally you need to compile Go to the platform and if you compile against Linux, then Windows would not be able to run it? But is Docker handling the translation here, or is Windows? What if you ran it on BSD? Or a different architecture, like ARM?
Go statically links the compiled code. Same source code is compiled for Linux or Windows or Mac or BSD. You're making my point with the first statement. There are no kernel dependencies, external libraries, etc with a Go app in the container. The same source could be run across most operating systems (excluding AIX and some other UNIX).
But your point was that Docker was including a kernel to run a full VM. My point was that it doesn't have to, it uses a shared kernel. So this makes my point, that Go doesn't require a full VM, therefore can use whatever kernel is already there. So it is a shared kernel.
OMG. It was not. My point is you can run Docker containers with NO SHARED KERNEL.
Right, so Docker is a type 2 hypervisor.
If you believe this statement is wrong, please explain how? Because to me, you just screamed "DOCKER IS A TYPE 2 HYPERVISOR" while seemingly trying to say it is not.
Shared Kernel = Contrainerization
No Shared Kernel = Type 2 Hypervisor (when an OS is needed beneath, like with Docker.)You're being purposefully obtuse. Your last sentence would mean KVM is a type 2. Docker creates a KVM VM on bare metal, type 1 end of story.
No, I'm not being obtuse at all. KVM doesn't run ON an OS, it IS the OS, making it a TYpe 1 (or Type 0 some call it.) We've covered this a lot and is unrelated here.
Docker is using KVM? So Socker is EXACTLY like ProxMox now? Just using Docker as the container and KVM for the virtualization? So Docker is NOT able to do full VMs, but just provides an interface to a hypervisor?
That's not at all the same as what you had said, that Docker was doing it itself. Any tool can automate something that already exists. I can write a script to manage KVM, it doesn't make the resulting VMs a script, or part of my script. It's just a management tool to the real thing.
It was obtuse to say it like Docker had this power and was doing things itself. Docker runs on top of an OS, so if Docker itself is virtualizing a full VM by definition it is a type 2. If Docker requires KVM, it can be a management tool for a type 1.
They use kubernetes to orhestrate docker brining up KVM VMs for OpenStack. Sure you can write scripts but you don't get anywhere near the power you have with k8s.
It's not a type 2 you're looking at this incorrectly. Docker is ensuring the VM runs on the host. The VM isn't running in a shared kernel at all. Again docker manages namespaces and cgroups. The it doesn't "contain" things like LXC. You can write your own SELinux policies and such to do this but it doesn't by default.
But when running a "normal" Docker workload, it is a container just like LXC (but not LXC any more) and does this stuff. That Docker was containerization was its bread and butter purpose from day one, just one focused on a very specific usage, for app isolation.
Docker still does all that, right? That K8s can orchestrate KVM seems great, but is Docker in play when doing that?
No it's not. Default docker is namespaces and cgroups. They call it "containerization" but it is namespaces and cgroups.
Namespaces and cgroups were how the first containerization was done. That's the core of containers. That's how LXC does it, more or less.
Containerization uses those but that's not what makes it containerization. Normal processes are controlled with namespaces and cgroups as well.
-
Here's a decent article from Jess Frazelle. She was on the core Docker Dev team and is a Linux kernel dev.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
Here's a decent article from Jess Frazelle. She was on the core Docker Dev team and is a Linux kernel dev.
Except she gets the basics wrong. I'm sure she knows the ins and outs of Linux containers, but she is using "container" incorrectly in a new, made up way. BSD Jails and Solaris Zones are both containers. In fact, the term containers started with the Jail system, it predates everything else. Any other use of container is a new use, like cloud. Cloud computing is a very well defined thing and the term originated there. Similar with containers. Now she's trying to use it in some unique way and trying to say that the "founding fathers" of containerization aren't containers at all, that's total BS.
We were using containers before Linux started using the term, and Linux copied it both in name and technology from those that came before it.
She even mentioned Solaris Zones which are explicitly containers. And jails is a synonymous term with containers. We could call LXC a form of jails and be correct.
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
"..containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,[1] partitions, virtualization engines (VEs) or jails (FreeBSD jail or chroot jail), may.."
OR... is she trying to use Linux Containers, but attempting shorthand to the very different generic world "containers"? If so, maybe the article is accurate and maybe English isn't her first language.
For the article to make sense, she has to be assuming we already know that all four options are "containers", small c, and that she is referring, without ever saying it, to Linux Containers the specific technology, each and every time she uses the world containers, which should at least be capitalized if she is going to use a proper noun without any other clarity.
In which case, she is correct, but the article doesn't seem to them refer to what we are discussing. It only makes sense to have been linked in the case where we assume she was contrasting all of those technologies with containers, which is incorrect as they are the prime textbook examples of containers.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
Containers use shared kernels by definition, that's what makes it a container.
This isn't really how Docker works. Docker manages namespaces. If you use "FROM Alpine" then it will share the kernel, but if you write an app in Go and use "FROM scratch" it has zero reliance on a specific kernel. You can also run full VMs in a Docker container which is how Red Hat uses OpenShift to deploy OpenStack VMs.
Well go requires the kernel too. But yes for the most is the "from scratch" part which allows more abstraction
Well I mean you have to have a kernel for anything to run. My point was it is technically possible to run a Go app in Docker natively on Windows with no Linux anywhere.
Well sure, but you have a Windows kernel. Why would a Linux kernel be expected to be required to run a Go app? The Windows kernel has a Linux compatibility layer to mimic Linux calls. So we'd expect it to be able to run anything that can run on Linux.
I assume you are using Go as an example because normally you need to compile Go to the platform and if you compile against Linux, then Windows would not be able to run it? But is Docker handling the translation here, or is Windows? What if you ran it on BSD? Or a different architecture, like ARM?
Go statically links the compiled code. Same source code is compiled for Linux or Windows or Mac or BSD. You're making my point with the first statement. There are no kernel dependencies, external libraries, etc with a Go app in the container. The same source could be run across most operating systems (excluding AIX and some other UNIX).
But your point was that Docker was including a kernel to run a full VM. My point was that it doesn't have to, it uses a shared kernel. So this makes my point, that Go doesn't require a full VM, therefore can use whatever kernel is already there. So it is a shared kernel.
OMG. It was not. My point is you can run Docker containers with NO SHARED KERNEL.
Right, so Docker is a type 2 hypervisor.
If you believe this statement is wrong, please explain how? Because to me, you just screamed "DOCKER IS A TYPE 2 HYPERVISOR" while seemingly trying to say it is not.
Shared Kernel = Contrainerization
No Shared Kernel = Type 2 Hypervisor (when an OS is needed beneath, like with Docker.)You're being purposefully obtuse. Your last sentence would mean KVM is a type 2. Docker creates a KVM VM on bare metal, type 1 end of story.
No, I'm not being obtuse at all. KVM doesn't run ON an OS, it IS the OS, making it a TYpe 1 (or Type 0 some call it.) We've covered this a lot and is unrelated here.
Docker is using KVM? So Socker is EXACTLY like ProxMox now? Just using Docker as the container and KVM for the virtualization? So Docker is NOT able to do full VMs, but just provides an interface to a hypervisor?
That's not at all the same as what you had said, that Docker was doing it itself. Any tool can automate something that already exists. I can write a script to manage KVM, it doesn't make the resulting VMs a script, or part of my script. It's just a management tool to the real thing.
It was obtuse to say it like Docker had this power and was doing things itself. Docker runs on top of an OS, so if Docker itself is virtualizing a full VM by definition it is a type 2. If Docker requires KVM, it can be a management tool for a type 1.
They use kubernetes to orhestrate docker brining up KVM VMs for OpenStack. Sure you can write scripts but you don't get anywhere near the power you have with k8s.
It's not a type 2 you're looking at this incorrectly. Docker is ensuring the VM runs on the host. The VM isn't running in a shared kernel at all. Again docker manages namespaces and cgroups. The it doesn't "contain" things like LXC. You can write your own SELinux policies and such to do this but it doesn't by default.
But when running a "normal" Docker workload, it is a container just like LXC (but not LXC any more) and does this stuff. That Docker was containerization was its bread and butter purpose from day one, just one focused on a very specific usage, for app isolation.
Docker still does all that, right? That K8s can orchestrate KVM seems great, but is Docker in play when doing that?
No it's not. Default docker is namespaces and cgroups. They call it "containerization" but it is namespaces and cgroups.
Namespaces and cgroups were how the first containerization was done. That's the core of containers. That's how LXC does it, more or less.
@scottalanmiller @stacksofplates
I found something that will please you both, check this guy:
https://twitter.com/DEVOPS_BORAT
@DEVOPS_BORATHard part in devops is make money from wheel after you are reinvent it.
-
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
Here's a decent article from Jess Frazelle. She was on the core Docker Dev team and is a Linux kernel dev.
Except she gets the basics wrong. I'm sure she knows the ins and outs of Linux containers, but she is using "container" incorrectly in a new, made up way. BSD Jails and Solaris Zones are both containers. In fact, the term containers started with the Jail system, it predates everything else. Any other use of container is a new use, like cloud. Cloud computing is a very well defined thing and the term originated there. Similar with containers. Now she's trying to use it in some unique way and trying to say that the "founding fathers" of containerization aren't containers at all, that's total BS.
We were using containers before Linux started using the term, and Linux copied it both in name and technology from those that came before it.
She even mentioned Solaris Zones which are explicitly containers. And jails is a synonymous term with containers. We could call LXC a form of jails and be correct.
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
"..containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,[1] partitions, virtualization engines (VEs) or jails (FreeBSD jail or chroot jail), may.."
She's saying "Docker containers" aren't a thing. She's separating them out because people are calling them "containers" when they aren't. Whereas LXC/zones/jails are.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
I'm confused, though. "Normal processes" use shared kernels. If we use Linux or Windows, and no containerization at all, all processes use shared kernels, that's the core of normal operating system functions.
Hypervisors are what allow us to use non-shared kernels, whether for OSes or something else (rare.) Docker either has to provide another kernel that isn't shared, or must share the one that is there. That the workloads aren't tied to a specific kernel is very different than not requiring that they share whatever one is there.
Kernel agnostic isn't the same as kernel-free. You can't be kernel free, not really. You always need the kernel unless you have no multi-tasking on the system whatsoever.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
Here's a decent article from Jess Frazelle. She was on the core Docker Dev team and is a Linux kernel dev.
Except she gets the basics wrong. I'm sure she knows the ins and outs of Linux containers, but she is using "container" incorrectly in a new, made up way. BSD Jails and Solaris Zones are both containers. In fact, the term containers started with the Jail system, it predates everything else. Any other use of container is a new use, like cloud. Cloud computing is a very well defined thing and the term originated there. Similar with containers. Now she's trying to use it in some unique way and trying to say that the "founding fathers" of containerization aren't containers at all, that's total BS.
We were using containers before Linux started using the term, and Linux copied it both in name and technology from those that came before it.
She even mentioned Solaris Zones which are explicitly containers. And jails is a synonymous term with containers. We could call LXC a form of jails and be correct.
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
"..containerization, refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances. Such instances, called containers,[1] partitions, virtualization engines (VEs) or jails (FreeBSD jail or chroot jail), may.."
She's saying "Docker containers" aren't a thing. She's separating them out because people are calling them "containers" when they aren't. Whereas LXC/zones/jails are.
She never says that, ever. She once refers to Linux containers, but that's LXC, not Docker. Otherwise, she just says "containers." From where do you get the impression she's even aware of Docker, let alone speaking about it? Docker isn't mentioned a single time in the article, DockerCon is, but that's a conference and easily people talk about other things there, too.
The article doesn't appear to be about Docker at all, but contrasting LXC with Zones, Jails, and VMs.
-
She explicitly says "Linux containers" once, but only once. But it's the only hint we have, and Linux containers is LXC (that's what the abbreviation stands for.)
-
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
I'm confused, though. "Normal processes" use shared kernels. If we use Linux or Windows, and no containerization at all, all processes use shared kernels, that's the core of normal operating system functions.
Hypervisors are what allow us to use non-shared kernels, whether for OSes or something else (rare.) Docker either has to provide another kernel that isn't shared, or must share the one that is there. That the workloads aren't tied to a specific kernel is very different than not requiring that they share whatever one is there.
Kernel agnostic isn't the same as kernel-free. You can't be kernel free, not really. You always need the kernel unless you have no multi-tasking on the system whatsoever.
But by that definition if you used Ansible to start a process you would say Ansible is using a shared kernel. That's such a weird way of saying it. Obviously a process has to use a kernel. The "sharing" comes in where you have a whole set of different libraries, etc and have to rely on a kernel that's outside of itself.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@stacksofplates said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
She is correct, of course, that the designs are different. Each OS approaches the problem from a unique angle. But all are containers and use a shared kernel to manage resources.
Docker doesn't require a shared kernel is my point. You can run a single process that requires nothing shared from the kernel. It's effectively like starting a normal so process.
I'm confused, though. "Normal processes" use shared kernels. If we use Linux or Windows, and no containerization at all, all processes use shared kernels, that's the core of normal operating system functions.
Hypervisors are what allow us to use non-shared kernels, whether for OSes or something else (rare.) Docker either has to provide another kernel that isn't shared, or must share the one that is there. That the workloads aren't tied to a specific kernel is very different than not requiring that they share whatever one is there.
Kernel agnostic isn't the same as kernel-free. You can't be kernel free, not really. You always need the kernel unless you have no multi-tasking on the system whatsoever.
But by that definition if you used Ansible to start a process you would say Ansible is using a shared kernel. That's such a weird way of saying it. Obviously a process has to use a kernel. The "sharing" comes in where you have a whole set of different libraries, etc and have to rely on a kernel that's outside of itself.
Correct, we don't say that because it's obvious and necessary so stating it is like saying that Ansible requires an OS. But obviously Ansible requires a shared kernel. What makes us mention it with containers is that unlike all other forms of virtualization that use a hypervisor to use non-shared kernels, containers are shared kernel virtualization. So it is mentioned all the time because it's necessary to understand that it is truly a container and not some other thing.
