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.
-
@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.
-
@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:
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.
From where do you get the impression she's even aware of Docker, let alone speaking about it?
These are the kind of things you say that people get annoyed with. Well first she's written a decent part of Docker so there is that. Second, she's speaking to the myriad of people who have heard of Docker and think it's something that it isn't. She's pretty famous for understanding how all of this works together.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
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.
Right, but with normal VMs, it's not a shared kernel (with the host.) So the term "shared kernel" in this context is another way of saying "containter." And something that "runs a workload without a shared kernel" is another way of saying "full or para virtualization".
Shared Kernel Virtualization = Container (or Type C, Jails, etc.)
Non-Shared Kernel Virtualization = Full or Para Virtualization (or Type 1 and Type 2)The term container means that it is virtual, but the kernel is shared.
-
@emad-r said in Check my 2 min audio theory on Containers:
DevOps
DevOps Engineer maybe could be a job title, but it's almost certainly not what you are doing in your job.
DevOps Admin could possibly be a job title, for someone who administers the DevOps tools.
DevOps is not a department, and companies that uses titles like DevOps Engineer probably aren't really doing DevOps, just using some DevOps tools.
-
@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:
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.
From where do you get the impression she's even aware of Docker, let alone speaking about it?
These are the kind of things you say that people get annoyed with. Well first she's written a decent part of Docker so there is that. Second, she's speaking to the myriad of people who have heard of Docker and think it's something that it isn't. She's pretty famous for understanding how all of this works together.
Of course her AUDIENCE has HEARD of Docker. But you can't actually say that she's talking about Docker when she never once even implies it, and specifically says something very different (that it is LXC.) You are adding your own interpretation to her words. Maybe she means Docker, if so, she's a terrible writer. You don't use the wrong term for something you use every day and just assume people think you meant the opposite. That's insane.
It's not ME doing something annoying here. You are showing me an article that clearly says one thing that isn't too bad. But are claiming it's actually referencing something very different, and meaning something it doesn't say. Instead of taking it at face value, you are twisting her words into a meaning that isn't there at all. And then saying I'm being annoying for not having added my own interpretation to the article that isn't there in any form.
Even if you are correct, how could I without the goal of making it be about Docker, possible think it was about something never mentioned and explicitly ruled out? LXC is Linux containers, Docker is not. It can't be me being annoying here. If I claimed the article did that, you'd jump all over me for making up its meaning.
-
@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:
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.
By that definition every process would be virtualized because every process would need a "shared kernel"
