Fixed #8342: Add ARM64 architecture to Docker Builds

[zacharyfleck]

Description

Discovered today that Snipe-IT's docker image does not currently support the ARM architecture, which as many may know is becoming more prominent thanks to Apple Silicon and Amazon's Graviton processors (and similar from other cloud providers). We utilize Snipe-IT in Kubernetes and are in the process of migrating our infra over from x86_64 to ARM64 to provide cost savings and performance gains.

Currently - Attempting to run the AMD64 version of Snipe-IT in an AWS EKS cluster with node type m7g.large returns exec /startup.sh: exec format error. Adding a native ARM image, however, starts like normal with seemingly no errors. (I would like to note, however, that I did not receive the exec /startup.sh: exec format error error on my local M1 Mac)

I have tested this image to the best of my abilities to look for any issues or errors, and none have been found as of now.

Relates to #8342

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Test Configuration: N/A - See Dockerfile in root of repository for relevant information.

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[welcome]

💖 Thanks for this pull request! 💖

We use semantic commit messages to streamline the release process and easily generate changelogs between versions. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix if it doesn't have one already.

Examples of commit messages with semantic prefixes:

• Fixed #<issue number>: don't overwrite prevent_default if default wasn't prevented
• Added #<issue number>: add checkout functionality to assets
• Improved Asset Checkout: use new notification method for checkout

Things that will help get your PR across the finish line:

• Document any user-facing changes you've made.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[what-the-diff]

PR Summary

• Updated Docker Configuration Files
  Both docker-alpine.yml and docker.yml files were modified.
• Added ARM64 Platform Support
  Changes were made to support both linux/amd64 and linux/arm64 platforms.

[uberbrady]

This looks great!!!! Thank you for fixing this for us! I really appreciate it. I'll try and see if I can figure out how to test it on my own machine (which is ARM64), and get it merged up. (Our fleet for our hosted platform is pretty near to 100% Graviton2 on AWS, as well).

[zacharyfleck]

I'll try and see if I can figure out how to test it on my own machine (which is ARM64)

Neat! Like I said I couldn't directly reproduce the issue in Docker on my M1 Mac, though I haven't tried spinning it up in Kubernetes locally. If you have a Graviton EKS cluster available to you at all, I was able to get it to happen there simply by running kubectl run snipe --env APP_KEY=base64key --image snipe/snipe-it and saw the issue very clearly. That of course runs without MySQL, but had the same issue on our helm deployment which first waits for MySQL to be available prior to allowing Snipe to spin up.

[zacharyfleck]

@uberbrady Just realized that I need to remove the space from in between linux/amd64, linux/arm64. Making that change now.

[zacharyfleck]

Fixed - Should be good to go as you see fit.

[welcome]

Congrats on merging your first pull request! 🎉🎉🎉

[snipe]

Awesome, thank you!

[zacharyfleck]

@snipe @uberbrady I noticed builds randomly failed last night for the ubuntu image. Looks like it was unable to find packages, wondering if maybe it was some kind of networking error either in GitHub or Ubuntu's repos. Without making any code changes (with the exception of allowing the action to run on my fork of the repo) the build succeeded today: https://github.com/zacharyfleck/snipe-it/actions/runs/4811232692/jobs/8564946218

I have a feeling next push to develop or master will yield no issues with the docker build here.

GitHub

should build without attempt to push? · zacharyfleck/snipe-it@adcd2e1

A free open source IT asset/license management system - should build without attempt to push? · zacharyfleck/snipe-it@adcd2e1