Category: Bluemix

Logging in to Bluemix via wsk

To set up the authentication for the OpenWhisk cli tool wsk you do this:

The host and key are provided to from your OpenWhisk supplier. For Bluemix OpenWhisk, you can find it by logging in and then going to the Download OpenWhisk CLI page.

To make my life easier, I use a bash function to swap OpenWhisk environments and I documented it in my Switching OpenWhisk Environments article.

Log into Bluemix for API Gateway

OpenWhisk also comes with an API Gateway and authentication for this on Bluemix OpenWhisk, at least, is different. The wsk api set of commands don't work unless you've logged into Bluemix using wsk bluemix login, for which you need your Bluemix username and password.

A better way to do it is to use the --sso switch to wsk bluemix login which will use the credentials from the main Bluemix command line tool which is called bx. You can grab bx from this page and then you authenticate using:

Note that you need an API host for bx login. The easiest way to get this is to take your OpenWhisk one and change the openwhisk to api. i.e. if you OpenWhisk host is, then the bx one is You can always find your OpenWhisk host using wsk property get --apihost

The reason we use bx login is that you can create an API key rather than using your username and password which is much better for automation. I recommend you do this by following the instructions on the Managing API Keys page and then save the API key file to your local disk. I put it in ~/.bx_apikey.json.

Automatically logging into to Bluemix

Given that you have a Bluemix API key file and you have set the apihost and auth key for your wsk, then you can log into Bluemix using this handy function:

You can now use the wsk api commands to work with the API Gateway on the correct Bluemix region, organisation and namespace without having to enter your Bluemix password .

Why do it this way around?

You only need to be logged into bx in order to work with the API Gateway. It turns out that I don't do this very often and as it can take up to 10 seconds to log into Bluemix and it's less than 1 second to change the OpenWhisk auth key and host, I just do that nearly all the time. When I do find that I need to work with Bluemix's API Gateway, then I can simply do bxlogin and it will log me into the correct region, organisation and namespace based on the current wsk information which is where I'm currently working.

It just makes the Bluemix authentication a little less painful, but I can't help but think that this should all be quicker and easier for Bluemix OpenWhisk customers that don't use the Bluemix Cloud Foundry offering.

Switching OpenWhisk environments

When developing with OpenWhisk, it's useful to use separate environments for working locally or on the cloud for development, staging and production of your application. In OpenWhisk terms, this means setting the host and the API key for your wsk command line application.

(Of course, for live and staging, ideally, you will be using a build server!)

For a Vagrant install of OpenWhisk, the host is and the key can be found inside the ansible provisioning files. On Bluemix, the host is found on the Download OpenWhisk CLI page, buried in a command that you can copy. Separate environments is most easily done using separate "namespaces" as each space has its own key.

To avoid having to keep looking up the correct keys, I wrote a simple Bash function in my .bash_profile file:

(Actual keys are stored separately.)

This code uses a case statement to set up the right host and key to use. I'm lazy, so just hardcode my Bluemix keys via environment variables. There's probably a better way to that though. For the local Vagrant instance, I get the key directly from the file used by Ansible for provisioning. Again, due to laziness, I've hardcoded the Vagrant VM's IP address.

Lastly I set display the current host and namespace – tput is my new favourite bash command!

Switching environments

I can then use the function to switch to my Vagrant installation like this:

Or, I can switch to my cloud development environment using:

Updating the CLI tool

I also have a script to update the CLI tool:

This is a quick way to collect the latest version of the Bluemix version of the wsk app.