Support for ARM64 architecture in Bitnami container images #7305

carrodher · 2021-08-24T15:51:22Z

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)

The text was updated successfully, but these errors were encountered:

samip5 · 2021-08-26T12:06:40Z

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)

carrodher · 2021-08-26T14:48:56Z

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   176MB

samip5 · 2021-08-26T14:59:06Z

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   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?

carrodher · 2021-08-26T20:42:06Z

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   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?

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.

samip5 · 2021-08-26T21:47:34Z

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   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?
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.

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?

carrodher · 2021-08-27T15:41:14Z

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   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?
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.
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.

samip5 · 2021-08-27T19:46:00Z

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-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.

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?

carrodher · 2021-08-30T13:33:37Z

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-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.

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.

samip5 · 2021-08-30T15:05:26Z

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-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.

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.

anthr76 · 2021-08-31T00:08:41Z

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?

adm271828 · 2021-08-31T12:53:04Z

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.

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.

balusarakesh · 2021-09-13T14:40:02Z

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

samip5 · 2021-09-13T18:33:00Z

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.

adm271828 · 2021-09-14T22:22:16Z

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.

julweber · 2021-09-20T14:24:51Z

+1 It would be so great to be able to use the bitnami helm charts on my raspberry pi

turowicz · 2021-10-13T12:17:02Z

@carrodher is anything planned for this?

carrodher · 2021-10-13T12:30:35Z

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

blowfishpro · 2023-05-09T19:50:09Z

all attempts at emulating them via Rosetta or setting the platform in the docker-compose are failing

This is sort of a tangent but is there something specific that prevents those images from being run under virtualization? I've been able to run other amd64 images on my ARM mac.

eddywashere · 2023-05-11T20:56:46Z

Hi all, we are more than happy to announce that from now on the Bitnami container catalog is available as multi-arch in Docker Hub 🎉 🎉

This means you don’t need to specify anything when pulling the container images from Docker Hub, Docker (or any other software) will automatically pull the container image matching the host platform from which the pull command was issued.

Here you can find more info about this announcement.

As usual, please create a new GitHub issue if you would like to report any bug or problem or directly contribute by creating a PR. Here you can find the contributing guidelines.

Please note, at this very moment the following container images are not available as multi-arch due to different technical issues:

airflow (airflow-scheduler, airflow-worker)

cassandra

concourse

discourse

kong

mastodon

mongodb

mxnet

percona-mysql

rails

redmine

sonarqube

supabase (postgrest, supabase-postgres-meta, supabase-postgres, supabase-realtime, supabase-storage)

Any news on supporting discourse arm image? or where can I track that?

carrodher · 2023-05-12T07:44:29Z

Any news on supporting discourse arm image? or where can I track that?

At this moment there are no plans to work on the pending assets since ARM support was recently added and it is very likely that the issues we faced in the past are still present. We will revisit the list of exceptions in the future and we will update this issue.

bwmills · 2023-08-07T18:52:20Z

Thanks everyone, we are definitely interested in running mongodb on arm64 on AWS storage optimized instances in EKS.

This PR adds a Helm chart for MongoDB, supporting both standalone mode and sharded cluster mode. Shard rules, including shard keys, shard methods, and unique constraints, are defined and managed in the values.yaml. This chart depends on Bitnami's mongodb-sharded chart (https://github.com/bitnami/charts/tree/main/bitnami/mongodb-sharded). There are a few known issues with it: A problem with livenessProbe and readinessProbe - Issues: bitnami/charts#21957 - Solution: use custom livenessProbe and readinessProbe instead Lack of ARM64 support in the Bitnami mongodb-sharded container - Issues: - bitnami/charts#7305 (comment) - bitnami/containers#40947 - Solution: use the official Mongo 6.0 image instead and set up the cluster via a Job. --------- Co-authored-by: Youngteac Hong <[email protected]>

carrodher pinned this issue Aug 24, 2021

carrodher added the on-hold Issues or Pull Requests with this label will never be considered stale label Aug 26, 2021

ppbaena mentioned this issue Sep 14, 2021

Support ARM/multi-arch images for Kubeapps containers vmware-tanzu/kubeapps#929

Closed

artursouza mentioned this issue Sep 14, 2021

Missing instructions for setting up Redis on ARM64 K8s dapr/docs#1207

Open

github-actions bot added the solved label May 12, 2023

