Support for ARM64 architecture in Bitnami container images
carrodher opened this issue ยท 199 comments
Currently, the Bitnami container images do not support the ARM64 architecture.
We are aware of the growing interest in this architecture and there are ongoing internal plans to release the Bitnami Community Catalog for ARM64 in the future, definitely, it is something we would like to support, but we need to find the bandwidth to do it in a proper way maintaining our quality standards.
At the moment, only our base image bitnami/minideb has support for ARM64 thanks to the community contribution in this PR: bitnami/minideb#90
Although there are some initiatives and Engineering work going on, we cannot guarantee a specific ETA for this topic. We will update this issue with more information.
Thanks for using Bitnami Containers and Helm Charts!
Update 24th February: ARM containers are already available in DockerHub, see #7305 (comment)
Are most of your builds being bult on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)
Are most of your builds being built on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)
There is an internal pipeline based on Jenkins where we build the image with the docker CLI and then run several tests using the image in a deployment based on docker-compose and also in k8s via Helm Charts, you can find more information about this test and release process in the following link: https://docs.bitnami.com/tutorials/bitnami-best-practices-hardening-charts/#bitnami-release-process-and-tests.
Once tested the image, is published in different repositories such as
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
public.ecr.aws/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB
quay.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB
docker.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB
gcr.io/bitnami-containers/apache 2.4 3156fbf7dfbd 23 hours ago 176MBAre most of your builds being built on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)There is an internal pipeline based on Jenkins where we build the image with the docker CLI and then run several tests using the image in a deployment based on docker-compose and also in k8s via Helm Charts, you can find more information about this test and release process in the following link: https://docs.bitnami.com/tutorials/bitnami-best-practices-hardening-charts/#bitnami-release-process-and-tests.
Once tested the image, is published in different repositories such as
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB quay.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB docker.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB gcr.io/bitnami-containers/apache 2.4 3156fbf7dfbd 23 hours ago 176MB
Where is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?
Are most of your builds being built on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)There is an internal pipeline based on Jenkins where we build the image with the docker CLI and then run several tests using the image in a deployment based on docker-compose and also in k8s via Helm Charts, you can find more information about this test and release process in the following link: https://docs.bitnami.com/tutorials/bitnami-best-practices-hardening-charts/#bitnami-release-process-and-tests.
Once tested the image, is published in different repositories such as$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB quay.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB docker.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB gcr.io/bitnami-containers/apache 2.4 3156fbf7dfbd 23 hours ago 176MBWhere is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?
I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different https://github.com/bitnami/bitnami-docker-ASSET repositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.
In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.
Are most of your builds being built on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)There is an internal pipeline based on Jenkins where we build the image with the docker CLI and then run several tests using the image in a deployment based on docker-compose and also in k8s via Helm Charts, you can find more information about this test and release process in the following link: https://docs.bitnami.com/tutorials/bitnami-best-practices-hardening-charts/#bitnami-release-process-and-tests.
Once tested the image, is published in different repositories such as$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB quay.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB docker.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB gcr.io/bitnami-containers/apache 2.4 3156fbf7dfbd 23 hours ago 176MBWhere is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.
Okey so you kind of say that the community could help, but without the ability to see all of the build steps, there's pretty much NO WAY for people outside the org to help properly for example in the mariadb container build process to get it multi arched.
I cannot help without knowning how it's supposed to work under CI, as just changing docker files is not going to be nowhere enough to get this really anywhere. docker buildx requires a greater than 19.x, cannot remember.
What does this need to get this bumped to a higher priority in your roadmap?
Are most of your builds being built on either Travis CI or CircleCI?
Eg, how is the MariaDB container being built? I cannot find build files for it? (https://github.com/bitnami/bitnami-docker-mariadb)There is an internal pipeline based on Jenkins where we build the image with the docker CLI and then run several tests using the image in a deployment based on docker-compose and also in k8s via Helm Charts, you can find more information about this test and release process in the following link: https://docs.bitnami.com/tutorials/bitnami-best-practices-hardening-charts/#bitnami-release-process-and-tests.
Once tested the image, is published in different repositories such as$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE public.ecr.aws/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB quay.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB docker.io/bitnami/apache 2.4 3156fbf7dfbd 23 hours ago 176MB gcr.io/bitnami-containers/apache 2.4 3156fbf7dfbd 23 hours ago 176MBWhere is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.
In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.Okey so you kind of say that the community could help, but without the ability to see all of the build steps, there's pretty much NO WAY for people outside the org to help properly for example in the mariadb container build process to get it multi arched.
I cannot help without knowning how it's supposed to work under CI, as just changing docker files is not going to be nowhere enough to get this really anywhere. docker buildx requires a greater than 19.x, cannot remember.
There are some parts public like the Dockerfile, bash initialization logic, etc so users can build their own image customizing it. What is not public is the internal logic we use to compile the source code if needed, build, test, and release the Bitnami container images.
What does this need to get this bumped to a higher priority in your roadmap?
The internal roadmap is based on business and product decisions, taking into account community users but other variables as well.
Where is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.
In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.Okey so you kind of say that the community could help, but without the ability to see all of the build steps, there's pretty much NO WAY for people outside the org to help properly for example in the mariadb container build process to get it multi arched.
I cannot help without knowning how it's supposed to work under CI, as just changing docker files is not going to be nowhere enough to get this really anywhere. docker buildx requires a greater than 19.x, cannot remember.There are some parts public like the Dockerfile, bash initialization logic, etc so users can build their own image customizing it. What is not public is the internal logic we use to compile the source code if needed, build, test, and release the Bitnami container images.
Can you share any information about the whole process? Jenkins processes the Dockerfiles, is Jenkins build pipeline architecture aware as in does it support multiple architecture building via Docker Buildx?
What does this need to get this bumped to a higher priority in your roadmap?
The internal roadmap is based on business and product decisions, taking into account community users but other variables as well.
Which doesn't say much, and I don't feel like you actually answered my question so please do. Does one need to throw money at you before you take this as a higher priority than what it currently is?
Where is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.
In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.Okey so you kind of say that the community could help, but without the ability to see all of the build steps, there's pretty much NO WAY for people outside the org to help properly for example in the mariadb container build process to get it multi arched.
I cannot help without knowning how it's supposed to work under CI, as just changing docker files is not going to be nowhere enough to get this really anywhere. docker buildx requires a greater than 19.x, cannot remember.There are some parts public like the Dockerfile, bash initialization logic, etc so users can build their own image customizing it. What is not public is the internal logic we use to compile the source code if needed, build, test, and release the Bitnami container images.
Can you share any information about the whole process? Jenkins processes the Dockerfiles, is Jenkins build pipeline architecture aware as in does it support multiple architecture building via Docker Buildx?
In a generic way, the internal pipeline is tracking the upstream repositories, when there is a new version in any of the tracked applications, the source code is downloaded and compiled, then the Dockerfile and the initialization logic is generated (those files are public), with those files the container image is built, before releasing it, the container image is tested as part of different docker-composes and the Helm chart; if everything works as expected the container image is pushed to the different repositories.
The logic of this pipeline is not public, users can contribute to the Helm Charts (this is 100% public) or the container initialization logic, Dockerfile, docker-compose.yaml, etc; but unfortunately not with the pipeline logic itself that is the one in charge of build the image
What does this need to get this bumped to a higher priority in your roadmap?
The internal roadmap is based on business and product decisions, taking into account community users but other variables as well.
Which doesn't say much, and I don't feel like you actually answered my question so please do. Does one need to throw money at you before you take this as a higher priority than what it currently is?
When defining the roadmap, different parameters are considered such as the capacity of the team; we are a small team and we can't address all the requests we receive such as adding new Helm Charts to the catalog, implement new features, fix existing bugs, or as in this case, support a new arch. We would like to address everything ASAP, but the capacity is not infinite so we need to prioritize some topics.
Here you can find more info about Tanzu Application Catalog (TAC), which is the paid version of the Bitnami Community Catalog (BCC). In terms of the arch, ARM64 is not supported in TAC nor BCC, but other distros such as CentOS, PhotonOS, or Ubuntu are supported in TAC while only Debian is supported in BCC.
Where is the Docker version used defined?
What would need to be PR'ed to be able to produce multi-arch images with Docker Buildx?I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.
In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.Okey so you kind of say that the community could help, but without the ability to see all of the build steps, there's pretty much NO WAY for people outside the org to help properly for example in the mariadb container build process to get it multi arched.
I cannot help without knowning how it's supposed to work under CI, as just changing docker files is not going to be nowhere enough to get this really anywhere. docker buildx requires a greater than 19.x, cannot remember.There are some parts public like the Dockerfile, bash initialization logic, etc so users can build their own image customizing it. What is not public is the internal logic we use to compile the source code if needed, build, test, and release the Bitnami container images.
Can you share any information about the whole process? Jenkins processes the Dockerfiles, is Jenkins build pipeline architecture aware as in does it support multiple architecture building via Docker Buildx?
In a generic way, the internal pipeline is tracking the upstream repositories, when there is a new version in any of the tracked applications, the source code is downloaded and compiled, then the Dockerfile and the initialization logic is generated (those files are public), with those files the container image is built, before releasing it, the container image is tested as part of different docker-composes and the Helm chart; if everything works as expected the container image is pushed to the different repositories.
The logic of this pipeline is not public, users can contribute to the Helm Charts (this is 100% public) or the container initialization logic, Dockerfile, docker-compose.yaml, etc; but unfortunately not with the pipeline logic itself that is the one in charge of build the image
So basically the portion that would be required to have changes made to it for multi-architecture image building aka pipeline logic that's charge in the building of it, is not public. So that would probably warrant a note on anything Bitnami stating that multi-arch is not supported on most of the images. Currently every time I see Bitnami anything, I take the assumption that there's no multi-arch images, which make it not usable at all.
Can you say the reason why the pipeline logic itself is not public?
What does this need to get this bumped to a higher priority in your roadmap?
The internal roadmap is based on business and product decisions, taking into account community users but other variables as well.
Which doesn't say much, and I don't feel like you actually answered my question so please do. Does one need to throw money at you before you take this as a higher priority than what it currently is?
When defining the roadmap, different parameters are considered such as the capacity of the team; we are a small team and we can't address all the requests we receive such as adding new Helm Charts to the catalog, implement new features, fix existing bugs, or as in this case, support a new arch. We would like to address everything ASAP, but the capacity is not infinite so we need to prioritize some topics.
Here you can find more info about Tanzu Application Catalog (TAC), which is the paid version of the Bitnami Community Catalog (BCC). In terms of the arch, ARM64 is not supported in TAC nor BCC, but other distros such as CentOS, PhotonOS, or Ubuntu are supported in TAC while only Debian is supported in BCC.
Okey, so if I were a paying customer of yours, would that actually make a difference in terms of getting an issue fast tracked? One would hope so, but somehow I doubt it.
Is there a good reason to re-build every single image and by extension not have compatibility with an upstream image when using the Bitnami charts?
I'm sorry but this part of the test & release pipeline is not public. You can find the Dockerfile for all the assets present in the catalog by looking into the different
https://github.com/bitnami/bitnami-docker-ASSETrepositories. As the Dockerfile is public you can build the image using them. In the same repository, you can customize the bash scripts used for the initialization logic.In some of the above-mentioned issues, there are some community members that tried to customize some repositories to make them compatible with different architectures.
Hi,
The point is the Dockerfiles can not be used as they fetch precompiled binaries (directives such as: RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack ...), that are not available for ARM architecture.
So, in order to use the Dockerfiles, one has to recreate the binary archives with the very same software components selected by bitnami, without knowing which ones and not knowing how they were compiled. This may be achieved with great motivation and time but, in practice, is a waste of time. When I started a project that needed ARM images, I believed that it woud not be (too) difficult to rebuild docker images compatible with bitnami's chart, but I gave up pretty soon.
I wonder if people/organisations that choose to make bitnami's Helm Chart as their official chart (probably because they feel those chart's quality is good and possibly other good reasons) even realize that they, in fact, restrict the use of the chart to architectures supported by bitnami.
Best regards.
- has anyone gotten a chance to try and build a bitnami docker image with publicly available ARM64 packages instead of the ones compiled by bitnami? if yes, did it work? example like this...we notice that we are downloading a package from bitnami servers....if we replaced that with the publicly available package, would that work?
- we are kind of in a hurry to migrate to ARM64 and we'd like to know if there is any alternative
Thank you
- we are kind of in a hurry to migrate to ARM64 and we'd like to know if there is any alternative
Thank you
Altirnative is to not use Bitnami images on arm64.
- has anyone gotten a chance to try and build a bitnami docker image with publicly available ARM64 packages instead of the ones compiled by bitnami? if yes, did it work? example like this...we notice that we are downloading a package from bitnami servers....if we replaced that with the publicly available package, would that work?
- we are kind of in a hurry to migrate to ARM64 and we'd like to know if there is any alternative
Thank you
As far as I understood, bitnami packages have nothing to do with publicly available packages. They are the result of bitnami's secret build process and have their own structure. Packages enumerated in bitnami_components.json are downloaded with the corresponding lines in Dockerfile (RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack ...).
Some charts are said to be compatible with official docker images. I tried it with postgresql and was indeed able to deploy and boot the official ARM64 docker image with bitnami's chart.
However the "compatibility" is extremely limited and missleading. Almost every more elaborated options in the chart (that make bitnami's chart worth) were simply not working because the docker image was not compatible in the first place.
So if you started a projet with bitnami's charts and images, you're probably stuck to architectures selected by bitnami
Best regards.
+1 It would be so great to be able to use the bitnami helm charts on my raspberry pi
@carrodher is anything planned for this?
We are making some progress on different internal tools to allow the automated pipeline to compile and build images based on the new architecture, but there is still a way to go. We will update this thread once there are some visible progress
@carrodher Bitnami's ARM support is very crucial to AWS Graviton/Oracle Cloud Ampere platform for ARM Kubernetes to function well. Right now I can't even source a working Postgres cluster image in ARM K8S and have to run in lone database mode, so please let us know if there is any assistance needed from the community
Thanks for the information @stevefan1999-personal, we are aware of the importance that ARM support has for certain scenarios and use cases, that's why we are working on this task. Unfortunately, the changes required should be done in our internal test & release pipeline and this is something not publicly available, thanks for your offer.
Due to we are a small team and we are also working on different projects, the bandwidth dedicated to this topic makes us advance more slowly but we are doing some progress and, for sure, it is also we have in mind and we are working on.
Thank you very much that you working on this topic, we are looking forward for kafka support for M1 Chips.
Do you already see any light in the end of the tunnel? Do you know by when we can use the arm images?
Thank you and kind regards
There is some progress in the internal tools we use to build, test and release the container images, but there is still some work to do. Unfortunately, I can't provide an ETA at this moment since it depends on other priorities.
Oh bad to hear. Hope it will come soon.
@carrodher is there any point for me to try and build the redis dockerfile for ARM? It seems that its using the minideb which has an ARM variant already.
Unfortunately, it's not an option at this moment. Although all the initialization logic is public in the container repositories and based on bash, the components are built using the above-mentioned tools (the ones we are modifying to support the new distro), and it is something that needs to be re-built with different modifications to support the new arch:
# Install required system packages and dependencies
RUN install_packages acl ca-certificates curl gzip libc6 libssl1.1 procps tar
RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "wait-for-port" "1.0.0-3" --checksum 7521d9a4f9e4e182bf32977e234026caa7b03759799868335bccb1edd8f8fd12
RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "redis" "6.2.6-1" --checksum 172caf7ebf69ba8105ec7f05150a7e341fdf117c9650cbcb9191919a523ada86
RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "gosu" "1.14.0-0" --checksum 3e6fc37ca073b10a73a804d39c2f0c028947a1a596382a4f8ebe43dfbaa3a25eAs you rightly said, minideb already supports ARM since it was one of the first pieces we worked on, but we need to continue working on other pieces/tools needed to build, test and release the containers.
I never realised how very few good templates are out there, because I was only using Bitnami charts. Trying to find alternatives to work with ARM64 images from the arm64v8 project shows how necessary it is to get Bitnami helm charts to work on ARM. Helm without Bitnami is a complete mess.
Some Helm charts support the use of non-bitnami images, I mean, you should be able to replace the image: block (registry, repository, tag, etc) to use another image based on ARM. Although this is not something tested nor supported out-of-the-box in all the charts, but you can give it a try in the meantime.
On our side, we understand the relevance of the issue and the wishes from the community, that's why we are actively working on it; but at this moment we can't spend more time per week than the one we are spending right now, that makes the process go slower than expected
@carrodher the main worry is that changing the image will spin up the service, but all chart configuration may not be used. Currently I am looking for etcd and keycloak (with postgres) to run on ARM64 K3S instance.
@carrodher the main worry is that changing the image will spin up the service, but all chart configuration may not be used. Currently I am looking for etcd and keycloak (with postgres) to run on ARM64 K3S instance.
Postgres Bitnami chart supports the official Postgres image at least partially.
After reading this thread, I am going to stop using bitnami images in all my projects, that's not the way the opensource world should be, you hide the sources and lots of staff under the cover and remove the opportunity for the community to help with migration and finally can't give estimate on anything.
Anyone who will end up with Bitnami images, be aware, this is not true opensource project
After reading this thread, I am going to stop using bitnami images in all my projects, that's not the way the opensource world should be, you hide the sources and lots of staff under the cover and remove the opportunity for the community to help with migration and finally can't give estimate on anything.
Anyone who will end up with Bitnami images, be aware, this is not true opensource project
Better start asking for that refund
I've given up using redis-cluster.
The quay.io/coreos/etcd image seems to be working quite well with Bitnami chart. It has tags for many architectures.
Related https://github.com/bitnami/bitnami-docker-etcd/issues/6
I'd love to see consul and postgresql ported to ARM64 so I can run it on my Raspberry Pi running Debian Bullseye aarch64.
After reading this thread, I am going to stop using bitnami images in all my projects, that's not the way the opensource world should be, you hide the sources and lots of staff under the cover and remove the opportunity for the community to help with migration and finally can't give estimate on anything.
Anyone who will end up with Bitnami images, be aware, this is not true opensource projectBetter start asking for that refund
this type of arrogant and condescending comments should not be allowed in any open source community.
Hi, as there are no arm64 images now, I want to build the etcd image by myself, could you tell me how Bitnami builds the below required packages from source?
12 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "yq" "4.16.2-0" --checksum 8200ea4477d139cb9be607a962760075e9240a760b56fb2f1f870a7facbf3e69
13 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "gosu" "1.14.0-0" --checksum 3e6fc37ca073b10a73a804d39c2f0c028947a1a596382a4f8ebe43dfbaa3a25e
14 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "etcd" "3.5.1-1" --checksum 424ad409fddf0b8bbb44fae42c1696bfe85ae147acbbbd0489fc75367feaf309
Hi, as there are no arm64 images now, I want to build the etcd image by myself, could you tell me how Bitnami builds the below required packages from source?
12 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "yq" "4.16.2-0" --checksum 8200ea4477d139cb9be607a962760075e9240a760b56fb2f1f870a7facbf3e69 13 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "gosu" "1.14.0-0" --checksum 3e6fc37ca073b10a73a804d39c2f0c028947a1a596382a4f8ebe43dfbaa3a25e 14 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "etcd" "3.5.1-1" --checksum 424ad409fddf0b8bbb44fae42c1696bfe85ae147acbbbd0489fc75367feaf309
Most likely answer is "It's not public".
Hi, as there are no arm64 images now, I want to build the etcd image by myself, could you tell me how Bitnami builds the below required packages from source?
12 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "yq" "4.16.2-0" --checksum 8200ea4477d139cb9be607a962760075e9240a760b56fb2f1f870a7facbf3e69 13 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "gosu" "1.14.0-0" --checksum 3e6fc37ca073b10a73a804d39c2f0c028947a1a596382a4f8ebe43dfbaa3a25e 14 RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "etcd" "3.5.1-1" --checksum 424ad409fddf0b8bbb44fae42c1696bfe85ae147acbbbd0489fc75367feaf309Most likely answer is "It's not public".
OK.
FYI
I share my built arm64 etcd image with upstream etcd release tar here.
Docker hub url: xin3liang/bitnami-etcd:3.5.1-debian-10-r67
The hacked patch is:
ubuntu@liuxl-focal:~/work/k8s/bitnami/bitnami-docker-etcd$ git diff
diff --git a/3/debian-10/Dockerfile b/3/debian-10/Dockerfile
index 9f52c26ac23e..125e3f09bf45 100644
--- a/3/debian-10/Dockerfile
+++ b/3/debian-10/Dockerfile
@@ -2,16 +2,18 @@ FROM docker.io/bitnami/minideb:buster
LABEL maintainer "Bitnami <containers@bitnami.com>"
ENV HOME="/" \
- OS_ARCH="amd64" \
+ OS_ARCH="arm64" \
OS_FLAVOUR="debian-10" \
OS_NAME="linux"
COPY prebuildfs /
# Install required system packages and dependencies
RUN install_packages acl ca-certificates curl gzip procps tar
-RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "yq" "4.16.2-0" --checksum 8200ea4477d139cb9be607a962760075e9240a760b56fb2f1f870a7facbf3e69
-RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "gosu" "1.14.0-0" --checksum 3e6fc37ca073b10a73a804d39c2f0c028947a1a596382a4f8ebe43dfbaa3a25e
-RUN . /opt/bitnami/scripts/libcomponent.sh && component_unpack "etcd" "3.5.1-1" --checksum 424ad409fddf0b8bbb44fae42c1696bfe85ae147acbbbd0489fc75367feaf309
+# Use upstream arm64 releases
+RUN mkdir -p /opt/bitnami/common/bin /opt/bitnami/etcd/bin
+RUN curl -SL https://github.com/mikefarah/yq/releases/download/v4.16.2/yq_linux_arm64 -o /opt/bitnami/common/bin/yq && chmod a+x /opt/bitnami/common/bin/yq
+RUN curl -SL https://github.com/tianon/gosu/releases/download/1.14/gosu-arm64 -o /opt/bitnami/common/bin/gosu && chmod a+x /opt/bitnami/common/bin/gosu
+RUN curl -SL https://github.com/etcd-io/etcd/releases/download/v3.5.1/etcd-v3.5.1-linux-arm64.tar.gz | tar --strip-components=1 -xzC /opt/bitnami/etcd/bin
RUN chmod g+rwX /opt/bitnami
COPY rootfs /
Hi,
Thank you so much for the temporary workaround! As soon as there are news on this, we will update the ticket.
After reading this thread, I am going to stop using bitnami images in all my projects, that's not the way the opensource world should be, you hide the sources and lots of staff under the cover and remove the opportunity for the community to help with migration and finally can't give estimate on anything.
Anyone who will end up with Bitnami images, be aware, this is not true opensource projectBetter start asking for that refund
I don't agree. It's fair for the community to be upset with a kind-of monopoly in Kubernetes operators for open source apps to have a closed source build manifests.
Obviously, your not paying for the product, and of course you can adapt the manifests to use other images, but that's just real open source workarounds for a problem in closed source software. A good analogy is userChrome.css in Firefox community.
The truth is that most production ready operator are open source but uses bitnami images. This is a mixed approach in the ownership of the code running in the cluster, and at the end, is getting the transition to arm64 cloud and home computing delayed. Don't forget why GNU licence was made: Community's interest is stronger than Big Companies Horsepower.
Your comment is truly toxic. Your just being satiric over others comment without analyzing their arguments. Shame of you.
@fdelucchijr IMHO I will not argue with you, my comment was very direct at that time. I am not willing to use such "closed-open source software". Giving feedback is good for any kind of business, project, etc... even if it's bad feedback. This small issue could become even worse next time when you or your project will not meet such roadmap, goals, priorities of Bitnami team, and you will be in a very bad situation trying to migrate all your images to smth.
Hi, is there a status update on kafka Macbook M1(ARM) support?
Arggg, just got bit by this trying to use the PostgreSQL chart.
pi@kube-master: $ kubectl logs postgresql-postgresql-0
standard_init_linux.go:228: exec user process caused: exec format errorI was able to build both arm64 and amd64 Docker containers for other projects using the experimental Docker feature Buildx. It runs multiple builds in parallel and uses a container manifest file to list all the different architectures. After configuring buildx:
docker buildx create --useThe Docker build command just needs to be updated to:
docker buildx build --platform linux/amd64,linux/arm64 -t <tag-here> --push ...See the following blog post on using buildx https://blog.jaimyn.dev/how-to-build-multi-architecture-docker-images-on-an-m1-mac/.
I am trying to build the Linux ARM64 Bitnami docker image for mysql. I dont seem to find the corresponding tar gz file from bitnami URL https://downloads.bitnami.com/files/stacksmith.
Please help me with the instructions on how to add the corresponding tar gz file here and build arm images.
How about this way? I referenced Bitnami's recipe and made a small project that replaces downloading the stacksmith binary. It can be replaced with Docker, apt, or go build.
https://github.com/zcube/bitnami-compat
I created some samples. for
- bitnami/bitnami-shell
- bitnami/mariadb
- bitnami/rabbitmq
- bitnami/minio
- bitnami/minio-client
- bitnami/consul
- bitnami/postgresql
- bitnami/consul-exporter
- bitnami/mysqld-exporter
- bitnami/etcd
- bitnami/cert-manager
- bitnami/acmesolver
- bitnami/cert-manager-webhook
- bitnami/cainjector
- bitnami/redis
- bitnami/redis-sentinel
- bitnami/redis-exporter
- bitnami/redis-cluster
- bitnami/tomcat
- bitnami/elasticsearch
@ZCube wow, thanks for your repo https://github.com/zcube/bitnami-compat. Curious, how did you manage to do this? Just invoking using buildx and docker buildx build --platform linux/amd64,linux/arm64 -t <tag-here> --push ...
Modified my PostgreSQL values file to:
image:
registry: ghcr.io # required for arm64
repository: zcube/bitnami-compat/postgresql # required for arm64
tag: 13.5.0-debian-10
@ZCube wow, thanks for your repo https://github.com/zcube/bitnami-compat. Curious, how did you manage to do this? Just invoking using
buildxanddocker buildx build --platform linux/amd64,linux/arm64 -t <tag-here> --push ...Modified my PostgreSQL values file to:
image: registry: ghcr.io # required for arm64 repository: zcube/bitnami-compat/postgresql # required for arm64 tag: 13.5.0-debian-10
I use github actions.
- name: Build and push Docker image
uses: docker/build-push-action@v2
with:
context: bitnami-docker-${{ matrix.APP }}/${{ matrix.VERSION_MAJOR }}/${{ matrix.OS_FLAVOUR }}
push: true
tags: ${{ steps.meta.outputs.tags }}
cache-from: type=registry,ref=${{ env.REGISTRY }}/${{ steps.repository.outputs.lowercase }}/cache/${{ matrix.APP }}:${{ matrix.VERSION }}
cache-to: type=registry,ref=${{ env.REGISTRY }}/${{ steps.repository.outputs.lowercase }}/cache/${{ matrix.APP }}:${{ matrix.VERSION }}
labels: ${{ steps.meta.outputs.labels }}
platforms: linux/amd64,linux/arm64
How about this way? I referenced Bitnami's recipe and made a small project that replaces downloading the stacksmith binary. It can be replaced with Docker, apt, or go build.
https://github.com/zcube/bitnami-compat
I created some samples. for
- bitnami/bitnami-shell
- bitnami/mariadb
- bitnami/rabbitmq
- bitnami/minio
- bitnami/minio-client
- bitnami/consul
- bitnami/postgresql
- bitnami/consul-exporter
- bitnami/mysqld-exporter
- bitnami/etcd
- bitnami/cert-manager
- bitnami/acmesolver
- bitnami/cert-manager-webhook
- bitnami/cainjector
- bitnami/redis
- bitnami/redis-sentinel
- bitnami/redis-exporter
- bitnami/redis-cluster
- bitnami/tomcat
- bitnami/elasticsearch
I've removed my comments as the above is superior. Can we also have keycloak? :)
How about this way? I referenced Bitnami's recipe and made a small project that replaces downloading the stacksmith binary. It can be replaced with Docker, apt, or go build.
https://github.com/zcube/bitnami-compat
I created some samples. for
- bitnami/bitnami-shell
- bitnami/mariadb
- bitnami/rabbitmq
- bitnami/minio
- bitnami/minio-client
- bitnami/consul
- bitnami/postgresql
- bitnami/consul-exporter
- bitnami/mysqld-exporter
- bitnami/etcd
- bitnami/cert-manager
- bitnami/acmesolver
- bitnami/cert-manager-webhook
- bitnami/cainjector
- bitnami/redis
- bitnami/redis-sentinel
- bitnami/redis-exporter
- bitnami/redis-cluster
- bitnami/tomcat
- bitnami/elasticsearch
I've removed my comments as the above is superior. Can we also have keycloak? :)
@turowicz Added to build docker image with keycloak binary, but I can't test it. Because I don't know about that package :)
@ZCube Could you please allow the issues on your repo so that we don't pollute this thread with new image requests :)?
@ZCube Could you please allow the issues on your repo so that we don't pollute this thread with new image requests :)?
OK
bitnami/elasticsearch
@ZCube, thanks for the efforts! Do I understand it correctly that you're not using Bitnami`s setup at all here: https://github.com/ZCube/bitnami-compat/blob/main/docker/elasticsearch/7.16.3-4/Dockerfile.install ?
This isn't the goal of not using Bitnami's setup. It is to replace the binary installation method to make Bitnami's chart work on ARM64. Reference : https://www.elastic.co/guide/en/elasticsearch/reference/current/targz.html
Okay, thanks. The side effect seems to be the loss of Bitnami's envvars setup for Elasticsearch.
@tormi It supports some environment variables, but the contents of the repository are not the subject of this issue. I do not want to pollute this thread. If you have any questions, ask them as an issue in the repository.
I'm also working on armhf support here: https://github.com/RedstoneWizard08/minideb
I compiled the speech + postgres + redis for ARM64, but I didn't succeed in connecting the bank to the speech, it probably needs more things to change. Has anyone come to test the speech for ARM64? I have some servers at Oracle on ARM64 and I would like to run your Docker Image Speech there, but it's complicated, I've been trying for two days, could anyone help me?
I have access to ARM based system, how can I contribute to the project for supporting ARM based images?
We have the same problem like @anuragagarwal561994 . How can we contribute bitnami to support ARM. Is there any sample ?
Any updates on redis-cluster m1 support?
Hi,
I'm afraid it is still in our backlog. We've done some feasibility studies but I still cannot provide a date on when this will be available.
What do you think are the issues and how can the community help?
Would absolutely โค๏ธ arm64 containers / helm chart support for the following:
- postgresql
- memcached
For example, a project I am trying to deploy Gitea uses Bitnami for PostgreSQL and Memcached dependencies, but I cannot run it because running on a Raspberry Pi (arm64) Kubernetes cluster.
@nodesocket you could give ZCube/bitnami-compat a spin ref #7305 (comment)
@ddelange from a security standpoint, not sure we can in good faith use the ZCube builds unfortunately. We need a trusted source of truth.
Just to double-check: are we blocked here because ARM64 build agents are not available (e.g. paid for)? Or are we blocked because there's potentially non-trivial work to adopt ARM64 build agents?
You don't need special build agents. E.g. https://github.com/t1/rdohna-wildfly-docker-image builds just fine on standard GitHub build infrastructure, both arm and amd.
Just to double-check: are we blocked here because ARM64 build agents are not available (e.g. paid for)? Or are we blocked because there's potentially non-trivial work to adopt ARM64 build agents?
I think the bottleneck is not so much the computational resources but rather the human resources to get this done in the internal Jenkins pipeline (#7305 (comment) and #7305 (comment)). If I understand correctly, in the end the ETA will come down to the priorities in the Tanzu roadmap (#7305 (comment)), as it is not something the open source community can support with.
Is there a tracker anywhere marking which images are already supporting arm64 and which ones aren't? It would be really nice to follow the progress over time here.
It's not progressive work, if finally arm64 is supported, all the container images will be available at the same time, no little by little. Technically, the key point is the underlying test & release infrastructure, not the images themselves.
Also already added support, or is there still prediction for arm64 for postgresql-ha?, in addition to raspberry pi 4, we also have a complete cluster in oracle with this "Ampere A1" architecture with OCPU ARM, it would be amazing to be able to run the kubernetes cluster too!
Technically, the key point is the underlying test & release infrastructure, not the images themselves.
@carrodher Is there anything we at https://nhost.io could help with to make this faster? We are currently evaluating moving all our databases to k8s and the bitnami postgres chart covers all our requirements. We are talking about a considerable deployment of the chart for 2k+ databases.
Any update on this work? We like using bitnami upstream, but without arm-64 image support we need to start looking elsewhere.
Hello, can we have this issue prioritized? A lot of our containers uses bitnami images...
any news on this issue? some images are running fine with arm64 now.
@joaquinjsb do you know which images are running for you? looks like latest is failing, but it was working for me last week on M1
When could you make it possible to support aws arm? m waiting for
This:
It's not progressive work, if finally arm64 is supported, all the container images will be available at the same time, no little by little. Technically, the key point is the underlying test & release infrastructure, not the images themselves.
and this:
any news on this issue? some images are running fine with arm64 now.
are contradictory.
Do we have some non-official support for native ARM on some images already? If so, how can we track which ones are ready?
Do we have some non-official support for native ARM on some images already? If so, how can we track which ones are ready?
from higher up in this thread: https://github.com/ZCube/bitnami-compat
"These images are NOT intended for production use."
Is this means that I can not use these charts if I am on a macbook pro m1 max?
Is there any progress on OpenLDAP image for ARM64?
Is this means that I can not use these charts if I am on a macbook pro m1 max?
MacOS supports running them in x64 emulation generally, but e.g. raspberry pis won't work
Is it possible to make a pull request out of this?
Or bitnami is not interested into support the arm64 architecture?
Hi @Jonatthu,
I'm afraid it's a hack that replaces binaries that are built by internal bitnami pipelines with ones available via official channels like apt-get (which are generally built for multiple cpu architectures, whereas bitnami pipelines currently only build x86).
See also my earlier comment #7305 (comment)
@ddelange Is there any workaround to run these images on MacOs m1 pro max with rosseta? After all usually when we deploy these charts they go to an EKS or AKS cluster running in Linux or Windows
I just want to be able to test these charts locally.
Can bitnami helm charts be scheduled to be on kubernetes.io/arch: amd64 in the meantime? It's always annoying to run into random issues only for it to boil down to exec format error
[root@office-server-1 ~]# kubectl get pods -n kubeapps -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
apprepo-kubeapps-cleanup-bitnami-dzzgt-7slgs 0/1 Error 0 96s 10.0.3.1 pinewall-2 <none> <none>
apprepo-kubeapps-cleanup-bitnami-dzzgt-gn6pn 0/1 Error 0 4m30s 10.0.4.70 pinewall-1 <none> <none>
apprepo-kubeapps-cleanup-bitnami-dzzgt-lsfrx 0/1 Error 0 4m14s 10.0.4.95 pinewall-1 <none> <none>
apprepo-kubeapps-cleanup-bitnami-dzzgt-qlrhr 0/1 Error 0 3m49s 10.0.4.234 pinewall-1 <none> <none>
apprepo-kubeapps-cleanup-bitnami-dzzgt-v97xv 0/1 Error 0 3m2s 10.0.9.37 pinewall-4 <none> <none>
apprepo-kubeapps-cleanup-bitnami-dzzgt-zntgw 0/1 Error 0 4m36s 10.0.4.153 pinewall-1 <none> <none>
apprepo-kubeapps-sync-mcsh-27671740-zndtx 0/1 CrashLoopBackOff 5 (2m13s ago) 5m14s 10.0.7.26 pinewall-3 <none> <none>
apprepo-kubeapps-sync-mcsh-79kzv-5krb2 0/1 CrashLoopBackOff 5 (87s ago) 4m22s 10.0.4.188 pinewall-1 <none> <none>
apprepo-kubeapps-sync-mcsh-7jrgz-6jj5z 0/1 CrashLoopBackOff 5 (30s ago) 3m27s 10.0.7.212 pinewall-3 <none> <none>
apprepo-kubeapps-sync-mcsh-9qvvz-f7jrj 0/1 CrashLoopBackOff 4 (58s ago) 2m34s 10.0.7.234 pinewall-3 <none> <none>
apprepo-kubeapps-sync-mcsh-gsrm4-wxmbx 0/1 CrashLoopBackOff 4 (57s ago) 2m41s 10.0.9.110 pinewall-4 <none> <none>
apprepo-kubeapps-sync-mcsh-jht9h-449vl 0/1 CrashLoopBackOff 5 (2m2s ago) 5m2s 10.0.3.81 pinewall-2 <none> <none>
apprepo-kubeapps-sync-mcsh-k878h-hxbmf 0/1 Error 5 (89s ago) 3m6s 10.0.3.243 pinewall-2 <none> <none>
apprepo-kubeapps-sync-mcsh-mb4vq-22khd 0/1 CrashLoopBackOff 5 (115s ago) 5m7s 10.0.9.35 pinewall-4 <none> <none>
apprepo-kubeapps-sync-mcsh-nhshj-ztp77 0/1 CrashLoopBackOff 5 (78s ago) 4m33s 10.0.9.122 pinewall-4 <none> <none>
apprepo-kubeapps-sync-mcsh-qqzwj-8wnh2 0/1 CrashLoopBackOff 4 (63s ago) 2m45s 10.0.4.155 pinewall-1 <none> <none>
apprepo-kubeapps-sync-mcsh-vp7wj-khl22 0/1 Error 5 (95s ago) 3m8s 10.0.4.22 pinewall-1 <none> <none>
kubeapps-56fdc4565d-5gtzl 2/2 Running 19 (3d10h ago) 29d 10.0.0.227 office-server-1 <none> <none>
kubeapps-56fdc4565d-w25dr 2/2 Running 20 (3d10h ago) 29d 10.0.0.42 office-server-1 <none> <none>
kubeapps-internal-apprepository-controller-6f96498df7-97tcg 1/1 Running 3 29d 10.0.0.180 office-server-1 <none> <none>
kubeapps-internal-dashboard-55694d5b9d-5tnk9 1/1 Running 3 29d 10.0.0.123 office-server-1 <none> <none>
kubeapps-internal-dashboard-55694d5b9d-p4j8z 1/1 Running 3 29d 10.0.0.250 office-server-1 <none> <none>
kubeapps-internal-kubeappsapis-6c6c54976f-fdskd 1/1 Running 3 29d 10.0.0.126 office-server-1 <none> <none>
kubeapps-internal-kubeappsapis-6c6c54976f-rzdzz 1/1 Running 3 29d 10.0.0.172 office-server-1 <none> <none>
kubeapps-internal-kubeops-77ddc5fddc-ct5sn 1/1 Running 3 29d 10.0.0.232 office-server-1 <none> <none>
kubeapps-internal-kubeops-77ddc5fddc-k8lzf 1/1 Running 3 29d 10.0.0.52 office-server-1 <none> <none>
kubeapps-postgresql-0 1/1 Running 3 29d 10.0.0.114 office-server-1 <none> <none>
Can bitnami helm charts be scheduled to be on
kubernetes.io/arch: amd64
It's not zero work but it looks like most of the charts accept nodeAffinity somewhere in their values. If you're running a mixed cluster that might be the best option for now.
We taint our arm64 instances so we can set the toleration on our own charts for services that can be deployed there. This way the "default" is amd64, which is backward compatible with Bitnami and other third party charts.
I found this a useful read on multi-arch clusters: https://cablespaghetti.dev/2021/02/20/managing-multi-arch-kubernetes-clusters/#taints-and-tolerations
Why is this on hold?
Hi! Is Solr going to have support for ARM64 too? Can you guys share what workaround (if there's any) could we execute to update the current image and use it with ARM64? Thanks in advance!
When I use docker.io/bitnami/minideb:buster to make a docker image on arm64 architecture, it prompts "E: The repository 'http://security.debian.org buster/updates InRelease' is not signed." Is there any way to solve it?
Soo...this issue has it's first birthday a few weeks ago, what's the plan here?
Soo...this issue has it's first birthday a few weeks ago, what's the plan here?
I found a workaround (specifically for Lando, but the Docker containers referenced should work on standard Docker, too) that I published here: lando/lando#2688 (comment) I hope it helps someone else out there! -- Good luck, M1 frens
Hi @carrodher
Is there any plan, roadmap for this topic?
To be honest, it feels a little bit like you not really care. The most important apps has already ARM images, but bitnami can't deliver.
Would be nice that you are give us at least some plan.
Thanks
mysql, redis and redis-cluster to support arm64