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...
Related
I am trying to leverage the address sanitizer from GCC 8.3.0 in a 32 bit debian buster docker container, but keep hitting my head against a wall when launching the executable:
==17738==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==17738==ASan shadow was supposed to be located in the [0x1ffff000-0x3fffffff] range.
==17738==Process memory map follows:
0x29414000-0x295f3000
...
0x5762d000-0x57a9c000
0xfff26000-0xfff47000 [stack]
==17738==End of process memory map.
As you might be able to see, there does not seem to be an overlap. And the kernel version 5.11.0-41-generic does not seem to have the issues other people reported with similar symptoms.
The same binary works flawlessly on the 64 bit host Ubuntu system, but the 32 bit debian buster docker container (AND a 64 bit debian docker image) always gives the above error.
The sanitizer is compiled with -fsanitize=address and linked with -static-libasan in the debian docker container.
Other people have indicated launching docker with --privileged --cap-add=SYS_PTRACE should help, but it does not seem to alleviate the problem.
Ive taken an app and built a docker image for windows server 2016 using microsoft/aspnetcore:2.0 base image.
My question is...what machines/OS's will I be able to run the container on?
I know it cant run on Linux.....but could it run on (e.g.) ANY version of windows server 2016? How about windows server 2019?
The architecture is AMD64....does that mean the container will only run on machines with that exact architecture?
Im trying to figure out why containers are considered beneficial
I don't have any experience with Docker Windows containers, but I have a ton of experience with Docker containers in general, and the concepts between Windows and Linux containers should be mostly the same.
When you run your built app, no matter if you run it on Windows Server 2016, Windows Server 2019, or even Windows 10 Pro, the app should function exactly the same. Under the covers, Docker provides an isolated application environment. From your applications perspective, it only knows/experiences/sees itself and the Windows Kernel that it's running on. If you had, say, an IIS instance also running on that server, your app would have no idea. The point here is that Docker provides a means to:
Run multiple versions of an app on the same machine, in complete isolation.
Have a more clean running environment for every app.
Be much more resource efficient than running discrete VMs
Another huge benefit of Docker is that it provides a means to ephemeral environments. Which means you should expect to have the exact same behavior from an app running on machine #1 as you do on machine #2. It eliminates the "works on my machine" mentality, especially when some other 3rd party dependency is not installed/forgotten, because these will be bundled into the container as part of the build.
Lastly, about architecture. The app you built is designed to run against the architecture of the Windows Kernel it was built with. In your case AMD64, from my understanding, this implies the x86_64 architecture. This should mean that your container will run on any 64-bit x86 machine (AMD or Intel). Your container will not run on any other architecture: x86 (32 bit), 386, 486, ARM, ARM 64, etc. I think in the case of Windows this isn't as important of an issue, because 90% of the time you're running on x86_64. But with Linux you end up with everything from SPARC to ARM, and so that architecture distinction is important.
I too had a lot of the same questions when I started using docker. While the product "Docker" has been hit-or-miss on occasion, the concept "containers" and the benefits they provide when used correctly are very powerful and I use the for almost every project I work on.
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.
I'm trying to create a 32-bit docker image with Ubuntu 14.04 and, any time that I run uname, I see that it is x86_64 instead of i386. Could anyone tell me why this is happening?
docker run talex5/lucid32 uname -m
The weird thing is when I look up the architecture type a different way, it says 32-bit:
docker run i386/ubuntu:14.04 file /sbin/init
/sbin/init: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=c394677bccc720a3bb4f4c42a48e008ff33e39b1, stripped`
This happens consistently whenever I download different docker images that say they are 32-bit and even when I create my own docker image using debootstrap.
Thanks!
uname reports the version and OS details of the kernel, but Docker containers always use the host system's kernel, and if it's a 64-bit kernel it will report x86_64.
You should see the same results running this with a mixed 32-/64-bit OS install (in Ubuntu land installing packages like libc6:i686); with a 32-bit filesystem tree in a chroot; and in a Docker container; which are all the same case of running 32-bit binaries on a system with a 64-bit kernel.
This is possible these days, with just a simple script. You could use https://github.com/docker-32bit/ubuntu.
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.