ricsanfre mentioned this issue May 13, 2023

Update Velero installation documentation ricsanfre/pi-cluster#128

Closed

carrodher unpinned this issue May 31, 2023

roeniss mentioned this issue Jul 9, 2023

Lab 2 sidenote for M1 users MichaelCade/KubeCon2023_EU#2

Open

debdutdeb mentioned this issue Jul 14, 2023

[bitnami/mongodb] Mongodb doesn't run on M1 Mac bitnami/containers#40947

Open

github-actions bot removed the solved label Aug 7, 2023

carrodher removed the triage Triage is needed label Aug 8, 2023

github-actions bot added the solved label Aug 8, 2023

FernandoMiguel mentioned this issue Aug 28, 2023

Included redis-exporter doesn't support arm64 arch argoproj/argo-helm#2233

Closed

Jasstkn mentioned this issue Oct 23, 2023

chore: update readme litmuschaos/litmus-helm#344

Merged

3 tasks

exfly mentioned this issue Nov 3, 2023

[bitnami/postgresql-repmgr] How to make a temporary patched postgres image to bitnami/postgres image bitnami/containers#52319

Closed

sejongk mentioned this issue Jan 19, 2024

Add Helm chart for MongoDB sharded cluster yorkie-team/yorkie#769

Merged

4 tasks

MauroSoli mentioned this issue Jan 30, 2024

Support for ARM64 architecture in Bitnami container images on Amazon ECR Public Gallery #22932

Closed

joebowbeer mentioned this issue Jul 21, 2024

Tutorials in Linux ARM64 k8s fail dapr/quickstarts#739

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for ARM64 architecture in Bitnami container images #7305

Support for ARM64 architecture in Bitnami container images #7305

carrodher commented Aug 24, 2021 •

edited

Loading

samip5 commented Aug 26, 2021 •

edited

Loading

carrodher commented Aug 26, 2021

samip5 commented Aug 26, 2021 •

edited

Loading

carrodher commented Aug 26, 2021

samip5 commented Aug 26, 2021

carrodher commented Aug 27, 2021

samip5 commented Aug 27, 2021 •

edited

Loading

carrodher commented Aug 30, 2021

samip5 commented Aug 30, 2021 •

edited

Loading

anthr76 commented Aug 31, 2021

adm271828 commented Aug 31, 2021 •

edited

Loading

balusarakesh commented Sep 13, 2021 •

edited

Loading

samip5 commented Sep 13, 2021

adm271828 commented Sep 14, 2021

julweber commented Sep 20, 2021

turowicz commented Oct 13, 2021

carrodher commented Oct 13, 2021

blowfishpro commented May 9, 2023

eddywashere commented May 11, 2023

carrodher commented May 12, 2023

bwmills commented Aug 7, 2023

Support for ARM64 architecture in Bitnami container images #7305

Support for ARM64 architecture in Bitnami container images #7305

Comments

carrodher commented Aug 24, 2021 • edited Loading

samip5 commented Aug 26, 2021 • edited Loading

carrodher commented Aug 26, 2021

samip5 commented Aug 26, 2021 • edited Loading

carrodher commented Aug 26, 2021

samip5 commented Aug 26, 2021

carrodher commented Aug 27, 2021

samip5 commented Aug 27, 2021 • edited Loading

carrodher commented Aug 30, 2021

samip5 commented Aug 30, 2021 • edited Loading

anthr76 commented Aug 31, 2021

adm271828 commented Aug 31, 2021 • edited Loading

balusarakesh commented Sep 13, 2021 • edited Loading

samip5 commented Sep 13, 2021

adm271828 commented Sep 14, 2021

julweber commented Sep 20, 2021

turowicz commented Oct 13, 2021

carrodher commented Oct 13, 2021

blowfishpro commented May 9, 2023

eddywashere commented May 11, 2023

carrodher commented May 12, 2023

bwmills commented Aug 7, 2023

carrodher commented Aug 24, 2021 •

edited

Loading

samip5 commented Aug 26, 2021 •

edited

Loading

samip5 commented Aug 26, 2021 •

edited

Loading

samip5 commented Aug 27, 2021 •

edited

Loading

samip5 commented Aug 30, 2021 •

edited

Loading

adm271828 commented Aug 31, 2021 •

edited

Loading

balusarakesh commented Sep 13, 2021 •

edited

Loading