Publishing ARM32v7 images/tags for an existing repo

Me and others are owners of .NET Core and the related microsoft/dotnet repo. We are in the process of publishing ARM32v7 Docker images. It is unclear how to us how best to do this. We have not been able to find guidance on this, so are relying on a combination of our best design sense and reverse engineering the choices of the official base images.

Note: We are using Debian base images published @ https://hub.docker.com/r/arm32v7/debian/.

We immediately noticed that the official images are published in one location for X64 and another for ARM32v7. I think of this as "segmenting repos by architecture". I am wondering if this is a long-term decision or if it is a stop-gap until better multi-arch support lands. As a side note, the asymmetry between the X64 images from both a FROM and URL standpoint is unfortunate. ARM32 feels tacked onto the side. To a large degree, that's my issue and what I'm wondering how to navigate for the microsoft/dotnet repo.

Solution 1 -- mimic official repos

The easiest solution is to create a microsoft/dotnet-arm32v7 repo. This would mimic the approach used by the official images, IMO. The advantage is that the split between X64 and ARM32 is obvious and the existing microsoft/dotnet README isn't encumbered with ARM32 info (we assume that X64 audience dwarfs the ARM32 one). The disadvantage is that the ARM32 repo isn't super discoverable and it will start us down a combinatorics exercise on repos (we'll have two "-nightly" repos, for example).

Solution 2 -- use multi-arch

The more interesting solution to discuss is segmenting/exposing architecture within the microsoft/dotnet repository using multi-arch tags. Today, we use multi-arch solely for OS but we'd extend it for architecture as well.

Here is an example of our existing MA use (again, only for OS targeting for X64) from our README (simplified a bit):

• 2-runtime
  • 2-runtime-stretch
  • 2-runtime-nanoserver

The interesting thing is that if we added an ARM32 variant for Stretch that we wouldn't need to add any more text, right? Both 2-runtime and 2-runtime-stretch would be multi-arch tags. That's good in the sense that our README wouldn't grow, but it would be non-obvious that we supported both x64 and ARM32 for the Stretch images. In addition, users would need to specify (somehow) that they want to build for x64 vs. ARM32 for 2-runtime when the default isn't what they want. Users should be able to FROM 2-runtime on Windows x64 machine (with Docker for Windows) but generate an ARM32 image for Stretch. I'm assuming that x64 Linux would be the default when in "Linux mode" on Windows. The same problem exists on other OSes, too.

I guess we could inflate our README to read like this:

• 2-runtime
  • 2-runtime-stretch
    • 2-runtime-stretch-x64
    • 2-runtime-stretch-arm32v7
  • 2-runtime-nanoserver

That's starting to look quite bad and I'm wondering if mere mortals will be able to reason about the Docker tag soup. Recall that we are bringing new users to Docker who know nothing about Linux and little about architectures. They are going to adopt Docker first through Visual Studio and need to reason about the Docker artifacts that we generate for them. We need as much simplicity as possible. I'm sure that Docker / Linux experts would also appreciate simplicity, too!

Summing it Up

So, to sum it up in a set of goals:

• We want to publish ARM32 images for microsoft/dotnet.
• We want an intuitive user experience that enables users to use their Dockerfiles (for dotnet) on multiple OSes and architectures with minimal changes (ideally, no changes) to their Dockerfile and commandline parameters. Ideally, only the commandline needs to capture extra intent in special cases.
• We want a way to communicate to users which OSes and architectures we support for a given MA tag.

We would like guidance on how to best achieve these goals. TIA from your friends on the .NET Core Team!

/cc @MichaelSimons @kendrahavens @friism @tianon @glennc