Provide support for ARM 32bit #4444

Merged
merged 2 commits into from Mar 1, 2017

Conversation

Projects
None yet
2 participants
@jcberthon
Contributor

jcberthon commented Feb 8, 2017

I wanted to use docker-compose on my Raspberry Pi 2 (ARM 32bit). There is no built version for it, so I attempted to build one myself. The provided commit implement the necessary change to support this architecture. Fixes #3795

Based on the master branch and due to recent commits (which upgraded pip and a few other dependencies), the change is now very simple. Basically it revolves around changing the base image (debian is x86_64 only, so I've been using armhf/debian instead) and downloading the docker binary for armel architecture.

I've tried to adapt the script/test/default in order to validate the generated docker-compose binary, but it is an unfinished job as I'm stuck with the fact that there are no images available of dind for ARM (dockerswarm/dind only provide x86_64 images).

Anyway, I have 2 small projects which uses docker-compose.yml and both works. But I'm only using a subset of all of docker-compose features, and I do not have a Swarm configured to test those aspects as well. So my commit is only partially validated. But at least it works perfectly for what I'm using of it.

Note: Try to use the bump-1.10.0 branch (in order to get a "stable" version of docker-compose) is a bit more tricky and requires several additional changes w.r.t. this PR. Those are visible on this branch of my fork, this is just for your information.

jcberthon added some commits Feb 8, 2017

Add support to build docker-compose on ARM 32bit
Added a new Dockerfile (Dockerfile.armhf) specific for ARM 32 bit.
The Dockerfile was updated compare to default one:
  - Base image is armhf/debian instead of debian
  - Docker binary is downloaded with the correct arch (although it does not
    seems to be used)

Signed-off-by: Jean-Christophe Berthon <huygens@berthon.eu>
Add first attempt at supporting test suite on ARM
Modify `script/test/default` so it supports a first attempt at testing on ARM.
Call the script with: `$ DOCKERFILE=Dockerfile.armhf script/test/default` to
use the Dockerfile.armhf instead of the default Dockerfile for building the image.

However, running the script is not working fully. The problem is that
`dockerswarm/dind` does not provide an ARM image and therefore cannot be executed.
If that is fixed then we should be able to change the script in order to use the ARM
image instead of the default x86_64 image for running further tests.

Signed-off-by: Jean-Christophe Berthon <huygens@berthon.eu>
@jcberthon

This comment has been minimized.

Show comment
Hide comment
@jcberthon

jcberthon Feb 9, 2017

Contributor

I have found out that I would need to update the script/release/build-binaries in order to build for the right target platform. Actually, this script does not need to be changed, but the scripts it calls should be adapted.

I can try to work on that, but I'd like some feedback/guidance on how to do that so it fits best with the project "culture".

My idea would be to add an architecture detection function which could be called by scripts in order to pick the right Dockerfile. So basically, the script call the detection functions which returns "armhf" (for instance) and then check that a Dockerfile.armhf exists if not fails. For amd64 (the "default" architecture), we would search for Dockerfile simply (without an filename extension).

This would require of course that all Dockerfile have an equivalent for each CPU architecture.

What do you think?

Contributor

jcberthon commented Feb 9, 2017

I have found out that I would need to update the script/release/build-binaries in order to build for the right target platform. Actually, this script does not need to be changed, but the scripts it calls should be adapted.

I can try to work on that, but I'd like some feedback/guidance on how to do that so it fits best with the project "culture".

My idea would be to add an architecture detection function which could be called by scripts in order to pick the right Dockerfile. So basically, the script call the detection functions which returns "armhf" (for instance) and then check that a Dockerfile.armhf exists if not fails. For amd64 (the "default" architecture), we would search for Dockerfile simply (without an filename extension).

This would require of course that all Dockerfile have an equivalent for each CPU architecture.

What do you think?

@shin- shin- referenced this pull request Feb 21, 2017

Closed

Can we get armhf binaries? #4508

@shin-

This comment has been minimized.

Show comment
Hide comment
@shin-

shin- Feb 22, 2017

Member

Hey, thanks for taking the time to look into this, and sorry for the delayed response!

This PR as it is looks good to me. As far as ./script/release/build-binaries is concerned, I'm not sure it's necessary to update it since it's mostly an internal tool for me and other contributors to produce a new release, and I don't think it would be wise for us to make an official ARM release at that time.
Rather, it would be good to have a new arm script in ./script/build for people to build their own binary from source if they are on an architecture that supports it. Let me know what you think!

Member

shin- commented Feb 22, 2017

Hey, thanks for taking the time to look into this, and sorry for the delayed response!

This PR as it is looks good to me. As far as ./script/release/build-binaries is concerned, I'm not sure it's necessary to update it since it's mostly an internal tool for me and other contributors to produce a new release, and I don't think it would be wise for us to make an official ARM release at that time.
Rather, it would be good to have a new arm script in ./script/build for people to build their own binary from source if they are on an architecture that supports it. Let me know what you think!

@jcberthon

This comment has been minimized.

Show comment
Hide comment
@jcberthon

jcberthon Feb 25, 2017

Contributor

Hi @shin-

Great! That is fine with me. I can come up with such script. Do you prefer that I make a new PR then?

Given my limited free time, it might take a week or two before I find the time to write it.

Contributor

jcberthon commented Feb 25, 2017

Hi @shin-

Great! That is fine with me. I can come up with such script. Do you prefer that I make a new PR then?

Given my limited free time, it might take a week or two before I find the time to write it.

@shin-

This comment has been minimized.

Show comment
Hide comment
@shin-

shin- Mar 1, 2017

Member

Yes, a separate PR is fine whenever you have time to do so. Thank you!

Member

shin- commented Mar 1, 2017

Yes, a separate PR is fine whenever you have time to do so. Thank you!

@shin-

shin- approved these changes Mar 1, 2017

@shin- shin- added this to the 1.12.0 milestone Mar 1, 2017

@shin- shin- merged commit ac99bc5 into docker:master Mar 1, 2017

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
dco-signed All commits are signed

@shin- shin- removed this from the 1.12.0 milestone Mar 1, 2017

@jcberthon jcberthon deleted the jcberthon:compose-master-armv7 branch Mar 2, 2017

@muka muka referenced this pull request in hypriot/arm-compose Mar 23, 2017

Closed

Please update to 1.11.2 #15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment