Usually when migrating a ZF1 application from built-in auto-loading to composer based auto-loading (which is strongly recommended for deploying on CloudControls Pinky stack) you just need to take some simple steps:
Create a composer.json file and require Zend Framework (e.g. latest release from version 1.12) with:
{
"require" : {
"zendframework/zendframework1" : "1.12.*"
}
}
Install composer dependencies via CLI with:
composer install
Update your .gitignore file and add:
vendor/*
Recursively delete current ZF folder from your library path (e.g. ./library):
rm -r library/Zend
Include composer autoloader in your index.php before any usage of Zend_ classes by adding:
$loader = include 'vendor/autoload.php';
Remove every now obsolete ZF related require or require_once statements from your index.php - e.g. this is not needed anymore:
require_once 'Zend/Application.php';
Once you are done with the above changes you commit and push via git as normal and then you deploy the new version on CloudControl via CLI (where APP_NAME and DEP_NAME here refer to your app and deployment names):
cctrlapp APP_NAME/DEP_NAME deploy
You will notice that cctrlapp prints out some information about resolving composer dependencies and finally initiates the deployment of the new version. To check whether it is done you can run:
cctrlapp APP_NAME/DEP_NAME log deploy
Ok, deployment log looks fine – nice – let's open the browser!
What the f***! Internal server error? Why?? Everything worked well with the local LA(M)P stack!!!
Fortunately CloudControl gives us access to the error logs as well ...
cctrlapp APP_NAME/DEP_NAME log error
Shouldn't be too hard to find out what's wrong here.
But ... err ...
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
As the above error messages are not helpful at all we first need to track down this very bug. And this can indeed be tricky! We can google a bit. We can try something. We can then redeploy. We can google a bit more. We can try another thing. We can then redeploy again. We can google another time. We can try out every other thing. We can ... but do we want?
Luckily the Pinky stack offers another way to speed things up (which Luigi does not all). While it still incorporates cumbersome manual debugging at least we can save some time – go to your CLI and execute:
cctrlapp APP_NAME/DEP_NAME run bash
CloudControl now instantiates a new container for us and gives us SSH based shell access to it. As the documentation says everything should be as it is inside our deployment boxes:
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.
Let's see if we can find out more (from inside the container):
cd code/public
php index.php
Hmm ... nothing reported here ... and ... nothing reported at the logs?! What the hell?!!
So, there seems to be a difference between the web and the run containers – and there is!
To find this out I started by editing the index.php right away:
vi index.php
And after a while I finally got to reproduce at least another error:
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/ ...
Looks like some file is missing – maybe related to auto-loading – shouldn't be too hard to fix it.
But wait, what's that: Failed opening required ''? Sure you fail to require nothing you stupid code you!!
Well ... when looking at the respective ZF library files you won't find anything wrong there. The include paths seem to be correct as well – and yes, the files are present – composer managed both things correctly.
To be more precise it is a bug with PECL APC which affects Pinky's current versions of PHP 5.4.30 / APC 3.1.13 - see:
https://bugs.php.net/bug.php?id=62398
And that's exactly the difference between the run and the web containers as php.ini option apc.stat is set to 0 (off) for the web containers and 1 (on) for the run container.
Clone the CloudControl Pinky PHP buildpack from GitHub:
git clone https://github.com/cloudControl/buildpack-php.git
Copy all files from this repository and add them to your project root folder at:
.buildpack/php
Edit .buildpack/php/conf/php.ini and set:
apc.stat = 1
Commit, push, deploy and enjoy!
Keep in mind that this is just a workaround as APC stat does not need to be activated in such an environment (where the stack is recreated on deploy) and it slows down execution. See the PHP docs:
On a production server where the script files rarely change, a significant performance boost can be achieved by disabled stats.
Finally I'd like to thank Dimitris and Mateusz from CloudControl for general advises – though I need to find out on my own what was going on here. Furthermore I want to thank @BullfrogBlues and @Thierry_Marianne here at Stack Overflow who tried to answer another questioners thread dating back to November last year, which finally pointed me to look for APC related issues.