cloudcontrol / buildpack-php Goto Github PK

While trying to deploy with custom-php (~5.5.28 resulting in a found 5.5.29 version) on Exoscale I receive an error:

PHP Warning: PHP Startup: Unable to load dynamic library '/srv/www/php-5.5.29/lib/php/extensions/pdo_mysql.so' - /srv/www/php-5.5.29/lib/php/extensions/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0
(...)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- The requested PHP extension ext-pdo_mysql * is missing from your system.

But according to http://www.paasfinder.com/custom-php-version/ ext-pdo_mysql is one of the standard requirements which will be required even if I don't use the custom-php since 14.09.2015.

Providing a custom composer.phar with supposedly "incorrect" permissions results in the push being rejected. I'm not sure how to get the permissions right on a Windows client from the top of my head. Shouldn't it be part of the buildpack to ensure, the composer.phar is executable, before we try to execute it?

Either make it executable, or don't try to execute it when it's not executable.

http://stackoverflow.com/questions/18509000/pushing-my-app-to-cloudcontrol-paas-fails-hook-declined

Letting the push fail as shown in the above Stackoverflow discussion isn't the best approach imho.

Composer has a way to specify dependencies only required for development. We should exclude these for at least the default deployment. Maybe we should even make it configurable for all the other ones?

See http://getcomposer.org/doc/03-cli.md#update for more details.

When using the Blackfire.io add-on, the following error-message is displayed by the Blackfire Companion Chrome extension as soon as I try to profile an URL that ends in .html, .js, .css, .txt, etc.

Are you authorized to profile this page? Probe not found, invalid signature or Varnish related issue. Troubleshooting?

Does the current CloudControl Varnish configuration allow the HTTP headers as suggested in the Blackfire documentation?

A simple info.php or other URLs that are skipped by Varnish are profiled without problem.

Hi,

I'm currently trying to setup ZF1 application using the cloudControll buildpack.

I set the buildpack usage by this command:
heroku config:set BUILDPACK_URL=https://github.com/cloudControl/buildpack-php

But when I try to git push

I see this:

-----> Fetching custom git buildpack... done
-----> PHP/Zend1 app detected
/tmp/buildpack_3a0j5lzt23ogx/bin/compile: line 78: php: command not found

 !     Push rejected, failed to compile PHP/Zend1 app

Any thoughts? Or am I doing something wrong?

Thanks in advance

The user is free to configure the composer vendor-dir in his/her config.json file: https://getcomposer.org/doc/04-schema.md#config

In https://github.com/cloudControl/buildpack-php/blob/master/bin/compile#L67 we assume that it's always vendor and fail after the install if defined otherwise: https://github.com/cloudControl/buildpack-php/blob/master/bin/compile#L90 (cp: cannot stat `/srv/tmp/builddir/code/vendor': No such file or directory)

having this composer.json

[...]
"require": {
    "php-64bit": "5.6.12",        
    "ext-curl": "*",
    "ext-mcrypt": "*",
    "ext-zip": "*",
    "ext-pdo": "*",
    "ext-pdo_mysql": "*"
},
[...]

results in this error:

PHP Warning: PHP Startup: Unable to load dynamic library '/srv/www/php-5.6.12/lib/php/extensions/pdo_mysql.so' - /srv/www/php-5.6.12/lib/php/extensions/pdo_mysql.so: undefined symbol: mysqlnd_allocator in Unknown on line 0

This also did not work with php-64bit 5.6.13

When trying to install Blackfire using composer, the result is not very sunny for this black magic extension 😢

Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 321 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)

-----> Receiving push
-----> Packaging ext/blackfire 0.23.1 (for Zend module API version 20100525)...

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
 !     cloudControl push rejected, failed to compile php app
 !     
remote: error: hook declined to update refs/heads/test
To ssh://[email protected]/repository.git
 ! [remote rejected] deploymentName -> deploymentName (hook declined)
error: failed to push some refs to 'ssh://[email protected]/repository.git'
Command '['/usr/bin/git', 'push', u'ssh://[email protected]/repository.git', 'deploymentName']' returned non-zero exit status 1

Maybe this is related?

Ok, I think I just found a nice approach to currently use the custom-php-buildpack approach without having to change to much to a CloudControl deployment:

• The Buildpack parses the composer.json file to determine which PHP version / extensions need to be installed after the cctrlapp application/deployment push is received
• Composer itself prefers the composer.lock file (if available) to install the application dependencies.

Conclusion, when deploying an application to CloudControl, do NOT use the same composer.json file that was used for the application, only commit the generated composer.lock file. This is something that can be done during an automated build process.

Note that this approach will generate a warning message like:

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.

But this is expected and can therefore be ignored.

