简单的部分...

通常，将 ZF1 应用程序从内置自动加载迁移到基于 composer 的自动加载(强烈建议部署在 CloudControls Pinky 堆栈上)时，您只需执行一些简单的步骤:

创建一个 composer.json 文件并要求 Zend Framework(例如 1.12 版的最新版本):

{
    "require" : {
        "zendframework/zendframework1" : "1.12.*"
    }
}

通过 CLI 安装 composer 依赖项:

composer install

更新您的 .gitignore 文件并添加:

vendor/*

从库路径中递归删除当前 ZF 文件夹(例如 ./library):

rm -r library/Zend

在 index.php 任何 Zend_ 类的使用之前，通过添加以下内容来包含 composer autoloader:

$loader = include 'vendor/autoload.php';

从您的 index.php 中删除所有与 ZF 相关的 require 或 require_once 语句 - 例如这不再需要了:

require_once 'Zend/Application.php';

完成上述更改后，您可以像往常一样通过 git 提交和推送，然后通过 CLI 在 CloudControl 上部署新版本(此处为 APP_NAME 和 DEP_NAME请引用您的应用和部署名称):

cctrlapp APP_NAME/DEP_NAME deploy

您会注意到 cctrlapp 打印出一些有关解析 composer 依赖项的信息，并最终启动新版本的部署。要检查它是否完成，您可以运行:

cctrlapp APP_NAME/DEP_NAME log deploy

好的，部署日志看起来不错——不错——让我们打开浏览器吧!

他妈的!内部服务器错误？为什么？？本地 LA(M)P 堆栈一切正常!!!

最佳答案

棘手的部分...

幸运的是，CloudControl 还允许我们访问错误日志...

cctrlapp APP_NAME/DEP_NAME log error

应该不难找出这里的问题。

但是……错了……

8/1/14 5:23 AM  error [error] [client ] FastCGI: incomplete headers (0 bytes) received from server "/app/php/box/php-fpm"
8/1/14 5:23 AM  error [error] [client ] (104)Connection reset by peer: FastCGI: comm with server "/app/php/box/php-fpm" aborted: read failed

由于上述错误消息根本没有帮助，我们首先需要找出这个错误。这确实很棘手!我们可以谷歌一下。我们可以尝试一下。然后我们可以重新部署。我们可以再谷歌一下。我们可以尝试另一件事。然后我们可以再次重新部署。我们可以改天谷歌。我们可以尝试所有其他的东西。我们可以……但是我们想要吗？

幸运的是，Pinky 堆栈提供了另一种加快速度的方法(Luigi 并非全部)。虽然它仍然包含繁琐的手动调试，但至少我们可以节省一些时间——转到您的 CLI 并执行:

cctrlapp APP_NAME/DEP_NAME run bash

CloudControl 现在为我们实例化了一个新容器，并为我们提供了基于 SSH 的 shell 访问权限。正如文档所说，一切都应该与我们的部署箱中的一样:

The distributed nature of the cloudControl platform means it's not possible to SSH into the actual server. Instead, we offer the run command, that allows you to launch a new container and connect to that via SSH.

The container is identical to the web or worker containers but starts an SSH daemon instead of one of the Procfile commands. It's based on the same stack image and deployment image and does also provides the Add-on credentials.

让我们看看是否可以(从容器内部)找到更多信息:

cd code/public
php index.php

嗯...这里没有任何报告...而且...日志中没有任何报告？!什么鬼？!!

因此，网络容器和运行容器之间似乎存在差异——而且确实存在差异! 为了找出这一点，我开始立即编辑 index.php:

vi index.php

一段时间后，我终于重现了至少另一个错误:

8/1/14 8:55 AM  error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Fatal error:  require_once(): Failed opening required '' (include_path='/srv/www/code/vendor/zendframework/zendframework1/library:/srv/www/code/library:.:/usr/share/php') in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
8/1/14 8:55 AM  error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Warning: require_once(/srv/www/code/vendor/zendframework/zendframework1/library): failed to open stream: No such file or directory in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...

看起来有些文件丢失了——可能与自动加载有关——修复它应该不难。

等等，那是什么:Failed opening required ''？当然你不需要任何东西你愚蠢的代码!

好吧……当查看相应的 ZF 库文件时，您不会发现那里有任何问题。包含路径似乎也是正确的 - 是的，文件存在 - composer 正确地管理了这两件事。

这是一个 PHP 错误!

更准确地说，这是 PECL APC 的一个错误，它会影响 Pinky 当前版本的 PHP 5.4.30/APC 3.1.13 - 见:

https://bugs.php.net/bug.php?id=62398

这正是运行容器和 Web 容器之间的区别，因为 php.ini 选项 apc.stat 设置为 0(关闭) 用于 Web 容器，1 (on) 用于运行容器。

tl;dr

从 GitHub 克隆 CloudControl Pinky PHP 构建包:

git clone https://github.com/cloudControl/buildpack-php.git

复制此存储库中的所有文件并将它们添加到您的项目根文件夹中:

.buildpack/php

编辑 .buildpack/php/conf/php.ini 并设置:

apc.stat = 1

提交、推送、部署并享受!

注意事项:

请记住，这只是一种解决方法，因为 APC stat 不需要在这样的环境中激活(在部署时重新创建堆栈)并且它会减慢执行速度。请参阅 PHP 文档:

On a production server where the script files rarely change, a significant performance boost can be achieved by disabled stats.

感谢:

最后，我要感谢 CloudControl 的 Dimitris 和 Mateusz 提供的一般建议——尽管我需要自己找出这里发生的事情。此外，我要感谢 Stack Overflow 的 @BullfrogBlues 和 @Thierry_Marianne，他们试图回答另一个发问者的帖子，可追溯到去年 11 月，这最终让我找到了与 APC 相关的问题。

关于php - 如何成功地将 Zend Framework 1 应用程序从 CloudControl Luigi 迁移到 Pinky 堆栈？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25131147/