Windows 向けの CLI は、zip アーカイブとして提供されます。これは Red Hat カスタマーポータル からダウンロードできます。Red Hat アカウントでログイン後、ダウンロードページにアクセスするには、有効な OpenShift Enterprise サブスクリプションが必要です。

Red Hat カスタマーポータルからの CLI のダウンロード

または、クラスター管理者がリンクを有効にしている場合は、Web コンソールの About ページから CLI をダウンロードし、展開することができます。

チュートリアルの動画

以下の動画ではこのプロセスを紹介しています。 視聴するには、ここをクリックしてください。

次に ZIP プログラムでアーカイブを展開し、oc バイナリーを PATH 上のディレクトリーに移動します。PATH を確認するには、コマンドプロンプトを開いて以下を実行します。

C:\> path

Mac OS X 向けの CLI は、tar.gz アーカイブとして提供されます。これは Red Hat カスタマーポータル からダウンロードできます。Red Hat アカウントでログイン後、ダウンロードページにアクセスするには、有効な OpenShift Enterprise サブスクリプションが必要です。

Red Hat カスタマーポータルからの CLI のダウンロード

または、クラスター管理者がリンクを有効にしている場合は、Web コンソールの About ページから CLI をダウンロードし、展開することができます。

チュートリアルの動画

以下の動画ではこのプロセスを紹介しています。視聴するには、ここをクリックしてください。

次にアーカイブを展開し、oc バイナリーを PATH 上のディレクトリーに移動します。PATH を確認するには、ターミナルのウィンドウを開いて以下を実行します。

$ echo $PATH

Red Hat Enterprise Linux (RHEL) 7 の場合、Red Hat アカウントに有効な OpenShift Enterprise サブスクリプションがある場合、Red Hat Subscription Management (RHSM) を使用して RPM として CLI をインストールできます。

RHEL、Fedora その他 Linux ディストリビューションの場合、 CLI を Red Hat カスタマーポータル から tar.gz アーカイブとして直接ダウンロードできます。Red Hat アカウントでログイン後、ダウンロードページにアクセスするには、有効な OpenShift Enterprise サブスクリプションが必要です。

Red Hat カスタマーポータルからの CLI のダウンロード

チュートリアルの動画

以下の動画ではこのプロセスを紹介しています。視聴するには、ここをクリックしてください。

または、クラスター管理者がリンクを有効にしている場合は、Web コンソールの About ページから CLI をダウンロードし、展開することができます。

次にアーカイブを展開し、oc バイナリーを PATH 上のディレクトリーに移動します。PATH を確認するには、以下を実行します。

$ echo $PATH

アーカイブを展開するには、以下を実行します。

$ tar -xf <file>

oc: No such file or directory

OpenShift Container Platform の一部のコアとなるコンセプトの概要を表示します。

$ oc types

OpenShift Container Platform サーバーにログインします。

$ oc login

現在のセッションを終了します。

$ oc logout

新しいプロジェクトを作成します。

$ oc new-project <project_name>

現在のディレクトリー内のソースコードに基づいて 新規アプリケーションを作成 します。

$ oc new-app .

リモートリポジトリー内のソースコードに基づいて新規アプリケーションを作成します。

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

プライベートリモートリポジトリー内のソースコードに基づいて新規アプリケーションを作成します。

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

現在のプロジェクトの概要を表示します。

$ oc status

別のプロジェクトに切り替えます。現在のプロジェクトを表示するには、オプションなしで実行します。アクセス可能なすべてのプロジェクトを表示するには、oc projects を実行します。

$ oc project <project_name>

指定された オブジェクトタイプ のオブジェクトの一覧を返します。オプションの <object_name> が要求に含まれている場合には、結果の一覧はその値でフィルターされます。

$ oc get <object_type> [<object_name>]

たとえば、以下のコマンドはプロジェクトの利用可能なイメージを一覧表示します。

$ oc get images

sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3   registry.redhat.io/jboss-datagrid-6/datagrid65-openshift@sha256:f86e02fb8c740b4ed1f59300e94be69783ee51a38cc9ce6ddb73b6f817e173b3
sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351b   registry.redhat.io/jboss-fuse-6/fis-karaf-openshift@sha256:f98f90938360ab1979f70195a9d518ae87b1089cd42ba5fc279d647b2cb0351b

出力形式を変更するには、-o または --output オプションを使用できます。

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

出力形式には、JSON や YAML、または カスタムカラム、golang テンプレート、および jsonpath などの拡張性のある形式を使用できます。

たとえば、以下のコマンドは特定のプロジェクトで実行される Pod の名前を一覧表示します。

$ oc get pods -n default -o jsonpath='{range .items[*].metadata}{"Pod Name: "}{.name}{"\n"}{end}'

Pod Name: docker-registry-1-wvhrx
Pod Name: registry-console-1-ntq65
Pod Name: router-1-xzw69

クエリーによって返される特定のオブジェクトに関する情報を返します。特定の <object_name> を指定する必要があります。オブジェクトタイプ で説明されるように、利用可能な実際の情報は状況によって異なります。

$ oc describe <object_type> <object_name>

必要なオブジェクトタイプを編集します。

$ oc edit <object_type>/<object_name>

必要なオブジェクトタイプを指定のテキストエディターで編集します。

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

必要なオブジェクトを指定の形式 (例: JSON) で編集します。

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

ボリューム を変更します。

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

オブジェクトのラベルを更新します。

$ oc label <object_type> <object_name> <label>

サービスを検索し、これをルートとして公開します。デプロイメント設定、レプリケーションコントローラー、サービス、または Pod を指定されたポート上の新規サービスとして公開する機能もあります。ラベルが指定されていない場合、新規オブジェクトは公開するオブジェクトのラベルを再利用します。

サービスを公開する場合、デフォルトのジェネレーターは --generator=route/v1 になります。デフォルトが --generator=service/v2 になるその他すべてのケースでは、ポート名が指定されないままになります。通常は oc expose コマンドにジェネレーターを設定する必要はありません。3 つ目のジェネレーター --generator=service/v1 はデフォルトのポート名で利用できます。

$ oc expose <object_type> <object_name>

指定されたオブジェクトを削除します。オブジェクトの設定は STDIN で渡すこともできます。oc delete all -l <label> 操作は、指定された <label> に一致するすべてのオブジェクトを削除します。これには レプリケーションコントローラー も含まれ、これが削除されると Pod は再作成されなくなります。

$ oc delete -f <file_path>

$ oc delete <object_type> <object_name>

$ oc delete <object_type> -l <label>

$ oc delete all -l <label>

指定したオブジェクトの特定のプロパティーを変更します。

$ oc set env dc/mydc VAR1=value1

$ oc set build-secret --source bc/mybc mysecret

指定されたビルド設定ファイルを使用して、手動でビルドプロセスを開始します。

$ oc start-build <buildconfig_name>

直前のビルドの名前を開始点として指定し、ビルドプロセスを手動で開始します。

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

設定ファイルを指定するか、または直前のビルドの名前を指定してビルドプロセスを手動で開始し、そのビルドログを取得します。

$ oc start-build --from-build=<build_name> --follow

$ oc start-build <buildconfig_name> --follow

ビルドが完了するまで待機し、ビルドが失敗する場合はゼロ以外のリターンコードを出して終了します。

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

ビルド設定を変更することなく、現在のビルドの環境変数を設定するか、または上書きします。または、-e を使用します。

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

ビルド時にデフォルトのビルドログレベルの出力を設定するか、または上書きします。

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

ビルドで使用する必要のあるソースコードのコミット ID を指定します。これには Git リポジトリーに基づくビルドが必要です。

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

<build_name> の名前でビルドを再実行します。

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

<dir_name> をアーカイブし、これを使用してバイナリー入力としてビルドします。

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

