[QUESTION] Size mb docker frankenphp

[MakFly]

I don't understand why when building the frankenphp docker in prod weighs as much as an alpine custom docker php image.
How come it weighs around 700-800 mb :o? even empty?

FROM dunglas/frankenphp

# Disable https
ENV SERVER_NAME=:80

# add additional extensions here:
RUN install-php-extensions \
    @composer \
	pdo_mysql \
    pdo_pgsql \
	gd \
	intl \
	zip \
    bcmath \
    xdebug
    # opcache # disable for local development

# WORKDIR /app

# Install git
RUN apt-get update && apt-get install -y git

RUN apt-get install -y libnss3-tools

# Install symfony cli
RUN curl -1sLf 'https://dl.cloudsmith.io/public/symfony/stable/setup.deb.sh' | bash
RUN apt-get update && apt-get install -y symfony-cli

# Copy the new Caddyfile to the container
COPY ./docker/Caddyfile /etc/caddy/Caddyfile

# Install composer
# RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
ENV COMPOSER_ALLOW_SUPERUSER=1

# Copy the current directory contents into the container at /app
COPY . /app

RUN composer install

RUN echo "END 🐘🐳🐧🚀"

[AlliBalliBaba]

Most of the size from the frankenphp docker image comes from the php bookworm image it is based on (~175 MB -> ~190MB compressed). There is also a much smaller alpine version of frankenphp (~70 MB compressed), which sadly is not recommended at the moment though.

In many cases the extra size of the operating system doesn't matter much tough, maybe it makes pulling and deploying the image a few seconds faster. I usually prefer alpine because it's minimalism makes it often safer from a security perspective.

[withinboredom]

I realize you ask "how come" but do you have a usecase for a smaller image? I see questions like this ever since Docker came out, but I can count with less than one hand where I've heard reasons that actually make sense.

1. Deployment speed at-scale -- such as deploying to thousands of nodes.
2. Low storage environments -- such as embedded devices, though why you'd be running PHP on them is anyone's guess.
3. Low bandwidth environments -- such as crappy wifi in an airport and you just want to run some code.

If you can add to this list, let me know.

Alpine has a lot of issues, such as DNS just up and randomly failing to work correctly and depending on which PHP function you are using it will depend on how it does DNS in the OS, which means it in one line everything is fine, but will fail on the next line (literally why we switched from Alpine in prod at work, a few months ago, after it happened on several production instances and caused a cascading failure). And then there's the fact that PHP doesn't actually test (at least not yet) musl libc (aka, alpine) and thus if things are broken, it isn't proactively fixed -- it has to be reported. And lastly, these library docker images (aka, the base images from docker pull php:cli-alpine) are community supported, they aren't "PHP official" so there's that to consider as well -- in case you were wondering why there was an Alpine base image; it's literally because someone opened a PR and it was merged, not because it is actually supported by PHP.