$ oc <action> <object_type> <object_name>
×
Developer CLI Operations
Important
Azure Red Hat OpenShift 3.11 will be retired 30 June 2022. Support for creation of new Azure Red Hat OpenShift 3.11 clusters continues through 30 November 2020. Following retirement, remaining Azure Red Hat OpenShift 3.11 clusters will be shut down to prevent security vulnerabilities.
Follow this guide to create an Azure Red Hat OpenShift 4 cluster. If you have specific questions, please contact us
Overview
This topic provides information on the developer CLI operations and their syntax. You must setup and login with the CLI before you can perform these operations.
The developer CLI uses the oc 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 Azure Red Hat OpenShift. Many common oc operations are invoked
using the following syntax:
This specifies:
-
An
<action>to perform, such asgetordescribe. -
The
<object_type>to perform the action on, such asserviceor the abbreviatedsvc. -
The
<object_name>of the specified<object_type>.
For example, the oc get operation returns a complete list of services that are
currently defined:
$ oc get svcExample Output
NAME LABELS SELECTOR IP PORT(S)
docker-registry docker-registry=default docker-registry=default 172.30.78.158 5000/TCP
kubernetes component=apiserver,provider=kubernetes <none> 172.30.0.2 443/TCP
kubernetes-ro component=apiserver,provider=kubernetes <none> 172.30.0.1 80/TCPThe oc describe operation can then be used to return detailed information
about a specific object:
$ oc describe svc docker-registryExample Output
Name: docker-registry
Labels: docker-registry=default
Selector: docker-registry=default
IP: 172.30.78.158
Port: <unnamed> 5000/TCP
Endpoints: 10.128.0.2:5000
Session Affinity: None
No events.Object Types
Below is the list of the most common object types the CLI supports, some of which have abbreviated syntax:
| Object Type | Abbreviated Version |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you want to know the full list of resources the server supports, use oc api-resources.
Basic CLI Operations
The following table describes basic oc operations and their general syntax:
new-app
Creates a new application based on the source code in the current directory:
$ oc new-app .Creates a new application based on the source code in a remote repository:
$ oc new-app https://github.com/sclorg/cakephp-exCreates a new application based on the source code in a private remote repository:
$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecretApplication Modification Operations
get
Return a list of objects for the specified object type. If
the optional <object_name> is included in the request, then the list of
results is filtered by that value.
$ oc get <object_type> [<object_name>]For example, the following command lists the available images for the project:
$ oc get imagesExample Output
sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3 registry.redhat.io/jboss-datagrid-6/datagrid65-openshift@sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3
sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351b registry.redhat.io/jboss-fuse-6/fis-karaf-openshift@sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351bYou can use the -o or --output option to modify the output format.
$ 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, golang template, and jsonpath.
For example, the following command lists the name of the pods running in a specific project:
$ oc get pods -n default -o jsonpath='{range .items[*].metadata}{"Pod Name: "}{.name}{"\n"}{end}'Example Output
Pod Name: docker-registry-1-wvhrx
Pod Name: registry-console-1-ntq65
Pod Name: router-1-xzw69describe
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.
$ oc describe <object_type> <object_name>edit
Edit the desired object type:
$ oc edit <object_type>/<object_name>Edit the desired object type with a specified text editor:
$ OC_EDITOR="<text_editor>" oc edit <object_type>/<object_name>Edit the desired object in a specified format (eg: JSON):
$ oc edit <object_type>/<object_name> \
--output-version=<object_type_version> \
-o <object_type_format>expose
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.
$ 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.
$ oc delete -f <file_path>$ oc delete <object_type> <object_name>$ oc delete <object_type> -l <label>$ oc delete all -l <label>Build and Deployment Operations
One of the fundamental capabilities of Azure Red Hat OpenShift is the ability to build applications into a container from source.
Azure Red Hat OpenShift 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:
$ oc start-build <buildconfig_name>Manually start the build process by specifying the name of a previous build as a starting point:
$ 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:
$ oc start-build --from-build=<build_name> --follow$ oc start-build <buildconfig_name> --followWait for a build to complete and exit with a non-zero return code if the build fails:
$ oc start-build --from-build=<build_name> --waitSet or override environment variables for the current build without changing the
build configuration. Alternatively, use -e.
$ oc start-build --env <var_name>=<value>Set or override the default build log level output during the build:
$ 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:
$ oc start-build --commit=<hash>Re-run build with name <build_name>:
$ oc start-build --from-build=<build_name>Archive <dir_name> and build with it as the binary input:
$ 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:
$ oc start-build --from-archive=<archive_name>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.
$ oc start-build --from-file=<file_name>Download the binary input using HTTP or HTTPS instead of reading it from the file system:
$ oc start-build --from-file=<file_URL>Download an archive and use its contents as the build source:
$ oc start-build --from-archive=<archive_URL>The path to a local source code repository to use as the binary input for a build:
$ oc start-build --from-repo=<path_to_repo>Specify a webhook URL for an existing build configuration to trigger:
$ oc start-build --from-webhook=<webhook_URL>The contents of the post-receive hook to trigger a build:
$ oc start-build --git-post-receive=<contents>The path to the Git repository for post-receive; defaults to the current directory:
$ oc start-build --git-repository=<path_to_repo>List the webhooks for the specified build configuration or build; accepts all,
generic, or github:
$ oc start-build --list-webhooksOverride the Spec.Strategy.SourceStrategy.Incremental option of a source-strategy build:
$ oc start-build --incrementalOverride the Spec.Strategy.DockerStrategy.NoCache option of a docker-strategy build:
$oc start-build --no-cachenew-build
Create a build configuration based on the source code in the current Git repository (with a public remote) and a container image:
$ oc new-build .Create a build configuration based on a remote git repository:
$ oc new-build https://github.com/sclorg/cakephp-exCreate a build configuration based on a private remote git repository:
$ oc new-build https://github.com/youruser/yourprivaterepo --source-secret=yoursecretcancel-build
Stop a build that is in progress:
$ oc cancel-build <build_name>Cancel multiple builds at the same time:
$ oc cancel-build <build1_name> <build2_name> <build3_name>Cancel all builds created from the build configuration:
$ oc cancel-build bc/<buildconfig_name>Specify the builds to be canceled:
$ 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:
$ 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:
$ oc scale <object_type> <object_name> --replicas=<#_of_replicas>Advanced Commands
create
Parse a configuration file and create one or more Azure Red Hat OpenShift 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.
$ 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.
$ oc replace -f <file_or_dir_path>process
Transform a project template into a project configuration file:
$ 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:
| API Resource | --generator Option |
|---|---|
Deployment configuration |
|
Pod |
|
Replication controller |
|
Deployment using |
|
Deployment using |
|
Job |
|
Cron job |
|
You can choose to run in the foreground for an interactive container execution.
$ oc run NAME --image=<image> \
[--generator=<resource>] \
[--port=<port>] \
[--replicas=<replicas>] \
[--dry-run=<bool>] \
[--overrides=<inline_json>] \
[options]patch
Updates one or more fields of an object using strategic merge patch:
$ oc patch <object_type> <object_name> -p <changes>The <changes> 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:
$ oc patch node node1 -p '{"spec":{"unschedulable":true}}'autoscale
Setup an autoscaler for your application. Requires metrics to be enabled in the cluster.
$ oc autoscale dc/<dc_name> [--options]Troubleshooting and Debugging Operations
debug
Launch a command shell to debug a running application.
$ oc debug -hWhen 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.
Examples
To debug a currently running deployment:
$ oc debug dc/testTo test running a deployment as a non-root user:
$ oc debug dc/test --as-user=1000000To debug a specific failing container by running the env command in the second container:
$ oc debug dc/test -c second -- /bin/envTo view the pod that would be created to debug:
$ oc debug dc/test -o yamllogs
Retrieve the log output for a specific build, deployment, or pod. This command works for builds, build configurations, deployment configurations, and pods.
$ oc logs -f <pod> -c <container_name>exec
Execute a command in an already-running container. You can optionally specify a container ID, otherwise it defaults to the first container.
$ oc exec <pod> [-c <container>] <command>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:
$ oc rsync <local_dir> <pod>:<pod_dir> -c <container>To copy contents from a directory in a pod to a local directory:
$ oc rsync <pod>:<pod_dir> <local_dir> -c <container>port-forward
Forward one or more local ports to a pod:
$ oc port-forward <pod> <local_port>:<remote_port>proxy
Run a proxy to the Kubernetes API server:
$ oc proxy --port=<port> --www=<static_directory>|
For security purposes, the
|
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. -
9- provides full HTTP request and response, including body and samplecurlinvocation. -
10- provides all possible output the command provides.