このページはコミュニティによって翻訳されたもので、最新ではない可能性があります。参照用のバージョンをご覧ください。

このページはコミュニティによって翻訳されたもので、最新ではない可能性があります。参照用のバージョンをご覧ください。

このページはコミュニティによって翻訳されたもので、最新ではない可能性があります。参照用のバージョンをご覧ください。

提供
既知の問題

既知の問題

# 未対応のPHP拡張モジュール

以下の拡張モジュールはFrankenPHPと互換性がないことが確認されています:

名前理由代替手段
imapスレッドセーフでないjavanile/php-imap2, webklex/php-imap, ImapEngine
newrelicスレッドセーフでない-
pcovスレッドセーフでない (クラシックモードでのSIGSEGV)CLI SAPIでカバレッジを収集する(FrankenPHPの外部でPHPUnit/Pestを実行する)

# バグのあるPHP拡張モジュール

以下の拡張モジュールはFrankenPHPとの組み合わせで既知のバグや予期しない動作が確認されています:

名前問題
datadogFrankenPHPのプロファイリング時に不安定な動作が確認されています。このバグはDataDogによって追跡中です。
blackfireFrankenPHPのサポートはベータ版であり、まだ機能が完全ではありません。
imagickImageMagickのOpenMPスレッドがFrankenPHPのスレッドと競合し、不安定性やクラッシュを引き起こします。\Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1)でImageMagickのスレッドを無効にするか、--disable-openmpでImageMagickをコンパイルすることで軽減できます。静的バイナリおよび公式のapt/apk/rpmパッケージではOpenMPはすでに無効になっているため、DockerイメージとHomebrewインストールのみが影響を受けます。

# PHPのハードメモリ制限を超過するとサーバー全体が停止する

PHP 8.2.35、8.3.36、8.4.27、および8.5.12以降、memory_limitを超過してもスクリプトがすぐに停止しなくなりました。「Allowed memory size exhausted」の致命的なエラーは、次の関数呼び出しまたはループイテレーションで発生します。 それ以前にスクリプトがハードメモリ制限を超えて割り当てを行うと、PHPはプロセスを終了します。 ハード制限はデフォルトでmemory_limitの2倍(または1 GiBを超える場合はmemory_limitプラス1 GiB)であり、memory_hard_limit_percent INI設定で変更できます。

memory_limitを超えて実行され続けるコードは、例えばmemory_limitより大きい単一の割り当て(大規模な配列に対するarray_merge()など)や、連続する文字列連結によって、この制限に達する可能性があります。

PHP-FPMは1つの子プロセスしか失いません。 FrankenPHPはすべてのリクエストを単一プロセスのスレッドから処理するため、処理中のすべてのリクエストが失われ、サーバーは再起動されるまで停止します。 Dockerの再起動ポリシーやsystemdのRestart=(debおよびrpmパッケージではすでに設定済み)など、FrankenPHPを再起動する監視プログラムの下で実行してください。

# get_browser

get_browser()関数は継続使用するとパフォーマンスが悪化することが確認されています。回避策として、User Agentごとの結果をキャッシュ(例:APCuを利用)してください。User Agentごとの結果は静的なためです。

# スタンドアロンバイナリおよびAlpineベースのDockerイメージ

スタンドアロンバイナリおよびAlpineベースのDockerイメージ(dunglas/frankenphp:*-alpine)は、バイナリサイズを小さく保つためにglibc and friendsではなくmusl libcを使用しています。これによりいくつかの互換性問題が発生する可能性があります。特に、globフラグGLOB_BRACEは サポートされていません 。

問題が発生した場合は、静的バイナリのGNU版およびDebianベースのDockerイメージを使用することをお勧めします。

# Dockerでhttps://127.0.0.1を使用する

デフォルトでは、FrankenPHPはlocalhost用のTLS証明書を生成します。 これはローカル開発における最も簡単かつ推奨される方法です。

どうしても127.0.0.1をホストとして使用したい場合は、サーバー名を127.0.0.1に設定してその証明書を生成させることが可能です。

ただし、Dockerのネットワークシステムの仕組みにより、Dockerを使用する場合はこれだけでは不十分です。 この場合、curl: (35) LibreSSL/3.3.6: error:1404B438:SSL routines:ST_CONNECT:tlsv1 alert internal errorのようなTLSエラーが発生します。

