Compute Services
Community buildpack updates in Bluemix
June 30, 2016 | Written by: Jarek Gawor
Categorized: Compute Services | What's New
Share this post:
In the next few days, we will be updating the community buildpacks across all the Bluemix public regions. After the upgrade, the following buildpack versions will be available:
- go_buildpack v1.7.5
- ruby_buildpack v1.6.16
- php_buildpack v4.3.10
- python_buildpack v1.5.5
- nodejs_buildpack v1.5.11
- java_buildpack v3.6
Will my application be affected?
Any existing application deployed with any of the updated buildpacks will not be affected unless it is re-deployed. Once re-deployed, some applications might be affected by the changes in the buildpack dependencies, defaults or other runtime-specific changes outlined below. Most applications should re-deploy and continue to work without any additional updates.
How can my application be affected?
Cached dependencies
Except the java_buildpack
, the community buildpacks installed on Bluemix have a cache of the key runtime versions and other dependencies. Typically, the cache contains two patch versions for each runtime’s major version. For example, the new nodejs_buildpack
contains 0.12.12
and 0.12.13
versions of the 0.12.x
runtime and 0.10.43
and 0.10.44
versions of the 0.10.x
runtime.
If an application requests a specific runtime version that’s not in the cache, the application deployment will fail. Therefore, it is important to check if your application does not rely on a specific dependency that may no longer be in the cache after the buildpack update.
The best practice of specifying runtime versions for your application is to only specify the major version if possible. For example, in case of Node.js applications specify node version as 0.12.x
in your package.json
file instead of the full version such as 0.12.11
. That way your application will be much less susceptible to the cached runtime version changes with each buildpack update. This will also make it easier for your application to stay atop of latest runtime security updates or bug fixes.
Buildpack defaults
The buildpacks will usually use a default version of the runtime or other key component if an application does not explicitly set it.
The defaults may change between buildpack versions. Therefore, it is also important to check if your application is relying on these defaults, as they may affect your application.
The best practice is to always specify your application dependencies explicitly.
What are the key changes?
You can find what runtime versions are supported and all other details on each buildpack’s release page (see the links above). Below is a short list of the key changes in the new buildpack versions that may affect your application:
- go_buildpack – the godep version was updated to
v62
. The buildpack provides the following cached Go versions:1.4.2
,1.4.3
,1.5.3
,1.5.4
,1.6
, and1.6.1
. - ruby_buildpack – the default runtime version is now
2.2.4
. The default Bundler version is now1.11.2
. The buildpack provides the following cached Ruby versions:2.1.8
,2.1.9
,2.2.3
,2.2.4
, and2.3.0
. It also includesjruby-1.7.25
andjruby-9.0.5.0
. - php_buildpack – the default runtime version is now
5.5.43
. The default Nginx version is now1.9.14
. The Composer version was updated to1.0.0
and the HHVM runtime was completely removed. The buildpack provides the following cached PHP versions:5.5.33
,5.5.34
,5.6.19
,5.6.20
,7.0.4
, and7.0.5
. It also provides other cached dependencies such as:httpd-2.4.20
,nginx-1.8.1
, andnginx-1.9.14
. - python_buildpack – the default runtime version is now
2.7.11
. The default PIP version is now8.1.1
and the default setuptools version is20.3
. The buildpack provides the following cached Python versions:2.7.10
,2.7.11
,3.3.5
,3.3.6
,3.4.3
,3.4.4
,3.5.0
, and3.5.1
. - nodejs_buildpack – the default runtime version is now
4.4.2
. The buildpack provides the following cached Node.js versions:0.10.43
,0.10.44
,0.12.12
,0.12.13
,4.4.2
,5.10.0
, and5.10.1
.
How can I quickly get my application running again?
Most applications will not be affected at all by these updates, while some may require minor updates to the dependencies versions or code. Yet, there might be some small number of applications that require additional effort to get them working again.
If you need to get your application back up and running quickly, re-deploy it with the same buildpack version as before the update using an external buildpack. Specifically, when using the cf
command line client, pass the -b <buildpackURL>
option to specify a GitHub URL of the community buildpack. The following list shows the URLs to use:
- go_buildpack –
https://github.com/cloudfoundry/go-buildpack.git#v1.7.0
. - ruby_buildpack –
https://github.com/cloudfoundry/ruby-buildpack.git#v1.6.9
. - php_buildpack –
https://github.com/cloudfoundry/php-buildpack.git#v4.3.0
. - python_buildpack –
https://github.com/cloudfoundry/python-buildpack.git#v1.5.2
. - nodejs_buildpack –
https://github.com/cloudfoundry/nodejs-buildpack.git#v1.5.3
. - java_buildpack –
https://github.com/cloudfoundry/java-buildpack.git#v3.5.1
.
For best results, use the buildpacks provided on Bluemix.
Kubernetes Tutorials: 5 Ways to Get You Building Fast
Ready to start working with Kubernetes? Want to build your Kubernetes skills? The five tutorials in this post will teach you everything you need to know about how to manage your containerized apps with Kubernetes.
Using Portworx to Deploy and Manage an HA MySQL Cluster on IBM Cloud Kubernetes Service
This tutorial is a walkthrough of the steps involved in deploying and managing a highly available MySQL cluster on IBM Cloud Kubernetes Service.
Kubernetes v1.14.1 Now Available in IBM Cloud Kubernetes Service
We are excited to announce the availability of Kubernetes v1.14.1 for your clusters that are running in IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service continues to be the first public managed Kubernetes service to support the latest upstream versions from the community.