Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Interacting with OpenShift using Container Development Kit

CDK creates a virtual machine and provisions a local, single-node OpenShift cluster in this VM. The following sections describe how CDK can assist you in interacting and configuring your local OpenShift cluster.

For details about managing the CDK VM, see the Basic Usage section.

3.1. Using the OpenShift Client Binary (oc)
Copy link

3.1.1. Overview
Copy link

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_HOME/cache/oc/v3.11.374 directory, assuming that you use the default OpenShift version for CDK. 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. 

$ minishift oc-env
export PATH="/home/user/.minishift/cache/oc/v3.11.374:$PATH"
# Run this command to configure your shell:
# eval $(minishift oc-env)
Copy to Clipboard Toggle word wrap

3.1.2. CDK CLI Profile
Copy link

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.

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

$ oc config use-context minishift
Copy to Clipboard Toggle word wrap

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

3.1.3. Logging Into the Cluster
Copy link

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: 

$ oc login -u system:admin
Copy to Clipboard Toggle word wrap

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.

Note

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: 

$ oc config view
Copy to Clipboard Toggle word wrap

3.1.4. Accessing the Web Console
Copy link

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

$ minishift console --url
Copy to Clipboard Toggle word wrap

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

$ minishift console
Copy to Clipboard Toggle word wrap

3.1.5. Accessing OpenShift Services
Copy link

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

$ minishift openshift service [-n NAMESPACE] [--url] NAME
Copy to Clipboard Toggle word wrap

For more information refer also to Exposing Services.

3.1.6. Viewing OpenShift Logs
Copy link

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

$ minishift logs
Copy to Clipboard Toggle word wrap

3.1.7. Updating OpenShift Configuration
Copy link

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: 

$ minishift openshift config view
Copy to Clipboard Toggle word wrap

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.

Note

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

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: 

$  minishift openshift config set --patch '{"corsAllowedOrigins": [".*"]}'
Copy to Clipboard Toggle word wrap
Note

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: 

PS> minishift.exe openshift config set --patch '{\"corsAllowedOrigins\": [\".*\"]}'
Copy to Clipboard Toggle word wrap

If you use Command Prompt, use the following: 

C:\> minishift.exe openshift config set --patch "{\"corsAllowedOrigins\": [\".*\"]}"
Copy to Clipboard Toggle word wrap

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, CDK 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: 

$ minishift openshift config set --patch '{"routingConfig": {"subdomain": "<IP-ADDRESS>.xip.io"}}'
Copy to Clipboard Toggle word wrap

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

3.1.8. Add Component to OpenShift Cluster
Copy link

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

$ minishift openshift component add <component-name>
Copy to Clipboard Toggle word wrap

3.1.8.1. Example: Add service-catalog component
Copy link

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

$ minishift openshift component add service-catalog
Copy to Clipboard Toggle word wrap

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

$ minishift openshift component list
Copy to Clipboard Toggle word wrap

3.2. Exposing Services
Copy link

3.2.1. Overview
Copy link

There are several ways you can expose your service after you deploy it on OpenShift. The following sections describe the various methods and when to use them.

3.2.2. Routes
Copy link

If you are deploying a Web application, the most common way to expose it is by a route. A route exposes the service as a host name. You can create a route using the Web console or the CLI: 

$ oc expose svc/frontend --hostname=www.example.com
Copy to Clipboard Toggle word wrap

To see a full example of creating an application and exposing it with a route, see the Deploying a Sample Application section.

3.2.3. NodePort Services
Copy link

In case the service you want to expose is not HTTP based, you can create a NodePort service. In this case, each OpenShift node will proxy that port into your service. To access this port on your CDK VM, you need to configure an Ingress IP using oc expose with the parameter type=LoadBalancer.

A common use-case for Ingress IP Self-Service is the ability to expose a database service. The following example shows the complete workflow to create and expose a MariaDB instance using CDK: 

$ minishift start
$ eval $(minishift oc-env)
$ oc new-app -e MYSQL_ROOT_PASSWORD=admin https://raw.githubusercontent.com/openshift/origin/master/examples/db-templates/mariadb-persistent-template.json
$ oc rollout status -w dc/mariadb
$ oc expose dc mariadb --type=LoadBalancer --name=mariadb-ingress
$ oc export svc mariadb-ingress
 ....
ports:
    - nodePort: 30907
 ....
Copy to Clipboard Toggle word wrap

After the service is exposed, you can access MariaDB with the mysql CLI using the CDK VM IP and the exposed NodePort service. 

$ mysql --user=root --password=admin --host=$(minishift ip) --port=30907
Copy to Clipboard Toggle word wrap

3.2.4. Port Forwarding
Copy link

3.2.4.1. Using oc port-forward
Copy link

If you want to quickly access a port of a specific pod of your cluster, you can also use the oc port-forward command of the OpenShift CLI. 

$ oc port-forward POD [LOCAL_PORT:]REMOTE_PORT
Copy to Clipboard Toggle word wrap

3.2.4.2. Using VirtualBox tools
Copy link

In case you’re using the VirtualBox driver plug-in there is another method you can use for port forwarding. This method will allow for permanent port forwarding as well as for forwarding multiple ports at the same time. This method requires you to set up a nodePort as outlined above.

If we go by the example above, we can do the following: 

$ VBoxManage controlvm minishift natpf1 "mariadb,tcp,,3306,,30907"
Copy to Clipboard Toggle word wrap

This will allow us to communicate with the mariadb service on localhost:3306 which might be convenient if you don’t want to change default ports. Additionally, an important advantage of this way of forwarding ports is that we can talk to a service as opposed to just a single pod.

3.3. Accessing the OpenShift Docker Registry
Copy link

3.3.1. Overview
Copy link

OpenShift provides an integrated Docker registry which can be used for development as well. Images present in the registry can directly be used for applications, speeding up the local development workflow.

3.3.2. Logging Into the Registry
Copy link

  1. Start CDK and add the oc binary to the PATH. For a detailed example, see the CDK Quickstart section.
  2. Make sure your shell is configured to reuse the CDK Docker daemon.

  3. Log into the OpenShift Docker registry. 

     $ docker login -u developer -p $(oc whoami -t) $(minishift openshift registry)
    Copy to Clipboard Toggle word wrap

3.3.3. Deploying Applications
Copy link

The following example shows how to deploy an OpenShift application directly from a locally-built Docker image. This example uses the OpenShift project myproject. This project is automatically created by minishift start.

  1. Make sure your shell is configured to reuse the CDK Docker daemon.
  2. Build the Docker image as usual.

  3. Tag the image against the OpenShift registry: 

     $ docker tag my-app $(minishift openshift registry)/myproject/my-app
    Copy to Clipboard Toggle word wrap

  4. Push the image to the registry to create an image stream with the same name as the application: 

     $ docker push $(minishift openshift registry)/myproject/my-app
    Copy to Clipboard Toggle word wrap

  5. Create an application from the image stream and expose the service: 

     $ oc new-app --image-stream=my-app --name=my-app
 $ oc expose service my-app
    Copy to Clipboard Toggle word wrap
Note

If you want to deploy an application using oc run --image […​] then exposed internal registry route doesn’t work. You should use internal registry IP along with your project and app to deploy, as following: 

$ oc run myapp --image 172.30.1.1:5000/myproject/myapp
Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat