How-tos

Deploying to Kubernetes with the IBM Cloud Developer Tools CLI

Share this post:

The recent release of the IBM Cloud Developer Tools CLI (formerly referred to as the Bluemix CLI dev plugin) is packed full of new features, including enablement for existing projects, productivity enhancements, bug fixes, and what I’d like to focus on in this post, support for Kubernetes deployments.

What is Kubernetes?

For those not yet familiar, Kubernetes is an open source platform designed to automate deploying, scaling, and operating application containers.   This lets you package your application(s) within Docker images and deploy/scale applications quickly and easily in a self healing environment.  This is the backbone for the IBM Container service, as well as the IBM Cloud Private offering.  In this post, we will focus on Kubernetes deployment to public IBM Cloud environment.

Kubernetes Support?

In general, the IBM Cloud Developer Tools CLI enables rapid application development and deployment by generating template applications that you can run immediately or customize as the starter for your own solutions.

For the CLI dev extension, adding support for Kubernetes environments means two things:

  1. In addition to generating starter application code and Dockerfile/CloudFoundry assets (which were already generated prior to this release), the code generators used by the dev CLI and web console will now generate files to aid deployment into Kubernetes environments.  Specifically, the templates now generate Helm charts that describe the application’s initial Kubernetes deployment configuration, and are easily extended to create multi-image or complex deployments as needed.
  2. The IBM Cloud Developer Tools CLI’s `deploy` command now supports deployment to Kubernetes environments in addition to Cloud Foundry environments.

You can see a preview of the new Kubernetes support within the IBM Cloud Developer Tools CLI in the video below:

If you run bx dev deploy without any additional arguments or changes to the cli-config.yml configuration file, the CLI will target a Cloud Foundry application deployment by default.

You can instruct the CLI dev plugin to deploy to a Kubernetes environment in two ways:

Set your deployment preferences in cli-config.yml

You can instruct the bx dev deploy command to target Kubernetes environments by modifying the cli-config.yml file in your application’s root directory.  Setting the following values inside of your cli-config.yml file will enable Kubernetes deployment:

chart-path: "chart/myapplication"
deploy-target: "container"
deploy-image-target: "registry.<Bluemix Region>.bluemix.net/<Container Registry Namespace>/<App-Name>"
ibm-cluster: "mycluster"

The chart-path value describes the relative path to your helm chart.  This should already be set for you by the bx dev create or bx dev enable process.

The deploy-target value describes the target environment.  Valid values are either “buildpack” (Cloud Foundry) or “container” (Kubernetes).

The deploy-image-target value specifies the target where your Docker image should be pushed.  If you’re logged in and targeting an application running on the Bluemix Container Service, this should be in the format registry.<Bluemix Region>.bluemix.net/<Container Registry Namespace>/<App-Name>.   A sample in this format would be “registry.ng.bluemix.net/andrewtrice/my-test-application”.  You can also specify the deployment image target as just an application name (no spaces), such as my-test-application.  In this case, the deploy command will not upload to a container registry, instead it will push to the environment defined within your KUBECONFIG environment variable, such as a local MiniKube cluster.

If you are logged into IBM Cloud, the ibm-cluster value specifies the name of your Kubernetes cluster on the IBM Container Service that will be targeted for deployment.  If you are not logged in, this will be ignored and assume the deploy-image-target is pointing at a MiniKube or IBM Cloud public environment.  If you do not already have a Kubernetes cluster on IBM Cloud, you can create one on the IBM Container Service.

When targeting Kubernetes on the IBM Container Service, the deploy command will:

  • Build and upload the Docker image of your application to the IBM Container Registry
  • Download the configuration of your Kubernetes cluster on the IBM Cloud
  • Perform a deployment to your Kubernetes cluster using the generated Helm chart.

Note: If you haven’t setup a Helm tiller server in your Kubernetes cluster, that’s ok.  The deploy command will run “helm init” for you, if it is not already configured.

Set your deployment preferences as CLI arguments

If you don’t want to change any configuration files, you can add -t container arguments to your CLI invocation like so:

bx dev deploy -t container

This will instruct the deploy command to target the Kubernetes environment.  When you invoke the deploy command, you’ll be prompted for additional input like the sample below:

$ bx dev deploy -t container

The container deployment image name for the deployment of this project will be:
registry.ng.bluemix.net/andrewtrice/my-test-application

? Press [Return] to accept this, or enter a new value now>

The IBM cluster name for the deployment of this project will be:
mycluster

? Press [Return] to accept this, or enter a new value now>

The first value that you are prompted for is the deployment image target.  This is functionally equivalent to the deploy-image-target cli-config value described above.  The second value you will be prompted for is the name of your cluster on the IBM Cloud.

Your responses to these prompts will be persisted so the values can be easily reused on future deployments.  Both of these values could also be passed as the --deploy-image-target and --ibm-cluster command line arguments.

Getting started

This sounds great, right?  So, now you’re probably wondering “How do I get started?”  The first thing you need to do is install the IBM Cloud Developer Tools CLI, and it’s prerequisite dependencies. While this might sound like a lot of legwork, it’s really not.

If you’re on MacOS or Linux, just open up a terminal and run the following command:

curl -sL https://ibm.biz/idt-installer | bash

If you’re on Windows 10, open Windows PowerShell by right-clicking and select “Run as Administrator” and run the following command:

Set-ExecutionPolicy Unrestricted; iex(New-Object Net.WebClient).DownloadString('http://ibm.biz/idt-win-installer')

This will install the Bluemix CLI, all necessary extensions, git, docker, kubectl, and helm if you don’t already have them installed.  If you’re curious about what this installer is doing “under the covers”, you can check out the installation scripts at https://github.com/IBM-Bluemix/ibm-cloud-developer-tools

Next, make sure you create a namespace for the Bluemix Container Registry by running the namespace-add command:

bx cr namespace-add mynamespace

Now you’re ready to generate a project!  You can generate a new project that contains Kubernetes support by simply running the bx dev create command, or run bx dev enable to create Kubernetes deployment files for an existing Node, Java, Python, or Swift project.

More How-tos stories

How to deliver great performance for global apps on IBM Cloud

A large telecommunications service provider in Europe wants to serve customers in Brazil from their Frankfurt, Germany location. One challenge with such large geographical distances is achieving consistently low latency in order to provide a good user experience. Another challenge is scaling the infrastructure to handle a large number of user requests during peak traffic conditions.

Continue reading

Securing your Python app with OpenID Connect (OIDC)

Some weeks back I introduced to a tutorial on how to analyse GitHub traffic. The tutorial combines serverless technology and Cloud Foundry to automatically retrieve statistics and store them in Db2. The data can then be accessed and analyzed using a Python Flask app. Today, I am going to show you how the web site is protected using OpenID Connect and IBM Cloud App ID.

Continue reading

Custom login page for App ID integration

When developing an application that integrates with App ID, the standard hosted login page has a few options to change the colours or logo. In some cases, this isn't enough and direct customisation is necessary. There exists a handy guide for a custom App ID login screen in mobile applications, however for web applications a little more effort is required.

Continue reading