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:
@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"
-
@flaxking said in Check my 2 min audio theory on Containers:
DevOps is not a department, and companies that uses titles like DevOps Engineer probably aren't really doing DevOps, just using some DevOps tools.
As someone who was in a DevOps department, separate from the non-DevOps SA department, it really is. Uncommon, but real.
-
@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:
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.
No I'm looking at historically what she has said. Of course you can look at one sentence out of a thousand and construe it to mean someone doesn't know what theyre talking about.
-
@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:
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"
You are being intentionally obtuse. You pointed out how absurd it is to mention shared kernel for things that are obvious, so we don't. All mentioned of shared kernel, except when explaining kernel sharing explicitly, is a reference to container virtualization. Any reference to not being shared kernel, is a reference to Type 1 or Type 2 para/full virtualization.
-
I've officially run out of time to argue with you today. Maybe another day we can continue another pointless back and forth.
-
@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:
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.
No I'm looking at historically what she has said. Of course you can look at one sentence out of a thousand and construe it to mean someone doesn't know what theyre talking about.
I looked through the ENTIRE article. That she has written about other things in the past would never be a reason to assume she got it all wrong here. I've written about Linux a lot, but if I write about Windows, it would be insane and totally wrong to claim that based on my having written about Linux previously that all of the times that I mention Windows that "obviously you are supposed to know that I actually meant Linux." That's nuts.
I assume she's not just some Docker drone but a human capable of and expected to discuss more than one specific topic. No amount of other writings on Docker should rule out her being allowed to discuss LXC.
That she is aware of Docker, all the more that we'd note expect her to confuse Docker with other things that aren't Docker. The more she knows Docker, the more likely this article isn't about Docker but can be taken at face value of being about Linux containers.
-
@stacksofplates said in Check my 2 min audio theory on Containers:
I've officially run out of time to argue with you today. Maybe another day we can continue another pointless back and forth.
Honestly, I feel like you are arguing just to argue. You are using all kinds of weird terms and saying you didn't say them or describing them clearly.
You say Docker uses a shared kernel obviously, but over and over again say it doesn't. But you don't see that conflicting?
