Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Bitnami ARM containers available at Docker Hub (bitnami.com)
91 points by jacooper on Feb 24, 2023 | hide | past | favorite | 25 comments


I can't comment on ARM because all of my workloads are x86, but the Bitnami containers are almost always a good bet: https://bitnami.com/stacks/containers

Currently I build all of my language runtime containers myself (such as Java, Python, .NET, Node and so on) for the sake of simplicity and common tools, but when I'm dealing with something more complex to configure or turnkey software (think along the lines of Keycloak, MinIO, RabbitMQ, Redis, as well as databases like MariaDB or PostgreSQL), then I often just go with what Bitnami is offering. Here's their GitHub with a bit more information about why someone might use their images: https://github.com/bitnami/containers

Of course, do have a look at their instructions, because in the case of some of their images there can be some differences from the alternatives, for example: https://blog.kronis.dev/everything%20is%20broken/bitnami-mar... (title is tongue in cheek, but in short, the official MariaDB image uses "/var/lib/mysql" and Bitnami MariaDB image uses "/bitnami/mariadb" for persistence; that tripped me up because I glanced over it, as the environment variables were the same)


On the serve side, AWS Graviton3 and Ampere Altera are pushing server workloads to optimize for ARM.

On the consumer side, Apple Silicon is pushing the industry to optimize for ARM.

I think we will see a ton of companies switch to ARM workloads in the server as soon as this year. I can see AWS Graviton3 taking over 80% of all new EC2 instances. Graviton2 already took over 50% of all new EC2 instances in the year 2020. [0]

[0] https://www.anandtech.com/show/16640/arm-announces-neoverse-...


> I can see AWS Graviton3 taking over 80% of all new EC2 instances. Graviton2 already took over 50% of all new EC2 instances in the year 2020.

Speaking of this. Friendly reminder that AWS currently has a free trial[0] of 750 hours/month free for t4g.small EC2 instances, until the end of the year.

You'd still need to pay for storage, but it's a good deal if you want to use it as DNS or WireGuard server for the remaining of 2023, since 1GB storage is enough for Alpine Linux.

[0]: https://aws.amazon.com/ec2/instance-types/t4/


> On the serve side, AWS Graviton3 and Ampere Altera are pushing server workloads to optimize for ARM.

My hope is that eventually we'll get something as affordable as Scaleway's old ARM offerings in budget cloud providers (e.g. Hetzner, Scaleway, maybe Vultr and DigitalOcean etc.). Ideally, I'd get an ARM VPS for a few euros a month with 4 GB of RAM or something to that order and would be able to host whatever I need on those for cheaper than the x86 equivalents. Going from something like 5 Euros/month per node to 3 Euros/month doesn't seem like a big change, but it adds up, especially when your workloads would be well served by multiple separate low performance nodes.

Of course, that'd be nice if I could easily build and test ARM container images or something to that tune from my x86 development machine, given that I already have the hardware and I doubt I'll personally be able to switch to ARM on the desktop/homelab CI nodes anytime soon. But hey, that's an inconvenience at worst, because you can still build things "in the cloud" from the source as well, provided that there aren't many ARM specific bugs, debugging which would be hard.


I have this impression of vmware that they’re more focused on enterprise sales relationships than tech, a la Salesforce, Oracle, et al. I use Fusion to run VMs on macOS but that’s a toy, I wouldn’t build critical infrastructure on their tools. Just a feeling, but my intuition is based on a lot of experience.


Look what happened to the Bitnami Kubernetes Production Runtime.

Maintenance stalled for months until eventually they officially stopped development. No warning, and all repo activity indicated the next release was underway. Then it just kinda fizzled out…


That's because Bitnami is useful for VMware for their image catalog (what this post is about) and not for their forays into k8s land. It took me some serious convincing to keep sealed-secrets from being abandoned too (I'm the former sealed-secrets maintainer).

I'm happy to see that my former colleagues are still doing a great job with the images!


It was interesting building out this rendition of my homelab with ESXi. I’m doing it because my company uses VMware tools but throughout the whole process it felt, like you said, this is about “enterprise relationships” not tech - and it’s really good tech!


I remember first using Bitnami in 2015- such a great resource. Although now everything in VMWare land is extremely enterprise/data-center-y its nice that they still ship stuff like this to hobbyists in the public.


Excellent news!

Our team has been having to run older x86 Macs for a number of years just so that we can continue running certain images that are not available for arm64.


—-platform linux/amd64 and similar arguments didn’t work?


My first thought too. Especially in Docker for Mac the amd64 containers mostly just work.


Not with native-code performance, though.


Surprisingly close. I’ve had plenty of intel apps run faster on an M1 Mac than a recent intel MacBook.


amd64 Docker containers on arm64 run under much slower QEMU emulation, not fast Rosetta.



Oh wow, that's very exciting for me! It's been probably my biggest pain point about Apple Silicon


colima + Rosetta2 is also a thing now that more or less makes x86-64 containers a complete non-issue


Is it known which exact ARM processors Bitnami is using? A current project of mine targets the ARM TEE which is only available since ARMv9.


As I understand it, Bitnami produces their own containerized distributions of things like Postgres, pgbouncer, etc. ARM support just means that they are now pushing images compiled for ARM (probably lowest common denominator aarch64) in addition to their x86_64 images. This means that if you run these things on docker or k8s on your Apple Silicon, you no longer have to rely on binfmt_misc emulation.

This is all somewhat amusing to me because we moved away from distributing Bitnami images because they didn't have arm64 support.

Side tip. If you use Linux, you can setup qemu to emulate binaries from non-native architectures: https://wiki.debian.org/QemuUserEmulation. I did this on my workstation and I can run pretty much any Linux binary that comes my way. Very convenient in this new multi-arch world. (Yes it's pretty slow, but it's nice if you're building ARM binaries to be able to test that they at least start up OK. binfmt_misc works great for that!)


IIRC Docker with the whole binfmt_misc and qemu schmuck only supports building v8 images.


What is "qemu schmuck" here?


qemu can do userspace emulation, so you can run an aarch64 binary transparently on x86_64, as long as you have all the right libraries installed. You can also drop a Raspberry Pi image onto your computer, copy qemu-user-static into the image, chroot into it, and you've got a Raspberry Pi commandline without any physical Raspberry Pi. It's honestly pretty amazing.

https://wiki.debian.org/QemuUserEmulation

https://wiki.debian.org/RaspberryPi/qemu-user-static


BuildX supports ArmV7


Great. I was defnitely missing this




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: