Variables in manifest.yml
The post about deploying a Node.js application to Bluemix warned about a potential problem with having a single manifest.yml in use by multiple developers. The problem occurs in a situation where the deployment subtarget (hostname) of an application has a fixed value in the manifest. If two developers try to deploy their application to the same hostname, Bluemix rejects second and subsequent deployment attempts because of the conflict as to which of the two applications should run on the hostname, e.g. hello-world.ng.bluemix.net
The post suggested manually changing a postfix in the manifest.yml file in case if Bluemix rejects deployment attempts due to the same hostname error. Of course, this approach is not acceptable in most cases, especially if one tries to automate the deployment process. One way to address this problem is to use features of bash and sed to introduce randomly generated numbers characters into the manifest.yml file. For example, you can create a manifest.yml.template file where the host parameter is specified as follows:
Then, prior to performing a push using the Cloud Foundry cf tool, you can execute the following sed command to generate a manifest.yml file where the string $RANDOM is replaced with a randomly generated number.
Use of random numbers in the application hostname makes the possibility of name collisions unlikely but introduces another problem: finding out the URL of an application after the deployment process completes. The cf tool has a command to help called cf routes that returns up to date information about active hostname URLs and corresponding applications.
Zend Server Buildpack
During the deployment process described in the previous post, the package.json file provided a hint for Bluemix to use the Node.js runtime. Without this hint the application would have failed to stage because Bluemix would not know which runtime to prepare for the application.
Buildpacks are used by Cloud Foundry to prepare the environment for running an application (e.g. setting environment variables, copying settings files into the right places), compile binaries (if any) and launch the application in the runtime. A detailed explaination of buildpacks is outside the scope of this post and more detail is available from Cloud Foundry and Heroku documentation. It is important to note that some buildpacks, such as the one for Node.js, are built into Bluemix which means that the buildpack does not have to be specified explicitly to the cf push command.
Given enough time and effort one can create a custom buildpack for a runtime that is not built into Bluemix. Once the buildpack is available on the web via git, Bluemix can use git clone of the buildpack repository to copy the buildpack to the execution environment during the deployment process and launch an application in the custom runtime. The next section describes how to use a custom buildpack for a Zend Server, a PHP runtime to run a simple Hello World application on Bluemix
PHP Hello World Application
The Hello World application in index.php is very simple. The <?php prefix on line 1 instructs the PHP interpreter to process the code between the prefix and the closing ?> bracket on line 3. The actual code on line 2 just prints "Hello World" to any HTTP request sent to the PHP container running the application.
The parameters in the manifest.yml are covered earlier in this post and in the previous post while a more detailed explanation is available from the Cloud Foundry documentation.
The following is a snippet of the application deployment session to Bluemix, starting with
cf push hello-world-php command.
Note that due to variability of download speeds it may take a while to deploy the application. If you are seeing problems with timeout when deploying the application, try setting the CF_STARTUP_TIMEOUT and CF_STAGING_TIMEOUT to be at least 15 minutes.