search

jacobalberty / firebird-docker

Firebird Dockerfile
130 stars 96 forks source link

Minideb #13

Closed fdcastel closed 2 years ago

fdcastel commented 7 years ago

Hi Jacob!

The nice guys @Bitnami made a very interesting image which they are using for all their Docker images. It is a very battle-tested solution.

You can read more about it here and here.

TL;DR:

The minideb image currently weighs in at around 50MB uncompressed. For comparison the debian library image is 123MB, the alpine image is 5MB, and the newly released amazonlinux image is 328MB.

While minideb is much larger than alpine it is a lot smaller than the standard debian image while retaining most of the compatibility.

Do you think this could be used instead of current debian:jessie image?

Please note that, contrary to what I suggested in #10, I'm not asking you to maintain a new image. I know alpine is stretching the limits and it is reasonable to keep a different fork (like many other projects do). But I believe this is not the case here.

jacobalberty commented 7 years ago

I haven't had a chance to even try building under minideb yet, i see no reason it shouldn't just be a quick swap to get it up and running though. Just fyi alpine builds and works I just am explicitly blocking it from being tagged on the hub. I'm trying to get the alpine image actually turned into packages for alpine base instead of being a whole docker image.

When things slow down at work I'll take a look at minideb.

jacobalberty commented 7 years ago

Took me way longer than I intended to look at this. Just to compare a few file sizes for options on slimming down the image. for comparison jacobalberty/firebird:3.0 is 184MB

minideb:jessie is 113MB minideb:stretch is 114mb jessie-slim is 139MB and finally... stretch-slim is 115MB

I'm tempted to try and just move to stretch-slim, its only 2MB bigger than the minideb:jessie and as long as docker and debian are around they're going to keep the debian images updated... Of course the problem with stretch is jessie uses libicu52 while stretch uses libicu57, which means indexes would be broken without either a backup and restore, or an index rebuild, so either way is messy.

mariuz commented 2 years ago

I guess this can be closed , i see that debian:bullseye-slim is used to build the images , so i guess that fixes the size issue :)

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 14 days.