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

4.1. 概要

このトピックでは、開発者 CLI の各種操作およびそれらの構文に関する情報を提供します。これらの操作を実行する前に、CLI を使用して 設定およびログインしている必要があります。

oc コマンドを使用する開発者 CLI はプロジェクトレベルの操作で使用されます。これは管理者 CLI とは異なります。管理者 CLI では、より高度な管理者操作に oc adm コマンドを使用します。

4.2. 一般的な操作

開発者 CLI は、OpenShift Container Platform で管理される各種オブジェクトとの対話を許可します。以下の構文を使用して、多くの一般的な oc 操作が呼び出されます。

$ oc <action> <object_type> <object_name>

これにより、以下が指定されます。

  • get または describe などの実行する <action>
  • service または svc (省略形) などのアクションを実行する <object_type>
  • 指定した <object_type><object_name>

たとえば、oc get 操作は、現在定義されているサービスの完全な一覧を返します。

$ oc get svc
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/TCP

次に oc describe 操作を使用して、特定のオブジェクトに関する詳細情報を返すことができます。

$ oc describe svc docker-registry
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.

4.3. オブジェクトタイプ

以下は、CLI がサポートする最も一般的なオブジェクトタイプの一覧です。これらの一部には省略された構文が含まれます。

オブジェクトタイプ省略バージョン

Build

 

BuildConfig

bc

DeploymentConfig

dc

Deployments

deploy

Event

ev

ImageStream

is

ImageStreamTag

istag

ImageStreamImage

isimage

Job

 

CronJob (テクノロジープレビュー)

cj

LimitRange

limits

Node

 

Pod

po

ResourceQuota

quota

ReplicationController

rc

ReplicaSet

rs

Secrets

 

Service

svc

ServiceAccount

sa

StatefulSets

sts

PersistentVolume

pv

PersistentVolumeClaim

pvc

サーバーがサポートするリソースの詳細な一覧を把握しておく必要がある場合は、oc api-resources を使用します。

4.4. 基本的な CLI 操作

以下の表は、基本的な oc 操作と、それらの一般的な構文について説明しています。

4.4.1. types

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

$ oc types

4.4.2. login

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

$ oc login

4.4.3. logout

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

$ oc logout

4.4.4. new-project

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

$ oc new-project <project_name>

4.4.5. new-app

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

$ oc new-app .

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

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

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

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

4.4.6. status

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

$ oc status

4.4.7. project

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

$ oc project <project_name>

4.5. アプリケーション変更操作

4.5.1. get

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

$ oc get <object_type> [<object_name>]

出力形式を変更するには、-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

4.5.2. describe

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

$ oc describe <object_type> <object_name>

4.5.3. edit

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

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

4.5.4. volume

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

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

4.5.5. label

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

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

4.5.6. expose

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

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

$ oc expose <object_type> <object_name>

4.5.7. delete

指定されたオブジェクトを削除します。オブジェクトの設定は 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>

4.5.8. set

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

4.5.8.1. set env

デプロイメント設定またはビルド設定の環境変数を設定します。

$ oc set env dc/mydc VAR1=value1

4.5.8.2. set build-secret

ビルド設定のシークレットの名前を設定します。シークレットは、イメージのプル/プッシュシークレットまたはソースリポジトリーシークレットになります。

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

4.6. ビルドおよびデプロイメントの各種操作

OpenShift Container Platform の基本的な機能の 1 つとして、アプリケーションをソースからコンテナーにビルドする機能があります。

OpenShift Container Platform では CLI のアクセスを提供し、getcreate、および describe などの標準の oc リソース操作を使用してデプロイメント設定を検査したり、操作したりします。

4.6.1. start-build

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

$ 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 を一覧表示します。allgeneric、または 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

4.6.2. rollback

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

$ oc rollback <deployment_name>

4.6.3. new-build

現在の 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

4.6.4. cancel-build

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

$ 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 があります。

4.6.5. import-image

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

$ oc import-image <image_stream>

4.6.6. scale

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

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

4.6.7. tag

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

$ oc tag <current_image> <image_stream>

4.7. 高度なコマンド

4.7.1. create

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

$ oc create -f <file_or_dir_path>

4.7.2. replace

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

$ oc replace -f <file_or_dir_path>

4.7.3. process

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

$ oc process -f <template_file_path>

4.7.4. run

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

API リソース--generator オプション

デプロイメント設定

deploymentconfig/v1 (デフォルト)

Pod

run-pod/v1

レプリケーションコントローラー

run/v1

extensions/v1beta1 エンドポイントを使用したデプロイメント

deployment/v1beta1

apps/v1beta1 エンドポイントを使用したデプロイメント

deployment/apps.v1beta1

ジョブ

job/v1

Cron ジョブ

cronjob/v2alpha1

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

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

4.7.5. patch

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

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

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

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

4.7.6. policy

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

$ oc policy [--options]

4.7.7. secrets

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

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

4.7.8. autoscale

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

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

4.8. トラブルシューティングおよびデバッグ操作

4.8.1. debug

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

$ 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 はリモートコマンドの完了時またはシェルが中断する際に削除されます。

4.8.1.1. 使用法

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

4.8.1.2. 例

現在実行中のデプロイメントをデバッグするには、以下を実行します。

$ oc debug dc/test

非 root ユーザーとしてデプロイメントの実行をテストするには、以下を実行します。

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

second コンテナーで env コマンドを実行し、特定の失敗したコンテナーをデバッグするには、以下を実行します。

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

デバッグするために作成される Pod を表示するには、以下を実行します。

$ oc debug dc/test -o yaml

4.8.2. logs

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

$ oc logs -f <pod>

4.8.3. exec

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

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

4.8.4. rsh

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

$ oc rsh <pod>

4.8.5. rsync

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

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

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

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

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

4.8.6. port-forward

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

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

4.8.7. proxy

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

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

セキュリティー上の理由により、oc exec コマンドは、特権付きコンテナーにアクセスする場合には機能しません。ただし、cluster-admin ユーザーがこのコマンドを実行する場合を除きます。管理者はノードホストに対して SSH を実行し、必要なコンテナーで docker exec コマンドを使用することができます。

4.9. トラブルシューティング oc

-v=X フラグを使用してログレベルを上げることにより、より詳細な出力を取得することができます。デフォルトで、ログレベルは 0 に設定されますが、この値 010 に設定することができます。

各ログレベルの概要

  • 1-5: 通常、作成者がフローについてより詳細な説明を提供するようにした場合にコマンドによって内部で使用されます。
  • 6: HTTP 操作および URL など、クライアントとサーバー間の HTTP トラフィックについての基本的な情報を提供します。
  • 7: HTTP 操作、URL、要求ヘッダーおよび応答ステータスコードなどのより詳細な HTTP 情報を提供します。
  • 8: 本体を含む完全な HTTP 要求および応答を提供します。
  • 9: 本体およびサンプル curl 呼び出しを含む、完全な HTTP 要求および応答を提供します。
  • 10: コマンドが提供する可能性のあるすべての出力を提供します。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。