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

Added Arm Multi-arch Make Logic #36

Merged
merged 4 commits into from
Jul 8, 2020
Merged

Added Arm Multi-arch Make Logic #36

merged 4 commits into from
Jul 8, 2020

Conversation

firethestars
Copy link
Contributor

I am hoping to resolve part of Issue #18 with this pull request (would have included ppc64le, but I only have amd64 and arm hardware to test against). I tried to follow the logic in the velero Makefile as closely as possible, so this should look familiar. This will require/create extra dockerhub repositories of velero-plugin-for-aws-amd64, velero-plugin-for-aws-arm, and velero-plugin-for-aws-arm64; which are needed to manifest the multi-arch velero-plugin-for-aws image.

  • Added file Dockerfile-arm for building arm 32bit builds
  • Added file Dockerfile-arm64 for building arm 64bit builds
  • modified Makefile to try and have similar logic to the multi-arch Makefile in the base velero project adding targets all-containers, all-push, manifest, etc. Original targets should continue to work as is.
  • updated hack/docker-push to use the new targets to build multi-arch images

Signed-off-by: Chris Lynch [email protected]

- Added file Dockerfile-arm for building arm 32bit builds
- Added file Dockerfile-arm64 for building arm 64bit builds
- modified Makefile to try and have similar logic to the multi-arch Makefile in the base velero project adding targets all-containers, all-push, manifest, etc. Original targets should continue to work as is.
- updated hack/docker-push to use the new targets to build multi-arch images

Signed-off-by: Chris Lynch <[email protected]>
@firethestars
Copy link
Contributor Author

TravisCI seems to be stuck as it has been at this for several days without returning. If I had to guess, I would say that it is the changes to hack/docker-push.sh that it might object to. Let me know if there is something on my side that requires changing or that I can help with.

@nrb
Copy link
Contributor

nrb commented Apr 17, 2020

Hi @firethestars, sorry for the long delay in replying. https://travis-ci.org/github/vmware-tanzu/velero-plugin-for-aws/builds/667981259 says that it finished, but I don't see that it's updated here. I'm going to close and re-open the PR to see if that kicks it off again.

@nrb nrb closed this Apr 17, 2020
@nrb nrb reopened this Apr 17, 2020
@firethestars
Copy link
Contributor Author

@nrb, thanks for kicking it off again. Looks like it passed the automatic checks. Just let me know if there is anything I can do to help on my side.

@xunholy
Copy link

xunholy commented Apr 19, 2020

Rather than creating multiple Dockerfiles essentially duplicating the same content, you could approach it using docker buildx to build for a much wider variety of architectures currently supported. Here is an example of how that might look in reality - https://github.com/raspbernetes/multi-arch-images/blob/master/build/velero-aws-plugin/Dockerfile

@firethestars
Copy link
Contributor Author

@xunholy That is a pretty interesting tool that I did not even know existed. If that is the preferred way to do multi-arch builds, then I can certainly alter the pull request to use that instead (might just submit a new parallel one).

My main concern about moving to buildx would be that then it will be using a different build/make workflow than the base velero project (which cannot as easily take up buildx because they are doing some extra work-around stuff in the dockerfile for powerpc).

If you don't mind my asking, in the example Dockerfile you linked to, I note your initial from does not have a "--platform=$BUILDPLATFORM" switch. My limited reading and trying it seems to indicate it is necessary for cross-platform builds, so I wonder if that is a quirk of your compilation environment or if I am doing something wrong.

@xunholy
Copy link

xunholy commented Apr 25, 2020

Yep, buildx is a fantastic tool that will help multi-architecture images become more mainstream in the year(s) to come.

If you don't mind my asking, in the example Dockerfile you linked to, I note your initial from does not have a "--platform=$BUILDPLATFORM" switch. My limited reading and trying it seems to indicate it is necessary for cross-platform builds, so I wonder if that is a quirk of your compilation environment or if I am doing something wrong.

This is because in a lot of my examples I'm compiling the Binary for multi-architecture - It's not enough to only have a multi-arch image if the binary is still compiled for a specific OS and ARCH. Thankfully Golang is good at handling the OS, ARCH, and even the ARM version to use.

Also the reason there is no switch is because that is a native Docker env variable - not a regular build arg which you might be more familiar with although that ARG actually does change for each architecture which is how the compilation works and exports the correct versions.

@nrb
Copy link
Contributor

nrb commented Apr 27, 2020

@xunholy Thanks for pointing that command out! I think we should definitely look into cleaning up our build pipeline, but I think I also agree with @firethestars - I'd prefer to do it in core Velero and work out to the plugins we support (that's AWS, GCP, Azure, and CSI). Right now, that's not going to make it in for our v1.4 release.

I've made vmware-tanzu/velero#2464 to capture that so we don't lose it. Thanks for the suggestion!

nrb
nrb previously approved these changes Apr 27, 2020
Copy link
Contributor

@nrb nrb left a comment

Choose a reason for hiding this comment

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

👍 Thanks for this! Apologies again for the long delay.

@firethestars
Copy link
Contributor Author

@nrb - I just wanted to follow up and see if there are any action items I could take on to help move this forward.

@carlisia
Copy link
Contributor

@firethestars thank you for this. You are missing the DCO signature, please add it so it passes the check.

@nrb and @ashish-amarnath PTAL when you have a chance, you two are way more well versed in this than I am.

Dockerfile-arm Outdated


FROM arm32v7/ubuntu:bionic
#RUN mkdir /plugins
Copy link
Member

Choose a reason for hiding this comment

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

Please remove commented steps in the Dockerfiles.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comment removed from both dockerfiles.

Dockerfile-arm Outdated
@@ -0,0 +1,25 @@
# Copyright 2017, 2019 the Velero contributors.
Copy link
Member

Choose a reason for hiding this comment

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

Copyright boilerplate should have 2020 as the year.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Year has been updated.

@firethestars
Copy link
Contributor Author

Sorry I was busy all week, but the requested changes should now be in place. Please let me know if anything else needs attention.

@skriss skriss removed their request for review July 6, 2020 16:18
@carlisia carlisia requested a review from ashish-amarnath July 8, 2020 13:53
Copy link
Member

@ashish-amarnath ashish-amarnath left a comment

Choose a reason for hiding this comment

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

Thank you for making the changes.
LGTM.
I have one comment about ppv64le.

LGTM otherwise.

# See the License for the specific language governing permissions and
# limitations under the License.

FROM golang:1.13-buster AS build
Copy link
Member

Choose a reason for hiding this comment

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

Can we please switch this to golang 1.14?

Copy link
Member

Choose a reason for hiding this comment

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

This needs to be done on the other dockerfile too.
Going to clean this in a follow-up PR

RUN GOARCH=arm64 CGO_ENABLED=0 GOOS=linux go build -v -o /go/bin/velero-plugin-for-aws ./velero-plugin-for-aws


FROM arm64v8/ubuntu:bionic
Copy link
Member

Choose a reason for hiding this comment

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

Can we use the more recent ubuntu:focal instead?

Copy link
Member

Choose a reason for hiding this comment

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

This needs to be done on the other dockerfile too.
Going to clean this in a follow-up PR

VERSION ?= master

CONTAINER_PLATFORMS ?= amd64 arm arm64 # ppc64le
Copy link
Member

Choose a reason for hiding this comment

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

should ppv64le be uncommented?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think ppc64le needs to be removed entirely; it's not supported by Velero itself.

Copy link
Contributor

@nrb nrb left a comment

Choose a reason for hiding this comment

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

Lets get this merged for now and fix the issues in a follow up PR in order to reduce the back and forth.

Thanks for your patience @firethestars!

@nrb nrb merged commit 46c18b3 into vmware-tanzu:master Jul 8, 2020
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.

5 participants