I'm trying to run a docker image on MacBook M1, but this image doesn't support arm architecture (vosk-server), so docker needed to emulate through qemu.
But my issue is that the performance is bad, but I think it is due to the use of only 1 cpu core. I saw this in the activity monitor, that qemu was only using 1 cpu core.
My question is if it is possible to increase the number of cpu core qemu can use through docker.
Thank you
Related
I'd like to know if I'll be able to run Docker on ARM (Windows) machine and still have the same versatility?
I didn't see a lot of readings about this, as ARM PCs are quite new.
Let's say that I make an image for an OS that uses a kernel of version 10. What behavior does Docker exhibit if I run a container for that image on a host OS running a kernel of version 9? What about version 11?
Does the backward compatibility of the versions matter? I'm asking out of curiosity because the documentation only talks about "minimum Linux kernel version", etc. This sounds like it doesn't matter what kernel version the host is running beyond that minimum. Is this true? Are there caveats?
Let's say that I make an image for an OS that uses a kernel of version 10.
I think this is a bit of a misconception, unless you are talking about specific software that relies on newer kernel features inside your Docker image, which should be pretty rare. Generally speaking a Docker image is just a custom file/directory structure, assembled in layers via FROM and RUN instructions in one or more Dockerfiles, with a bit of meta data like what ports to open or which file to execute on container start. That's really all there is to it. The basic principle of Docker is very much like a classic chroot jail, only a bit more modern and with some candy on top.
What behavior does Docker exhibit if I run a container for that image on a host OS running a kernel of version 9? What about version 11?
If the kernel can run the Docker daemon it should be able to run any image.
Are there caveats?
As noted above, Docker images that include software which relies on bleeding edge kernel features will not work on kernels that do not have those features, which should be no surprise. Docker will not stop you from running such an image on an older kernel as it simply does not care whats inside an image, nor does it know what kernel was used to create the image.
The only other thing I can think of is compiling software manually with aggressive optimizations for a specific cpu like Intel or Amd. Such images will fail on hosts with a different cpu.
Docker's behaviour is no different: it doesn't concern itself (directly) with the behaviour of the containerized process. What Docker does do is set up various parameters (root filesystem, other mounts, network interfaces and configuration, separate namespaces or restrictions on what PIDs can be seen, etc.) for the process that let you consider it a "container," and then it just runs the initial process in that environment.
The specific software inside the container may or may not work with your host operating system's kernel. Using a kernel older than the software was built for is not infrequently problematic; more often it's safe to run older software on a newer kernel.
More often, but not always. On a host with kernel 4.19 (e.g. Ubuntu 18.04) try docker run centos:6 bash. You'll find it segfaults (exit code 139) because that old build of bash does something that greatly displeases the newer kernel. (On a 4.9 or lower kernel, docker run centos:6 bash will work fine.) However, docker run centos:6 ls will not die in the same way because that program is not dependent on particular kernel facilities that have changed (at least, not when run with no arguments).
This sounds like it doesn't matter what kernel version the host is running beyond that minimum. Is this true?
As long as your kernel meets Docker's minimum requirements (which mostly involve having the necessary APIs to support the isolated execution environment that Docker sets up for each container), Docker doesn't really care what kernel you're running.
In many way, this isn't entirely a Docker question: for the most part, user-space tools aren't tied particularly tightly to specific kernel versions. This isn't unilaterally true; there are some tools that by design interact with a very specific kernel version, or that can take advantage of APIs in recent kernel versions for improved performance, but for the most part your web server or database just doesn't care.
Are there caveats?
The kernel version you're running may dictate things like which storage drivers are available to Docker, but this doesn't really have any impact on your containers.
Older kernel versions may have security vulnerabilities that are fixed in more recent versions, and newer versions may have fixes that offer improved performance.
I know that the official support is only for 64-bit but I can see from a few people have tried to custom build the docker binaries for 32-bit and succeeded (32-bit version of docker maybe a little unstable but it is fine for my use-case).
However, most of those blogs are old and do not work. Is there anyone who has done this recently?
I'm trying to build docker on 2 machines (i686) running with debian - wheezy and stretch (with kernel > 3.10; the minimum required). Has at-least 2GB of RAM and sufficient disk space.
There's 32bit docker on 32bit ARM machines, i think i've seen it done on RPis and ODROIDs at least.
On 32bit x86... i doubt you'll find much. It's not that it's impossible (if there's 32bit ARM docker, there can be 32bit x86 docker), but nobody cares enough. You can run 32bit docker images (in fact i've done it recently) on a 64bit system, but docker itself...
I've been doing a lot of Raspberry Pi work, but that means I have to carry about my Pi (or SSH home), and well, the Pi isn't the fastest in the world. I've been using Docker for running things like Postgres, and was thinking it would be awesome to just download a Docker image of the ARM build of Debian Jessie, and have everything function as if it was actually running in a real rPi. Even better if I could just somehow then quickly mirror this to an SD card and throw it into a real rPi.
Has anyone explored this? Everything I'm finding is about running Docker on the rPi, not running Docker to emulate an rPi.
Based on the answers and comments to similar questions - such as this one on the Raspberry Pi Stack Exchange site I think that the short answer to "no" (or at least not without a lot of effort)
Your problem is that as mentioned in the comments Docker doesn't do full-on virtualisation (that's kind of the point of it) so you can't get an ARM Raspbian Docker image and run it on an x86 Virtualbox host - which is what it sounds like you'd like to do.
The Docker image needs to be built for the same architecture as the host system. you get the same problem if you try to run x86 Docker images on the Raspberry Pi if it is acting as a Docker host.
By way of a solution - what I'd suggest is running a Debian VM on your Mac. Raspbian is close enough to Debian that you'll have a fairly "Pi-like" environment to develop in and can copy your code to an SD card when you're done.
If you want an easy way to manage the configuration so that the number of cores, RAM, disk space etc matches your Pi, then Vagrant may be a good solution.
I have machine with several GPUs. My idea is to attach them to different docker instances in order to use that instances in CUDA (or OpenCL) calculations.
My goal is to setup docker image with quite old Ubuntu and quite old AMD video drivers (13.04). Reason is simple: upgrade to newer version of driver will broke my OpenCL program (due to buggy AMD linux drivers).
So question is following. Is it possible to run docker image with old Ubuntu, old kernel (3.14 for example) and old AMD (fglrx) driver on fresh Arch Linux setup with fresh kernel 4.2 and newer AMD (fglrx) drivers in repository?
P.S. I tried this answer (with Nvidia cards) and unfortunately deviceQuery inside docker image doesn't see any CUDA devices (as It happened with some commentors of original answer)...
P.P.S. My setup:
CPU: Intel Xeon E5-2670
GPUs:
1 x Radeon HD 7970
$ lspci -nn | grep Rad
83:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] [1002:6798]
83:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series] [1002:aaa0]
2 x GeForce GTX Titan Black
With docker you rely on virtualization on Operating System level. That means you use the same kernel in all containers. If you wish to run different kernels for each container, you'll probably have to use system-level virtualization, e.g., KVM, VirtualBox. If your setup supports Intel's VT-d, you can pass the GPU as a PCIe device to the container(better terminology in this case is, Virtual Machine).