既存のアーカイブをバイナリー入力として使用します。 --from-file とは異なり、ビルドプロセスの前にビルダーがアーカイブを展開します。

$ oc start-build --from-archive=<archive_name>

<file_name> をビルドのバイナリー入力として使用します。このファイルはビルドソース内の唯一のファイルでなければなりません。たとえば、pom.xml または Dockerfile などがこれに該当します。

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

ファイルシステムから読み取るのではなく、HTTP または HTTPS を使用してバイナリー入力をダウンロードします。

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

アーカイブをダウンロードし、そのコンテンツをビルドソースとして使用します。

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

ビルドのバイナリー入力として使用するローカルソースコードリポジトリーへのパスです。

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

トリガーする既存ビルド設定の Webhook URL を指定します。

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

ビルドをトリガーする post-receive フックのコンテンツです。

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

post-receive の Git リポジトリーへのパスです。デフォルトは現在のディレクトリーに設定されます。

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

指定されたビルド設定またはビルドの Webhook を一覧表示します。 all、generic、または github を受け入れます。

$ oc start-build --list-webhooks

source-strategy ビルドの Spec.Strategy.SourceStrategy.Incremental オプションを上書きします。

$ oc start-build --incremental

docker-strategy ビルドの Spec.Strategy.DockerStrategy.NoCache オプションを上書きします。

$oc start-build --no-cache

ロールバック を実行します。

$ oc rollback <deployment_name>

現在の Git リポジトリー (パブリックリモート) およびコンテナーイメージのソースコードに基づいてビルド設定を作成します。

$ oc new-build .

リモート Git リポジトリーに基づくビルド設定を作成します。

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

プライベートリモート Git リポジトリーに基づいてビルド設定を作成します。

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

進行中のビルドを停止します。

$ oc cancel-build <build_name>

複数のビルドを同時にキャンセルします。

$ oc cancel-build <build1_name> <build2_name> <build3_name>

ビルド設定から作成されたビルドすべてをキャンセルします。

$ oc cancel-build bc/<buildconfig_name>

取り消すビルドを指定します。

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

state の値の例には、new または pending があります。

外部のイメージリポジトリーからタグおよびイメージ情報をインポートします。

$ oc import-image <image_stream>

レプリケーションコントローラー またはデプロイメント設定の必要なレプリカ数を指定されるレプリカ数に設定します。

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

イメージストリームまたはコンテナーイメージのプル仕様 (pull spec) から既存のタグまたはイメージを取得し、1 つ以上の他のイメージストリームのタグに最新イメージとして設定します。

$ oc tag <current_image> <image_stream>

設定ファイルを解析し、ファイルの内容に基づいて 1 つ以上の OpenShift Container Platform オブジェクトを作成します。-f フラグは、複数の異なるファイルまたはディレクトリーパスを使用して複数回渡すことが可能です。フラグが複数回渡される場合、oc create がフラグごとに繰り返され、指示されたファイルすべてに記述されるオブジェクトが作成されます。既存のリソースはいずれも無視されます。

$ oc create -f <file_or_dir_path>

指定された設定ファイルの内容に基づいて、既存オブジェクトの変更を試行します。-f フラグは、複数の異なるファイルまたはディレクトリーパスを使用して複数回渡すことが可能です。フラグが複数回渡される場合、oc replace がフラグごとに繰り返され、指定のファイルすべてに記述されるオブジェクトが更新されます。

$ oc replace -f <file_or_dir_path>

プロジェクトの テンプレート をプロジェクト設定ファイルに変換します。

$ oc process -f <template_file_path>

特定のイメージを作成し、実行します。デフォルトで、作成されたコンテナーを管理するためにデプロイメント設定を作成します。--generator フラグを使用して別のリソースの作成を選択することができます。

対話型コンテナーの場合には、フォアグラウンドでの実行を選択できます。

