New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker doesn't, but should, support 32-bit hosts #136
Comments
Here's what I suggest: Step 1: docker only supports amd64. It will refuse to start a container on any other architecture.This should be made clear to the user. Step 2: docker will eventually support more architectures, including i386. This will include arch-specific images, facilities to look them up etc. So, I will accept anything that makes it easier to support multiple architectures in the future. But for now we're sticking to amd64. |
Enforced in f783759 |
So getting a i686 build would be something you would merge? |
Shouldn't there be an open issue that we can subscribe to and get notified when it gets implemented? |
How should we interpret the closure of this issue? Is the real answer "wontfix", or are there seriously plans to support hosting on 32 bit (and other architectures) someday? If the former, then closing this issue makes sense. If the latter, then leaving this issue open makes sense. Saying that docker will eventually support 32 bit hosts, then closing this issue without first doing so, sends mixed signals at best. The reference to bug #611 doesn't make sense here either -- #611 is about 32 bit containers, not hosts; not a dup. For the record: As of today, there still appears to be no supported way to install or build docker on a 32 bit Ubuntu Raring machine. (1) The instructions at http://docs.docker.io/en/latest/installation/ubuntulinux/ cover 64 bit only, and fail on a 32 bit machine with "E: Unable to locate package lxc-docker". (2) Following http://docs.docker.io/en/latest/contributing/devenvironment/ to build from source fails, of course, because it depends on an existing installation of docker, which isn't readily available due to (1). Wash, rinse, repeat. |
There is a solution I need to try here: |
What's the 'official' word on this? Is official support for running Docker containers on 32-bit systems coming? |
I am also curious about the official word on 32-bit Linux support. Thanks. |
me, too |
Supporting this in docker is easy but that hard work is around registry support to make sure that when you run |
Here's another vote for 32-bit hosts. I have no desire to run a 64-bit operating system, since it chews up much more memory than a 32-bit one (I'm guessing it has to do with pointers taking up 8 bytes instead of 4). I am also interested in why @shykes refuses to run containers on anything other than amd64. What are the technical limitations or dangers of 32bit for containers? (it's not a rhetorical question, I have no knowledge about the subject and would like to know why) |
I think @crosbymichael's post explains the main reasoning. The actual running of the container is not hard, getting the images to be architecture aware is the plumbing that is not present today. |
Good point, @vmarmol. Didn't notice that comment, was falling asleep at the keyboard :) Could someone elaborate on that issue, please?
What's that "registry support"? |
+1 to 32 bit support. We're distributing an open source application for humanitarian use in lightweight netbooks. We use LXC because there's no way of running virtual machines in the netbook, and that's why Docker is very interesting to us. If only docker can start supporting 32 bit, we can get rid of all the current manual rpm/deb/lxc packages/snapshots, and simply say docker rules everything! |
+1 for 32bits support |
+1 to 32 bit support. Trying to setup sample application with database through docker, as application under test to demonstrate open source testing tools. But we are blocked due to this issue, since most of users will have low end machines only. |
I know we haven't focused at all on this (and are maybe trying not to), but docker should support 32-bit hosts.
Some extra considerations will have to be made, like the ability to tag (or at least name) images with their supported architectures.
Related to at least #116 and #117 . I'll self-assign since I'm looking at these issues anyhow.
The text was updated successfully, but these errors were encountered: