search

freeipa / freeipa-container

FreeIPA server in containers — images at https://quay.io/repository/freeipa/freeipa-server?tab=tags
https://quay.io/repository/freeipa/freeipa-server?tab=tags
Apache License 2.0
614 stars 259 forks source link

arm64 images #596

Closed fichte closed 8 months ago

fichte commented 8 months ago

Hi,

is there any problem to provide arm64 images? I successfully built the rawhide image for arm64. It would be nice if they could be provided as the amd64 images.

Thank you fichte

adelton commented 8 months ago

The problem is to do it in a sustainable way with some guarantees of functionality and updates (respins) of those image, not just do a one-off build and then let it rot. The convenience of having built arm64 images for users is also a liability for this project, something I don't treat lightly given fairly limited number of maintainers and the time they can devote to the project. Even getting and keeping the existing matrix of images (all on x86_64) working is nontrivial, for example we currently don't test and push Fedora rawhide and CentOS 9 Stream images due to https://bugzilla.redhat.com/show_bug.cgi?id=2265995 and https://issues.redhat.com/browse/RHEL-20465. Add another architecture to the mix and the maintenance complexity might multiply.

(Which, by the way, means that while you might have built a Fedora rawhide image -- does it work? It fails for me: https://github.com/adelton/freeipa-container/actions/runs/8234965268/job/22518208838)

Currently we build the images for https://quay.io/repository/freeipa/freeipa-server?tab=tags and https://hub.docker.com/r/freeipa/freeipa-server/tags using GitHub Actions' hosted runners which are x86_64 (amd64). For arm64 builds we could either do multi-arch builds with docker buildx on those x86_64 runners but then couldn't test them there; or we could build on ARM on Cirrus CI or CircleCI but even if we got the systemd-in-container running on those CIs to run the tests, we'd then have the problem of integrating those two completely separate sources of images into single manifest for reasonable consumption.

Neither of those approaches screams easy. Are there any others?

I tested building with Cirrus CI and CircleCI before but on neither platform did I get stable setup to even run the CI jobs (without pushing the built images to Quay/Docker Hub).

That's why I'm currently waiting to see if the ARM-runners of GitHub Actions mentioned in https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/ will become available outside of the private beta and what they will look like, to give our ARM options another look.

fichte commented 8 months ago

The problem is to do it in a sustainable way with some guarantees of functionality and updates (respins) of those image, not just do a one-off build and then let it rot. The convenience of having built arm64 images for users is also a liability for this project, something I don't treat lightly given fairly limited number of maintainers and the time they can devote to the project. Even getting and keeping the existing matrix of images (all on x86_64) working is nontrivial, for example we currently don't test and push Fedora rawhide and CentOS 9 Stream images due to https://bugzilla.redhat.com/show_bug.cgi?id=2265995 and https://issues.redhat.com/browse/RHEL-20465. Add another architecture to the mix and the maintenance complexity might multiply.

(Which, by the way, means that while you might have built a Fedora rawhide image -- does it work? It fails for me: https://github.com/adelton/freeipa-container/actions/runs/8234965268/job/22518208838)

i created a pull request which fixes this /etc/pki/pki-tomcat issue see https://github.com/freeipa/freeipa-container/pull/597

Currently we build the images for https://quay.io/repository/freeipa/freeipa-server?tab=tags and https://hub.docker.com/r/freeipa/freeipa-server/tags using GitHub Actions' hosted runners which are x86_64 (amd64). For arm64 builds we could either do multi-arch builds with docker buildx on those x86_64 runners but then couldn't test them there; or we could build on ARM on Cirrus CI or CircleCI but even if we got the systemd-in-container running on those CIs to run the tests, we'd then have the problem of integrating those two completely separate sources of images into single manifest for reasonable consumption.

Neither of those approaches screams easy. Are there any others?

I tested building with Cirrus CI and CircleCI before but on neither platform did I get stable setup to even run the CI jobs (without pushing the built images to Quay/Docker Hub).

That's why I'm currently waiting to see if the ARM-runners of GitHub Actions mentioned in https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/ will become available outside of the private beta and what they will look like, to give our ARM options another look.

thanks for the detailed explanation. then i will use my own built arm64 image until the CI stuff is working properly :)

adelton commented 8 months ago

Nod, setting up your build pipeline is probably the best solution for now.

clouds56 commented 1 month ago

That's why I'm currently waiting to see if the ARM-runners of GitHub Actions mentioned in https://github.blog/changelog/2023-10-30-accelerate-your-ci-cd-with-arm-based-hosted-runners-in-github-actions/ will become available outside of the private beta and what they will look like, to give our ARM options another look.

Now it's public beta, https://github.blog/news-insights/product-news/arm64-on-github-actions-powering-faster-more-efficient-build-systems/, shall we reopen this?

adelton commented 1 month ago

I don't see ARM architecture available for the standard GitHub-hosted runners, only on the larger runners.

abbra commented 1 month ago

From the blog: "These runners are available to our customers on our GitHub Team and Enterprise Cloud plans. We expect to begin offering Arm runners for open source projects by the end of the year."