Release docker image for arm64

[odidev]

The following files have been modified and added:

• In .circleci/config.yml added a new job publish in order to use buildx to build and push images for both the platforms to dockerhub.

• Added docker/Dockerfile.cloud-agent_multiarch file for building cloud-agent image which uses multi-stage build that builds the scope binary in stage 1 and in stage 2 follows the same steps as written in Dockerfile.cloud-agent.

• Added docker/Dockerfile.scope_multiarch file for building scope image which uses multi-stage that builds all the binaries in stage 1 and in stage 2 copies all the binaries same as Dockerfile.scope.

[odidev]

Can you please review this PR and let me know if any changes are required?

[jonwilliams84]

I have a mixed arch cluster, have pulled this image and replaced the official image for the agent daemonset in my cluster and it looks to be working:

Screenshot of nodes...all rpi-* nodes are pi4's and the jet- node is a Jetson Nano:

Can also see pod network interactions on those nodes.

Can this be merged please?

[kingdonb]

I appreciate the work that has been done here, thanks very much for contributing this!

I don't quite have access to see what's wrong with the failing integration tests, but I suspect it has something to do with the recent CircleCI deprecations. Maybe there's more to it than that.

If there is someone who has the desire to perform the maintainer role, it will help a lot, as I'm able to facilitate but cannot take on the role myself. There are too many other responsibilities, primarily around Flux and getting to GA/CNCF graduation.

[kingdonb]

The situation at present is, this project is without an active maintainer. I'm afraid it wouldn't be right to publish a release without addressing all or most known security issues (right now I'm not apprised), but that doesn't mean we cannot merge this. I would like to see a passing run of the integration tests. Unfortunately not positioned to investigate further at this time.

Is there anyone familiar enough with the release machinery that is built into scope who would be able to comment on what needs to be done to publish this as a prerelease, and would that be enough to satisfy the need here? (Is it sufficient to merge the PR, then we'll see a prerelease image pop out on Docker Hub or somewhere?)

My concern is that publishing a new release after such a hiatus might send the message that someone is looking out for dependency upgrades and security, when in fact we've only looked at this one PR. Publishing as a pre-release would lessen my concerns, but the concern remains as anyone who runs this would potentially be at risk, if a known or undiscovered issue was able to be exploited. In that sense, it would be better to archive the repo and take more active steps to discourage the use if it isn't going to be maintained.

(But if there is someone who is interested to act as the maintainer, it could be a different story!)