Developer CLI Operations

    The developer CLI uses the command, and is used for project-level operations. This differs from the administrator CLI, which uses the oc adm command for more advanced, administrator operations.

    Common Operations

    The developer CLI allows interaction with the various objects that are managed by OKD. Many common oc operations are invoked using the following syntax:

    This specifies:

    • An <action> to perform, such as get or describe.

    • The <object_type> to perform the action on, such as service or the abbreviated svc.

    • The <object_name> of the specified <object_type>.

    For example, the oc get operation returns a complete list of services that are currently defined:

    1. NAME              LABELS                                    SELECTOR                  IP              PORT(S)
    2. docker-registry   docker-registry=default                   docker-registry=default   172.30.78.158   5000/TCP
    3. kubernetes        component=apiserver,provider=kubernetes   <none>                    172.30.0.2      443/TCP
    4. kubernetes-ro     component=apiserver,provider=kubernetes   <none>                    172.30.0.1      80/TCP

    The oc describe operation can then be used to return detailed information about a specific object:

    1. $ oc describe svc docker-registry
    2. Name:            docker-registry
    3. Labels:            docker-registry=default
    4. Selector:        docker-registry=default
    5. IP:            172.30.78.158
    6. Port:            <unnamed>    5000/TCP
    7. Endpoints:        10.128.0.2:5000
    8. Session Affinity:    None
    9. No events.

    Object Types

    Below is the list of the most common object types the CLI supports, some of which have abbreviated syntax:

    If you want to know the full list of resources the server supports, use oc api-resources.

    The following table describes basic oc operations and their general syntax:

    Display an introduction to some core OKD concepts:

    1. $ oc types

    login

    1. $ oc login

    logout

    End the current session:

    1. $ oc logout

    new-project

    Create a new project:

    1. $ oc new-project <project_name>

    new-app

    Creates a new application based on the source code in the current directory:

    1. $ oc new-app .

    Creates a new application based on the source code in a remote repository:

    Creates a new application based on the source code in a private remote repository:

    1. $ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret

    status

    Show an overview of the current project:

    1. $ oc status

    project

    Switch to another project. Run without options to display the current project. To view all projects you have access to run oc projects.

    1. $ oc project <project_name>

    Application Modification Operations

    get

    Return a list of objects for the specified . If the optional <object_name> is included in the request, then the list of results is filtered by that value.

    1. $ oc get <object_type> [<object_name>]

    You can use the -o or --output option to modify the output format.

    1. $ oc get <object_type> [<object_name>]-o|--output=json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]

    The output format can be a JSON or YAML, or an extensible format like custom columns, , and jsonpath.

    For example, the following command lists the name of the pods running in a specific project:

    1. $ oc get pods -n default -o jsonpath='{range .items[*].metadata}{"Pod Name: "}{.name}{"\n"}{end}'
    3. Pod Name: docker-registry-1-wvhrx
    4. Pod Name: registry-console-1-ntq65
    5. Pod Name: router-1-xzw69

    describe

    Returns information about the specific object returned by the query. A specific <object_name> must be provided. The actual information that is available varies as described in object type.

    1. $ oc describe <object_type> <object_name>

    edit

    Edit the desired object type:

    1. $ oc edit <object_type>/<object_name>

    Edit the desired object type with a specified text editor:

    1. $ OC_EDITOR="<text_editor>" oc edit <object_type>/<object_name>

    Edit the desired object in a specified format (eg: JSON):

    1. $ oc edit <object_type>/<object_name> \
    2.     --output-version=<object_type_version> \
    3.     -o <object_type_format>

    volume

    Modify a :

    1. $ oc set volume <object_type>/<object_name> [--option]

    label

    Update the labels on a object:

    1. $ oc label <object_type> <object_name> <label>

    Look up a service and expose it as a route. There is also the ability to expose a deployment configuration, replication controller, service, or pod as a new service on a specified port. If no labels are specified, the new object will re-use the labels from the object it exposes.

    If you are exposing a service, the default generator is --generator=route/v1. For all other cases the default is --generator=service/v2, which leaves the port unnamed. Generally, there is no need to set a generator with the oc expose command. A third generator, --generator=service/v1, is available with the port name default.

    1. $ oc expose <object_type> <object_name>

    delete

    Delete the specified object. An object configuration can also be passed in through STDIN. The oc delete all -l <label> operation deletes all objects matching the specified <label>, including the replication controller so that pods are not re-created.

    1. $ oc delete -f <file_path>
    1. $ oc delete <object_type> <object_name>
    1. $ oc delete <object_type> -l <label>
    1. $ oc delete all -l <label>

    set

    Modify a specific property of the specified object.

    set env

    Sets an environment variable on a deployment configuration or a build configuration:

    1. $ oc set env dc/mydc VAR1=value1

    set build-secret

    Sets the name of a secret on a build configuration. The secret may be an image pull or push secret or a source repository secret:

    Build and Deployment Operations

    One of the fundamental capabilities of OKD is the ability to build applications into a container from source.

    OKD provides CLI access to inspect and manipulate deployment configurations using standard oc resource operations, such as get, create, and describe.

    start-build

    Manually start the build process with the specified build configuration file:

    1. $ oc start-build <buildconfig_name>

    Manually start the build process by specifying the name of a previous build as a starting point:

    1. $ oc start-build --from-build=<build_name>

    Manually start the build process by specifying either a configuration file or the name of a previous build and retrieve its build logs:

    1. $ oc start-build --from-build=<build_name> --follow
    1. $ oc start-build <buildconfig_name> --follow

    Wait for a build to complete and exit with a non-zero return code if the build fails:

    1. $ oc start-build --from-build=<build_name> --wait

    Set or override environment variables for the current build without changing the build configuration. Alternatively, use -e.

    1. $ oc start-build --env <var_name>=<value>

    Set or override the default build log level output during the build:

    1. $ oc start-build --build-loglevel [0-5]

    Specify the source code commit identifier the build should use; requires a build based on a Git repository:

    1. $ oc start-build --commit=<hash>

    Re-run build with name <build_name>:

    1. $ oc start-build --from-build=<build_name>

    Archive <dir_name> and build with it as the binary input:

    1. $ oc start-build --from-dir=<dir_name>

    Use existing archive as the binary input; unlike --from-file the archive will be extracted by the builder prior to the build process:

      Use <file_name> as the binary input for the build. This file must be the only one in the build source. For example, pom.xml or Dockerfile.

      1. $ oc start-build --from-file=<file_name>

      Download the binary input using HTTP or HTTPS instead of reading it from the file system:

      1. $ oc start-build --from-file=<file_URL>

      Download an archive and use its contents as the build source:

      1. $ oc start-build --from-archive=<archive_URL>

      The path to a local source code repository to use as the binary input for a build:

      1. $ oc start-build --from-repo=<path_to_repo>

      Specify a webhook URL for an existing build configuration to trigger:

      1. $ oc start-build --from-webhook=<webhook_URL>

      The contents of the post-receive hook to trigger a build:

      1. $ oc start-build --git-post-receive=<contents>

      The path to the Git repository for post-receive; defaults to the current directory:

      1. $ oc start-build --git-repository=<path_to_repo>

      List the webhooks for the specified build configuration or build; accepts all, generic, or github:

      1. $ oc start-build --list-webhooks

      Override the Spec.Strategy.SourceStrategy.Incremental option of a source-strategy build:

      1. $ oc start-build --incremental

      Override the Spec.Strategy.DockerStrategy.NoCache option of a docker-strategy build:

      1. $oc start-build --no-cache

      rollback

      Perform a :

      1. $ oc rollback <deployment_name>

      new-build

      Create a build configuration based on the source code in the current Git repository (with a public remote) and a container image:

      1. $ oc new-build .

      Create a build configuration based on a remote git repository:

      1. $ oc new-build https://github.com/sclorg/cakephp-ex

      Create a build configuration based on a private remote git repository:

      1. $ oc new-build https://github.com/youruser/yourprivaterepo --source-secret=yoursecret

      cancel-build

      Stop a build that is in progress:

      1. $ oc cancel-build <build_name>

      Cancel multiple builds at the same time:

      Cancel all builds created from the build configuration:

      1. $ oc cancel-build bc/<buildconfig_name> --state=<state>

      Example values for **state** are new or pending.

      import-image

      Import tag and image information from an external image repository:

      1. $ oc import-image <image_stream>

      scale

      Set the number of desired replicas for a replication controller or a deployment configuration to the number of specified replicas:

      1. $ oc scale <object_type> <object_name> --replicas=<#_of_replicas>

      tag

      Take an existing tag or image from an image stream, or a container image “pull spec”, and set it as the most recent image for a tag in one or more other image streams:

      1. $ oc tag <current_image> <image_stream>

      create

      Parse a configuration file and create one or more OKD objects based on the file contents. The -f flag can be passed multiple times with different file or directory paths. When the flag is passed multiple times, oc create iterates through each one, creating the objects described in all of the indicated files. Any existing resources are ignored.

      1. $ oc create -f <file_or_dir_path>

      replace

      Attempt to modify an existing object based on the contents of the specified configuration file. The -f flag can be passed multiple times with different file or directory paths. When the flag is passed multiple times, oc replace iterates through each one, updating the objects described in all of the indicated files.

      1. $ oc replace -f <file_or_dir_path>

      Transform a project template into a project configuration file:

      1. $ oc process -f <template_file_path>

      run

      Create and run a particular image, possibly replicated. By default, create a deployment configuration to manage the created container(s). You can choose to create a different resource using the --generator flag:

      You can choose to run in the foreground for an interactive container execution.

      1. $ oc run NAME --image=<image> \
      2.     [--generator=<resource>] \
      3.     [--port=<port>] \
      4.     [--replicas=<replicas>] \
      5.     [--dry-run=<bool>] \
      6.     [--overrides=<inline_json>] \
      7.     [options]

      patch

      Updates one or more fields of an object using strategic merge patch:

      1. $ oc patch <object_type> <object_name> -p <changes>

      The is a JSON or YAML expression containing the new fields and the values. For example, to update the spec.unschedulable field of the node node1 to the value true, the json expression is:

      1. $ oc patch node node1 -p '{"spec":{"unschedulable":true}}'

      policy

      Manage authorization policies:

      1. $ oc policy [--options]

      secrets

      Configure :

      1. $ oc secrets [--options] path/to/ssh_key

      autoscale

      Setup an for your application. Requires metrics to be enabled in the cluster. See Enabling Cluster Metrics for cluster administrator instructions, if needed.

      1. $ oc autoscale dc/<dc_name> [--options]

      Troubleshooting and Debugging Operations

      debug

      Launch a command shell to debug a running application.

      1. $ oc debug -h

      When debugging images and setup problems, you can get an exact copy of a running pod configuration and troubleshoot with a shell. Since a failing pod may not be started and not accessible to rsh or exec, running the debug command creates a carbon copy of that setup.

      The default mode is to start a shell inside of the first container of the referenced pod, replication controller, or deployment configuration. The started pod will be a copy of your source pod, with labels stripped, the command changed to /bin/sh, and readiness and liveness checks disabled. If you just want to run a command, add -- and a command to run. Passing a command will not create a TTY or send STDIN by default. Other flags are supported for altering the container or pod in common ways.

      A common problem running containers is a security policy that prohibits you from running as a root user on the cluster. You can use this command to test running a pod as non-root (with --as-user) or to run a non-root pod as root (with --as-root).

      The debug pod is deleted when the remote command completes or you interrupt the shell.

      Usage

      1. $ oc debug RESOURCE/NAME [ENV1=VAL1 ...] [-c CONTAINER] [options] [-- COMMAND]

      Examples

      To debug a currently running deployment:

      1. $ oc debug dc/test

      To test running a deployment as a non-root user:

      1. $ oc debug dc/test --as-user=1000000

      To debug a specific failing container by running the env command in the second container:

      1. $ oc debug dc/test -c second -- /bin/env

      To view the pod that would be created to debug:

      1. $ oc debug dc/test -o yaml

      logs

      Retrieve the log output for a specific build, deployment, or pod. This command works for builds, build configurations, deployment configurations, and pods.

      1. $ oc logs -f <pod>

      exec

      Execute a command in an already-running container. You can optionally specify a container ID, otherwise it defaults to the first container.

      1. $ oc exec <pod> [-c <container>] <command>

      rsh

      Open a remote shell session to a container:

      1. $ oc rsh <pod>

      rsync

      Copy the contents to or from a directory in an already-running pod container. If you do not specify a container, it defaults to the first container in the pod.

      To copy contents from a local directory to a directory in a pod:

      1. $ oc rsync <local_dir> <pod>:<pod_dir> -c <container>

      To copy contents from a directory in a pod to a local directory:

      1. $ oc rsync <pod>:<pod_dir> <local_dir> -c <container>

      port-forward

      Forward one or more local ports to a pod:

      1. $ oc port-forward <pod> <local_port>:<remote_port>

      Run a proxy to the Kubernetes API server:

      Troubleshooting oc

      You can get more verbosed output from any command by increasing the loglevel using -v=X flag. By default, the loglevel is set to 0, but you can set its value from 0 to 10.

      Overview of each loglevel

      • 1-5 - are usually used internally by the commands, if the author decides to provide more explanation about the flow.

      • 6 - provides basic information about HTTP traffic between the client and the server, such HTTP operation and URL.

      • 7 - provides more thorough HTTP information, such as HTTP operation, URL, request headers and response status code.

      • 8 - provides full HTTP request and response, including body.

      • - provides all possible output the command provides.