What are the pracitcal (not technical) differences between the inside of a debian docker container and a debian VM?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
I know that docker containers do not run their own kernel but share one with the host unlike a VM which runs it's own kernel but what is the practical differences between a debian docker image and a vm with debian installed?
Is there anything that can be done inside one but not the other or are they functionally the same so anything that runs on a real debian install will work as well inside of a docker debian container?
Also does the host OS change things? If I run a debian container on a CentOS system will it work different to a debian container on a debian system?
debian virtual-machine docker
add a comment |Â
up vote
2
down vote
favorite
I know that docker containers do not run their own kernel but share one with the host unlike a VM which runs it's own kernel but what is the practical differences between a debian docker image and a vm with debian installed?
Is there anything that can be done inside one but not the other or are they functionally the same so anything that runs on a real debian install will work as well inside of a docker debian container?
Also does the host OS change things? If I run a debian container on a CentOS system will it work different to a debian container on a debian system?
debian virtual-machine docker
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I know that docker containers do not run their own kernel but share one with the host unlike a VM which runs it's own kernel but what is the practical differences between a debian docker image and a vm with debian installed?
Is there anything that can be done inside one but not the other or are they functionally the same so anything that runs on a real debian install will work as well inside of a docker debian container?
Also does the host OS change things? If I run a debian container on a CentOS system will it work different to a debian container on a debian system?
debian virtual-machine docker
I know that docker containers do not run their own kernel but share one with the host unlike a VM which runs it's own kernel but what is the practical differences between a debian docker image and a vm with debian installed?
Is there anything that can be done inside one but not the other or are they functionally the same so anything that runs on a real debian install will work as well inside of a docker debian container?
Also does the host OS change things? If I run a debian container on a CentOS system will it work different to a debian container on a debian system?
debian virtual-machine docker
asked Apr 19 at 9:50
Qwertie
241210
241210
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
accepted
The main practicals differences between Docker container and VM:
Docker image is just base image from original system (
debootstap
helps to get this base image) and of cause it may (or not) contains kernel, initrd ... But the kernel, initrd ... are not make sense instead of researching, development, other packages dependencies. So, if they not necessary, then they can be safely removed.Docker containers starts in different namespace that hide real system processes, network connections ... from container impact. In simple, you can't to
kill
real system process from Docker container, but you can see Docker container process as ordinary process from real system and do anything with it. VM organised more difficult instead of namespace concept: all VMs starts as huge applications which controlled by VM software (VirtualBox, VMware ... ). VM software traps all system calls from this application and pass it to real hardware. Therefore they are slower than container concept.Docker containers provide support environment that needed to run some application (specific libraries versions, software components ...), but not kernel. Therefore, if your application uses new kernel features, they will not be worked.
Docker containers often doesn't contain full system image, because main target for Docker concept is share applications. The main target of VM is share Operation Systems.
There is no difference about real system that starts specific Docker image (except cases where your application depends on specific kernel).
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
The main practicals differences between Docker container and VM:
Docker image is just base image from original system (
debootstap
helps to get this base image) and of cause it may (or not) contains kernel, initrd ... But the kernel, initrd ... are not make sense instead of researching, development, other packages dependencies. So, if they not necessary, then they can be safely removed.Docker containers starts in different namespace that hide real system processes, network connections ... from container impact. In simple, you can't to
kill
real system process from Docker container, but you can see Docker container process as ordinary process from real system and do anything with it. VM organised more difficult instead of namespace concept: all VMs starts as huge applications which controlled by VM software (VirtualBox, VMware ... ). VM software traps all system calls from this application and pass it to real hardware. Therefore they are slower than container concept.Docker containers provide support environment that needed to run some application (specific libraries versions, software components ...), but not kernel. Therefore, if your application uses new kernel features, they will not be worked.
Docker containers often doesn't contain full system image, because main target for Docker concept is share applications. The main target of VM is share Operation Systems.
There is no difference about real system that starts specific Docker image (except cases where your application depends on specific kernel).
add a comment |Â
up vote
3
down vote
accepted
The main practicals differences between Docker container and VM:
Docker image is just base image from original system (
debootstap
helps to get this base image) and of cause it may (or not) contains kernel, initrd ... But the kernel, initrd ... are not make sense instead of researching, development, other packages dependencies. So, if they not necessary, then they can be safely removed.Docker containers starts in different namespace that hide real system processes, network connections ... from container impact. In simple, you can't to
kill
real system process from Docker container, but you can see Docker container process as ordinary process from real system and do anything with it. VM organised more difficult instead of namespace concept: all VMs starts as huge applications which controlled by VM software (VirtualBox, VMware ... ). VM software traps all system calls from this application and pass it to real hardware. Therefore they are slower than container concept.Docker containers provide support environment that needed to run some application (specific libraries versions, software components ...), but not kernel. Therefore, if your application uses new kernel features, they will not be worked.
Docker containers often doesn't contain full system image, because main target for Docker concept is share applications. The main target of VM is share Operation Systems.
There is no difference about real system that starts specific Docker image (except cases where your application depends on specific kernel).
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
The main practicals differences between Docker container and VM:
Docker image is just base image from original system (
debootstap
helps to get this base image) and of cause it may (or not) contains kernel, initrd ... But the kernel, initrd ... are not make sense instead of researching, development, other packages dependencies. So, if they not necessary, then they can be safely removed.Docker containers starts in different namespace that hide real system processes, network connections ... from container impact. In simple, you can't to
kill
real system process from Docker container, but you can see Docker container process as ordinary process from real system and do anything with it. VM organised more difficult instead of namespace concept: all VMs starts as huge applications which controlled by VM software (VirtualBox, VMware ... ). VM software traps all system calls from this application and pass it to real hardware. Therefore they are slower than container concept.Docker containers provide support environment that needed to run some application (specific libraries versions, software components ...), but not kernel. Therefore, if your application uses new kernel features, they will not be worked.
Docker containers often doesn't contain full system image, because main target for Docker concept is share applications. The main target of VM is share Operation Systems.
There is no difference about real system that starts specific Docker image (except cases where your application depends on specific kernel).
The main practicals differences between Docker container and VM:
Docker image is just base image from original system (
debootstap
helps to get this base image) and of cause it may (or not) contains kernel, initrd ... But the kernel, initrd ... are not make sense instead of researching, development, other packages dependencies. So, if they not necessary, then they can be safely removed.Docker containers starts in different namespace that hide real system processes, network connections ... from container impact. In simple, you can't to
kill
real system process from Docker container, but you can see Docker container process as ordinary process from real system and do anything with it. VM organised more difficult instead of namespace concept: all VMs starts as huge applications which controlled by VM software (VirtualBox, VMware ... ). VM software traps all system calls from this application and pass it to real hardware. Therefore they are slower than container concept.Docker containers provide support environment that needed to run some application (specific libraries versions, software components ...), but not kernel. Therefore, if your application uses new kernel features, they will not be worked.
Docker containers often doesn't contain full system image, because main target for Docker concept is share applications. The main target of VM is share Operation Systems.
There is no difference about real system that starts specific Docker image (except cases where your application depends on specific kernel).
edited Apr 19 at 20:53
answered Apr 19 at 10:57
Yurij Goncharuk
2,2582521
2,2582521
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f438683%2fwhat-are-the-pracitcal-not-technical-differences-between-the-inside-of-a-debia%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password