Compute Services

Community buildpack updates in Bluemix

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:

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, and 1.6.1.
  • ruby_buildpack – the default runtime version is now 2.2.4. The default Bundler version is now 1.11.2. The buildpack provides the following cached Ruby versions: 2.1.8, 2.1.9, 2.2.3, 2.2.4, and 2.3.0. It also includes jruby-1.7.25 and jruby-
  • php_buildpack – the default runtime version is now 5.5.43. The default Nginx version is now 1.9.14. The Composer version was updated to 1.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, and 7.0.5. It also provides other cached dependencies such as: httpd-2.4.20, nginx-1.8.1, and nginx-1.9.14.
  • python_buildpack – the default runtime version is now 2.7.11. The default PIP version is now 8.1.1 and the default setuptools version is 20.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, and 3.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, and 5.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
  • ruby_buildpack
  • php_buildpack
  • python_buildpack
  • nodejs_buildpack
  • java_buildpack

For best results, use the buildpacks provided on Bluemix.

More stories
April 18, 2019

Bring Your Own ALB: DNS with Health Checks and SSL Certificates (Beta)

If you've ever wanted to run a web server, an API gateway, an Ingress controller, a Kafka proxy, a service that has a binary protocol like an MQTT service or database, or essentially anything that runs on TCP (or UDP), you can now run it in IBM Cloud Kubernetes Service on a host name.

Continue reading

April 17, 2019

Container Orchestration Explained

In the past, we've talked about containerization technology and dove into Kubernetes as an orchestration platform, but we're going to take a step back to look at why container orchestration is necessary and the benefits it brings to both developers and operations teams.

Continue reading

April 12, 2019

Monitoring Your Kubernetes Environment on IBM Cloud with Sysdig

Experience the difference that IBM Cloud Monitoring with Sysdig can make for your Kubernetes deployments by provisioning a free monitoring instance from the IBM Cloud Catalog.

Continue reading