How to install the runtime: Azure and PHP

Since November 2010, developments have opened up Windows Azure features of Windows Azure, but these developments have also made some operational differences, including the installation of PHP on Azure. Here are the methods I could find, and an opinion on their interest.

Installing PHP in Hosted Web Core.

This technique is one that was advocated before the availability of Full IIS Azure, and is based on installing PHP as a Web Role. This technique is still usable, but you have to adjust slightly the projects provided in standard Visual Studio. Indeed, the setting mode and exchange between IIS Hosted Web Core. Hosted Web Core within the parameters of your website are logically in Web.Config, but you can also take control of the IIS settings by relying on the file web.roleconfig. Here, for example the declaration of PHP FastCGI module and its use on the website:
web.roleconfig:
 
  <Configuration> 
    <System.webServer> 
      <Fastcgi> 
        <Application fullpath = "e: \ approot \ php \ php-cgi.exe" /> 
      </ Fastcgi> 
    </ System.webServer> 
  </ Configuration> 
 
Web.config:
 
   <System.webServer> <runAllManagedModulesForAllRequests modules = "true" /> <handler> <add name = "PHPFastcgi" verb = "*" path = "*. php" scriptProcessor = "e: \ approot \ php \ php-cgi. exe "modules =" FastCgiModule "resourceType =" Either "/> </ handlers> 
  ... 
 
Unfortunately, this beautiful mechanical does not work in Full mode (IIS web.roleconfig file is ignored), and the solution is simply to restore it to force your Web Role to switch back to Hosted Web Core, by modifying the file that csdef define your roles, and deleting the sections sites:
 
 <? Xml version = "1.0" encoding = "utf-8"?> <ServiceDefinition name = "JoomlaDansAzure" xmlns = "http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"> <name = WebRole "JoomlaWeb" vmsize = "ExtraSmall"> <! - <Sites> Site> name="Web"> <bindings> <binding name="Endpoint1" endpointName="Endpoint1" /> </ Bindings> </ Site> < / Sites> -> <Endpoints> <InputEndpoint name = "Endpoint1" protocol = "http" port = "80" /> </ Endpoints> <Genres> <Import moduleName = "Diagnostics" /> <Import moduleName = "RemoteAccess "/> <Import moduleName =" RemoteForward "/> </ Imports> </ WebRole> </ ServiceDefinition> 

PHP installation through WebPI.

This technique is currently presented in most posts, and it rests on a simple principle: instead of carrying oneself in PHP, it delegates this task to something that already does this, and is no longer able to manage dependencies.
This delegation of installing in a startup task: just before you insert your new body in the load balancer, it performs a number of tasks in the following form:
 
 <? Xml version = "1.0" encoding = "utf-8"?> <ServiceDefinition name = "InstallPHP" xmlns = "http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"> <name = WebRole "PHPWebRole"> <Locations> <site name = "Web"> <bindings> <Binding name = "HttpIn" endpointName = "HttpIn" /> </ Bindings> </ Site> </ Locations> <ConfigurationSettings> </ ConfigurationSettings > <Startup> <commandLine Task = "InstallPHP.cmd" ExecutionContext = "elevated" TaskType = "simple" /> </ startup> <Endpoints> <InputEndpoint name = "HttpIn" protocol = "http" port = "80" / > </ Endpoints> <Genres> <Import moduleName = "Diagnostics" /> <Import moduleName = "RemoteAccess" /> <Import moduleName = "RemoteForward" /> </ Imports> </ WebRole> </ ServiceDefinition>
  
File InstallPHP.cmd WebPI then uses to select the version of PHP to install (look in the Windows Azure Training Kit for details). The concern is that if you want more control over the installation, you must either create their own feeds (complicated and fragile), or chaining installations WebPI praying for not inconsistent with Azure's length ( and there is a hotfix for Windows 2008 does not apply to Azure, among other things that can block the installation).
Moreover, impossible to define with precision the php.ini or adding an extension.

Manual installation of PHP in IIS Azure in Full.

