Using the OpenShift Client Binary (oc)

Overview

The minishift start command creates an OpenShift cluster using the cluster up approach. For this purpose it copies the oc binary onto your host.

The oc binary is located in the ~/.minishift/cache/oc/v3.11.0 directory, assuming that you use Minishift’s default version of OpenShift. You can add this binary to your PATH using minishift oc-env, which displays the command you need to type into your shell.

The output of minishift oc-env differs depending on the operating system and the shell type.

  1. $ minishift oc-env
  2. export PATH="/home/john/.minishift/cache/oc/v1.5.0:$PATH"
  3. # Run this command to configure your shell:
  4. # eval $(minishift oc-env)

Minishift CLI Profile

As part of the minishift start command, a CLI profile named minishift is also created. This profile, also known as a context, contains the configuration to communicate with your OpenShift cluster.

Minishift activates this context automatically, but if you need to switch back to it after, for example, logging into another OpenShift instance, you can run:

  1. $ oc config use-context minishift

For an introduction to oc usage, see the Get Started with the CLI topic in the OpenShift documentation.

Logging Into the Cluster

By default, cluster up uses AllowAllPasswordIdentityProvider to authenticate against the local cluster. This means any non-empty user name and password can be used to login to the local cluster.

The recommended user name and password is developer and developer, respectively. This is because they are already assigned to the default project myproject and also can impersonate the administrator. This allows you to run administrator commands using the --as system:admin parameter.

To login as administrator, use the system account:

  1. $ oc login -u system:admin

In this case, client certificates are used. The certificates are stored in ~/.kube/config. The cluster up command installs the appropriate certificates as a part of the bootstrap.

If you run the command oc login -u system -p admin, you will log in but not as an administrator. Instead, you will be logged in as an unprivileged user with no particular rights.

To view the available login contexts, run:

  1. $ oc config view

Accessing the Web Console

To access the OpenShift Web console, you can run this command in a shell after starting Minishift to get the URL of the Web console:

  1. $ minishift console --url

Alternatively, after starting Minishift, you can use the following command to directly open the console in a browser:

  1. $ minishift console

Accessing OpenShift Services

To access a service that is exposed with a route, run this command in a shell:

  1. $ minishift openshift service [-n NAMESPACE] [--url] NAME

For more information refer also to Exposing Services.

Viewing OpenShift Logs

To access OpenShift logs, run the following command after starting Minishift:

  1. $ minishift logs

Updating OpenShift Configuration

While OpenShift is running, you can view and change the master or the node configuration of your cluster.

To view the OpenShift master configuration file master-config.yaml, run the following command:

  1. $ minishift openshift config view

To show the node or kubeapi-server configuration instead of the master configuration, specify the target flag.

For details about the view sub-command, see the minishift openshift config view synopsis.

After you update the OpenShift configuration, OpenShift will transparently restart.

Example: Configuring cross-origin resource sharing

In this example, you configure cross-origin resource sharing (CORS) by updating the OpenShift master configuration to allow additional IP addresses to request resources.

By default, OpenShift only allows cross-origin resource requests from the IP address of the cluster or from localhost. This setting is stored in the corsAllowedOrigins property of the master configuration file master-config.yaml.

To change the property value and allow cross-origin requests from all domains, run the following command:

  1. $  minishift openshift config set --patch '{"corsAllowedOrigins": [".*"]}'

If you get the error The specified patch need to be a valid JSON. when you run the above command, you need to modify the above command depending on your operating system, your shell environment and its interpolation behavior.

For example, if you use PowerShell on Windows 7 or 10, modify the above command to:

  1. PS> minishift.exe openshift config set —patch ‘{\”corsAllowedOrigins\”: [\”.\”]}’

If you use Command Prompt, you might need to use the following:

  1. C:\> minishift.exe openshift config set —patch “{\”corsAllowedOrigins\”: [\”.\”]}”

Example: Changing the OpenShift Routing Suffix

In this example, you change the OpenShift routing suffix in the master configuration.

If you use a static routing suffix, you can set the routing-suffix flag as part of the minishift start command. By default, Minishift uses a dynamic routing prefix based on nip.io, in which the IP address of the VM is a part of the routing suffix, for example 192.168.99.103.nip.io.

If you experience issues with nip.io, you can use xip.io, which is based on the same principles.

To set the routing suffix to xip.io, run the following command:

  1. $ minishift openshift config set --patch '{"routingConfig": {"subdomain": "<IP-ADDRESS>.xip.io"}}'

Make sure to replace IP-ADDRESS in the above example with the IP address of your Minishift VM. You can retrieve the IP address by running the minishift ip command.

Add component to OpenShift Cluster

To add a component to a running OpenShift Cluster, use the following:

  1. $ minishift openshift component add <component-name>

Example: Add service-catalog component

In this example, service-catalog component can be added as follows:

  1. $ minishift openshift component add service-catalog

List valid components to add to OpenShift cluster

To list valid components which can be add to running OpenShift cluster, use the following:

  1. $ minishift openshift component list