In this article, we are going to use a Cloud Foundry App in Bluemix, and deploy static web assets. As of this writing, we should be able to run a static website for free.
Starting with Bluemix and Cloud Foundry
Register at http://www.ibm.com/cloud-computing/bluemix/. Because we are not developing on Bluemix resources, we do not need to create a Cloud Foundry App. Instead, we upload our own static assets and buildpack.
The command line tool
cf (for Cloud Foundry) provides a standard way to push
apps and data to a CF-compliant container. I downloaded the OS X binary from
cf was installed in
$ which cf /usr/local/bin/cf $ cf --version cf version 6.15.0+fa1bfe2-2016-01-13
Next, an API connection must be made to your CF provider. For the rest of this article, I’m using IBM Bluemix.
Making a connection to Bluemix
$ cf api https://api.ng.bluemix.net Setting api endpoint to https://api.ng.bluemix.net... OK API endpoint: https://api.ng.bluemix.net (API version: 2.40.0) Not logged in. Use 'cf login' to log in.
Log in using your email address.
Establishing credentials with Bluemix
$ cf login -u email@example.com -o firstname.lastname@example.org -s dev API endpoint: https://api.ng.bluemix.net Password> Authenticating... OK Targeted org email@example.com Targeted space dev API endpoint: https://api.ng.bluemix.net (API version: 2.40.0) User: firstname.lastname@example.org Org: email@example.com Space: dev
I’m using the community-provided
staticfile-buildpack from https://github.com/cloudfoundry/staticfile-buildpack.
As of this writing, this buildpack is not one of the built-ins at Bluemix.
Listing server-installed build packs
$ cf buildpacks Getting buildpacks... buildpack position enabled locked filename liberty-for-java 1 true false buildpack_liberty-for-java_v2.5-20160209-1336.zip sdk-for-nodejs 2 true false buildpack_sdk-for-nodejs_v3.0-20160125-1224.zip noop-buildpack 3 true false noop-buildpack-20140311-1519.zip java_buildpack 4 true false java-buildpack-v3.5.1.zip ruby_buildpack 5 true false ruby_buildpack-cached-v1.6.7.zip nodejs_buildpack 6 true false nodejs_buildpack-cached-v1.5.0.zip go_buildpack 7 true false go_buildpack-cached-v1.6.2.zip python_buildpack 8 true false python_buildpack-cached-v1.5.1.zip php_buildpack 9 true false php_buildpack-cached-v4.1.5.zip aspnet5-experimental 10 true false buildpack_aspnet5-experimental_v0.7-20151022-1257.zip xpages_buildpack 11 true false xpages_buildpack_v9.0.1-bmix-pb-20151217-8000.zip aspnet5-experimental_v0_6-20150916-1220 12 true false buildpack_aspnet5-experimental_v0.6-20150916-1220.zip liberty-for-java_v2_3-20151208-1311 13 true false buildpack_liberty-for-java_v2.3-20151208-1311.zip sdk-for-nodejs_v2_8-20151209-1403 14 true false buildpack_sdk-for-nodejs_v2.8-20151209-1403.zip
It’s recommended for static sites a sentinel file called
Staticfile be created for automatic
buildpack detection if the host allows. In Hugo, contents from the
are copied verbatim into the output directory, defaulted to
Creating buildpack hint file
$ touch ~/code/mercuryroses.hugo/static/Staticfile
We should now be set up to deploy the buildpack to the CF host, along with our site
content. Go into your static site’s output “root” folder and run
cf. The application name,
which the host uses to identify the app, as well as the buildpack, are installed to the host.
My app name is
mercuryroses. If it doesn’t exist, it will be created automatically and be
available on the Bluemix dashboard; if it already exist, it will be updated with the settings
Initial push of static content to Bluemix
$ cd ~/code/mercuryroses.hugo/public $ cf push mercuryroses -b https://github.com/cloudfoundry-incubator/staticfile-buildpack.git Updating app mercuryroses in org firstname.lastname@example.org / space dev as email@example.com... OK Uploading mercuryroses... Uploading app files from: /Users/hanna/code/mercuryroses.hugo/public Uploading 1.1M, 384 files Done uploading OK Stopping app mercuryroses in org firstname.lastname@example.org / space dev as email@example.com... OK Starting app mercuryroses in org firstname.lastname@example.org / space dev as email@example.com... -----> Downloaded app package (512K) -----> Downloaded app buildpack cache (4.0K) Cloning into '/tmp/buildpacks/staticfile-buildpack'... Submodule 'compile-extensions' (https://github.com/cloudfoundry/compile-extensions.git) registered for path 'compile-extensions' Cloning into 'compile-extensions'... Submodule path 'compile-extensions': checked out '26a578c06a62c763205833561fec1c5c6d34deb6' -------> Buildpack version 1.3.1 Downloaded [https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/nginx/nginx-1.9.10-linux-x64.tgz] -----> Using root folder -----> Setting up nginx -----> Uploading droplet (3.1M) 0 of 1 instances running, 1 starting 1 of 1 instances running App started OK App mercuryroses was started using this command `sh boot.sh` Showing health and status for app mercuryroses in org firstname.lastname@example.org / space dev as email@example.com... OK requested state: started instances: 1/1 usage: 512M x 1 instances urls: mercuryroses.mybluemix.net last uploaded: Fri Feb 12 04:57:05 UTC 2016 stack: cflinuxfs2 buildpack: https://github.com/cloudfoundry-incubator/staticfile-buildpack.git state since cpu memory disk details #0 running 2016-02-11 10:57:57 PM 0.0% 4.7M of 512M 10.7M of 1G
Specifying the buldpack should only need to be done once for each app.
cf stores your settings
so future updates only need
cf push appname.
You can also check the status of your app with
cf app appname.
Checking app status
$ cf app mercuryroses Showing health and status for app mercuryroses in org firstname.lastname@example.org / space dev as email@example.com... OK requested state: started instances: 1/1 usage: 512M x 1 instances urls: mercuryroses.mybluemix.net, www.mercuryros.es last uploaded: Fri Feb 12 23:07:21 UTC 2016 stack: cflinuxfs2 buildpack: https://github.com/cloudfoundry-incubator/staticfile-buildpack.git state since cpu memory disk details #0 running 2016-02-12 05:07:54 PM 0.0% 4.8M of 512M 13.4M of 1G
Setting up DNS
So far, the web site is visible at appname.mybluemix.net: http://mercuryroses.mybluemix.net1. If that’s all you need, then you’re done. However, I also want to make my site available as http://mercuryros.es2 / http://www.mercuryros.es3.
Two components are involved with updating DNS:
- Updating Bluemix with a custom domain mercuryros.es.
- Updating the domain registrar’s DNS information to point to Bluemix.
Configuring DNS in Bluemix
Your apps appear on the Bluemix dashboard. Click on the gear (“Menu”) icon on your app and select “Edit Routes and App Access”.
The first screen has one route already defined:
Click “Add route” then put “www” in the left box, and choose “Add Custom Domain”. Type in your own domain name (mercuryros.es) and save. You should now have two routes:
We’re done with Bluemix config. Now we need to go to our DNS registrar.
I used Namecheap to register the mercuryros.es domain. To point it to my Bluemix app, I went into Advanced DNS and created the following records:
|CNAME Record||www.mercuryros.es||mercuryroses.mybluemix.net||30 min|
|URL Redirect Record||@||http://www.mercuryros.es4|
Then waited for DNS to propagate - I didn’t track it but I waited maybe 30-45 minutes, and my site was now reachable from http://www.mercuryros.es/5.
I hope this article helped you set up and push your static site to Bluemix!
This page was updated on 7 Jan 2019 to make inactive links inert.