When will Symfony 3.0 be supported? It currently won't push/deploy:

1. $ composer create-project symfony/framework-standard-edition symfony3-test

2. Change composer.json according to cloudControl blog

   "php": ">=5.5.9", ===> "php-64bit": ">=5.5.9",
   

3. Push

   $ git init and commit..
   $ cctrlapp mysymfony3testapp push
   

Result

...
       [Symfony\Component\Debug\Exception\ContextErrorException]                                                                                                                                                                                                                                                                                                                                                
       Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.

     cache:clear [--no-warmup] [--no-optional-warmers] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>

Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache handling the post-install-cmd event terminated with an exception

  [RuntimeException]                                                                                                                                                                                                                                                                                                                                                                                            
  An error occurred when executing the "'cache:clear --no-warmup'" command:                                                                                                                                                                                                                                                                                                                                     

    [Symfony\Component\Debug\Exception\ContextErrorException]                                                                                                                                                                                                                                                                                                                                                   
    Warning: date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.

  cache:clear [--no-warmup] [--no-optional-warmers] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>                                                                                                                                                                                                         

install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-plugins] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--ignore-platform-reqs] [--] [<packages>]...

 !     cloudControl push rejected, failed to compile php app
 !
remote: error: hook declined to update refs/heads/master
To ssh://[email protected]/repository.git
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'ssh://[email protected]/repository.git'

The idea of the custom buildpack is to allow users to determine what PHP version and extensions are installed. However, lets revert the part about the extensions. The purpose of Composer is to:

• derive dependencies based on composer.json files
• install derived dependencies

So, why won't we let Composer determine what extensions are required?

Lets take the following example:

    "require": {
        "php-64bit": "5.5.23",
        "beberlei/assert": "*"
}

The beberlei/assert package, depends on the ext-mbstring extension. I would expect that based on that dependency, the buildpack would install it. This way only the 'minimal' set of extensions would be installed, optimizing the resulting image.

Other examples to be used during testing:

• klarna/checkout
  • ext-curl
• intervention/image
  • ext-fileinfo

Of course, for stuff like database connections that require extensions like MySQL and MongoDB, the author of the application would need to add the dependencies to its own composer.json file...

During startup of the container, we run some PHP scripts using PHP-CLI which require the cURL extension. When checking why these scripts fail when using the custom-buildpack with the PHP 5.5.23 image, two problems were identified:

• wrong php executable is used? This is stil on PHP 5.4..
• incorrect path used for the main and additional parsed .ini files

cctrlapp application/deployment run bash

~$ php -v
PHP 5.4.41-1+deb.sury.org~precise+2 (cli) (built: May 24 2015 15:41:28) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

~$ php --ini
Configuration File (php.ini) Path: /etc/php5/cli
Loaded Configuration File:         /etc/php5/cli/php.ini
Scan for additional .ini files in: /app/php/conf
Additional .ini files parsed:      (none)

~$ /srv/www/php-5.5.23/bin/php -v 
PHP 5.5.23 (cli) (built: Apr 22 2015 16:53:10) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

~$ /srv/www/php-5.5.23/bin/php --ini
Configuration File (php.ini) Path: /srv/www/php-5.5.23/etc
Loaded Configuration File:         (none)
Scan for additional .ini files in: /app/php/conf
Additional .ini files parsed:      (none)

Note that for the latter one, NO ini files are parsed at all...

The path to the additional .ini files is /srv/www/php-5.5.23/etc/conf.d/extensions.ini

With this command I managed to get the extensions loading, but it is not the ideal solution:
/srv/www/php-5.5.23/bin/php -c /srv/www/php-5.5.23/etc/conf.d/extensions.ini

With a composer.json with:

"require": {
        "php-64bit": "5.6.10"
    }

and a container configuration set to 256M of available memory per container, phpinfo() shows:

memory_limit 128M

This can be manipulated by using a .buildpack/php/conf/php.ini file with a setting like:

memory_limit = 256M

Not sure whether this last configuration should be allowed to be set by a 'user'.

Just wondering what the policy is regarding new versions of PHP, for example PHP 5.6.14 has been available for two weeks.

According to https://semverio.cloudcontrolled.com/php/versions this version can not be used yet on CloudControl. Is there an automatic mechanism or does each version have to be verified and added manually?

Just wondering, no big 'issue' 😄

An error occurs when using the following composer.json snippet and pushing the changes:

"require": {
        "php-64bit": "5.6.10",
        "ext-newrelic": "*"
    }

The error:

