Skip to content
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

feat/add arm64 support #613

Merged
merged 4 commits into from
Mar 28, 2023
Merged

Conversation

Volatus
Copy link
Contributor

@Volatus Volatus commented Mar 24, 2023

This PR adds the Dockerfile to make linux/arm64 and darwin/arm64 builds easier/possible.

closes #603
closes #505

@nyurik
Copy link
Member

nyurik commented Mar 24, 2023

Thanks! What's the debian-based final container size compared to alpine?

@Volatus
Copy link
Contributor Author

Volatus commented Mar 24, 2023

Thanks! What's the debian-based container size compared to alpine?

On darwin/arm64 (which realistically is linux/arm64 as Docker runs on a VM on Macs) with the latest version of Docker Desktop, the final image size seems to be 98MB.

@nyurik
Copy link
Member

nyurik commented Mar 24, 2023

We need to check the size diff for i64

@Volatus
Copy link
Contributor Author

Volatus commented Mar 24, 2023

We need to check the size diff for i64

Not sure I quite got this. Are we talking about potential size differences of signed integers or the image size for x86 with the Debian based image?

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

lol, no, i meant x86-ia64 (amd64)

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

also, you may want to rebase on #614

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

Ok, i just checked. When running just docker-build with the old dockerfile (using the #614 for speed up):

> just docker-build
...
> docker images
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          8b3e3e02fc34   22 minutes ago   31.1MB

with the proposed docker image (same cargo patch), the result is

REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          aadb127bb44d   31 seconds ago   104MB

I don't think growing the image size by over 3x just to make mac docker images is a good proposition because the vast majority of these images are used on linux servers (this might change in the future).

@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

Ok, i just checked. When running just docker-build with the old dockerfile (using the #614 for speed up):

> just docker-build
...
> docker images
REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          8b3e3e02fc34   22 minutes ago   31.1MB

with the proposed docker image (same cargo patch), the result is

REPOSITORY                                TAG             IMAGE ID       CREATED          SIZE
ghcr.io/maplibre/martin                   latest          aadb127bb44d   31 seconds ago   104MB

I don't think growing the image size by over 3x just to make mac docker images is a good proposition because the vast majority of these images are used on linux servers (this might change in the future).

The size may be 3x difference, but numerically, is 100MB ever a dealbreaker over 30MB for users where you can assume their average image size is > 300MB? (We use martin and our images are way above that usually)

The other thing is, this PR is not about fixing Mac images (in fact there are no such thing as Mac images, they're all linux, just different CPU arch depending on the machine), it's about fixing arm64 as a whole.

If you try to build the old image on linux/arm64, it'll fail due to an issue with musl and glibc differences on arm64 intrinsics. I can attempt to bring the image size down a bit, but I doubt it's worth the effort. I'd say that solid images on Dockerhub are usually below the 200MB mark and this change still keeps us there.

@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

also, you may want to rebase on #614

Can do.

@Volatus Volatus force-pushed the feat/add-arm64-support branch 2 times, most recently from 7af0101 to 64146d2 Compare March 25, 2023 10:48
@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

@nyurik Just rebased on top of 8ef8953

@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

@nyurik I was able to cut 10MB by stripping the symbols release binary.

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

Sorry, I meant arm64 for linux. I don't think shaving the 3MB and loosing all symbols is a good path. I would much rather have proper stack traces with symbols if something happens, rather than having hard-to-parse stacktraces -- those 3MB actually add value. What I am concerned with is that we want to add 70MB to an image without any benefit to the existing user base. 70MB might not sound like a lot, but this is a waste that I would rather avoid unless absolutely must have.

I propose we figure out how to build with musl/libc on arm64 - it shouldn't be THAT difficult I would think. If we can't, lets just create a new arm64.Dockerfile that we will use for arm64 builds.

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

Regardless - I don't think that's the issue - there seem to be some issue with dockerx and manifests - and that's the same thing I saw before with @stepankuzmin 's PR

@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

Regardless - I don't think that's the issue - there seem to be some issue with dockerx and manifests - and that's the same thing I saw before with @stepankuzmin 's PR

That is a known issue - docker/buildx#59

It can be remedied by building the ARM image as a separate step. I could work on that, as long as there is some guarantee that the working solution would be merged. Wouldn't want to work on something that maintainers don't want to go forward with.

@nyurik
Copy link
Member

nyurik commented Mar 25, 2023

That I'm sure we will do, just possibly as arm64 specific docker file so to keep the image size low for others

@Volatus
Copy link
Contributor Author

Volatus commented Mar 25, 2023

That I'm sure we will do, just possibly as arm64 specific docker file so to keep the image size low for others

Got it, then I think I should go forward with arm64 specific Dockerfile and leave the current one as it is then.

@Volatus Volatus force-pushed the feat/add-arm64-support branch 2 times, most recently from e4b7251 to 481eee6 Compare March 26, 2023 13:28
Signed-off-by: Ismayil Mirzali <ismayilmirzeli@gmail.com>
@Volatus
Copy link
Contributor Author

Volatus commented Mar 26, 2023

@nyurik Seems to build fine, although slow, which is expected with emulation. For the time being, we can't run the DB tests on the ARM image yet because of unavailability of an ARM image for PostGIS. I'm looking into submitting a patch for that down the line. I think for the time being, we can assume that the DB tests that passed on x86 would also pass on arm64.

@nyurik nyurik enabled auto-merge (squash) March 28, 2023 06:04
Copy link
Member

@nyurik nyurik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great, thanks!

@nyurik nyurik merged commit c358ec5 into maplibre:main Mar 28, 2023
@Volatus Volatus deleted the feat/add-arm64-support branch March 28, 2023 08:16
@nyurik
Copy link
Member

nyurik commented Mar 28, 2023

@Volatus or @stepankuzmin could you verify that the arm64 image is published properly under the main tag?

@Volatus
Copy link
Contributor Author

Volatus commented Mar 28, 2023

@Volatus or @stepankuzmin could you verify that the arm64 image is published properly under the main tag?

@nyurik
The image seems to be there but the manifest list entry is not correct.

@nyurik
Copy link
Member

nyurik commented Mar 28, 2023

that's not good :(

can it be that the publish step needs to be modified as well somehow, to preserve the platform?

@stepankuzmin
Copy link
Collaborator

Yep, should fix the manifest

Unable to find image 'ghcr.io/maplibre/martin:latest' locally
latest: Pulling from maplibre/martin
docker: no matching manifest for linux/arm64/v8 in the manifest list entries.

@Volatus
Copy link
Contributor Author

Volatus commented Mar 28, 2023

that's not good :(

can it be that the publish step needs to be modified as well somehow, to preserve the platform?

Maybe try adding the platforms option to the push step as well?

@nyurik
Copy link
Member

nyurik commented Mar 28, 2023

Hmm, probably. I pushed it to main (no point in going via PRs because PRs don't trigger that step anyway)... will see.

@nyurik
Copy link
Member

nyurik commented Mar 28, 2023

Hmm, it seems the push step for some reason re-builds the docker image -- https://github.com/maplibre/martin/actions/runs/4545573925/jobs/8013094651

This is not good for several reasons - most importantly because it seems it uses a different dockerfile in that step... Any thoughts of why that might be?

@nyurik
Copy link
Member

nyurik commented Mar 29, 2023

@Volatus @stepankuzmin please retest - i think i fixed it, but no idea if the metadata is correct

@nyurik
Copy link
Member

nyurik commented Mar 29, 2023

Weirdly enough, there are two architectures listed: arm64 and unknown. Should the x86-amd64 specify its metadata in some other way? https://github.com/maplibre/martin/pkgs/container/martin/81143769?tag=main

@nyurik
Copy link
Member

nyurik commented Mar 29, 2023

And one more interesting tidbit: the image tagged as arm64 is actually amd64! And I wasn't able to download the unknown/unknown image, so i have no idea what that one is... Any ideas how to fix this? I would hate to revert this PR.

❯ docker pull --platform linux/arm64 ghcr.io/maplibre/martin:main
main: Pulling from maplibre/martin
fcdb9667c46b: Pull complete
bc959a36ad3b: Pull complete
Digest: sha256:248ef4abb68d3fe2dc1af2068984850fad48bc3d500af67bbfb9b3485620f8c9
Status: Downloaded newer image for ghcr.io/maplibre/martin:main
WARNING: image with reference ghcr.io/maplibre/martin was found but does not match the specified platform: wanted linux/arm64, actual: linux/amd64
ghcr.io/maplibre/martin:main

@nyurik
Copy link
Member

nyurik commented Mar 29, 2023

@Volatus
Copy link
Contributor Author

Volatus commented Mar 29, 2023

I think if both of them have their own manifest step, it should end up working.

@Volatus
Copy link
Contributor Author

Volatus commented Mar 29, 2023

@nyurik It's surely not the case the issue is due to order right?

include:
- platform: linux/amd64
file: Dockerfile
- platform: linux/arm64
file: arm64.Dockerfile

with:
platforms: linux/arm64,linux/amd64

@nyurik
Copy link
Member

nyurik commented Mar 29, 2023

@Volatus definitly not because i added the QEMU configuration after I saw the issue. Before this, QEMU was configured with ALL

nyurik added a commit to nyurik/martin that referenced this pull request May 9, 2023
This reverts commit c358ec5,
as well as any other related changes to the docker github action.

It is clearly not working, while also not allowing us to build
proper releases quicker.

Several ways to fix:
* Use 3rd party CI service to just build multi-platform docker images
* Use cross-compilation wiht github actions
* (???)
nyurik added a commit to nyurik/martin that referenced this pull request May 9, 2023
This reverts commit c358ec5,
as well as any other related changes to the docker github action.

It is clearly not working, while also not allowing us to build
proper releases quicker.

Several ways to fix:
* Use 3rd party CI service to just build multi-platform docker images
* Use cross-compilation wiht github actions
* (???)
nyurik added a commit to nyurik/martin that referenced this pull request May 9, 2023
This reverts commit c358ec5,
as well as any other related changes to the docker github action.

It is clearly not working, while also not allowing us to build
proper releases quicker.

Several ways to fix:
* Use 3rd party CI service to just build multi-platform docker images
* Use cross-compilation wiht github actions
* (???)
nyurik added a commit that referenced this pull request May 9, 2023
This reverts commit c358ec5, as well as
any other related changes to the docker github action.

It is clearly not working, while also not allowing us to build proper
releases quicker.

Several ways to fix:
* Use 3rd party CI service to just build multi-platform docker images
* Use cross-compilation wiht github actions
* (???)

See also #655,  #603 and #505
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

linux/arm64/v8 docker images do not exist Add Linux/arm64/v8 docker image
3 participants