Deploying to IBM Cloud Private with IBM Cloud Developer Tools CLI

Share this post:

IBM Cloud Private is an application platform for developing and managing on-premises, containerized applications. It is an integrated environment for managing containers that includes the container orchestrator Kubernetes, a private image repository, a management console, and monitoring frameworks.

The recent promotion of the IBM Cloud Developer Tools to 1.0 introduced support for Kubernetes deployments.  This support is not just to the Kubernetes environment on the public IBM Cloud; it also supports IBM Cloud Private (formerly known as Spectrum Conductor for Containers).  This means that you can use the the IBM Cloud Developer Tools CLI to generate starter applications and also perform deployments to your IBM Cloud Private environments.

To install the IBM Cloud Developer Tools, follow these instructions.  Once installed, ensure your Helm version is appropriate for your IBM Cloud Private environment.  To get a particular Helm version, for example to install Helm for use with IBM Cloud Private 2.1 use:


Complete these commands:

export DESIRED_VERSION=v2.6.0
curl -sL | bash


Download and install the binary at

Deploying to IBM Cloud Private

First things first, you need to create a starter application to deploy, using the bx dev create command.  Follow the prompts, and select the pattern/language/starter that you’d like to use.  I recommend either the Node.js or Java Basic Web starters – they are simple and easy to follow, but feel free to choose any language or starter.   Once it is created, cd into the new directory on your system.  You can also enable an existing application for Kubernetes deployment using the bx dev enable command.

Once you have an application, you need to configure your local machine to push to the IBM Cloud Private environment.

Configure Docker Registry Access

First, create an entry in your hosts file that maps to mycluster.icp:

# Replace <remote IP> with the IP address of your IBM Cloud Private system
<the remote IP> mycluster.icp

This is added in /etc/hosts on MacOS and Linux, or C:\Windows\System32\drivers\etc\hosts on Windows.

Next we need to add the registry mycluster.icp:8500 for IBM Cloud Private to the list of insecure Docker registries on your local machine.  Instructions by operating system platform are found here.

Finally, log in to the the IBM Cloud Private Docker registry, using the appropriate user and password from your server, and using the hostname you defined above:

docker login mycluster.icp:8500

Configure Kubernetes

There are a couple commands to ensure both the kubectl client and the Kubernetes service account are ready for deployment.

Configure kubectl for access

In the IBM Cloud Private management console, click on your user name in the top right corner, and then select the “Configure client” option.

To ensure that the credentials for your client are valid, you should complete a fresh login to the IBM Cloud Private management console.  If you need help logging into IBM Cloud Private, see these instructions.  “Configure client” will provide a set of commands like the following example, that you then run on your local system:

kubectl config set-cluster mycluster.icp --server=https://<some IP>:8001 --insecure-skip-tls-verify=true
kubectl config set-context mycluster.icp-context --cluster=mycluster.icp
kubectl config set-credentials mycluster.icp-user --token=eyJhbGciOiJSUzI1NiIs...
kubectl config set-context mycluster.icp-context --user=mycluster.icp-user --namespace=default
kubectl config use-context mycluster.icp-context

Configure the service account

Next, you’ll configure the service account in IBM Cloud Private with the image pull secret.  This enables Kubernetes to pull images from the private registry.  Two techniques are provided, in both cases:

  • the user for the secret must be a user associated with the namespace to which you will deploy
  • you must have logged in to IBM Cloud Private previously with this user

The first technique is to edit the serviceaccounts directly with kubectl edit serviceaccounts and add or update this section, substituting <the user> with your user:

- name: <the user>.registrykey

The second technique uses jq, which can be installed using brew (Mac), yum (RedHat Linux) or apt (Ubuntu Linux).

kubectl get serviceaccounts default -o json |
jq  'del(.metadata.resourceVersion)'|
jq 'setpath(["imagePullSecrets"];[{"name":"admin.registrykey"}])' |
kubectl replace serviceaccount default -f -

Where “admin” is your user account associated with the namespace to which you will be deploying, and that you have used to login to IBM Cloud Private, previously.  Upon completion of jq, you will see an entry for the serviceaccount is noted as “replaced.”

Deploy an App

For the simplest deploy experience, you can update your application’s cli-config.yml file to point to the IBM Cloud Private Kubernetes environment by adding these entries:

deploy-target: "container"
deploy-image-target: "mycluster.icp:8500/<Namespace>/<App-Name>"

The  <Namespace> is the namespace on IBM Cloud Private to which you are deploying, for example default. <App-Name> is the name of your application deployment.

The deploy-target value instructs the CLI to target a Kubernetes/container environment, and the deploy-image-target value tells the CLI what to tag your image with for the IBM Cloud Private registry.  Note that if you do not update the cli-config.yml, you will need to specify -t container for the deploy command below, and then the deploy action will query you for the deploy-image-target.

Tip:  for public IBM Cloud users, you must execute bx logout before you deploy to IBM Cloud Private

You’re now ready to deploy your Kubernetes application to the IBM Cloud Private environment.  Just use the deploy command to kick off the deployment:

bx dev deploy

In this case, the deploy command will:

  • Build and upload the Docker image of your application to the IBM Cloud Private image repository
  • Perform a deployment to your IBM Cloud Private Kubernetes cluster using the Helm chart that was generated by the bx dev create or bx dev enable command.

…and now you have generated and deployed your first application to IBM Cloud Private using the IBM Cloud Developer Tools CLI.


Add Comment

Leave a Reply

Your email address will not be published.Required fields are marked *

Kok Wai

Any idea why this error happen? It keep referring to localhost

$ bx dev deploy
Tag the Run image to the Docker registry as mycluster.icp:8500/default/microprofiledemo:0.0.1
Push the Run image to the Docker registry
Failed to execute the action: exit status 1:Error: error installing: Post http://localhost:8080/apis/extensions/v1beta1/namespaces/kube-system/deployments: dial tcp [::1]:8080: getsockopt: connection refused

The ‘helm init’ command failed to complete due to: exit status 1

Untag the Run image from the Docker registry

More How-tos Stories

Use your own branded UI for user sign-in with App ID

With IBM Cloud App ID’s Cloud Directory feature, you can create a user registry, and add sign-up and email/password sign-in to your mobile or web app. Cloud Directory comes with a pre-built sign-in widget that you can use, or if you prefer to use your own branding, you can replace it with your own custom UI. This blog will show you how to use Cloud Directory APIs and add your own custom sign-in screen to an Android application. You can find the Android Cloud Land App on GitHub.

Continue reading

For Performant Swift Serverless actions…

While coding and drafting “Mobile app with a Serverless Backend”, We came up with an idea to use Swift on the server-side for the iOS app (it’s an interesting use case).So, that it will cater the full stack swift developers out there. The same is true for the Android version of the app as well.

Continue reading

App Launch on IBM Cloud Services

In an era of Continuous delivery - the defect fixes, enhancements and changes are delivered swiftly into production. If the users are happy about the change, good Job! If not, it is a risky task to roll back a feature which involves a lot of effort before a significant damage has been done. To avoid such instances, we must partner with our users early in the app development life cycle. Business innovation must be driven by customer experience.

Continue reading