Linuxを使用している場合、ホストネットワークドライバーを使用することで、この問題を解決できます:

docker run \
    -e SERVER_NAME="127.0.0.1" \
    -v $PWD:/app/public \
    --network host \
    dunglas/frankenphp

ホストネットワークドライバーはMacとWindowsではサポートされていません。これらのプラットフォームでは、コンテナのIPアドレスを推測してサーバー名に含める必要があります。

docker network inspect bridgeを実行し、Containersキーを確認してIPv4Addressにある現在割り当てられている最後のIPアドレスを特定し、それに1を加えます。コンテナがまだ実行されていない場合、最初に割り当てられるIPアドレスは通常172.17.0.2です。

そして、これをSERVER_NAME環境変数に含めます:

docker run \
    -e SERVER_NAME="127.0.0.1, 172.17.0.3" \
    -v $PWD:/app/public \
    -p 80:80 -p 443:443 -p 443:443/udp \
    dunglas/frankenphp

Caution

172.17.0.3の部分は、実際にコンテナに割り当てられるIPに置き換えてください。

これでホストマシンからhttps://127.0.0.1へアクセスできるはずです。

うまくいかない場合は、FrankenPHPをデバッグモードで起動して問題を特定してみてください:

docker run \
    -e CADDY_GLOBAL_OPTIONS="debug" \
    -e SERVER_NAME="127.0.0.1" \
    -v $PWD:/app/public \
    -p 80:80 -p 443:443 -p 443:443/udp \
    dunglas/frankenphp

# @php を参照するComposerスクリプト

Composerスクリプトでは、いくつかのタスクでPHPバイナリを実行したい場合があります。例えば、Laravelプロジェクトで@php artisan package:discover --ansiを実行する場合です。しかし現在これは以下の2つの理由で失敗します:

  • ComposerはFrankenPHPバイナリを呼び出す方法を知りません
  • Composerはコマンドで-dフラグを使用してPHP設定を追加する場合があり、FrankenPHPはまだサポートしていません

回避策として、未サポートのパラメータを削除してFrankenPHPを呼び出すシェルスクリプトを/usr/local/bin/phpに作成できます:

#!/usr/bin/env bash
# /usr/local/bin/php
args=("$@")
index=0
for i in "$@"
do
    if [ "$i" == "-d" ]; then
        unset 'args[$index]'
        unset 'args[$index+1]'
    fi
    index=$((index+1))
done

/usr/local/bin/frankenphp php-cli ${args[@]}

次に、環境変数PHP_BINARYにこのphpスクリプトのパスを設定してComposerを実行します:

export PHP_BINARY=/usr/local/bin/php
composer install

# 静的バイナリでのTLS/SSL問題のトラブルシューティング

静的バイナリを使用する場合、例えばSTARTTLSを使用してメールを送信する際に以下のTLS関連エラーが発生する可能性があります:

Unable to connect with STARTTLS: stream_socket_enable_crypto(): SSL operation failed with code 5. OpenSSL Error messages:
error:80000002:system library::No such file or directory
error:80000002:system library::No such file or directory
error:80000002:system library::No such file or directory
error:0A000086:SSL routines::certificate verify failed

静的バイナリにはTLS証明書がバンドルされていないため、OpenSSLにローカルのCA証明書の位置を明示する必要があります。

openssl_get_cert_locations()の出力を調べて、 CA証明書をどこにインストールすべきか確認し、その場所に保存してください。

Warning

WebとCLIコンテキストでは設定が異なる場合があります。 適切なコンテキストでopenssl_get_cert_locations()を実行してください。

Mozillaから抽出されたCA証明書はcurlのサイトでダウンロードできます。

または、Debian、Ubuntu、Alpineなどのディストリビューションでも、これらの証明書を含むca-certificatesというパッケージを提供しています。

SSL_CERT_FILEおよびSSL_CERT_DIRを使用してOpenSSLにCA証明書を探す場所をヒントとして与えることも可能です:

# TLS 証明書の環境変数を設定
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_DIR=/etc/ssl/certs
このページを編集