Roadmap 2023: ARM64 Support

[sophiewigmore]

In order to eventually support ARM64 use cases in the Paketo Buildpacks project, there's some precursory work that will need to happen first so that we can address user needs as well as ease maintainer burden. The point of this thread is to enumerate what that work entails, and to document use cases that we're aware of.

• Dependencies: The dependencies we ship via the Dependency Server are compiled for Ubuntu 18.06. We will also need to re-compile all of these dependencies for ARM64.

  • Compilation code: The main chunk of work associated with this task stems from the fact that our compilation code is quite outdated and complicated. It would be cumbersome to add (and then maintain) compilation code for a new architecture to this code base. As a maintainer of dependencies, I would be hesitant to add new logic to that code. In order to enable ARM64-compiled dependencies, we should re-write our compilation code to be more modular first.
  • Automation: We will need to add actions and workflow changes to the Dependency Server GHA set up. This will require the set up of ARM64 hosted runners.
  • Dependency publishing: We may need to formulate a new organization structure for how we publish dependencies in the dep-server, so that buildpacks can easily consume dependencies for both architectures.

• Stacks: We will need to ship ARM64-versions of our stacks. This is not a heavy lift, it will require the set up of self-hosted runners so that we can unblock things like Arm64 support stacks#86

• Infrastructure: We will need a mechanism to run ARM64 architecture in development and in CI. This will require self-hosted runners, which will require additional maintenance and funds to set up. Beyond performing the actual set up, we need to determine as a project who will maintain this.

• Multi-architecture Artifacts: Docker/OCI have support for multi-architecture images. There are currently no packaging tools for buildpack/builder images that support multi-architecture image builds/pulling. Ideally, we'd like to see something like this in pack (there are open issues for this).

Are there any other items we should make note of?

Use cases

Uses that we are aware of:

• Mac M1 users having trouble running buildpacks (workaround available via Rosetta emulation)
• AWS Graviton EC2 instance users
• Raspberry Pis
  If you have a different use case, feel free to sound off here as well.

[dmikusa]

For the Java-related buildpacks and some of the utility buildpacks, +1 to everything above with a couple of differences:

1. We don't compile from source for most of our binaries (or they are Java, so not arch dependent), so it requires locating upstream ARM64 versions of the native dependencies. I know that some of our supported JVM vendors have ARM64 builds, but I think some do not. We'll have to track this until upstream teams are producing ARM64 builds.

2. There are a number of assumptions made in our CI systems (track dependencies/update buildpack metadata) & asset management (download/install/cache code) which assume there's only one architecture. These assumptions need to be addressed and accommodations need to be made to support multiple architectures of a dependency. For example, we list dependencies in buildpack.toml. These will need architecture metadata and libpak will need to be able to filter on the architecture. In addition, when packaging assets with an image the code needs to again filter based on the intended image's architecture, so that an x86 dependency isn't packaged in an ARM buildpack image, thus wasting space.

[SnakeDoc]

The discussions revolving around ARM64 seem to be spread out among many threads/issues/discussions.

Is there a canonical place to see current status of ARM64 support and remaining tasks?

[mrclrchtr]

I'm also trying to find out the current status and whether you can provide any support. Unfortunately, I cannot find the appropriate issues/discussions. What is the current status?

[dmikusa]

From June 7th...

Hi ARM64 Buildpack Fans!
Today we merged ARM64 support for the last libpak-based buildpack!

This includes all of the #java buildpacks, all of the #rust buildpacks, all of the #app-monitoring buildpacks (except aternity which doesn’t seem to have ARM64 support) and all of the libpak-based #utilities buildpacks.

Nothing new, but we’re continuing to publish the paketo-buildpacks/java, paketo-buildpacks/java-native-image and paketo-buildpacks/rust composite buildpack collections all as ARM64 too.

These can all be used with the paketobuildpacks/builder-jammy-buildpackless-tiny which is being build for ARM64 too.

This is a significant step as you can now build many applications from top-to-bottom with buildpacks and ARM64 using all officially available images from the Paketo Project.

The road to ARM64 support continue on. In the future, we’re looking to publish the Ubuntu Noble stack with ARM64 (tiny, base and full), we’re looking to continue expanding the list of buildpacks that support ARM64, and also publish more builders with ARM64 support so that it’s easier to consume and build your applications on ARM64.

As always, please reach out with any feedback/issues/etc.. on the ARM64 support.

Other buildpacks and builders have yet to be updated to support ARM64.

[dmikusa]

In a nutshell, if you're using the paketobuildpacks/builder-jammy-buildpackless-tiny and any libpak based buildpacks, then you should be able to have ARM64 builds.

[mrclrchtr]

Thank you very much! I will try it.