Add arm32v7 variant of Stretch images

[richlander]

• We want to add ARM32v7 images to fix Provide an ARM version of the container dotnet-docker#223
• Based on guidance from Docker folks, we will integrate the new images in our existing dotnet and dotnet-nightly repos. See: Publishing ARM32v7 images/tags for an existing repo moby/moby#33759.
• We will make significant use of Docker multi-arch (MA) for dotnet images.
• At a later point, we can likely make use of multi-arch for Debian dependencies (when MA shows up for Debian base images).

This PR is not done -- left to do:

• Validate correctness of the Dockerfiles
• Update README to include arm32 appropriately.
• Generate appropriate MA tags/manifests.

[dnfclas]

@richlander,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

[MichaelSimons]

Would it make sense to put the existing Dockerfiles in an architecture directory so that the directory structure is consistent across platforms?

/2.0
/runtime
/stretch
/amd64
/arm32v7

[richlander]

Your formatting got messed up, but I'm pretty sure I know what you meant.

I spent some time looking at our README to see how the GitHub source links would show up per image. Upon further consideration, I like your suggestion better. My suggestion falls a little too much in the "clever" category by compressing the folder structure.

[richlander]

We could add an amd64 directory to the jessie directory for symmetry or leave as-is to keep things simple. Thoughts?

[richlander]

Just tested an ASP.NET Core Preview 2 app using these Docker images on raspbian. The app was dotnet new mvc.

[richlander]

What is left @MichaelSimons? I think we are getting close to landing this PR.

[MichaelSimons]

@richlander, my preference would be to add the amd64 dir for Jessie as well in order to have symmetry.

[MichaelSimons]

@richlander - Regarding your question about the remaining work.

• Machines to build arm images in official builds. I have a request out to DDIT on this.
• The image-builder tool used in official builds needs a minor tweak to support ARM builds. I have the changes locally.
• Once image-builder supports ARM, the new version needs to picked up and then the manifest.json needs to be updated so that official builds will build the MA tags for the ARM images.
• Unit Tests should be updated to cover the new runtime images.

[richlander]

@MichaelSimons I am getting back to this. We should re-up on where we are at. I was looking at the manifest.json. It would be good to get some guidance on how like you'd like to pivot architecture within the format. I can see a couple options.

I just did a git pull --rebase to make this branch current.

Any progress on the work items you mentioned above?

[MichaelSimons]

@richlander, I just made dotnet/docker-tools#28 to modify the image-builder tool to support ARM. In the process of testing my change, I updated the manifest locally. Once the PR is merged I will check-in my manifest changes. The blocking issue right now is to get machines to do official builds on. I will be pushing on this over the next few days to get us unblocked.

[MichaelSimons]

@richlander, @dagood I think this PR is ready for review. I plan on writing a CI test for the ARM images but see that as a separate PR.

[MichaelSimons]

If you want to try out the multi-arch arm32 tags, I used the build infrastructure changes within this PR to build and push the images to msimons/dotnet-nightly

[dagood]

Weird way to end a file, is this missing the cleanup?

[MichaelSimons]

Yes it is - looks like the && rm -rf /var/lib/apt/lists/* got chopped off.

[MichaelSimons]

Fixed

[richlander]

LGTM

[alexellis]

How close or possible is an SDK image for ARM 32-bit? I saw there is a Runtime - but the source needs to be built too.

[MichaelSimons]

@alexellis - The .NET Core SDK does not run on the Linux + ARM32 configuration. You will need to build your application on X64, copy the binaries to an ARM32 device and then build your Docker image. Alternatively you can make use of a multi-stage Dockerfile on Window 10 or macOS. The dotnet-docker-samples include a sample of this flow. If you have feedback on the sample please feel open an issue in the dotnet-docker-samples repo.

[alexellis]

Thanks for the clarification - perhaps you could update the documentation of the Docker Hub page? Otherwise I guess more people will end up here wondering where the SDK is. From a workflow/CI perspective this is disappointing. I work with the RPi platform + Docker a lot as a Docker Captain and .NET developer at work.

Is this a temporary stumbling block or a permanent design decision? What about 64-bit ARM? Packet.net for instance have enterprise-grade Cavium servers which are very generously spec'd.

[richlander]

I wrote up the situation here: dotnet/announcements#29.

So, no, not a permanent decision, but also not our highest priority to solve at the moment. The rational given (performance) wouldn't apply to ARM64, so I would expect a different choice there.

Our first focus is reducing the size of the SDK generally. Once we have that in-hand, then making a good experience on ARM32 should be easier.