第4章 開発者 CLI の各種操作

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/openshift/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>]

クエリーによって返される特定のオブジェクトに関する情報を返します。特定の <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 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/openshift/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 export <object_type> [--options]

プロジェクトの既存オブジェクトをテンプレート形式でエクスポートする方法についての詳細は、「既存オブジェクトからのテンプレートの作成」を参照してください。

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

$ 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>

すでに実行中のコンテナーでコマンドを実行します。オプションでコンテナー 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>

Pod に「1 つ以上のローカルポートを転送」するには、以下を実行します。

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

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

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