This is the technique I am currently exploring and right now I'm happy (but I have not covered all possible cases). The idea is to return to the model proposed by Hosted Web Core. The problem of Full IIS is that it is impossible to correctly adjust the components of IIS that are not under the control of the Web.Config. After a bit turned around the issue and read the documentation for manual installation of PHP on IIS done by Ruslan Yakushev, I used the Web.Config and a startup task.
The beginning of the packaging is identical to that of PHP as HWC: put the PHP runtime in a directory at the root of the website (you can also deport him elsewhere on the disc if desired using other startup tasks but I have not yet refined enough to take care of this kind of configuration).
It then inserts a startup task of the following form in csdef:
 
  <Startup> 
        <Task commandLine = "PHP \ InstallPHP.cmd" ExecutionContext = "elevated" TaskType = "simple"> </ Task> 
  </ Startup> 
 
And file InstallPHP.cmd is simply doing what was web.roleconfig Hosted Web Core mode:
 
  rem Creating IIS FastCGI process pool
 % Windir% \ system32 \ inetsrv \ appcmd set config / section: system.webServer / FastCGI / + [fullpath = 'e: \ approot \ php \ php-cgi.exe]> PHPInstallLog.txt

 rem Creating handler mapping for PHP requĂȘtes
 % Windir% \ system32 \ inetsrv \ appcmd set config / section: system.webServer / handlers / + [name = 'PHP_via_FastCGI' path = '*. php', verb ='*', modules = 'FastCgiModule' scriptProcessor = e: \ approot \ php \ php-cgi.exe 'resourceType =' Either ']>> PHPInstallLog.txt

 rem Configuring FastCGI and PHP recycling
 % Windir% \ system32 \ inetsrv \ appcmd.exe set config-section: system.webServer / fastcgi / [fullpath = 'E: \ AppRoot \ PHP \ php-cgi.exe]. InstanceMaxRequests: 10000>> PHPInstallLog.txt
 % Windir% \ system32 \ inetsrv \ appcmd.exe set config-section: system.webServer / fastcgi / + "[fullpath = 'E: \ AppRoot \ PHP \ php-cgi.exe]. EnvironmentVariables. [Name =' PHP_FCGI_MAX_REQUESTS 'value = '10000'] ">> PHPInstallLog.txt

 rem Configuring FastCGI timeout settings
 % Windir% \ system32 \ inetsrv \ appcmd.exe set config-section: system.webServer / fastcgi / [fullpath = 'E: \ AppRoot \ PHP \ php-cgi.exe' arguments ='']. activityTimeout: "90 "/ commit: apphost>> PHPInstallLog.txt
 % Windir% \ system32 \ inetsrv \ appcmd.exe set config-section: system.webServer / fastcgi / [fullpath = 'E: \ AppRoot \ PHP \ php-cgi.exe' arguments ='']. requestTimeout: "90 "/ commit: apphost>> PHPInstallLog.txt

 Changing the hiring of substituting php.ini file
 appcmd.exe set config-section: system.webServer / fastcgi / + "[fullpath = 'e: \ approt \ php \ php.exe' arguments ='']. environmentVariables. [name = 'PHPRC' value = ' e: \ approt \ php \] "/ commit: apphost>> PHPInstallLog.txt 
Note: Full mode IIS, the package is deployed twice, once at the root of approot and one in a subdirectory that is physically used by IIS. The deployment technique above uses the version deployed in AppRoot, which removes the PHP directory used by IIS in order not to deploy the PHP runtime in an area of ​​the filesystem accessible by http.
Attention to one last thing: if you prefer to make the association between your site and FastCGI web.config using the example provided in the CGI web roles is incorrect: in fact, it uses%% RoleRoot to designate where the reader is installed your package in the VM Azure, but this environment variable is not available when the Web.Config is parsed, so you have to hardcode E: in this way:
 
 <? Xml version = "1.0"?> <Configuration> <system.web> <compilation debug = "true" targetFramework = "4.0" /> </ system.web> <system.webServer> <runAllManagedModulesForAllRequests modules = "true" /> <handler> <add name = "PHPHandler" verb = "*" path = "*. php" scriptProcessor = "E: \ approot \ php \ php-cgi.exe" modules = "FastCgiModule" resourceType = "Either" /> </ handlers> </ system.webServer> </ configuration> 

0 comments:

Post a Comment