第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.
警告

Versions of oc prior to 3.0.2.0 did not have the ability to negotiate API versions against a server. So if you are using oc up to 3.0.1.0 with a server that only supports v1 or higher versions of the API, make sure to pass --api-version in order to point the oc client to the correct API endpoint. For example: oc get svc --api-version=v1.

4.3. オブジェクトタイプ

The CLI supports the following object types, some of which have abbreviated syntax:

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

build

 

buildConfig

bc

deploymentConfig

dc

deployments (Technology Preview)

deploy

event

ev

imageStream

is

imageStreamTag

istag

imageStreamImage

isimage

job

 

LimitRange

limits

node

 

pod

po

ResourceQuota

quota

replicationController

rc

replicaSet

rs

secrets

 

service

svc

ServiceAccount

sa

persistentVolume

pv

persistentVolumeClaim

pvc

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

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

$ oc new-app .

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

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

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

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

4.4.6. status

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

$ oc status

4.4.7. project

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

$ oc project <project_name>

4.5. Application Modification CLI Operations

4.5.1. get

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

$ oc get <object_type> [<object_name>]

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

Modify a volume:

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

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>

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. Build and Deployment CLI Operations

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

Perform a rollback:

$ oc rollback <deployment_name>

4.6.3. new-build

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

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

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>

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

Transform a project template into a project configuration file:

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

Export resources to be used elsewhere:

$ oc export <object_type> [--options]

See Creating a Template from Existing Objects for more information on exporting existing objects from your project in template form.

4.7.7. policy

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

$ oc policy [--options]

4.7.8. secrets

Configure secrets:

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

4.7.9. autoscale

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

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

4.8. Troubleshooting and Debugging CLI Operations

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

Forward one or more local ports to a pod:

$ 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 コマンドを使用することができます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.