remote: -----> Receiving push
remote: -----> Using php version 5.6.10
remote: 
remote: gzip: stdin: not in gzip format
remote: tar: Child returned status 1
remote: tar: Error is not recoverable: exiting now
remote:  !     cloudControl push rejected, failed to compile custom app
remote:  !
remote: -----> Custom buildpack provided
remote: error: hook declined to update refs/heads/master

Obviously, this causes the application to stop reporting to New Relic.

This time by using "php-64bit": ">=5.5 <7.0" again I receive a
"-----> Found php version definition >=5.5 <7.0
! cloudControl push rejected, failed to compile php app"

Locally I have a PHP 5.5 (>=5.5) but I want to try a remote 5.6 (< 7.0). Otherwise I have to use two different definitions for local and remote deployment which I want to avoid in any case.

The buildpack's framework detection expects Yii apps to have a seperate webroot. This seems to be the default when created via the command line script and is probably a good idea in general. However there are other use cases possible. We should discuss if and how we could support Yii apps with a index.php or a .htaccess file in the repository root directly and not only in a seperate webroot.

I tried to use PHP 7, but it seems semverio.cloudcontrolled.com does not yet know about it.

When will this be available?

I was trying to deploy with Custom PHP in composer and it produced the following error:

-----> Receiving push
-----> Found php version definition ~5.5.28
-----> Using php version php-5.5.28
bzip2: (stdin) is not a bzip2 file.
tar: Child returned status 2
tar: Error is not recoverable: exiting now
! cloudControl push rejected, failed to compile php app
!

It's likely not required at runtime and should especially not remain in www/

It would be great to have the environment variables (DEP_NAME, DEP_ID, DEP_VERSION, CRED_FILE, ...) available like in the deployment itself.

Those are required to actually compile the package according to its deployment target (e.g. production or stage), e.g. when using composer with script handlers.

After stumbling upon this article and this installation guide, I was wondering what CloudControl's stance is on supporting HTTP/2.

It seems eventually Varnish will also support it...

Did you guys already experiment with it?

This setting should be generally higher or be possible to configure.

Currently you have to use the most specific version constraint, for example:

    "require": {
        "php-64bit": "5.5.23",
    }

It would be great to be able to use ~5.5.10, so composer will run smoothly e.g. on local environments, that do not match the patch version.

The framework detection creates confusing messages for CakePHP apps.

-----> CakePhp Framework detected 
       You didn't push the plugins folder, please check your .gitignore file. 
       You didn't push the vendors folder, please check your .gitignore file.

Apps still work. Either the wording needs to be changed to reflect this is just an INFO level message, or the output should be removed alltogether.

PHP 5.5 comes bundled with opcache, which is a replacement for the OPCODE part of APC

Enabling opcache this can be done with an additional file: .buildpack/php/conf/opcache.ini:

[OPcache]
zend_extension = opcache.so

Great! PHP files are now OPCODE cached.

However, APC also offered a User Cache => a place to quickly store application information in memory. This is great when using a two-level cache, for example:

• APC User Cache as a fast cache, not persisted, every redeploy of the container the cache is cleared
• database as a slow cache, persistent, acts a fall back mechanism.

For PHP 5.5, it is advised to use APCu, the user part of APC.

Trying to install it with composer.json:

"require": {
    "php-64bit": "5.5.23",
    "ext-apcu": "*"
}

Results in a warning:

-----> Receiving push
-----> Using php version 5.5.23
-----> Installing composer dependencies...
PHP Warning:  PHP Startup: Unable to load dynamic library '/srv/www/php-5.5.23/lib/php/extensions/apcu.so' - /srv/www/php-5.5.23/lib/php/extensions/apcu.so: cannot open shared object file: No such file or directory in Unknown on line 0

Can this extension be added to the list of allowed extensions? This way applications that used APC on PHP 5.4 will not break, since APCu is compatible.

Pinky does provide Apache as part of the stack. Trinity does not anymore. Extend the PHP buildpack to include Apache.

The detect condition is wrong and short circuits if there's a kohana.php

Pushing at 04-09-2015 around 12:00 GMT+0200 seems to fail because of a missing library:

cctrlapp projectName/acceptation push

Counting objects: 244, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (210/210), done.
Writing objects: 100% (244/244), 47.18 KiB | 0 bytes/s, done.
Total 244 (delta 173), reused 0 (delta 0)

-----> Receiving push
-----> Found php version definition 5.6.12
-----> Using php version php-5.6.12
-----> Installing composer dependencies...
php: /usr/lib/x86_64-linux-gnu/libxml2.so.2: version `LIBXML2_2.9.0' not found (required by php)
 !     cloudControl push rejected, failed to compile custom app
 !     
-----> Custom buildpack provided
remote: error: hook declined to update refs/heads/acceptation

around 11:30 a push to our test environment still worked...