-
-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't get custom modules to build #591
Comments
It's hard to say anything without actual details of what you are doing. IRT WordPress: WordPress probably can't work in worker mode since it relies on global state. There are ways around that, at least for core, though it's unlikely plugins will work correctly. That basically limits you to cgi-mode, which is still pretty darn fast. I'd have to see your actual setup to get any idea as to what is going on.
I'd recommend not using those :) they're pretty good though. When I worked at Automattic, I spent quite a bit of time building out an actual "official" image instead of a community one, specifically for Jetpack. We ended up contracting with Bitnami (IIRC). I highly recommend those images as a good starting point. Beyond that, I'd recommend taking a look at vip-go's skeleton repo for some crazy stuff. IRT load testing: I've spotted a bug with Go's handling of FIN and FIN_WAIT packets (they can be delayed up to 600ms in my experience, which won't cause any issues for humans or actual traffic, but means most load testing software simply won't fire another request until the previous one closes which makes it seem as though it isn't as fast as it "really" is), but I haven't spent enough time trying to work out what is going on to properly report it. All I can say is that some load-testing tools show really bad performance depending on how they report the throughput. K6 seems to do pretty well in our experience. (IOW, do you measure the time to get all the data, or do you measure the time until the connection is actually closed? Both are useful metrics, one for humans and one for non-humans). IRT to modules:
How are you building them? From the looks of that error, some linker flags aren't set properly but should be set in the builder container described in the docs. |
Thanks for the feedback. Here's a link to the Dockerfile. https://github.com/wpeverywhere/wordpress-docker-frankenphp/blob/main/Dockerfile I did some testing, and I think it is an issue of using "cgo" . I can get FrankenPHP to build without the additional modules and I can get the modules to build without cgo. But, using cgo even breaks when not including FrankenPHP with these modules. If FrankenPHP continues to need cgo, then it may be good to add a disclaimer in that "custom Cadddy build" section of the site that additional modules need to be compatible with cgo. I'm assuming it has to be used for the C-Thread-Pool package in order to avoid php-fpm. -- Honestly, is there a big benefit of using FrankenPHP with WordPress than a Caddy server with php-fpm? I can include php-fpm with Caddy inside a single Dockerfile which is a big win. And since WordPress isn't suitable for Workers, then I'm not seeing the benefit... I do think FrankenPHP is likely really great for a sizeable amount of modern PHP projects, but WP may not be a good fit. |
In the dockerfile, where you set:
Try per the error message you got:
Cgo is the glue between caddy and PHP, PHP is running natively in caddy (similar to apache) and some caddy modules might also be using cgo. Sometimes those modules will have custom compiler/linker flags that need to be set manually in order to compile.
Hmm. Maybe. You could literally create a self-executable of your Wordpress installation (that would be possible with the bitnami layout mentioned earlier). Basically, you just drop "FrankenWP" into a folder with a plugins & content directory and run it. Done. Especially if you used something like https://wordpress.org/plugins/sqlite-database-integration/ (which is maintained by WP btw -- all unit tests run with that so, it is guaranteed to work and be maintained); you don't even need MySQL. A docker container wouldn't even be needed, just a single executable. So, yeah, I think there is some serious potential there if you wanted to do something bleeding edge. |
I gave it a few more tries to no success with the commands. I did several variations of @dunglas , have you been able to compile FrankenPHP with additional caddy modules? It could be helpful to have a list of known modules that work well and require more effort with FrankenPHP. I'd be willing to provide some help with it as well . -- I ended up just pushing up what I could for now. I'll reconsider working on a self-executable version in upcoming iterations. Its a cool idea. Thanks again for the feedback. |
@StephenMiracle this looks like a duplicate of #374. Can you try if #374 (comment) fixes your issue? |
Nice! That it is. And that did it :) Here's the full line in my Dockerfile that made it work: ENV CGO_ENABLED=1 CGO_LDFLAGS=-no-pie XCADDY_SETCAP=1 CGO_LDFLAGS=-pie XCADDY_GO_BUILD_FLAGS='-buildmode=pie -ldflags="-w -s" -trimpath' |
That would be nice to add this to the docs! PR welcome 🤗 |
Hey, I wanted to circle back to this one as it came up a bit ago when someone was trying to run the WP image on Rocky Linux arch . The attached screenshot is what occurs when I try to run the dockerfile with the custom build and pie values. I was trying to avoid going this route with the Dockerfile by trying to simulate the arm, but it doesn't appear to work in this case. Anyway, I am unsure what to do with the attached screenshot at this point. |
IIRC, this happens when you try to use something incompatible or needs custom build parameters. I could be wrong, it's hard to say without some way to reproduce it. |
Hi! I'm also trying to build frankenphp with souin, the build pass but I have a crash immedately after the first request. Caddy running logs
DockerfileARG DOCKER_HUB_PROXY="registry.hub.docker.com"
FROM $DOCKER_HUB_PROXY/dunglas/frankenphp:latest AS frankenphp_upstream
FROM $DOCKER_HUB_PROXY/dunglas/frankenphp:latest-builder AS frankenphp_builder_upstream
FROM $DOCKER_HUB_PROXY/library/caddy:builder AS caddy_builder_upstream
FROM $DOCKER_HUB_PROXY/composer/composer:2-bin AS composer_upstream
FROM frankenphp_builder_upstream as frankenphp_builder
COPY --from=caddy_builder_upstream /usr/bin/xcaddy /usr/bin/xcaddy
ENV CGO_ENABLED=1 XCADDY_SETCAP=1 CGO_LDFLAGS=-pie XCADDY_GO_BUILD_FLAGS='-buildmode=pie -ldflags="-w -s" -trimpath'
RUN xcaddy build \
--output /usr/local/bin/frankenphp \
--with github.com/dunglas/frankenphp=./ \
--with github.com/dunglas/frankenphp/caddy=./caddy/ \
--with github.com/dunglas/mercure/caddy \
--with github.com/dunglas/vulcain/caddy \
--with github.com/caddyserver/cache-handler
FROM frankenphp_upstream AS frankenphp_base
COPY --from=frankenphp_builder --link /usr/local/bin/frankenphp /usr/local/bin/frankenphp
RUN set -eux; \
apt-get update; \
apt-get install -y \
acl \
curl \
file \
gettext \
git \
; \
rm -rf /var/lib/apt/lists/*
RUN set -eux; \
install-php-extensions \
@composer \
amqp \
apcu \
intl \
igbinary \
opcache \
openssl \
pdo_pgsql \
redis \
zip
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
COPY --link docker/frankenphp/Caddyfile /etc/caddy/Caddyfile
ARG UID=1000
ARG GID=1000
RUN set -eux; \
groupadd -g $GID web; \
useradd -u $UID -d /home/web -m -g web web; \
mkdir -p /srv/app; chown $UID:$GID /srv/app; \
mkdir -p /var/run/php; chown $UID:$GID /var/run/php
USER web
WORKDIR /srv/app
HEALTHCHECK --start-period=60s CMD curl -f http://localhost:2019/metrics || exit 1
CMD [ "frankenphp", "run", "--config", "/etc/caddy/Caddyfile" ] |
Hello, I'm also encountering the same crash after following the https://api-platform.com/docs/core/performance/ tutorial (with fixes from this PR for building the Docker image) |
Hey I'm getting the same issue. I've tried to reduce my build as much as possible, but can't really get it down beyond this:
|
@J-Cake you should use FrankenPHP "builder" images as base. If you start from Caddy, you have to install PHP by yourself. https://frankenphp.dev/docs/docker/#how-to-install-more-caddy-modules |
Hi thanks for the quick reply! I've actually been playing with both. Unfortunately, I get different but similar errors regardless of which image I use. Anyway, for the sake of this project, I've decided to just use a dedicated cache in a different container, but it would be nice to have them all working together. Cheers and thanks for your help 🚀 |
The error message you get is just because PHP C file are missing. They are required to compile FrankenPHP. What is the other error message you get? |
Hi apologies for the non-reply again. Here's the error message when building with the frankenphp image:
|
i have same issue #944 with apiplatform |
Could you please stop to reference your issue in all frankenphp issues? |
What happened?
I can't get FrankenPHP to compile with HTTP cache module: https://github.com/caddyserver/cache-handler (or other popular caddy modules)
I'm building a WordPress Docker image where I'm hoping to beat benchmarks and stress tests of the standard WordPress Docker image. I've been using loader.io and FrankenPHP starts to get significantly slower than the standard Apache Docker Image. I believe it is due to some caching. Apache response times for Apache stay consistent no matter the load I throw at it.
I've updated to match the WordPress image defaults as much as possible. I've included & optimized Opcache, but it still gets up to 7-8 seconds when I send 1800 requests to my WordPress image in 1 minute. Comparably, the standard WordPress Apache version takes 450ms consistently.
So I believe it must be something with additional HTTP caching.
--
I'm trying to build FrankenPHP with this module: github.com/caddyserver/cache-handler , but its throwing back C errors that I just can't understand. I've tried other modules but still have similar issues.
I'm attaching the build errors in the log output below.
Thanks! I'm really enjoying this project.
Build Type
Docker (Debian Bookworm)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
x86_64
Relevant log output
The text was updated successfully, but these errors were encountered: