Getting Started

In this section we walk you through necessary steps to start using ike. It will take you just a few minutes to start coding!

What do you need

  • oc or kubectl

  • Telepresence CLI tool (and required runtime dependencies)

  • ike binary (see below)

  • Kubernetes cluster with Istio (i.e. Maistra)

Installing ike CLI

Run curl -sL http://git.io/get-ike | bash to get latest ike binary.

You can also specify the version and directory before downloading curl -sL http://git.io/get-ike | bash -s -- --version=v0.0.3 --dir=/usr/bin

Here are all available flags of this installation script

get - downloads ike binary matching your operating system
 
./get.sh [options]
 
Options:
-h, --help          shows brief help
-v, --version       defines version specific version of the binary to download (defaults to latest)
-d, --dir           target directory to which the binary is downloaded (defaults to random tmp dir in /tmp suffixed with ike-version)
-n, --name          saves binary under specific name (defaults to ike)
bash

Installing cluster component

Before you can start using CLI we have to add few backend bits to the cluster, so that we can safely swap services you will work on.

If you’re using Openshift you can install the istio-workspace operator via the Operator Hub in the web console.

If you’re on vanilla Kubernetes you can install it by installing the Operator Lifecycle Management using the Operator SDK:

operator-sdk install
operator-sdk run bundle quay.io/maistra/istio-workspace-operator-bundle:latest
bash
The images are available in our Quay repository https://quay.io/repository/maistra/istio-workspace?tab=tags

Using ike CLI

ike develop  \
  --deployment details-v1 \ (1)
  --port 9080 \ (2)
  --watch \ (3)
  --run 'ruby details.rb 9080' \ (4)
  --route header:end-user=alien-ike \ (5)
bash

Now you have process based on your local code base which proxies connections from/to your Kubernetes cluster! Have fun hacking!

Let’s break it down to see what is going on under the hood:

1 Name of the Deployment or DeploymentConfig you want to work with.
2 Exposed port of the service.
3 Whether to watch changes in the file system and re-run the process when they occur.
4 Command to run.
5 Route differentiation based on which the traffic will be directed to your forked service.
All command line flags can also be persisted in the configuration file and shared as part of the project. Jump to configuration section for more details.