AZ CLI Dockerfile scaffolding assumes `amd64`?

[philliphoff]

I discovered (presumably) why my porter install was failing on my M1 Mac; it looks like the AZ CLI mixin Dockerfile scaffolding assumes an amd64 architecture. The bundle is successfully created, but then the az commands fail, being unable to find the amd64 Linux libraries it expects in the container.

az login --output table --output json --password ******* --service-principal --tenant ******* --username *******
/lib64/ld-linux-x86-64.so.2: No such file or directory
Error: error running command az login --output table --output json --password ******* --service-principal --tenant ******* --username *******: exit status 255

[philliphoff]

Alternatively, is there a way we can indicate what architecture Porter uses when building its images? (I ran into this while using porter inside a (emulated) amd64 image on my M1 Mac which redirects Docker commands back to the parent, which defaults to arm64 for multi-arch base images. Come to think of it, perhaps I could do this by specifically choosing an architecture in the Dockerfile.tmpl?)

[squillace]

Just to understand, the issue is that when running inside amd64, porter builds an amd64 image, yes?

[carolynvs]

Just to clarify and set expectations on what should work.

1. Porter only supports linux-amd64 for the invocation image
2. On the client we only support linux/windows/mac amd64

I will count this as a request for us to support different OS/ARCH combinations for the runtime and client that are M1 friendly. The former (1) is a large feature that will require a Porter Enhancement Proposal to figure out how it should work.

The later (2) is a small feature that could be done without a PEP. Off the top of my head we would want to compile with Go 1.16, and update the client matrix in all of our makefiles (for porter and the mixins) to include the new ARCH. Also the installers would need to be improved to select the appropriate arch to download for the client.

[philliphoff]

@squillace Just to understand, the issue is that when running inside amd64, porter builds an amd64 image, yes?

The issue is that porter build, being run inside an amd64 Docker container running in emulation on a M1 Mac (where the Docker CLI is redirected back to the parent host (i.e. the M1 Mac)), attempts to generate a arm64 image (as Docker tries to match the architecture of the host by default), but the AZ plugin ends up installing the amd64 version of the AZ CLI, which doesn't work when the installer actually runs.

[philliphoff]

@carolynvs I'm ok with Porter not generally supporting arm64 in the short term; I'm just logging issues as I find them. (It was a condition of management buying me a shiny new M1. :-)) It might be useful, however, to have a simple architecture check during porter build and warn/fail early if it's not (expected to be) compatible--at least for plugins which are architecture dependent like the AZ CLI. That could save others from having to dig into supposedly successful builds to understand why they don't actually install.

[carolynvs]

Thanks that's a great workaround!