Open jduan00 opened 1 month ago
You're very likely encountering https://github.com/php/php-src/issues/13648. The PHP Foundation is working on it: https://github.com/php/php-src/issues/14734
it would be highly beneficial to have an official binary distribution for glibc-based systems
It's unfortunately not that simple because unlike with musl, it's not really possible to create portable binaries with glibc. We'll have to add package for every distribution.
For Debian/Ubuntu, see https://github.com/dunglas/frankenphp/issues/1039
Thank you @dunglas for your prompt response. I understand your reasons for not making a portable binary with glibc. As I am playing around with your official docker image, it is working.
The size of the docker image is over 500MB, is it possible to slim it down? Thanks
Just a comparison:
REPOSITORY TAG IMAGE ID CREATED SIZE
eaglwine/debian-frankenphp latest 38d2a10971b5 2 minutes ago 665MB
dunglas/frankenphp latest 15f7ddf8f380 22 hours ago 579MB
eaglwine/ubuntu-php83 latest c83793361d63 5 weeks ago 261MB
Hi @dunglas, I am very flattered by your work. Since I am still a newbie here, a simple question:
Can I still start https://localhost:8000 with docker under wsl (windows)?
I am using laravel octane (from fresh install eg. composer create project, bla, bla--), and want to use frankenphp on my local machine
Trying image dunglas/frankenphp:latest-php8.3.7-bookworm, dunglas/frankenphp:latest-php8.3.7-alpine
but no luck 😔 (ERR_SSL_PROTOCOL_ERROR)
Anyway, great thanks!
@dunglas : I am happy to share that by doing multi-stage build, docker image size came down by almost an half!
REPOSITORY TAG IMAGE ID CREATED SIZE
eaglwine/debian-frankenphp83 latest 47011976bff8 34 seconds ago 375MB
Dockerfile
FROM dunglas/frankenphp as builder
# Install php extensions
RUN install-php-extensions pdo_mysql gd intl zip opcache exif pcntl
# Start from a simple base
FROM debian:bookworm-slim AS base
COPY --from=builder /usr/local /usr/local
COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer
RUN apt-get update && \
apt-get install -yqq --no-install-recommends supervisor procps curl \
libreadline8 libbrotli1 libxml2 libssl3 libsqlite3-0 libcurl4 libonig5 \
libargon2-1 libpng16-16 libavif15 libwebp7 libxpm4 libfreetype6 libsodium23 libzip4 \
unzip httping htop file p7zip-full \
net-tools iputils-ping bind9-dnsutils jq vim-tiny
....
@jduan00, most likely those 'lost megabytes' are libraries used by extensions, like libmysql, libzip, libexif, etc, and your application will crash when trying to use some of those extensions.
As mentioned, the glibc build isn't "portable" and you can't just copy it over to another system.
@sukrokucing, your message is a bit off-topic and probably belongs in the discussion section instead. There isn't enough information to help with your specific problem, but SERVER_NAME="https://localhost:8000" ./frankenphp -c default/Caddyfile
works for me. If you need help, please drop into the discussions tab at the top of the page and start a discussion!
@withinboredom : Actually we are on the same page, in the Dockerfile I am installing all required libraries. The docker image is still 378MB. We are doing a lot of QA Testing for a length of time before deciding to switch this to Production.
RUN apt-get update && \
apt-get install -yqq --no-install-recommends supervisor procps curl \
libreadline8 libbrotli1 libxml2 libssl3 libsqlite3-0 libcurl4 libonig5 \
libargon2-1 libpng16-16 libavif15 libwebp7 libxpm4 libfreetype6 libsodium23 libzip4 \
unzip httping htop file p7zip-full \
net-tools iputils-ping bind9-dnsutils jq vim-tiny
If you don't mind, I'd be very interested and grateful to see a gist of the additional files in the frankenphp image. I wonder if it is stuff that got left behind from a build process (maybe even the base php image) or whatever.
https://github.com/GoogleContainerTools/container-diff isn't maintained anymore, but still works last I tried it.
@withinboredom : be happy to in a day. Just to confirm: container-diff on: dunglas/frankenphp vs eaglwine/debian-frankenphp83?
@jduan00 no rush, but that sounds right assuming eaglwine/debian-frankenphp83 is the image you are copying everything to manually.
@withinboredom like this? #1041
@jduan00, most likely those 'lost megabytes' are libraries used by extensions, like libmysql, libzip, libexif, etc, and your application will crash when trying to use some of those extensions.
As mentioned, the glibc build isn't "portable" and you can't just copy it over to another system.
@sukrokucing, your message is a bit off-topic and probably belongs in the discussion section instead. There isn't enough information to help with your specific problem, but
SERVER_NAME="https://localhost:8000" ./frankenphp -c default/Caddyfile
works for me. If you need help, please drop into the discussions tab at the top of the page and start a discussion!
If you don't mind, I'd be very interested and grateful to see a gist of the additional files in the frankenphp image. I wonder if it is stuff that got left behind from a build process (maybe even the base php image) or whatever.
https://github.com/GoogleContainerTools/container-diff isn't maintained anymore, but still works last I tried it.
@withinboredom : can you please let me know the exact container-diff command options you like to see?
Here is what I have
Linux 5.15.0-1063-ibm #66-Ubuntu SMP Fri Aug 30 13:43:36 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 22.04.5 LTS
REPOSITORY TAG IMAGE ID CREATED SIZE
eaglwine/debian-frankenphp83 latest 5806d46e80e4 36 minutes ago 319MB
dunglas/frankenphp latest 6b969579b9bc 15 hours ago 586MB
$ container-diff diff daemon://eaglwine/debian-frankenphp83:latest daemon://dunglas/frankenphp:latest
-----Size-----
Image size difference between eaglwine/debian-frankenphp83:latest and dunglas/frankenphp:latest:
SIZE1 SIZE2
306.6M 558.4M
$ container-diff diff daemon://eaglwine/debian-frankenphp83:latest daemon://dunglas/frankenphp:latest --type=history
-----History-----
// lots of info
@withinboredom FYI, here is the most important part of my Dockerfile. So far our Lavavel Octane app is passing QA test. More work to be done.
FROM dunglas/frankenphp as builder
USER root
# Install php extensions
RUN install-php-extensions pdo_mysql gd intl zip opcache exif pcntl
RUN rm -rf /usr/local/bin/phpdbg /usr/local/bin/php-cgi
# Start from a simple base
FROM debian:bookworm-slim AS base
COPY --from=builder /usr/local/bin /usr/local/bin
COPY --from=builder /usr/local/etc /usr/local/etc
COPY --from=builder /usr/local/lib /usr/local/lib
COPY --from=composer:latest /usr/bin/composer /usr/local/bin/composer
# Install packages
RUN apt-get update && \
apt-get install -yqq --no-install-recommends supervisor procps curl \
libreadline8 libbrotli1 libxml2 libssl3 libsqlite3-0 libcurl4 libonig5 \
libargon2-1 libpng16-16 libavif15 libwebp7 libxpm4 libfreetype6 libsodium23 libzip4 \
unzip httping htop file p7zip-full \
net-tools iputils-ping bind9-dnsutils jq vim-tiny && \
apt-get install --reinstall ca-certificates && \
apt autoremove -qy && \
apt clean && \
apt autoclean && \
rm -rf /var/lib/apt/lists/*
# Drop in GEI files
WORKDIR /app
COPY --chown=root:root ./app /app
I suspect it is the /usr/local/src
(IIRC) directory used to install extensions and contains the source code of php? For example, I suspect pecl won't be able to compile new extensions in your resulting docker image.
@withinboredom : the resulting docker image is minimized for deploying production apps, so no need to install or compile any additional PHP extensions. Thanks for looking into it!
What happened?
Description: We are experiencing crashes when running our Laravel application using the binary release of FrankenPHP (musl). However, when using the official FrankenPHP Docker image with the same Laravel application, everything works as expected.
Environment: • FrankenPHP Version: v1.2.5 • PHP Version: 8.3.11 • Caddy Version: v2.8.4 (h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=) • OS: Linux x64 (Ubuntu 24.x)
Issue Details: • Working scenario: Running the Laravel application inside the official FrankenPHP Docker image works without any issues. • Problematic scenario: When running the same Laravel application using the standalone binary release (musl), the application crashes frequently.
Request: We use a Docker deployment process based on Ubuntu 24.x, and while we are capable of recompiling FrankenPHP per the documentation, it would be highly beneficial to have an official binary distribution for glibc-based systems. This would simplify our deployment process and likely resolve the crashes related to musl incompatibility.
Thank you for your consideration!
Build Type
Official static build
Worker Mode
Yes
Operating System
GNU/Linux
CPU Architecture
x86_64
PHP configuration
Relevant log output
No response