I'm experimenting with the new docker setup on macOS Monteray. To be short I've moved docker daemon into VirtualBox, here is some setup details:
Vagrant + VirtualBox (with the latest Ubuntu LTS);
Dockerd runs on Ubuntu (inside VirtualBox);
I have docker client on the host (macOS)
Host and guest docker client versions are matching
I've built images from my java project within VB and everything works fine.
I did exactly the same, but from host os, and as a result, I have some serious performance degradation with newly built images.
Can anyone explain why this happens and how to overcome these issues?
Related
From what I understand, the container includes all dependencies to run, but all containers running on the same platform whether it's a VM, or bare-metal will share the underlying kernel.
I believe I read somewhere that in order to run linux containers on windows, the Docker client spins up a linux based VM, and runs the container in that.
But now I see that docker for windows runs linux containers natively (ie, without hyper-v).
My question is: How can an image that was built to run on linux run on a system that has a windows kernel?
This is the original source that my question arose from:
https://www.hanselman.com/blog/DockerAndLinuxContainersOnWindowsWithOrWithoutHyperVVirtualMachines.aspx
With the latest version of Windows 10 (or 10 Server) and the beta of
Docker for Windows, there's native Linux Container support on Windows.
That means there's no Virtual Machine or Hyper-V involved (unless you
want), so Linux Containers run on Windows itself using Windows 10's
built in container support.
I saw some similar questions, but they explained how a linux container runs on a windows platform by utilising a vm/hyper-v
How docker desktop runs linux containers on Windows machine
Does "Docker On Windows" launch a linux virtual machine?
Perhaps I didn't understand their answers, but from what I understood, it still seems like the linux container is sitting on-top of the windows kernel.
this is the magic of LCOW (https://github.com/linuxkit/lcow)
you are right to run a container the base KERNEL should be same , since container is just an abstraction , so to run a linux container on windows there are two options
either use moby linux on hyperv and run containers there
use lcow to run light weight linux vm for each container. (lcow)
https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers
with WSL in windows in future we might be able to get a third method don't know if already someone is working on it .
I just got started with docker. To my understanding, docker container runs a discrete process on the host machine and shares system resources of host machine too to that process, and as we know, codes building for Linux may not able to run on MacOS, and vice versa. My question is: can a docker image built on an OS platform can be deployed to another OS, like MacOS to Linux, or Ubuntu to CentOS?
If the question is NO, how come it only has one official mysql image on docker repositories, but not multiple like for Mac, for Ubuntu, for RHEL?
Docker on mac works by creating a linux virtual machine. So a docker image built on Mac is in fact built on a linux virtual machine and can be freely exchanged with most other docker systems - including most docker on windows.
There is a windows version of dockers that is not linux based. Those images are not interchangeable.
In fact, the docker built from any linux-based image can be run (w/o VM as an additional layer) on any linux distribution that has the same OS kernel.
It means docker built from e.g. SuSE image can be then run on Fedora/Ubuntu/Debian/etc... w/o any restrictions.
Short form - yes it can, but i think it will depend on the setup - notably user/group in - docker-compose file.
Recently i had some issues with work docker-compose files being setup without a user specified, these work ok when building on a mac as had an app user, but when run on my linux machine the user defaulted to root and thus the build was not successful. So it depends on the quality of the config.
Docker images are platform agnostic. The first thing a Dockerfile declares is what base image it pulls from, and that should determine the operating system under which the containers will run.
Using the MySQL 8 Dockerfile as an example:
https://github.com/docker-library/mysql/blob/223f0be1213bbd8647b841243a3114e8b34022f4/8.0/Dockerfile
FROM debian:stretch-slim
This means the image, and thus any containers started from it, will be based on Debian Linux...even if the host machine is MacOS.
I've read that:
Docker is a system for management and deployment of application containers, not operating system containers.
However, in several resources (e.g. around 1:20 into https://www.youtube.com/watch?v=pGYAg7TMmp0) it gives an example of "problems" you might encounter if you've developed a web application on a Windows PC or Mac, and are deploying it to a Linux server.
So, how does Docker help in this situation? If we take a web application I understand Docker could help you make a container with the source, and say a specific version of PHP. But could you specify a target OS for it to run on, if it's different from the server that Docker is running on?
The Docker FAQ (https://docs.docker.com/engine/faq/) says
You can run both Linux and Windows programs and excutables in Docker containers.
Does this mean you need Docker installed on a Linux and Windows machine separately to do this, or is it possible to specify any OS within your Docker image and have any machine run it?
Please can someone explain how - or if - Docker deals with specifying a particular OS for your application?
Docker started as a way to run containers on Linux hosts, and this remains the dominate target for docker containers. Developer environments include an embedded VM to run Linux under the covers on Mac and Windows. Originally this was VirtualBox, but newer releases use xhyve and hyperv. The host OS in all of these are Linux so you are not building your image on one OS and running it on another OS.
Since that start, Docker has expanded target OS's. This requires that you have a docker installation for that OS, and it requires that your image be designed to run on that architecture/OS. This started with other architectures of Linux like arm64, and now zLinux. The Microsoft partnership is a rather large rewrite, partially in Windows itself, but also in the Docker code, and especially in the images designed to run natively on Windows. To run these, you have to change the settings on Docker for Windows to run Windows containers instead of Linux containers, you cannot run them both concurrently on the same host. At present, running Windows binaries can only be done on a Windows host, Microsoft isn't shipping free VMs for Linux hosts. And as a new target platform, it still lags behind in features from the Linux hosts.
I tried to run Docker on a virtual machine.
Host : MacBook
VM : Parallels Windows 7
And error occurs:
Is it possible?
If the VM is a Linux, you can do this without any problem - on Linux, the Docker is essentially a well-worked chroot. Thus, the Linux docker is not virtualization.
In the case of Windows, it is not so easy. Windows Docker internally uses Hyper-V to emulate the containers. Which means that you can only run, if you can use nested virtualization:
On your host machine runs a Windows VM
Inside your Windows VM, runs a HyperV
HyperV is managed by the docker installed on your virtual Windows.
I tried qemu/kvm, virtualbox and vmware player. I configured them deeply and strongly, I've hacked them, I did every possible to do. Only the last worked (VMWare).
There are significant speed costs, but it may be useful for development on Linux, and then trial-test on Windows configurations.
You will need a lot of ram. At least 16G. 32G is better. A relative useful configuration would be:
32GB physical RAM for the physical host
12GB virtual RAM for the Windows VM running on it
8GB virtual RAM inside the Windows VM for the HyperV Linux host.
Sometimes it will be a little bit buggy, but only your HyperV will crash out, your virtual Win, or your host machine won't. It is okay for testing a docker container on a Windows machine, what you've developed on a Linux. Don't create mission critical servers on this way. :-)
You're using Docker Machine in your Windows VM, which is actually going to create a Linux VM inside the Windows VM on your Mac. You can do that, but you need to enable nested virtualization - which I'm not sure you can do in Parallels 7.
Instead you can run Docker Machine on the Mac directly and use Parallels to create the Linux VM - which means Docker is running in a Linux VM on your Mac, and you don't need nested virtualization.
Or preferably use Docker for Mac if your OS supports it, it's the latest product and has much better host integration than Docker Machine.
If you would be using Windows 10/11 Pro or Enterprise and Hyper-V, then all you must do is to enable nested virtualization. On your host, just run (with your guest off):
> Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
Now you can start your guest and run Docker Desktop as normal.
According to Docker's terms I don't think it's allowed. Section 4.1(b)(vii) says you shall not "use the Service on virtual machines." For clarification, "'Service' refers to the applications, software (including any Open Source Software), products and services provided by Docker, including any beta or trial versions."
If I am reading this right, that means it's illegal to run Docker on any VM.
Worked perfectly fine. Base OS win 10 pro with VirtualBox Version: 6.1 and vagrant with ubuntu 20.04. Using vagrant box follow docker instructions. With vagrant public network no need for port forwarding all apps were accessible.
Previous persons comment is very concerning considering on Windows and Mac you run docker inside a virtual machine lul. Windows uses WSL2 and Mac uses an arm linux machine to manage its docker.
Also, you can run docker in a vm, but it must be linuxOS vm as windows 7 does not support docker.
Have been trying to learn Docker and one thing that puzzles me is how a different flavour of Linux (to the host OS) actually runs in the Docker container.
If we assume my Docker host is running RedHat and I start a container from an Ubuntu image then are the following true?:
logically speaking, if the Ubuntu image footprint is around 550MB then will the Docker Daemon actually download (from an image registry) 550MB worth of Ubuntu image in order to create the Container?
is the instance of Ubuntu running in the container essentially no different than if I had downloaded and installed the same version manually?
I'm aware that the Docker container shares the same kernel used by the host OS and that one of the fundamental points of Docker was its efficiency gains of the container using the underlying OS. So Im a bit confused about what actually happens when you start a Container created from a different Linux version than the host.
I think this previous post may help you understand it a little more - Docker container isolation, does it care about underlying Linux OS?.
The crux of the matter is that if the Host OS is RedHat then it is the RedHat kernel which will be used by whatever build of Linux you run in your Docker container ie. Ubuntu in your example.
This comes down to understanding what the difference is between a Linux OS and a Linux Image. You will not be running a full Ubuntu OS inside the Docker Container but an image of Ubuntu.
For the purpose of your question think:-
OS = kernel + filesystem/libraries
Image = filesystem/libraries
The Ubuntu image running inside your Docker container is just the Ubuntu filesystem/libraries - it will not contain the Ubuntu kernel. This partly explains the efficiencies you get from a Docker container which is leveraging the Kernel (among other things) of the underlying Host.
The Ubuntu image running inside the Docker container runs in what is called the user space for that container. This image can make kernel system calls to the RedHat host OS kernel (as part of transferring control from user space to kernel space for some user operations). Since the core kernel is common technology, the system calls are expected to be compatible even when the call is made from an Ubuntu user space code to a Redhat kernel code. This compatibility make it possible to share the kernel across containers which may all have different base OS images.