$ oc run NAME --image=<image> \
    [--generator=<resource>] \
    [--port=<port>] \
    [--replicas=<replicas>] \
    [--dry-run=<bool>] \
    [--overrides=<inline_json>] \
    [options]

ストラテジーに基づくマージパッチを使用して、オブジェクトの 1 つ以上のフィールドを更新します。

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

<changes> は、新しいフィールドおよび値を含む JSON または YAML 式です。たとえば、ノード node1 の spec.unschedulable フィールドを true の値に更新する場合、JSON 式は以下のようになります。

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

認証ポリシーを管理します。

$ oc policy [--options]

シークレット を設定します。

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

アプリケーションの autoscaler を設定します。メトリクスをクラスターで有効にする必要があります。クラスター管理者向けの説明については クラスターメトリクスの有効化 を随時参照してください。

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

コマンドシェルを起動して、実行中のアプリケーションをデバッグします。

$ oc debug -h

イメージおよび設定の問題をデバッグする際、実行中の Pod 設定の正確なコピーを取得し、shell でトラブルシュートを実行することができます。障害が発生している Pod は起動できず、rsh または exec にアクセスできない可能性があるため、debug コマンドを実行して、対象の設定の正確なコピーを作成します。

デフォルトモードでは、参照される Pod、レプリケーションコントローラー、またはデプロイメント設定の最初のコンテナー内でシェルを起動します。起動される Pod はソース Pod のコピーになりますが、ラベルは取られ、コマンドは /bin/sh に変更され、readiness および liveness チェックは無効にされます。コマンドのみを実行する必要がある場合には、-- と実行する 1 つのコマンドを追加します。コマンドを渡しても、デフォルトで TTY が作成されたり、STDIN が送信されたりすることはありません。コンテナーまたは Pod を一般的な方法で変更する際に使用できる他のサポートされているフラグを使用することもできます。

コンテナーを実行する際の一般的な問題として、セキュリティーポリシーによってクラスター上で root ユーザーとしての実行が禁止されることがあります。このコマンドは、(--as-user を使用して) root ユーザー以外で Pod の実行をテストするか、または (--as-root を使用して) root ユーザーとして root 以外の Pod を実行するために使用できます。

デバッグ Pod はリモートコマンドの完了時またはシェルが中断する際に削除されます。

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

$ oc debug dc/test

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

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

$ oc debug dc/test -o yaml

特定のビルド、デプロイメント、または Pod のログ出力を取得します。このコマンドは、ビルド、ビルド設定、デプロイメント設定、および Pod で機能します。

$ oc logs -f <pod> -c <container_name>

すでに実行中のコンテナーでコマンドを実行します。オプションでコンテナー ID を指定できますが、指定しない場合はデフォルトで最初のコンテナーが指定されます。

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

コンテナーへのリモートシェルセッションを開きます。

$ oc rsh <pod>

すでに実行中の Pod コンテナーのディレクトリーへコンテンツをコピーするか、またはこのディレクトリーからコンテンツをコピーします。コンテナーを指定しない場合は、デフォルトで Pod 内の最初のコンテナーが指定されます。

ローカルディレクトリーから Pod 内のディレクトリーにコンテンツをコピーするには、以下を実行します。

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

Pod 内のディレクトリーからローカルディレクトリーにコンテンツをコピーするには、以下を実行します。

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

1 つ以上のローカルポート を Pod に転送します。

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

Kubernetes API サーバーのプロキシーを実行します。

$ oc proxy --port=<port> --www=<static_directory>

新しいプロジェクトを作成します。

$ oc adm new-project <project_name>

承認ポリシーを管理します。

$ oc adm policy

グループを管理します。

$ oc adm groups

ルーターをインストールします。

$ oc adm router <router_name>

ノードセットの IP フェイルオーバーグループをインストールします。

$ oc adm ipfailover <ipfailover_config>

統合コンテナーイメージレジストリーをインストールします。

$ oc adm registry

ビルドの入力と依存関係を出力します。

