Check my 2 min audio theory on Containers
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
100% agree. It makes sense only in a developers world no sysadmin usefulness here.
Yes, that's a good way, I think, to look at it. Docker seems to be designed to entice lazy, sloppy developers to not have to do their jobs well and just throw code "over the wall" to system admins that they don't want to talk to.
Docker didn't start off as an IT solution, but as a problem that IT has to contend with if we deal with bad developers. It was sold to developers as some silver bullet and tried to trick them into thinking that with Docker, they could skip operational knowledge. Something I see lots of dev shops attempting to do.
-
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
It does that, it does create more complexity at first.
Installing an app for us is much easier, like PHP-FPM + apache, it is only 10 commands or something, however if you did in docker/container in VPS you get the extra benefit of having clean environment in the host OS always + the container can be moved around easily to another VPS + it is much easier for non smart people to get your app and its updates + Docker provides free accout to publish one app.
Also the performance aspect is very good, but the storing this is bad abit.
The key idea here it is not currently hyper visor replacement, it is complementary tool that is good when you have service/server that does not need to store data.
While I find useful to have a package+config easily moveable I would syggest to manage staless services with ansible/salt and their playbooks if you want automation at sysadmin level.
Exactly. Rapid spin up, isolation, portability... I have all of that with existing tools. Docker just breaks that, rather than fixes it.
-
@flaxking said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@scottalanmiller said in Check my 2 min audio theory on Containers:
@matteo-nunziati said in Check my 2 min audio theory on Containers:
@emad-r actually The main benefit of containers is to disconnect sysadmin and devel work.
Not really. Containers are virtualization like any other, they've been around for decades and the idea that they were anything for developers is an extremely recent use case of only a very specific subset of containers. Most containers, and most of the history of containers, don't do anything like that, no more than any other kind of virtualization.
Yes but I think here we are talking docker. Docker is like python virtual envs for anything and not just for python. This is their main meaning to me.
Sure, if we are talking Docker and not talking Containerization, then Docker just seems like a sloppy, error prone way to do that.
My biggest issue with Docker is that it seems to make things worse rather than better. More complexity, more things to break, more dependencies. It introduces the very problems it claims to solve, problems that we weren't experiencing previously.
It does that, it does create more complexity at first.
Installing an app for us is much easier, like PHP-FPM + apache, it is only 10 commands or something, however if you did in docker/container in VPS you get the extra benefit of having clean environment in the host OS always + the container can be moved around easily to another VPS + it is much easier for non smart people to get your app and its updates + Docker provides free accout to publish one app.
Also the performance aspect is very good, but the storing this is bad abit.
The key idea here it is not currently hyper visor replacement, it is complementary tool that is good when you have service/server that does not need to store data.
While I find useful to have a package+config easily moveable I would syggest to manage staless services with ansible/salt and their playbooks if you want automation at sysadmin level.
The only pro of docker as a sysadmin tool is you have a good ecosystem with a lot of automation already done. With ansible/salt I don't know if you can pick from repos or you need to write everything from scratch.
The semi-equivalent of the docker pattern with ansible/salt is if you killed the server each time it you were going to do a configuration change or update, and redeployed it with your configuration. Then your CM has to bootstrap it before it is ready. Or you let your CM configure it, then image it and deploy the image... but you're just reinventing the wheel here, because that's what you do with Docker and you get smaller sized images.
So if the server doesn't make sense to use Docker for, maybe it's because it won't fit neatly into an immutable pattern?
Though your configuration as code being dockerfiles is not as nice.
Right. And you can do that. If that's something you want, Docker isn't necessary. Easy to do that without Docker. It's just that without Docker, no one wants that. It seems like Docker is designed to promote ideas that no one wants without the buzz of Docker itself. If you actually describe what Docker does, it doesn't sound very good.
Not that immutable deployments aren't beneficial, that can be great. But I don't need to be locked into that.
-
@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.
By definition, though, that makes it not a container in those cases, but a Type 2 hypervisor. And what a bad idea that is. Now we are just automated VirtualBox.
Containers require a shared kernel to be a container. It's the shared kernel that gives the behaviour and performance that makes it interesting. Without that, it's just misleading and crappy.
Is that really what Docker is doing, switching to a Type 2 model now instead of being a container?
-
@travisdh1 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.
To simplify what you are saying.
Write software that doesn't really on the kennel and Docker just worksI actually agree with you on this.But we can do that without Docker.
-
@travisdh1 said in Check my 2 min audio theory on Containers:
My actual experience is that developers don't know when their code actually uses things from the kennel, thus 90+% of all Docker images I try to run are just broken.
Same here. Docker is the most extreme dependency hell I've witnessed yet. Just like with Windows, DLLs can be managed well if both the devs and the admins are in sync and know what they are doing. But Docker exacerbates this by encouraging the "throw it over the wall" effect and tries to trick both sides into thinking that they don't need to do the diligence necessary in the past - while actually seemingly to require it even more.
-
@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?
-
@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:
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.
By definition, though, that makes it not a container in those cases, but a Type 2 hypervisor. And what a bad idea that is. Now we are just automated VirtualBox.
Containers require a shared kernel to be a container. It's the shared kernel that gives the behaviour and performance that makes it interesting. Without that, it's just misleading and crappy.
It is in no way a type 2 hypervisor at this point. OpenShift (Docker) running on physical systems that spin up VMs on hardware. No type 2 anywhere.
-
@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).
-
@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:
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.
By definition, though, that makes it not a container in those cases, but a Type 2 hypervisor. And what a bad idea that is. Now we are just automated VirtualBox.
Containers require a shared kernel to be a container. It's the shared kernel that gives the behaviour and performance that makes it interesting. Without that, it's just misleading and crappy.
It is in no way a type 2 hypervisor at this point. OpenShift (Docker) running on physical systems that spin up VMs on hardware. No type 2 anywhere.
A full VM would require a Type 2. The description you gave was of a Type 2, not a Container. If it loads a full VM (including a kernel), it's a Type 2.
It has to be one or the other.
If it doesn't, then it's the shared kernel I mentioned.
-
@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.
-
@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:
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.
By definition, though, that makes it not a container in those cases, but a Type 2 hypervisor. And what a bad idea that is. Now we are just automated VirtualBox.
Containers require a shared kernel to be a container. It's the shared kernel that gives the behaviour and performance that makes it interesting. Without that, it's just misleading and crappy.
It is in no way a type 2 hypervisor at this point. OpenShift (Docker) running on physical systems that spin up VMs on hardware. No type 2 anywhere.
A full VM would require a Type 2. The description you gave was of a Type 2, not a Container. If it loads a full VM (including a kernel), it's a Type 2.
It has to be one or the other.
That sentence makes no sense. It's a VM running on bare metal. There is no type 2 anywhere.
And even if it was, that really has no bearing on anything anyway.
-
If DevOps is not Job Title, but how the hell I am DevOps Engineer
(Recent change thus the whole dive into all of this.) -
@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:
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.
By definition, though, that makes it not a container in those cases, but a Type 2 hypervisor. And what a bad idea that is. Now we are just automated VirtualBox.
Containers require a shared kernel to be a container. It's the shared kernel that gives the behaviour and performance that makes it interesting. Without that, it's just misleading and crappy.
It is in no way a type 2 hypervisor at this point. OpenShift (Docker) running on physical systems that spin up VMs on hardware. No type 2 anywhere.
A full VM would require a Type 2. The description you gave was of a Type 2, not a Container. If it loads a full VM (including a kernel), it's a Type 2.
It has to be one or the other.
That sentence makes no sense. It's a VM running on bare metal. There is no type 2 anywhere.
VM on bare metal isnt' a thing. You described Docker as a Type 2 hypervisor. By your description, Docker is the type 2 hypervisor, rather than being containerization.
There's no other option. If it can run a full VM, only a Type 2 can do that on top of an OS. Containers can't do that, by definition.
-
@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.
There were two different ideas in that paragraph. One was you can run Go containers with no shared kernel. The other was an example of how Red Hat is using Docker without a shared kernel.
-
@emad-r said in Check my 2 min audio theory on Containers:
If DevOps is not Job Title, but how the hell I am DevOps Engineer
(Recent change thus the whole dive into all of this.)DevOps is a department, DevOps Admin is a job title. Like System Administration isn't a title, but System Administrator is.
DevOps is a subset of System Administration.
-
@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.) -
@stacksofplates said in Check my 2 min audio theory on Containers:
There were two different ideas in that paragraph. One was you can run Go containers with no shared kernel. The other was an example of how Red Hat is using Docker without a shared kernel.
I get that. Go doesn't required a shared kernel, or anything. So Go isn't relevant to the other discussion. Go being able to be used anywhere doesn't tell us anything about the thing that it is running on.
If RH is able to run Docker without a shared kernel, that by definition means Docker is a Type 2 hypervisor if that is actually true.
-
@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.
-
Just to be clear, that you claim Docker is a type 2 hypervisor does not prevent it from being a container technology at other times. Only that it is like ProxMox and can do two unrelated things.
ProxMox isn't virtualization itself, of course, but merges KVM and OpenVZ. Docker must be doing something similar, but with the Type 2 and the container stuff both built in under a single brand name.