$ oc adm build-chain <image_stream>[:<tag>]

ノードを管理します。たとえば、Pod の一覧表示または退避を実行します。 または Ready (準備完了) のマークを付けます。

$ oc adm manage-node

リソースの古いバージョンをサーバーから削除します。

$ oc adm prune

kubelet 設定ファイルを変更します。

$ oc adm config <subcommand>

クライアント証明書から基本的な .kubeconfig ファイルを作成します。

$ oc adm create-kubeconfig

ユーザーとしてサーバーに接続する設定ファイルを作成します。

$ oc adm create-api-client-config

ブートストラッププロジェクトテンプレートを作成します。

$ oc adm create-bootstrap-project-template

デフォルトのブートストラップポリシーを作成します。

$ oc adm create-bootstrap-policy-file

ログインテンプレートを作成します。

$ oc adm create-login-template

ノードの設定バンドルを作成します。

$ oc adm create-node-config

証明書およびキーを管理します。

$ oc adm ca

プラグインローダーは、プラグインファイルの検索 のほか、プラグインを実行する上で必要最低限の情報をプラグインが提供するかどうかを確認します。正しい場所に置かれたファイルで、最低限の情報を提供しないもの (例: 不十分な plugin.yaml 記述子) は無視されます。

記述子ファイルは、以下の属性をサポートします。

name: "great-plugin"              # REQUIRED: the plug-in command name, to be invoked under 'kubectl'
shortDesc: "great-plugin plug-in" # REQUIRED: the command short description, for help
longDesc: ""                      # the command long description, for help
example: ""                       # command example(s), for help
command: "./example"              # REQUIRED: the command, binary, or script to invoke when running the plug-in
flags:                            # flags supported by the plug-in
  - name: "flag-name"             # REQUIRED for each flag: flag name
    shorthand: "f"                # short version of the flag name
    desc: "example flag"          # REQUIRED for each flag: flag description
    defValue: "extreme"           # default value of the flag
tree:                             # allows the declaration of subcommands
  - ...                           # subcommands support the same set of attributes

前述の記述子は great-plugin プラグインを宣言します。これには、-f | --flag-name という名前の 1 つのフラグが含まれます。これは以下を実行して呼び出すことができます。

$ oc plugin great-plugin -f value

プラグインが呼び出されると、記述子ファイルと同じディレクトリーにある example バイナリーまたはスクリプトが呼び出され、多くの引数および環境変数が渡されます。ランタイム属性へのアクセス のセクションでは、example コマンドがフラグ値およびその他のランタイムコンテキストにアクセスする方法について説明しています。

ファイルシステム内に、各プラグイン独自の (可能ならばプラグインコマンドと同じ名前の) サブディレクトリーを設定することが推奨されます。このディレクトリーには、plugin.yaml 記述子と任意のバイナリー、スクリプト、アセット、または必要とされるその他の依存関係が含まれている必要があります。

たとえば、great-plugin プラグインのディレクトリー構造は、以下のようになります。

~/.kube/plugins/
└── great-plugin
    ├── plugin.yaml
    └── example

多くの場合、プラグインをサポートするために作成するバイナリーまたはスクリプトファイルは、プラグインフレームワークで提供される一部のコンテキスト情報にアクセスできる必要があります。たとえば、記述子ファイルでフラグを宣言すると、プラグインは、ランタイムでユーザー提供のフラグ値へのアクセスが必要になります。

これはグローバルフラグの場合も同様です。プラグインフレームワークがこれを実行するので、プラグインの作成側で引数の解析を行う必要はありません。またこれにより、プラグインと通常の oc コマンド間の一貫性を最適なレベルに保つことができます。

プラグインは環境変数を使ってランタイムのコンテキスト属性にアクセスできます。たとえば、フラグで提供された値にアクセスするには、バイナリーまたはスクリプトの適切な関数呼び出しを使用して適切な環境変数の値を探します。

以下は、サポート対象の環境変数です。