CLI ツール

OpenShift Container Platform 4.8

OpenShift Container Platform コマンドラインツールの使用方法

概要

本書では、OpenShift Container Platform コマンドラインツールのインストール、設定および使用について説明します。また、CLI コマンドの参照情報およびそれらの使用方法についての例も記載しています。

第1章 OpenShift Container Platform CLI ツールの概要

OpenShift Container Platform での作業中に、次のようなさまざまな操作を実行します。

  • クラスターの管理
  • アプリケーションのビルド、デプロイ、および管理
  • デプロイメントプロセスの管理
  • Operator の開発
  • Operator カタログの作成と保守

OpenShift Container Platform には、一連のコマンドラインインターフェース(CLI)ツールが同梱されており、ユーザーがターミナルからさまざまな管理および開発操作を実行できるようにしてこれらのタスクを簡素化します。これらのツールでは、アプリケーションの管理だけでなく、システムの各コンポーネントを操作する簡単なコマンドを利用できます。

1.1. CLI ツールのリスト

OpenShift Container Platform では、以下のCLIツールのセットを使用できます。

  • OpenShift CLI(oc)です。OpenShift Container Platformのユーザーが最もよく使用するCLIツールです。これは、クラスター管理者と開発者の両方が、ターミナルを使用してOpenShift Container Platform全体でエンドツーエンドの操作が行えるようにします。Webコンソールとは異なり、ユーザーはコマンドスクリプトを使用してプロジェクトのソースコードを直接操作できます。
  • 開発者用CLI(odo)odoCLIツールは、複雑なKubernetesやOpenShift Container Platformの概念を抽象化することで、開発者がOpenShift Container Platform上でアプリケーションを作成・保守するという本来の目的に集中できるようにします。開発者は、クラスターを管理することなく、ターミナルからクラスター上のアプリケーションを書き、ビルドし、デバッグすることができます。
  • Knative CLI(kn)です。knCLIツールは、Knative ServingやEventingなどのOpenShift Serverlessコンポーネントの操作に使用できる、シンプルで直感的なターミナルコマンドを提供します。
  • Pipelines CLI(tkn)です。OpenShift Pipelinesは、OpenShift Container Platformにおける継続的インテグレーションおよび継続的デリバリ(CI/CD)ソリューションで、内部ではTektonを使用しています。tkn CLIツールには、シンプルで直感的なコマンドが同梱されており、ターミナルを使用してOpenShiftパイプラインを操作できます。
  • opm CLI:opmCLIツールは、Operator開発者やクラスタ管理者がターミナルからOperatorのカタログを作成・管理するのに役立ちます。
  • オペレータSDK。Operator Framework」のコンポーネントである「Operator SDK」は、Operator開発者がターミナルからOperatorを構築、テスト、デプロイするために使用できるCLIツールを提供します。これにより、Kubernetesネイティブアプリケーションを構築するプロセスが簡素化されます。これには、アプリケーション固有の深い運用知識が必要になる場合があります。

第2章 OpenShift CLI (oc)

2.1. OpenShift CLI の使用を開始する

2.1.1. OpenShift CLI について

OpenShift のコマンドラインインターフェース (CLI)、oc を使用すると、ターミナルからアプリケーションを作成し、OpenShift Container Platform プロジェクトを管理できます。OpenShift CLI は以下の状況に適しています。

  • プロジェクトソースコードを直接使用している。
  • OpenShift Container Platform 操作をスクリプト化する。
  • 帯域幅リソースによる制限があり、Web コンソールが利用できない状況でのプロジェクトの管理

2.1.2. OpenShift CLI のインストール。

OpenShift CLI(oc)をインストールするには、バイナリーをダウンロードするか、RPM を使用します。

2.1.2.1. バイナリーのダウンロードによる OpenShift CLI のインストール

コマンドラインインターフェースを使用して OpenShift Container Platform と対話するために CLI (oc) をインストールすることができます。oc は Linux、Windows、または macOS にインストールできます。

重要

以前のバージョンの oc をインストールしている場合、これを使用して OpenShift Container Platform 4.8 のすべてのコマンドを実行することはできません。新規バージョンの oc をダウンロードし、インストールします。

Linux への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Linux にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.8 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. アーカイブを展開します。

    $ tar xvzf <file>
  5. oc バイナリーを、PATH にあるディレクトリーに配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

$ oc <command>
Windows への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを Windows にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.8 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. ZIP プログラムでアーカイブを解凍します。
  5. oc バイナリーを、PATH にあるディレクトリーに移動します。

    PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

C:\> oc <command>
macOC への OpenShift CLI のインストール

以下の手順を使用して、OpenShift CLI (oc) バイナリーを macOS にインストールできます。

手順

  1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
  2. Version ドロップダウンメニューで適切なバージョンを選択します。
  3. OpenShift v4.8 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
  4. アーカイブを展開し、解凍します。
  5. oc バイナリーをパスにあるディレクトリーに移動します。

    PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

    $ echo $PATH

OpenShift CLI のインストール後に、oc コマンドを使用して利用できます。

$ oc <command>

2.1.2.2. RPM を使用した OpenShift CLI のインストール

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

前提条件

  • root または sudo の権限が必要です。

手順

  1. Red Hat Subscription Manager に登録します。

    # subscription-manager register
  2. 最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これを登録されたシステムにアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. OpenShift Container Platform 4.8 で必要なリポジトリーを有効にします。

    • Red Hat Enterprise Linux 8 の場合:

      # subscription-manager repos --enable="rhocp-4.8-for-rhel-8-x86_64-rpms"
    • Red Hat Enterprise Linux 7 の場合:

      # subscription-manager repos --enable="rhel-7-server-ose-4.8-rpms"
  6. openshift-clients パッケージをインストールします。

    # yum install openshift-clients

CLI のインストール後は、oc コマンドを使用して利用できます。

$ oc <command>

2.1.3. OpenShift CLI へのログイン

OpenShift CLI (oc) にログインしてクラスターにアクセスし、これを管理できます。

前提条件

  • OpenShift Container Platform クラスターへのアクセスが必要です。
  • OpenShift CLI (oc) がインストールされている必要があります。
注記

HTTP プロキシーサーバー上でのみアクセスできるクラスターにアクセスするには、HTTP_PROXYHTTPS_PROXY および NO_PROXY 変数を設定できます。これらの環境変数は、クラスターとのすべての通信が HTTP プロキシーを経由するように oc CLI で使用されます。

手順

  1. oc login コマンドを入力し、ユーザー名を渡します。

    $ oc login -u user1
  2. プロンプトが表示されたら、必要な情報を入力します。

    出力例

    Server [https://localhost:8443]: https://openshift.example.com:6443 1
    The server uses a certificate signed by an unknown authority.
    You can bypass the certificate check, but any data you send to the server could be intercepted by others.
    Use insecure connections? (y/n): y 2
    
    Authentication required for https://openshift.example.com:6443 (openshift)
    Username: user1
    Password: 3
    Login successful.
    
    You don't have any projects. You can try to create a new project, by running
    
        oc new-project <projectname>
    
    Welcome! See 'oc help' to get started.

    1
    OpenShift Container Platform サーバー URL を入力します。
    2
    非セキュアな接続を使用するかどうかを入力します。
    3
    ユーザーのパスワードを入力します。
注記

Web コンソールにログインしている場合には、トークンおよびサーバー情報を含む oc login コマンドを生成できます。このコマンドを使用して、対話プロンプトなしに OpenShift Container Platform CLI にログインできます。コマンドを生成するには、Web コンソールの右上にあるユーザー名のドロップダウンメニューから Copy login command を選択します。

これで、プロジェクトを作成でき、クラスターを管理するための他のコマンドを実行することができます。

2.1.4. OpenShift CLI の使用

以下のセクションで、CLI を使用して一般的なタスクを実行する方法を確認します。

2.1.4.1. プロジェクトの作成

新規プロジェクトを作成するには、oc new-project コマンドを使用します。

$ oc new-project my-project

出力例

Now using project "my-project" on server "https://openshift.example.com:6443".

2.1.4.2. 新しいアプリケーションの作成

新規アプリケーションを作成するには、oc new-app コマンドを使用します。

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

出力例

--> Found image 40de956 (9 days old) in imagestream "openshift/php" under tag "7.2" for "php"

...

    Run 'oc status' to view your app.

2.1.4.3. Pod の表示

現在のプロジェクトの Pod を表示するには、oc get pods コマンドを使用します。

$ oc get pods -o wide

出力例

NAME                  READY   STATUS      RESTARTS   AGE     IP            NODE                           NOMINATED NODE
cakephp-ex-1-build    0/1     Completed   0          5m45s   10.131.0.10   ip-10-0-141-74.ec2.internal    <none>
cakephp-ex-1-deploy   0/1     Completed   0          3m44s   10.129.2.9    ip-10-0-147-65.ec2.internal    <none>
cakephp-ex-1-ktz97    1/1     Running     0          3m33s   10.128.2.11   ip-10-0-168-105.ec2.internal   <none>

2.1.4.4. Pod ログの表示

特定の Pod のログを表示するには、oc logs コマンドを使用します。

$ oc logs cakephp-ex-1-deploy

出力例

--> Scaling cakephp-ex-1 to 1
--> Success

2.1.4.5. 現在のプロジェクトの表示

現在のプロジェクトを表示するには、oc project コマンドを使用します。

$ oc project

出力例

Using project "my-project" on server "https://openshift.example.com:6443".

2.1.4.6. 現在のプロジェクトのステータスの表示

サービス、デプロイメント、およびビルド設定などの現在のプロジェクトについての情報を表示するには、oc status コマンドを使用します。

$ oc status

出力例

In project my-project on server https://openshift.example.com:6443

svc/cakephp-ex - 172.30.236.80 ports 8080, 8443
  dc/cakephp-ex deploys istag/cakephp-ex:latest <-
    bc/cakephp-ex source builds https://github.com/sclorg/cakephp-ex on openshift/php:7.2
    deployment #1 deployed 2 minutes ago - 1 pod

3 infos identified, use 'oc status --suggest' to see details.

2.1.4.7. サポートされる API のリソースの一覧表示

サーバー上でサポートされる API リソースの一覧を表示するには、oc api-resources コマンドを使用します。

$ oc api-resources

出力例

NAME                                  SHORTNAMES       APIGROUP                              NAMESPACED   KIND
bindings                                                                                     true         Binding
componentstatuses                     cs                                                     false        ComponentStatus
configmaps                            cm                                                     true         ConfigMap
...

2.1.5. ヘルプの表示

CLI コマンドおよび OpenShift Container Platform リソースに関するヘルプを以下の方法で表示することができます。

  • 利用可能なすべての CLI コマンドの一覧および説明を表示するには、oc help を使用します。

    例: CLI についての一般的なヘルプの表示

    $ oc help

    出力例

    OpenShift Client
    
    This client helps you develop, build, deploy, and run your applications on any OpenShift or Kubernetes compatible
    platform. It also includes the administrative commands for managing a cluster under the 'adm' subcommand.
    
    Usage:
      oc [flags]
    
    Basic Commands:
      login           Log in to a server
      new-project     Request a new project
      new-app         Create a new application
    
    ...

  • 特定の CLI コマンドについてのヘルプを表示するには、--help フラグを使用します。

    例: oc create コマンドについてのヘルプの表示

    $ oc create --help

    出力例

    Create a resource by filename or stdin
    
    JSON and YAML formats are accepted.
    
    Usage:
      oc create -f FILENAME [flags]
    
    ...

  • 特定リソースについての説明およびフィールドを表示するには、oc explain コマンドを使用します。

    例: Pod リソースのドキュメントの表示

    $ oc explain pods

    出力例

    KIND:     Pod
    VERSION:  v1
    
    DESCRIPTION:
         Pod is a collection of containers that can run on a host. This resource is
         created by clients and scheduled onto hosts.
    
    FIELDS:
       apiVersion	<string>
         APIVersion defines the versioned schema of this representation of an
         object. Servers should convert recognized schemas to the latest internal
         value, and may reject unrecognized values. More info:
         https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
    
    ...

2.1.6. OpenShift CLI からのログアウト

OpenShift CLI からログアウトし、現在のセッションを終了することができます。

  • oc logout コマンドを使用します。

    $ oc logout

    出力例

    Logged "user1" out on "https://openshift.example.com"

これにより、サーバーから保存された認証トークンが削除され、設定ファイルから除去されます。

2.2. OpenShift CLI の設定

2.2.1. タブ補完の有効化

oc CLI ツールをインストールした後に、タブ補完を有効にして oc コマンドの自動補完を実行するか、または Tab キーを押す際にオプションの提案が表示されるようにできます。

前提条件

  • oc CLI ツールをインストールしていること。
  • bash-completion パッケージがインストールされている。

手順

以下の手順では、Bash のタブ補完を有効にします。

  1. Bash 補完コードをファイルに保存します。

    $ oc completion bash > oc_bash_completion
  2. ファイルを /etc/bash_completion.d/ にコピーします。

    $ sudo cp oc_bash_completion /etc/bash_completion.d/

    さらにファイルをローカルディレクトリーに保存した後に、これを .bashrc ファイルから取得できるようにすることができます。

タブ補完は、新規ターミナルを開くと有効にされます。

2.3. プラグインによる OpenShift CLI の拡張

デフォルトの oc コマンドを拡張するためにプラグインを作成およびインストールし、これを使用して OpenShift Container Platform CLI で新規および追加の複雑なタスクを実行できます。

2.3.1. CLI プラグインの作成

コマンドラインのコマンドを作成できる任意のプログラミング言語またはスクリプトで、OpenShift Container Platform CLI のプラグインを作成できます。既存の oc コマンドを上書きするプラグインを使用することはできない点に注意してください。

手順

以下の手順では、oc foo コマンドの実行時にターミナルにメッセージを出力する単純な Bash プラグインを作成します。

  1. oc-foo というファイルを作成します。

    プラグインファイルの名前を付ける際には、以下の点に留意してください。

    • プログインとして認識されるように、ファイルの名前は oc- または kubectl- で開始する必要があります。
    • ファイル名は、プラグインを起動するコマンドを判別するものとなります。たとえば、ファイル名が oc-foo-bar のプラグインは、oc foo bar のコマンドで起動します。また、コマンドにダッシュを含める必要がある場合には、アンダースコアを使用することもできます。たとえば、ファイル名が oc-foo_bar のプラグインはoc foo-bar のコマンドで起動できます。
  2. 以下の内容をファイルに追加します。

    #!/bin/bash
    
    # optional argument handling
    if [[ "$1" == "version" ]]
    then
        echo "1.0.0"
        exit 0
    fi
    
    # optional argument handling
    if [[ "$1" == "config" ]]
    then
        echo $KUBECONFIG
        exit 0
    fi
    
    echo "I am a plugin named kubectl-foo"

OpenShift Container Platform CLI のこのプラグインをインストールした後に、oc foo コマンドを使用してこれを起動できます。

追加リソース

2.3.2. CLI プラグインのインストールおよび使用

OpenShift Container Platform CLI のカスタムプラグインの作成後に、これが提供する機能を使用できるようインストールする必要があります。

前提条件

  • oc CLI ツールをインストールしていること。
  • oc- または kubectl- で始まる CLI プラグインファイルがあること。

手順

  1. 必要に応じて、プラグインファイルを実行可能な状態になるように更新します。

    $ chmod +x <plugin_file>
  2. ファイルを PATH の任意の場所に置きます (例: /usr/local/bin/)。

    $ sudo mv <plugin_file> /usr/local/bin/.
  3. oc plugin list を実行し、プラグインが一覧表示されることを確認します。

    $ oc plugin list

    出力例

    The following compatible plugins are available:
    
    /usr/local/bin/<plugin_file>

    プラグインがここに一覧表示されていない場合、ファイルが oc- または kubectl- で開始されるものであり、実行可能な状態で PATH 上にあることを確認します。

  4. プラグインによって導入される新規コマンドまたはオプションを起動します。

    たとえば、kubectl-ns プラグインを サンプルのプラグインリポジトリー からビルドし、インストールしている場合、以下のコマンドを使用して現在の namespace を表示できます。

    $ oc ns

    プラグインを起動するためのコマンドはプラグインファイル名によって異なることに注意してください。たとえば、ファイル名が oc-foo-bar のプラグインは oc foo bar コマンドによって起動します。

2.4. OpenShift CLI 開発者コマンドリファレンス

このリファレンスは、OpenShift CLI (oc) 開発者コマンドの説明とコマンド例を示しています。管理者コマンドについては、「OpenShift CLI 管理者コマンドリファレンス」を参照してください。

oc help を実行して、すべてのコマンドを表示するか、または oc <command> --help を実行して、特定のコマンドに関する追加情報を取得します。

2.4.1. OpenShift CLI (oc) 開発者コマンド

2.4.1.1. oc annotate

リソースへのアノテーションを更新します。

使用例

  # Update pod 'foo' with the annotation 'description' and the value 'my frontend'.
  # If the same annotation is set multiple times, only the last value will be applied
  oc annotate pods foo description='my frontend'

  # Update a pod identified by type and name in "pod.json"
  oc annotate -f pod.json description='my frontend'

  # Update pod 'foo' with the annotation 'description' and the value 'my frontend running nginx', overwriting any existing value.
  oc annotate --overwrite pods foo description='my frontend running nginx'

  # Update all pods in the namespace
  oc annotate pods --all description='my frontend running nginx'

  # Update pod 'foo' only if the resource is unchanged from version 1.
  oc annotate pods foo description='my frontend running nginx' --resource-version=1

  # Update pod 'foo' by removing an annotation named 'description' if it exists.
  # Does not require the --overwrite flag.
  oc annotate pods foo description-

2.4.1.2. oc api-resources

サーバー上のサポートされている API リソースを出力します。

使用例

  # Print the supported API Resources
  oc api-resources

  # Print the supported API Resources with more information
  oc api-resources -o wide

  # Print the supported API Resources sorted by a column
  oc api-resources --sort-by=name

  # Print the supported namespaced resources
  oc api-resources --namespaced=true

  # Print the supported non-namespaced resources
  oc api-resources --namespaced=false

  # Print the supported API Resources with specific APIGroup
  oc api-resources --api-group=extensions

2.4.1.3. oc api-versions

「group/version」という形式で、サーバー上でサポートされる API バージョンを出力します。

使用例

  # Print the supported API versions
  oc api-versions

2.4.1.4. oc apply

設定をファイル名または標準入力 (stdin) 別のリソースに適用します。

使用例

  # Apply the configuration in pod.json to a pod.
  oc apply -f ./pod.json

  # Apply resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml.
  oc apply -k dir/

  # Apply the JSON passed into stdin to a pod.
  cat pod.json | oc apply -f -

  # Note: --prune is still in Alpha
  # Apply the configuration in manifest.yaml that matches label app=nginx and delete all the other resources that are not in the file and match label app=nginx.
  oc apply --prune -f manifest.yaml -l app=nginx

  # Apply the configuration in manifest.yaml and delete all the other configmaps that are not in the file.
  oc apply --prune -f manifest.yaml --all --prune-whitelist=core/v1/ConfigMap

2.4.1.5. oc apply edit-last-applied

リソース/オブジェクトの最新の last-applied-configuration アノテーションを編集します。

使用例

  # Edit the last-applied-configuration annotations by type/name in YAML.
  oc apply edit-last-applied deployment/nginx

  # Edit the last-applied-configuration annotations by file in JSON.
  oc apply edit-last-applied -f deploy.yaml -o json

2.4.1.6. oc apply set-last-applied

ファイルの内容に一致するように、ライブオブジェクトに last-applied-configuration アノテーションを設定します。

使用例

  # Set the last-applied-configuration of a resource to match the contents of a file.
  oc apply set-last-applied -f deploy.yaml

  # Execute set-last-applied against each configuration file in a directory.
  oc apply set-last-applied -f path/

  # Set the last-applied-configuration of a resource to match the contents of a file, will create the annotation if it does not already exist.
  oc apply set-last-applied -f deploy.yaml --create-annotation=true

2.4.1.7. oc apply view-last-applied

リソース/オブジェクトの最新の last-applied-configuration アノテーションを表示します。

使用例

  # View the last-applied-configuration annotations by type/name in YAML.
  oc apply view-last-applied deployment/nginx

  # View the last-applied-configuration annotations by file in JSON
  oc apply view-last-applied -f deploy.yaml -o json

2.4.1.8. oc attach

実行中のコンテナーに割り当てます。

使用例

  # Get output from running pod mypod, use the oc.kubernetes.io/default-container annotation
  # for selecting the container to be attached or the first container in the pod will be chosen
  oc attach mypod

  # Get output from ruby-container from pod mypod
  oc attach mypod -c ruby-container

  # Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod mypod
  # and sends stdout/stderr from 'bash' back to the client
  oc attach mypod -c ruby-container -i -t

  # Get output from the first pod of a ReplicaSet named nginx
  oc attach rs/nginx

2.4.1.9. oc auth can-i

アクションが可能かどうかを確認します。

使用例

  # Check to see if I can create pods in any namespace
  oc auth can-i create pods --all-namespaces

  # Check to see if I can list deployments in my current namespace
  oc auth can-i list deployments.apps

  # Check to see if I can do everything in my current namespace ("*" means all)
  oc auth can-i '*' '*'

  # Check to see if I can get the job named "bar" in namespace "foo"
  oc auth can-i list jobs.batch/bar -n foo

  # Check to see if I can read pod logs
  oc auth can-i get pods --subresource=log

  # Check to see if I can access the URL /logs/
  oc auth can-i get /logs/

  # List all allowed actions in namespace "foo"
  oc auth can-i --list --namespace=foo

2.4.1.10. oc auth reconcile

RBAC Role、RoleBinding、ClusterRole、および ClusterRoleBinding オブジェクトのルールを調整します。

使用例

  # Reconcile rbac resources from a file
  oc auth reconcile -f my-rbac-rules.yaml

2.4.1.11. oc autoscale

デプロイメント設定、デプロイメント、レプリカセット、ステートフルセット、またはレプリケーションコントローラーを自動スケーリングします。

使用例

  # Auto scale a deployment "foo", with the number of pods between 2 and 10, no target CPU utilization specified so a default autoscaling policy will be used:
  oc autoscale deployment foo --min=2 --max=10

  # Auto scale a replication controller "foo", with the number of pods between 1 and 5, target CPU utilization at 80%:
  oc autoscale rc foo --max=5 --cpu-percent=80

2.4.1.12. oc cancel-build

実行中、保留中、または新規のビルドを取り消します。

使用例

  # Cancel the build with the given name
  oc cancel-build ruby-build-2

  # Cancel the named build and print the build logs
  oc cancel-build ruby-build-2 --dump-logs

  # Cancel the named build and create a new one with the same parameters
  oc cancel-build ruby-build-2 --restart

  # Cancel multiple builds
  oc cancel-build ruby-build-1 ruby-build-2 ruby-build-3

  # Cancel all builds created from the 'ruby-build' build config that are in the 'new' state
  oc cancel-build bc/ruby-build --state=new

2.4.1.13. oc cluster-info

クラスターの情報を表示します。

使用例

  # Print the address of the control plane and cluster services
  oc cluster-info

2.4.1.14. oc cluster-info dump

デバッグおよび診断に関する関連情報を多数ダンプします。

使用例

  # Dump current cluster state to stdout
  oc cluster-info dump

  # Dump current cluster state to /path/to/cluster-state
  oc cluster-info dump --output-directory=/path/to/cluster-state

  # Dump all namespaces to stdout
  oc cluster-info dump --all-namespaces

  # Dump a set of namespaces to /path/to/cluster-state
  oc cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state

2.4.1.15. oc completion

指定されたシェル (bash または zsh) の補完コードを出力します。

使用例

  # Installing bash completion on macOS using homebrew
  ## If running Bash 3.2 included with macOS
  brew install bash-completion
  ## or, if running Bash 4.1+
  brew install bash-completion@2
  ## If oc is installed via homebrew, this should start working immediately.
  ## If you've installed via other means, you may need add the completion to your completion directory
  oc completion bash > $(brew --prefix)/etc/bash_completion.d/oc


  # Installing bash completion on Linux
  ## If bash-completion is not installed on Linux, please install the 'bash-completion' package
  ## via your distribution's package manager.
  ## Load the oc completion code for bash into the current shell
  source <(oc completion bash)
  ## Write bash completion code to a file and source it from .bash_profile
  oc completion bash > ~/.kube/completion.bash.inc
  printf "
  # Kubectl shell completion
  source '$HOME/.kube/completion.bash.inc'
  " >> $HOME/.bash_profile
  source $HOME/.bash_profile

  # Load the oc completion code for zsh[1] into the current shell
  source <(oc completion zsh)
  # Set the oc completion code for zsh[1] to autoload on startup
  oc completion zsh > "${fpath[1]}/_oc"

2.4.1.16. oc config current-context

current-context を表示します

使用例

  # Display the current-context
  oc config current-context

2.4.1.17. oc config delete-cluster

kubeconfig から指定されたクラスターを削除します。

使用例

  # Delete the minikube cluster
  oc config delete-cluster minikube

2.4.1.18. oc config delete-context

kubeconfig から指定されたコンテキストを削除します。

使用例

  # Delete the context for the minikube cluster
  oc config delete-context minikube

2.4.1.19. oc config delete-user

kubeconfig から指定されたユーザーを削除します。

使用例

  # Delete the minikube user
  oc config delete-user minikube

2.4.1.20. oc config get-clusters

kubeconfig に定義されるクラスターを表示します。

使用例

  # List the clusters oc knows about
  oc config get-clusters

2.4.1.21. oc config get-contexts

コンテキストを 1 つまたは複数記述します。

使用例

  # List all the contexts in your kubeconfig file
  oc config get-contexts

  # Describe one context in your kubeconfig file.
  oc config get-contexts my-context

2.4.1.22. oc config get-users

kubeconfig で定義されるユーザーを表示します。

使用例

  # List the users oc knows about
  oc config get-users

2.4.1.23. oc config rename-context

kubeconfig ファイルからのコンテキストの名前を変更します。

使用例

  # Rename the context 'old-name' to 'new-name' in your kubeconfig file
  oc config rename-context old-name new-name

2.4.1.24. oc config set

kubeconfig ファイルに個別の値を設定します。

使用例

  # Set server field on the my-cluster cluster to https://1.2.3.4
  oc config set clusters.my-cluster.server https://1.2.3.4

  # Set certificate-authority-data field on the my-cluster cluster.
  oc config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

  # Set cluster field in the my-context context to my-cluster.
  oc config set contexts.my-context.cluster my-cluster

  # Set client-key-data field in the cluster-admin user using --set-raw-bytes option.
  oc config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

2.4.1.25. oc config set-cluster

kubeconfig でクラスターエントリーを設定します。

使用例

  # Set only the server field on the e2e cluster entry without touching other values.
  oc config set-cluster e2e --server=https://1.2.3.4

  # Embed certificate authority data for the e2e cluster entry
  oc config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

  # Disable cert checking for the dev cluster entry
  oc config set-cluster e2e --insecure-skip-tls-verify=true

  # Set custom TLS server name to use for validation for the e2e cluster entry
  oc config set-cluster e2e --tls-server-name=my-cluster-name

2.4.1.26. oc config set-context

kubeconfig のコンテキストエントリーを設定します。

使用例

  # Set the user field on the gce context entry without touching other values
  oc config set-context gce --user=cluster-admin

2.4.1.27. oc config set-credentials

kubeconfig のユーザーエントリーを設定します。

使用例

  # Set only the "client-key" field on the "cluster-admin"
  # entry, without touching other values:
  oc config set-credentials cluster-admin --client-key=~/.kube/admin.key

  # Set basic auth for the "cluster-admin" entry
  oc config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

  # Embed client certificate data in the "cluster-admin" entry
  oc config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

  # Enable the Google Compute Platform auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=gcp

  # Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

  # Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

  # Enable new exec auth plugin for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

  # Define new exec auth plugin args for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

  # Create or update exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

  # Remove exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=var-to-remove-

2.4.1.28. oc config unset

kubeconfig ファイルでの個別値の設定を解除します。

使用例

  # Unset the current-context.
  oc config unset current-context

  # Unset namespace in foo context.
  oc config unset contexts.foo.namespace

2.4.1.29. oc config use-context

kubeconfig ファイルで current-context を設定します。

使用例

  # Use the context for the minikube cluster
  oc config use-context minikube

2.4.1.30. oc config view

マージされた kubeconfig 設定または指定された kubeconfig ファイルを表示します。

使用例

  # Show merged kubeconfig settings.
  oc config view

  # Show merged kubeconfig settings and raw certificate data.
  oc config view --raw

  # Get the password for the e2e user
  oc config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

2.4.1.31. oc cp

ファイルおよびディレクトリーのコンテナーへの/からのコピーを実行します。

使用例

  # !!!Important Note!!!
  # Requires that the 'tar' binary is present in your container
  # image.  If 'tar' is not present, 'oc cp' will fail.
  #
  # For advanced use cases, such as symlinks, wildcard expansion or
  # file mode preservation consider using 'oc exec'.

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
  tar cf - /tmp/foo | oc exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar

  # Copy /tmp/foo from a remote pod to /tmp/bar locally
  oc exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

  # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the default namespace
  oc cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
  oc cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

  # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace <some-namespace>
  oc cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

  # Copy /tmp/foo from a remote pod to /tmp/bar locally
  oc cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

2.4.1.32. oc create

ファイルまたは標準入力 (stdin) からリソースを作成します。

使用例

  # Create a pod using the data in pod.json.
  oc create -f ./pod.json

  # Create a pod based on the JSON passed into stdin.
  cat pod.json | oc create -f -

  # Edit the data in docker-registry.yaml in JSON then create the resource using the edited data.
  oc create -f docker-registry.yaml --edit -o json

2.4.1.33. oc create build

新規ビルドを作成します。

使用例

  # Create a new build
  oc create build myapp

2.4.1.34. oc create clusterresourcequota

クラスターリソースクォータを作成します。

使用例

  # Create a cluster resource quota limited to 10 pods
  oc create clusterresourcequota limit-bob --project-annotation-selector=openshift.io/requester=user-bob --hard=pods=10

2.4.1.35. oc create clusterrole

ClusterRole を作成します。

使用例

  # Create a ClusterRole named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  oc create clusterrole pod-reader --verb=get,list,watch --resource=pods

  # Create a ClusterRole named "pod-reader" with ResourceName specified
  oc create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

  # Create a ClusterRole named "foo" with API Group specified
  oc create clusterrole foo --verb=get,list,watch --resource=rs.extensions

  # Create a ClusterRole named "foo" with SubResource specified
  oc create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

  # Create a ClusterRole name "foo" with NonResourceURL specified
  oc create clusterrole "foo" --verb=get --non-resource-url=/logs/*

  # Create a ClusterRole name "monitoring" with AggregationRule specified
  oc create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

2.4.1.36. oc create clusterrolebinding

特定の ClusterRole の ClusterRoleBinding を作成します。

使用例

  # Create a ClusterRoleBinding for user1, user2, and group1 using the cluster-admin ClusterRole
  oc create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

2.4.1.37. oc create configmap

ローカルファイル、ディレクトリー、またはリテラル値から configmap を作成します。

使用例

  # Create a new configmap named my-config based on folder bar
  oc create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config with specified keys instead of file basenames on disk
  oc create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

  # Create a new configmap named my-config with key1=config1 and key2=config2
  oc create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

  # Create a new configmap named my-config from the key=value pairs in the file
  oc create configmap my-config --from-file=path/to/bar

  # Create a new configmap named my-config from an env file
  oc create configmap my-config --from-env-file=path/to/bar.env

2.4.1.38. oc create cronjob

指定の名前で cronjob を作成します。

使用例

  # Create a cronjob
  oc create cronjob my-job --image=busybox --schedule="*/1 * * * *"

  # Create a cronjob with command
  oc create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

2.4.1.39. oc create deployment

指定の名前のデプロイメントを作成します。

使用例

  # Create a deployment named my-dep that runs the busybox image.
  oc create deployment my-dep --image=busybox

  # Create a deployment with command
  oc create deployment my-dep --image=busybox -- date

  # Create a deployment named my-dep that runs the nginx image with 3 replicas.
  oc create deployment my-dep --image=nginx --replicas=3

  # Create a deployment named my-dep that runs the busybox image and expose port 5701.
  oc create deployment my-dep --image=busybox --port=5701

2.4.1.40. oc create deploymentconfig

デフォルトのオプションを指定して特定のイメージを使用するデプロイメント設定を作成します。

使用例

  # Create an nginx deployment config named my-nginx
  oc create deploymentconfig my-nginx --image=nginx

2.4.1.41. oc create identity

アイデンティティーを手動で作成します (自動作成が無効になっている場合のみが必要)。

使用例

  # Create an identity with identity provider "acme_ldap" and the identity provider username "adamjones"
  oc create identity acme_ldap:adamjones

2.4.1.42. oc create imagestream

空のイメージストリームを新たに作成します。

使用例

  # Create a new image stream
  oc create imagestream mysql

2.4.1.43. oc create imagestreamtag

新規イメージストリームタグを作成します。

使用例

  # Create a new image stream tag based on an image in a remote registry
  oc create imagestreamtag mysql:latest --from-image=myregistry.local/mysql/mysql:5.0

2.4.1.44. oc create ingress

指定の名前で Ingress を作成します。

使用例

  # Create a single ingress called 'simple' that directs requests to foo.com/bar to svc
  # svc1:8080 with a tls secret "my-cert"
  oc create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

  # Create a catch all ingress of "/path" pointing to service svc:port and Ingress Class as "otheringress"
  oc create ingress catch-all --class=otheringress --rule="/path=svc:port"

  # Create an ingress with two annotations: ingress.annotation1 and ingress.annotations2
  oc create ingress annotated --class=default --rule="foo.com/bar=svc:port" \
  --annotation ingress.annotation1=foo \
  --annotation ingress.annotation2=bla

  # Create an ingress with the same host and multiple paths
  oc create ingress multipath --class=default \
  --rule="foo.com/=svc:port" \
  --rule="foo.com/admin/=svcadmin:portadmin"

  # Create an ingress with multiple hosts and the pathType as Prefix
  oc create ingress ingress1 --class=default \
  --rule="foo.com/path*=svc:8080" \
  --rule="bar.com/admin*=svc2:http"

  # Create an ingress with TLS enabled using the default ingress certificate and different path types
  oc create ingress ingtls --class=default \
  --rule="foo.com/=svc:https,tls" \
  --rule="foo.com/path/subpath*=othersvc:8080"

  # Create an ingress with TLS enabled using a specific secret and pathType as Prefix
  oc create ingress ingsecret --class=default \
  --rule="foo.com/*=svc:8080,tls=secret1"

  # Create an ingress with a default backend
  oc create ingress ingdefault --class=default \
  --default-backend=defaultsvc:http \
  --rule="foo.com/*=svc:8080,tls=secret1"

2.4.1.45. oc create job

指定の名前でジョブを作成します。

使用例

  # Create a job
  oc create job my-job --image=busybox

  # Create a job with command
  oc create job my-job --image=busybox -- date

  # Create a job from a CronJob named "a-cronjob"
  oc create job test-job --from=cronjob/a-cronjob

2.4.1.46. oc create namespace

指定の名前で namespace を作成します。

使用例

  # Create a new namespace named my-namespace
  oc create namespace my-namespace

2.4.1.47. oc create poddisruptionbudget

指定の名前で Pod Disruption Budget (PDB) を作成します。

使用例

  # Create a pod disruption budget named my-pdb that will select all pods with the app=rails label
  # and require at least one of them being available at any point in time.
  oc create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

  # Create a pod disruption budget named my-pdb that will select all pods with the app=nginx label
  # and require at least half of the pods selected to be available at any point in time.
  oc create pdb my-pdb --selector=app=nginx --min-available=50%

2.4.1.48. oc create priorityclass

指定の名前で priorityclass を作成します。

使用例

  # Create a priorityclass named high-priority
  oc create priorityclass high-priority --value=1000 --description="high priority"

  # Create a priorityclass named default-priority that considered as the global default priority
  oc create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

  # Create a priorityclass named high-priority that can not preempt pods with lower priority
  oc create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

2.4.1.49. oc create quota

指定の名前でクォータを作成します。

使用例

  # Create a new resourcequota named my-quota
  oc create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

  # Create a new resourcequota named best-effort
  oc create quota best-effort --hard=pods=100 --scopes=BestEffort

2.4.1.50. oc create role

単一ルールでロールを作成します。

使用例

  # Create a Role named "pod-reader" that allows user to perform "get", "watch" and "list" on pods
  oc create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

  # Create a Role named "pod-reader" with ResourceName specified
  oc create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

  # Create a Role named "foo" with API Group specified
  oc create role foo --verb=get,list,watch --resource=rs.extensions

  # Create a Role named "foo" with SubResource specified
  oc create role foo --verb=get,list,watch --resource=pods,pods/status

2.4.1.51. oc create rolebinding

特定のロールまたは ClusterRole の RoleBinding を作成します。

使用例

  # Create a RoleBinding for user1, user2, and group1 using the admin ClusterRole
  oc create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

2.4.1.52. oc create route edge

edge TLS termination を使用するルートを作成します。

使用例

  # Create an edge route named "my-route" that exposes the frontend service
  oc create route edge my-route --service=frontend

  # Create an edge route that exposes the frontend service and specify a path
  # If the route name is omitted, the service name will be used
  oc create route edge --service=frontend --path /assets

2.4.1.53. oc create route passthrough

passthrough TLS 終端を使用するルートを作成します。

使用例

  # Create a passthrough route named "my-route" that exposes the frontend service
  oc create route passthrough my-route --service=frontend

  # Create a passthrough route that exposes the frontend service and specify
  # a host name. If the route name is omitted, the service name will be used
  oc create route passthrough --service=frontend --hostname=www.example.com

2.4.1.54. oc create route reencrypt

re-encrypt TLS 終端を使用するルートを作成します。

使用例

  # Create a route named "my-route" that exposes the frontend service
  oc create route reencrypt my-route --service=frontend --dest-ca-cert cert.cert

  # Create a reencrypt route that exposes the frontend service, letting the
  # route name default to the service name and the destination CA certificate
  # default to the service CA
  oc create route reencrypt --service=frontend

2.4.1.55. oc create secret docker-registry

Docker レジストリーで使用するシークレットを作成します。

使用例

  # If you don't already have a .dockercfg file, you can create a dockercfg secret directly by using:
  oc create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

  # Create a new secret named my-secret from ~/.docker/config.json
  oc create secret docker-registry my-secret --from-file=.dockerconfigjson=path/to/.docker/config.json

2.4.1.56. oc create secret generic

ローカルファイル、ディレクトリー、またはリテラル値からシークレットを作成します。

使用例

  # Create a new secret named my-secret with keys for each file in folder bar
  oc create secret generic my-secret --from-file=path/to/bar

  # Create a new secret named my-secret with specified keys instead of names on disk
  oc create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub

  # Create a new secret named my-secret with key1=supersecret and key2=topsecret
  oc create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

  # Create a new secret named my-secret using a combination of a file and a literal
  oc create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

  # Create a new secret named my-secret from an env file
  oc create secret generic my-secret --from-env-file=path/to/bar.env

2.4.1.57. oc create secret tls

TLS シークレットを作成します。

使用例

  # Create a new TLS secret named tls-secret with the given key pair:
  oc create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key

2.4.1.58. oc create service clusterip

ClusterIP サービスを作成します。

使用例

  # Create a new ClusterIP service named my-cs
  oc create service clusterip my-cs --tcp=5678:8080

  # Create a new ClusterIP service named my-cs (in headless mode)
  oc create service clusterip my-cs --clusterip="None"

2.4.1.59. oc create service externalname

ExternalName サービスを作成します。

使用例

  # Create a new ExternalName service named my-ns
  oc create service externalname my-ns --external-name bar.com

2.4.1.60. oc create service loadbalancer

Pod に LoadBalancer サービスを作成します。

使用例

  # Create a new LoadBalancer service named my-lbs
  oc create service loadbalancer my-lbs --tcp=5678:8080

2.4.1.61. oc create service nodeport

NodePort サービスを作成します。

使用例

  # Create a new NodePort service named my-ns
  oc create service nodeport my-ns --tcp=5678:8080

2.4.1.62. oc create serviceaccount

指定の名前でサービスアカウントを作成します。

使用例

  # Create a new service account named my-service-account
  oc create serviceaccount my-service-account

2.4.1.63. oc create user

ユーザーを手動で作成します (自動作成が無効になっている場合のみ必要)。

使用例

  # Create a user with the username "ajones" and the display name "Adam Jones"
  oc create user ajones --full-name="Adam Jones"

2.4.1.64. oc create useridentitymapping

アイデンティティーをユーザーに手動でマップします。

使用例

  # Map the identity "acme_ldap:adamjones" to the user "ajones"
  oc create useridentitymapping acme_ldap:adamjones ajones

2.4.1.65. oc debug

デバッグ用に Pod の新規インスタンスを起動します。

使用例

  # Start a shell session into a pod using the OpenShift tools image
  oc debug

  # Debug a currently running deployment by creating a new pod
  oc debug deploy/test

  # Debug a node as an administrator
  oc debug node/master-1

  # Launch a shell in a pod using the provided image stream tag
  oc debug istag/mysql:latest -n openshift

  # Test running a job as a non-root user
  oc debug job/test --as-user=1000000

  # Debug a specific failing container by running the env command in the 'second' container
  oc debug daemonset/test -c second -- /bin/env

  # See the pod that would be created to debug
  oc debug mypod-9xbc -o yaml

  # Debug a resource but launch the debug pod in another namespace
  # Note: Not all resources can be debugged using --to-namespace without modification. For example,
  # volumes and service accounts are namespace-dependent. Add '-o yaml' to output the debug pod definition
  # to disk.  If necessary, edit the definition then run 'oc debug -f -' or run without --to-namespace
  oc debug mypod-9xbc --to-namespace testns

2.4.1.66. oc delete

ファイル名、stdin、リソースおよび名前、またはリソースおよびラベルセレクター別にリソースを削除します。

使用例

  # Delete a pod using the type and name specified in pod.json.
  oc delete -f ./pod.json

  # Delete resources from a directory containing kustomization.yaml - e.g. dir/kustomization.yaml.
  oc delete -k dir

  # Delete a pod based on the type and name in the JSON passed into stdin.
  cat pod.json | oc delete -f -

  # Delete pods and services with same names "baz" and "foo"
  oc delete pod,service baz foo

  # Delete pods and services with label name=myLabel.
  oc delete pods,services -l name=myLabel

  # Delete a pod with minimal delay
  oc delete pod foo --now

  # Force delete a pod on a dead node
  oc delete pod foo --force

  # Delete all pods
  oc delete pods --all

2.4.1.67. oc describe

特定のリソースまたはリソースのグループの詳細を表示します。

使用例

  # Describe a node
  oc describe nodes kubernetes-node-emt8.c.myproject.internal

  # Describe a pod
  oc describe pods/nginx

  # Describe a pod identified by type and name in "pod.json"
  oc describe -f pod.json

  # Describe all pods
  oc describe pods

  # Describe pods by label name=myLabel
  oc describe po -l name=myLabel

  # Describe all pods managed by the 'frontend' replication controller (rc-created pods
  # get the name of the rc as a prefix in the pod the name).
  oc describe pods frontend

2.4.1.68. oc diff

ライブバーションと適用バージョンとの差異を確認します。

使用例

  # Diff resources included in pod.json.
  oc diff -f pod.json

  # Diff file read from stdin
  cat service.yaml | oc diff -f -

2.4.1.69. oc edit

サーバーのリソースを編集します。

使用例

  # Edit the service named 'docker-registry':
  oc edit svc/docker-registry

  # Use an alternative editor
  KUBE_EDITOR="nano" oc edit svc/docker-registry

  # Edit the job 'myjob' in JSON using the v1 API format:
  oc edit job.v1.batch/myjob -o json

  # Edit the deployment 'mydeployment' in YAML and save the modified config in its annotation:
  oc edit deployment/mydeployment -o yaml --save-config

2.4.1.70. oc ex dockergc

Docker ストレージで領域を解放するためにガベージコレクションを実行します。

使用例

  # Perform garbage collection with the default settings
  oc ex dockergc

2.4.1.71. oc exec

コンテナーでコマンドを実行します。

使用例

  # Get output from running 'date' command from pod mypod, using the first container by default
  oc exec mypod -- date

  # Get output from running 'date' command in ruby-container from pod mypod
  oc exec mypod -c ruby-container -- date

  # Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod mypod
  # and sends stdout/stderr from 'bash' back to the client
  oc exec mypod -c ruby-container -i -t -- bash -il

  # List contents of /usr from the first container of pod mypod and sort by modification time.
  # If the command you want to execute in the pod has any flags in common (e.g. -i),
  # you must use two dashes (--) to separate your command's flags/arguments.
  # Also note, do not surround your command and its flags/arguments with quotes
  # unless that is how you would execute it normally (i.e., do ls -t /usr, not "ls -t /usr").
  oc exec mypod -i -t -- ls -t /usr

  # Get output from running 'date' command from the first pod of the deployment mydeployment, using the first container by default
  oc exec deploy/mydeployment -- date

  # Get output from running 'date' command from the first pod of the service myservice, using the first container by default
  oc exec svc/myservice -- date

2.4.1.72. oc explain

リソースのドキュメントを取得します。

使用例

  # Get the documentation of the resource and its fields
  oc explain pods

  # Get the documentation of a specific field of a resource
  oc explain pods.spec.containers

2.4.1.73. oc expose

複製されたアプリケーションをサービスまたはルートとして公開します。

使用例

  # Create a route based on service nginx. The new route will reuse nginx's labels
  oc expose service nginx

  # Create a route and specify your own label and route name
  oc expose service nginx -l name=myroute --name=fromdowntown

  # Create a route and specify a host name
  oc expose service nginx --hostname=www.example.com

  # Create a route with a wildcard
  oc expose service nginx --hostname=x.example.com --wildcard-policy=Subdomain
  # This would be equivalent to *.example.com. NOTE: only hosts are matched by the wildcard; subdomains would not be included

  # Expose a deployment configuration as a service and use the specified port
  oc expose dc ruby-hello-world --port=8080

  # Expose a service as a route in the specified path
  oc expose service nginx --path=/nginx

  # Expose a service using different generators
  oc expose service nginx --name=exposed-svc --port=12201 --protocol="TCP" --generator="service/v2"
  oc expose service nginx --name=my-route --port=12201 --generator="route/v1"

  # Exposing a service using the "route/v1" generator (default) will create a new exposed route with the "--name" provided
  # (or the name of the service otherwise). You may not specify a "--protocol" or "--target-port" option when using this generator

2.4.1.74. oc extract

シークレットまたは設定マップをディスクに抽出します。

使用例

  # Extract the secret "test" to the current directory
  oc extract secret/test

  # Extract the config map "nginx" to the /tmp directory
  oc extract configmap/nginx --to=/tmp

  # Extract the config map "nginx" to STDOUT
  oc extract configmap/nginx --to=-

  # Extract only the key "nginx.conf" from config map "nginx" to the /tmp directory
  oc extract configmap/nginx --to=/tmp --keys=nginx.conf

2.4.1.75. oc get

1 つ以上のリソースを表示します。

使用例

  # List all pods in ps output format.
  oc get pods

  # List all pods in ps output format with more information (such as node name).
  oc get pods -o wide

  # List a single replication controller with specified NAME in ps output format.
  oc get replicationcontroller web

  # List deployments in JSON output format, in the "v1" version of the "apps" API group:
  oc get deployments.v1.apps -o json

  # List a single pod in JSON output format.
  oc get -o json pod web-pod-13je7

  # List a pod identified by type and name specified in "pod.yaml" in JSON output format.
  oc get -f pod.yaml -o json

  # List resources from a directory with kustomization.yaml - e.g. dir/kustomization.yaml.
  oc get -k dir/

  # Return only the phase value of the specified pod.
  oc get -o template pod/web-pod-13je7 --template={{.status.phase}}

  # List resource information in custom columns.
  oc get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

  # List all replication controllers and services together in ps output format.
  oc get rc,services

  # List one or more resources by their type and names.
  oc get rc/web service/frontend pods/web-pod-13je7

2.4.1.76. oc idle

スケーラブルなリソースをアイドリングします。

使用例

  # Idle the scalable controllers associated with the services listed in to-idle.txt
  $ oc idle --resource-names-file to-idle.txt

2.4.1.77. oc image append

イメージにレイヤーを追加してレジストリーにプッシュします。

使用例

  # Remove the entrypoint on the mysql:latest image
  oc image append --from mysql:latest --to myregistry.com/myimage:latest --image '{"Entrypoint":null}'

  # Add a new layer to the image
  oc image append --from mysql:latest --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to the image and store the result on disk
  # This results in $(pwd)/v2/mysql/blobs,manifests
  oc image append --from mysql:latest --to file://mysql:local layer.tar.gz

  # Add a new layer to the image and store the result on disk in a designated directory
  # This will result in $(pwd)/mysql-local/v2/mysql/blobs,manifests
  oc image append --from mysql:latest --to file://mysql:local --dir mysql-local layer.tar.gz

  # Add a new layer to an image that is stored on disk (~/mysql-local/v2/image exists)
  oc image append --from-dir ~/mysql-local --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to an image that was mirrored to the current directory on disk ($(pwd)/v2/image exists)
  oc image append --from-dir v2 --to myregistry.com/myimage:latest layer.tar.gz

  # Add a new layer to a multi-architecture image for an os/arch that is different from the system's os/arch
  # Note: Wildcard filter is not supported with append. Pass a single os/arch to append
  oc image append --from docker.io/library/busybox:latest --filter-by-os=linux/s390x --to myregistry.com/myimage:latest layer.tar.gz

2.4.1.78. oc image extract

イメージからファイルシステムにファイルをコピーします。

使用例

  # Extract the busybox image into the current directory
  oc image extract docker.io/library/busybox:latest

  # Extract the busybox image into a designated directory (must exist)
  oc image extract docker.io/library/busybox:latest --path /:/tmp/busybox

  # Extract the busybox image into the current directory for linux/s390x platform
  # Note: Wildcard filter is not supported with extract. Pass a single os/arch to extract
  oc image extract docker.io/library/busybox:latest --filter-by-os=linux/s390x

  # Extract a single file from the image into the current directory
  oc image extract docker.io/library/centos:7 --path /bin/bash:.

  # Extract all .repo files from the image's /etc/yum.repos.d/ folder into the current directory
  oc image extract docker.io/library/centos:7 --path /etc/yum.repos.d/*.repo:.

  # Extract all .repo files from the image's /etc/yum.repos.d/ folder into a designated directory (must exist)
  # This results in /tmp/yum.repos.d/*.repo on local system
  oc image extract docker.io/library/centos:7 --path /etc/yum.repos.d/*.repo:/tmp/yum.repos.d

  # Extract an image stored on disk into the current directory ($(pwd)/v2/busybox/blobs,manifests exists)
  # --confirm is required because the current directory is not empty
  oc image extract file://busybox:local --confirm

  # Extract an image stored on disk in a directory other than $(pwd)/v2 into the current directory
  # --confirm is required because the current directory is not empty ($(pwd)/busybox-mirror-dir/v2/busybox exists)
  oc image extract file://busybox:local --dir busybox-mirror-dir --confirm

  # Extract an image stored on disk in a directory other than $(pwd)/v2 into a designated directory (must exist)
  oc image extract file://busybox:local --dir busybox-mirror-dir --path /:/tmp/busybox

  # Extract the last layer in the image
  oc image extract docker.io/library/centos:7[-1]

  # Extract the first three layers of the image
  oc image extract docker.io/library/centos:7[:3]

  # Extract the last three layers of the image
  oc image extract docker.io/library/centos:7[-3:]

2.4.1.79. oc image info

イメージに関する情報を表示します。

使用例

  # Show information about an image
  oc image info quay.io/openshift/cli:latest

  # Show information about images matching a wildcard
  oc image info quay.io/openshift/cli:4.*

  # Show information about a file mirrored to disk under DIR
  oc image info --dir=DIR file://library/busybox:latest

  # Select which image from a multi-OS image to show
  oc image info library/busybox:latest --filter-by-os=linux/arm64

2.4.1.80. oc image mirror

別のリポジトリーにイメージをミラーリングします。

使用例

  # Copy image to another tag
  oc image mirror myregistry.com/myimage:latest myregistry.com/myimage:stable

  # Copy image to another registry
  oc image mirror myregistry.com/myimage:latest docker.io/myrepository/myimage:stable

  # Copy all tags starting with mysql to the destination repository
  oc image mirror myregistry.com/myimage:mysql* docker.io/myrepository/myimage

  # Copy image to disk, creating a directory structure that can be served as a registry
  oc image mirror myregistry.com/myimage:latest file://myrepository/myimage:latest

  # Copy image to S3 (pull from <bucket>.s3.amazonaws.com/image:latest)
  oc image mirror myregistry.com/myimage:latest s3://s3.amazonaws.com/<region>/<bucket>/image:latest

  # Copy image to S3 without setting a tag (pull via @<digest>)
  oc image mirror myregistry.com/myimage:latest s3://s3.amazonaws.com/<region>/<bucket>/image

  # Copy image to multiple locations
  oc image mirror myregistry.com/myimage:latest docker.io/myrepository/myimage:stable \
  docker.io/myrepository/myimage:dev

  # Copy multiple images
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  myregistry.com/myimage:new=myregistry.com/other:target

  # Copy manifest list of a multi-architecture image, even if only a single image is found
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --keep-manifest-list=true

  # Copy specific os/arch manifest of a multi-architecture image
  # Run 'oc image info myregistry.com/myimage:latest' to see available os/arch for multi-arch images
  # Note that with multi-arch images, this results in a new manifest list digest that includes only
  # the filtered manifests
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --filter-by-os=os/arch

  # Copy all os/arch manifests of a multi-architecture image
  # Run 'oc image info myregistry.com/myimage:latest' to see list of os/arch manifests that will be mirrored
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --keep-manifest-list=true

  # Note the above command is equivalent to
  oc image mirror myregistry.com/myimage:latest=myregistry.com/other:test \
  --filter-by-os=.*

2.4.1.81. oc import-image

コンテナーイメージレジストリーからイメージをインポートします。

使用例

  # Import tag latest into a new image stream
  oc import-image mystream --from=registry.io/repo/image:latest --confirm

  # Update imported data for tag latest in an already existing image stream
  oc import-image mystream

  # Update imported data for tag stable in an already existing image stream
  oc import-image mystream:stable

  # Update imported data for all tags in an existing image stream
  oc import-image mystream --all

  # Import all tags into a new image stream
  oc import-image mystream --from=registry.io/repo/image --all --confirm

  # Import all tags into a new image stream using a custom timeout
  oc --request-timeout=5m import-image mystream --from=registry.io/repo/image --all --confirm

2.4.1.82. oc kustomize

ディレクトリーまたは URL から kustomization ターゲットをビルドします。

使用例

  # Build the current working directory
  oc kustomize

  # Build some shared configuration directory
  oc kustomize /home/config/production

  # Build from github
  oc kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6

2.4.1.83. oc label

リソースのラベルを更新します。

使用例

  # Update pod 'foo' with the label 'unhealthy' and the value 'true'.
  oc label pods foo unhealthy=true

  # Update pod 'foo' with the label 'status' and the value 'unhealthy', overwriting any existing value.
  oc label --overwrite pods foo status=unhealthy

  # Update all pods in the namespace
  oc label pods --all status=unhealthy

  # Update a pod identified by the type and name in "pod.json"
  oc label -f pod.json status=unhealthy

  # Update pod 'foo' only if the resource is unchanged from version 1.
  oc label pods foo status=unhealthy --resource-version=1

  # Update pod 'foo' by removing a label named 'bar' if it exists.
  # Does not require the --overwrite flag.
  oc label pods foo bar-

2.4.1.84. oc login

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

使用例

  # Log in interactively
  oc login --username=myuser

  # Log in to the given server with the given certificate authority file
  oc login localhost:8443 --certificate-authority=/path/to/cert.crt

  # Log in to the given server with the given credentials (will not prompt interactively)
  oc login localhost:8443 --username=myuser --password=mypass

2.4.1.85. oc logout

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

使用例

  # Log out
  oc logout

2.4.1.86. oc logs

Pod 内のコンテナーのログを出力します。

使用例

  # Start streaming the logs of the most recent build of the openldap build config
  oc logs -f bc/openldap

  # Start streaming the logs of the latest deployment of the mysql deployment config
  oc logs -f dc/mysql

  # Get the logs of the first deployment for the mysql deployment config. Note that logs
  # from older deployments may not exist either because the deployment was successful
  # or due to deployment pruning or manual deletion of the deployment
  oc logs --version=1 dc/mysql

  # Return a snapshot of ruby-container logs from pod backend
  oc logs backend -c ruby-container

  # Start streaming of ruby-container logs from pod backend
  oc logs -f pod/backend -c ruby-container

2.4.1.87. oc new-app

新規アプリケーションを作成します。

使用例

  # List all local templates and image streams that can be used to create an app
  oc new-app --list

  # Create an application based on the source code in the current git repository (with a public remote) and a Docker image
  oc new-app . --docker-image=registry/repo/langimage

  # Create an application myapp with Docker based build strategy expecting binary input
  oc new-app  --strategy=docker --binary --name myapp

  # Create a Ruby application based on the provided [image]~[source code] combination
  oc new-app centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git

  # Use the public Docker Hub MySQL image to create an app. Generated artifacts will be labeled with db=mysql
  oc new-app mysql MYSQL_USER=user MYSQL_PASSWORD=pass MYSQL_DATABASE=testdb -l db=mysql

  # Use a MySQL image in a private registry to create an app and override application artifacts' names
  oc new-app --docker-image=myregistry.com/mycompany/mysql --name=private

  # Create an application from a remote repository using its beta4 branch
  oc new-app https://github.com/openshift/ruby-hello-world#beta4

  # Create an application based on a stored template, explicitly setting a parameter value
  oc new-app --template=ruby-helloworld-sample --param=MYSQL_USER=admin

  # Create an application from a remote repository and specify a context directory
  oc new-app https://github.com/youruser/yourgitrepo --context-dir=src/build

  # Create an application from a remote private repository and specify which existing secret to use
  oc new-app https://github.com/youruser/yourgitrepo --source-secret=yoursecret

  # Create an application based on a template file, explicitly setting a parameter value
  oc new-app --file=./example/myapp/template.json --param=MYSQL_USER=admin

  # Search all templates, image streams, and Docker images for the ones that match "ruby"
  oc new-app --search ruby

  # Search for "ruby", but only in stored templates (--template, --image-stream and --docker-image
  # can be used to filter search results)
  oc new-app --search --template=ruby

  # Search for "ruby" in stored templates and print the output as YAML
  oc new-app --search --template=ruby --output=yaml

2.4.1.88. oc new-build

新規ビルド設定を作成します。

使用例

  # Create a build config based on the source code in the current git repository (with a public
  # remote) and a Docker image
  oc new-build . --docker-image=repo/langimage

  # Create a NodeJS build config based on the provided [image]~[source code] combination
  oc new-build centos/nodejs-8-centos7~https://github.com/sclorg/nodejs-ex.git

  # Create a build config from a remote repository using its beta2 branch
  oc new-build https://github.com/openshift/ruby-hello-world#beta2

  # Create a build config using a Dockerfile specified as an argument
  oc new-build -D $'FROM centos:7\nRUN yum install -y httpd'

  # Create a build config from a remote repository and add custom environment variables
  oc new-build https://github.com/openshift/ruby-hello-world -e RACK_ENV=development

  # Create a build config from a remote private repository and specify which existing secret to use
  oc new-build https://github.com/youruser/yourgitrepo --source-secret=yoursecret

  # Create a build config from a remote repository and inject the npmrc into a build
  oc new-build https://github.com/openshift/ruby-hello-world --build-secret npmrc:.npmrc

  # Create a build config from a remote repository and inject environment data into a build
  oc new-build https://github.com/openshift/ruby-hello-world --build-config-map env:config

  # Create a build config that gets its input from a remote repository and another Docker image
  oc new-build https://github.com/openshift/ruby-hello-world --source-image=openshift/jenkins-1-centos7 --source-image-path=/var/lib/jenkins:tmp

2.4.1.89. oc new-project

新規プロジェクトを要求します。

使用例

  # Create a new project with minimal information
  oc new-project web-team-dev

  # Create a new project with a display name and description
  oc new-project web-team-dev --display-name="Web Team Development" --description="Development project for the web team."

2.4.1.90. oc observe

リソースの変更を確認し、リソースに対応します (実験的)。

使用例

  # Observe changes to services
  oc observe services

  # Observe changes to services, including the clusterIP and invoke a script for each
  oc observe services --template '{ .spec.clusterIP }' -- register_dns.sh

  # Observe changes to services filtered by a label selector
  oc observe namespaces -l regist-dns=true --template '{ .spec.clusterIP }' -- register_dns.sh

2.4.1.91. oc patch

リソースのフィールドを更新します。

使用例

  # Partially update a node using a strategic merge patch. Specify the patch as JSON.
  oc patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

  # Partially update a node using a strategic merge patch. Specify the patch as YAML.
  oc patch node k8s-node-1 -p $'spec:\n unschedulable: true'

  # Partially update a node identified by the type and name specified in "node.json" using strategic merge patch.
  oc patch -f node.json -p '{"spec":{"unschedulable":true}}'

  # Update a container's image; spec.containers[*].name is required because it's a merge key.
  oc patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

  # Update a container's image using a json patch with positional arrays.
  oc patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

2.4.1.92. oc policy add-role-to-user

現在のプロジェクトのユーザーまたはサービスアカウントをロールに追加します。

使用例

  # Add the 'view' role to user1 for the current project
  oc policy add-role-to-user view user1

  # Add the 'edit' role to serviceaccount1 for the current project
  oc policy add-role-to-user edit -z serviceaccount1

2.4.1.93. oc policy scc-review

Pod を作成できるサービスアカウントを確認します。

使用例

  # Check whether service accounts sa1 and sa2 can admit a pod with a template pod spec specified in my_resource.yaml
  # Service Account specified in myresource.yaml file is ignored
  oc policy scc-review -z sa1,sa2 -f my_resource.yaml

  # Check whether service accounts system:serviceaccount:bob:default can admit a pod with a template pod spec specified in my_resource.yaml
  oc policy scc-review -z system:serviceaccount:bob:default -f my_resource.yaml

  # Check whether the service account specified in my_resource_with_sa.yaml can admit the pod
  oc policy scc-review -f my_resource_with_sa.yaml

  # Check whether the default service account can admit the pod; default is taken since no service account is defined in myresource_with_no_sa.yaml
  oc policy scc-review -f myresource_with_no_sa.yaml

2.4.1.94. oc policy scc-subject-review

ユーザーまたはサービスアカウントが Pod を作成できるかどうかを確認します。

使用例

  # Check whether user bob can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -f myresource.yaml

  # Check whether user bob who belongs to projectAdmin group can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -g projectAdmin -f myresource.yaml

  # Check whether a service account specified in the pod template spec in myresourcewithsa.yaml can create the pod
  oc policy scc-subject-review -f myresourcewithsa.yaml

2.4.1.95. oc port-forward

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

使用例

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
  oc port-forward pod/mypod 5000 6000

  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the deployment
  oc port-forward deployment/mydeployment 5000 6000

  # Listen on port 8443 locally, forwarding to the targetPort of the service's port named "https" in a pod selected by the service
  oc port-forward service/myservice 8443:https

  # Listen on port 8888 locally, forwarding to 5000 in the pod
  oc port-forward pod/mypod 8888:5000

  # Listen on port 8888 on all addresses, forwarding to 5000 in the pod
  oc port-forward --address 0.0.0.0 pod/mypod 8888:5000

  # Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
  oc port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000

  # Listen on a random port locally, forwarding to 5000 in the pod
  oc port-forward pod/mypod :5000

2.4.1.96. oc process

リソースの一覧に対してテンプレートを処理します。

使用例

  # Convert the template.json file into a resource list and pass to create
  oc process -f template.json | oc create -f -

  # Process a file locally instead of contacting the server
  oc process -f template.json --local -o yaml

  # Process template while passing a user-defined label
  oc process -f template.json -l name=mytemplate

  # Convert a stored template into a resource list
  oc process foo

  # Convert a stored template into a resource list by setting/overriding parameter values
  oc process foo PARM1=VALUE1 PARM2=VALUE2

  # Convert a template stored in different namespace into a resource list
  oc process openshift//foo

  # Convert template.json into a resource list
  cat template.json | oc process -f -

2.4.1.97. oc project

別のプロジェクトに切り替えます。

使用例

  # Switch to the 'myapp' project
  oc project myapp

  # Display the project currently in use
  oc project

2.4.1.98. oc projects

既存プロジェクトを表示します。

使用例

  # List all projects
  oc projects

2.4.1.99. oc proxy

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

使用例

  # To proxy all of the kubernetes api and nothing else.
  oc proxy --api-prefix=/

  # To proxy only part of the kubernetes api and also some static files.
  # You can get pods info with 'curl localhost:8001/api/v1/pods'
  oc proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

  # To proxy the entire kubernetes api at a different root.
  # You can get pods info with 'curl localhost:8001/custom/api/v1/pods'
  oc proxy --api-prefix=/custom/

  # Run a proxy to kubernetes apiserver on port 8011, serving static content from ./local/www/
  oc proxy --port=8011 --www=./local/www/

  # Run a proxy to kubernetes apiserver on an arbitrary local port.
  # The chosen port for the server will be output to stdout.
  oc proxy --port=0

  # Run a proxy to kubernetes apiserver, changing the api prefix to k8s-api
  # This makes e.g. the pods api available at localhost:8001/k8s-api/v1/pods/
  oc proxy --api-prefix=/k8s-api

2.4.1.100. oc registry info

統合レジストリーについての情報を表示します。

使用例

  # Display information about the integrated registry
  oc registry info

2.4.1.101. oc registry login

統合レジストリーにログインします。

使用例

  # Log in to the integrated registry
  oc registry login

  # Log in as the default service account in the current namespace
  oc registry login -z default

  # Log in to different registry using BASIC auth credentials
  oc registry login --registry quay.io/myregistry --auth-basic=USER:PASS

2.4.1.102. oc replace

リソースをファイル名または stdin に置き換えます。

使用例

  # Replace a pod using the data in pod.json.
  oc replace -f ./pod.json

  # Replace a pod based on the JSON passed into stdin.
  cat pod.json | oc replace -f -

  # Update a single-container pod's image version (tag) to v4
  oc get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | oc replace -f -

  # Force replace, delete and then re-create the resource
  oc replace --force -f ./pod.json

2.4.1.103. oc rollback

アプリケーションの一部を以前のデプロイメントに戻します。

使用例

  # Perform a rollback to the last successfully completed deployment for a deployment config
  oc rollback frontend

  # See what a rollback to version 3 will look like, but do not perform the rollback
  oc rollback frontend --to-version=3 --dry-run

  # Perform a rollback to a specific deployment
  oc rollback frontend-2

  # Perform the rollback manually by piping the JSON of the new config back to oc
  oc rollback frontend -o json | oc replace dc/frontend -f -

  # Print the updated deployment configuration in JSON format instead of performing the rollback
  oc rollback frontend -o json

2.4.1.104. oc rollout cancel

進行中のデプロイメントをキャンセルします。

使用例

  # Cancel the in-progress deployment based on 'nginx'
  oc rollout cancel dc/nginx

2.4.1.105. oc rollout history

ロールアウト履歴を表示します。

使用例

  # View the rollout history of a deployment
  oc rollout history dc/nginx

  # View the details of deployment revision 3
  oc rollout history dc/nginx --revision=3

2.4.1.106. oc rollout latest

トリガーからの最新状態を使用して、デプロイメント設定の新規ロールアウトを開始します。

使用例

  # Start a new rollout based on the latest images defined in the image change triggers
  oc rollout latest dc/nginx

  # Print the rolled out deployment config
  oc rollout latest dc/nginx -o json

2.4.1.107. oc rollout pause

提供されたリソースを一時停止としてマークします。

使用例

  # Mark the nginx deployment as paused. Any current state of
  # the deployment will continue its function, new updates to the deployment will not
  # have an effect as long as the deployment is paused
  oc rollout pause dc/nginx

2.4.1.108. oc rollout restart

リソースを再起動します。

使用例

  # Restart a deployment
  oc rollout restart deployment/nginx

  # Restart a daemonset
  oc rollout restart daemonset/abc

2.4.1.109. oc rollout resume

一時停止したリソースを再開します。

使用例

  # Resume an already paused deployment
  oc rollout resume dc/nginx

2.4.1.110. oc rollout retry

失敗したロールアウトを再試行します。

使用例

  # Retry the latest failed deployment based on 'frontend'
  # The deployer pod and any hook pods are deleted for the latest failed deployment
  oc rollout retry dc/frontend

2.4.1.111. oc rollout status

ロールアウトのステータスを表示します。

使用例

  # Watch the status of the latest rollout
  oc rollout status dc/nginx

2.4.1.112. oc rollout undo

以前のロールアウトを元に戻します。

使用例

  # Roll back to the previous deployment
  oc rollout undo dc/nginx

  # Roll back to deployment revision 3. The replication controller for that version must exist
  oc rollout undo dc/nginx --to-revision=3

2.4.1.113. oc rsh

コンテナーでシェルセッションを開始します。

使用例

  # Open a shell session on the first container in pod 'foo'
  oc rsh foo

  # Open a shell session on the first container in pod 'foo' and namespace 'bar'
  # (Note that oc client specific arguments must come before the resource name and its arguments)
  oc rsh -n bar foo

  # Run the command 'cat /etc/resolv.conf' inside pod 'foo'
  oc rsh foo cat /etc/resolv.conf

  # See the configuration of your internal registry
  oc rsh dc/docker-registry cat config.yml

  # Open a shell session on the container named 'index' inside a pod of your job
  oc rsh -c index job/sheduled

2.4.1.114. oc rsync

ローカルファイルシステムと Pod 間でファイルをコピーします。

使用例

  # Synchronize a local directory with a pod directory
  oc rsync ./local/dir/ POD:/remote/dir

  # Synchronize a pod directory with a local directory
  oc rsync POD:/remote/dir/ ./local/dir

2.4.1.115. oc run

クラスターで特定のイメージを実行します。

使用例

  # Start a nginx pod.
  oc run nginx --image=nginx

  # Start a hazelcast pod and let the container expose port 5701.
  oc run hazelcast --image=hazelcast/hazelcast --port=5701

  # Start a hazelcast pod and set environment variables "DNS_DOMAIN=cluster" and "POD_NAMESPACE=default" in the container.
  oc run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"

  # Start a hazelcast pod and set labels "app=hazelcast" and "env=prod" in the container.
  oc run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"

  # Dry run. Print the corresponding API objects without creating them.
  oc run nginx --image=nginx --dry-run=client

  # Start a nginx pod, but overload the spec with a partial set of values parsed from JSON.
  oc run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'

  # Start a busybox pod and keep it in the foreground, don't restart it if it exits.
  oc run -i -t busybox --image=busybox --restart=Never

  # Start the nginx pod using the default command, but use custom arguments (arg1 .. argN) for that command.
  oc run nginx --image=nginx -- <arg1> <arg2> ... <argN>

  # Start the nginx pod using a different command and custom arguments.
  oc run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

2.4.1.116. oc scale

Deployment、ReplicaSet、または Replication コントローラーに新規サイズを設定します。

使用例

  # Scale a replicaset named 'foo' to 3.
  oc scale --replicas=3 rs/foo

  # Scale a resource identified by type and name specified in "foo.yaml" to 3.
  oc scale --replicas=3 -f foo.yaml

  # If the deployment named mysql's current size is 2, scale mysql to 3.
  oc scale --current-replicas=2 --replicas=3 deployment/mysql

  # Scale multiple replication controllers.
  oc scale --replicas=5 rc/foo rc/bar rc/baz

  # Scale statefulset named 'web' to 3.
  oc scale --replicas=3 statefulset/web

2.4.1.119. oc serviceaccounts create-kubeconfig

サービスアカウントの kubeconfig ファイルを生成します。

使用例

  # Create a kubeconfig file for service account 'default'
  oc serviceaccounts create-kubeconfig 'default' > default.kubeconfig

2.4.1.120. oc serviceaccounts get-token

サービスアカウントに割り当てられたトークンを取得します。

使用例

  # Get the service account token from service account 'default'
  oc serviceaccounts get-token 'default'

2.4.1.121. oc serviceaccounts new-token

サービスアカウントの新規トークンを生成します。

使用例

  # Generate a new token for service account 'default'
  oc serviceaccounts new-token 'default'

  # Generate a new token for service account 'default' and apply
  # labels 'foo' and 'bar' to the new token for identification
  oc serviceaccounts new-token 'default' --labels foo=foo-value,bar=bar-value

2.4.1.122. oc set build-hook

ビルド設定のビルドフックを更新します。

使用例

  # Clear post-commit hook on a build config
  oc set build-hook bc/mybuild --post-commit --remove

  # Set the post-commit hook to execute a test suite using a new entrypoint
  oc set build-hook bc/mybuild --post-commit --command -- /bin/bash -c /var/lib/test-image.sh

  # Set the post-commit hook to execute a shell script
  oc set build-hook bc/mybuild --post-commit --script="/var/lib/test-image.sh param1 param2 && /var/lib/done.sh"

2.4.1.123. oc set build-secret

ビルド設定のビルドシークレットを更新します。

使用例

  # Clear the push secret on a build config
  oc set build-secret --push --remove bc/mybuild

  # Set the pull secret on a build config
  oc set build-secret --pull bc/mybuild mysecret

  # Set the push and pull secret on a build config
  oc set build-secret --push --pull bc/mybuild mysecret

  # Set the source secret on a set of build configs matching a selector
  oc set build-secret --source -l app=myapp gitsecret

2.4.1.124. oc set data

設定マップまたはシークレット内のデータを更新します。

使用例

  # Set the 'password' key of a secret
  oc set data secret/foo password=this_is_secret

  # Remove the 'password' key from a secret
  oc set data secret/foo password-

  # Update the 'haproxy.conf' key of a config map from a file on disk
  oc set data configmap/bar --from-file=../haproxy.conf

  # Update a secret with the contents of a directory, one key per file
  oc set data secret/foo --from-file=secret-dir

2.4.1.125. oc set deployment-hook

デプロイメント設定のデプロイメントフックを更新します。

使用例

  # Clear pre and post hooks on a deployment config
  oc set deployment-hook dc/myapp --remove --pre --post

  # Set the pre deployment hook to execute a db migration command for an application
  # using the data volume from the application
  oc set deployment-hook dc/myapp --pre --volumes=data -- /var/lib/migrate-db.sh

  # Set a mid deployment hook along with additional environment variables
  oc set deployment-hook dc/myapp --mid --volumes=data -e VAR1=value1 -e VAR2=value2 -- /var/lib/prepare-deploy.sh

2.4.1.126. oc set env

Pod テンプレートの環境変数を更新します。

使用例

  # Update deployment config 'myapp' with a new environment variable
  oc set env dc/myapp STORAGE_DIR=/local

  # List the environment variables defined on a build config 'sample-build'
  oc set env bc/sample-build --list

  # List the environment variables defined on all pods
  oc set env pods --all --list

  # Output modified build config in YAML
  oc set env bc/sample-build STORAGE_DIR=/data -o yaml

  # Update all containers in all replication controllers in the project to have ENV=prod
  oc set env rc --all ENV=prod

  # Import environment from a secret
  oc set env --from=secret/mysecret dc/myapp

  # Import environment from a config map with a prefix
  oc set env --from=configmap/myconfigmap --prefix=MYSQL_ dc/myapp

  # Remove the environment variable ENV from container 'c1' in all deployment configs
  oc set env dc --all --containers="c1" ENV-

  # Remove the environment variable ENV from a deployment config definition on disk and
  # update the deployment config on the server
  oc set env -f dc.json ENV-

  # Set some of the local shell environment into a deployment config on the server
  oc set env | grep RAILS_ | oc env -e - dc/myapp

2.4.1.127. oc set image

Pod テンプレートのイメージを更新します。

使用例

  # Set a deployment configs's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'.
  oc set image dc/nginx busybox=busybox nginx=nginx:1.9.1

  # Set a deployment configs's app container image to the image referenced by the imagestream tag 'openshift/ruby:2.3'.
  oc set image dc/myapp app=openshift/ruby:2.3 --source=imagestreamtag

  # Update all deployments' and rc's nginx container's image to 'nginx:1.9.1'
  oc set image deployments,rc nginx=nginx:1.9.1 --all

  # Update image of all containers of daemonset abc to 'nginx:1.9.1'
  oc set image daemonset abc *=nginx:1.9.1

  # Print result (in yaml format) of updating nginx container image from local file, without hitting the server
  oc set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

2.4.1.128. oc set image-lookup

アプリケーションのデプロイ時にイメージを解決する方法を変更します。

使用例

  # Print all of the image streams and whether they resolve local names
  oc set image-lookup

  # Use local name lookup on image stream mysql
  oc set image-lookup mysql

  # Force a deployment to use local name lookup
  oc set image-lookup deploy/mysql

  # Show the current status of the deployment lookup
  oc set image-lookup deploy/mysql --list

  # Disable local name lookup on image stream mysql
  oc set image-lookup mysql --enabled=false

  # Set local name lookup on all image streams
  oc set image-lookup --all

2.4.1.129. oc set probe

Pod テンプレートでプローブを更新します。

使用例

  # Clear both readiness and liveness probes off all containers
  oc set probe dc/myapp --remove --readiness --liveness

  # Set an exec action as a liveness probe to run 'echo ok'
  oc set probe dc/myapp --liveness -- echo ok

  # Set a readiness probe to try to open a TCP socket on 3306
  oc set probe rc/mysql --readiness --open-tcp=3306

  # Set an HTTP startup probe for port 8080 and path /healthz over HTTP on the pod IP
  oc probe dc/webapp --startup --get-url=http://:8080/healthz

  # Set an HTTP readiness probe for port 8080 and path /healthz over HTTP on the pod IP
  oc probe dc/webapp --readiness --get-url=http://:8080/healthz

  # Set an HTTP readiness probe over HTTPS on 127.0.0.1 for a hostNetwork pod
  oc set probe dc/router --readiness --get-url=https://127.0.0.1:1936/stats

  # Set only the initial-delay-seconds field on all deployments
  oc set probe dc --all --readiness --initial-delay-seconds=30

2.4.1.130. oc set resources

オブジェクトのリソース要求/制限を Pod テンプレートで更新します。

使用例

  # Set a deployments nginx container CPU limits to "200m and memory to 512Mi"
  oc set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

  # Set the resource request and limits for all containers in nginx
  oc set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

  # Remove the resource requests for resources on containers in nginx
  oc set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

  # Print the result (in YAML format) of updating nginx container limits locally, without hitting the server
  oc set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

2.4.1.131. oc set route-backends

ルートのバックエンドを更新します。

使用例

  # Print the backends on the route 'web'
  oc set route-backends web

  # Set two backend services on route 'web' with 2/3rds of traffic going to 'a'
  oc set route-backends web a=2 b=1

  # Increase the traffic percentage going to b by 10%% relative to a
  oc set route-backends web --adjust b=+10%%

  # Set traffic percentage going to b to 10%% of the traffic going to a
  oc set route-backends web --adjust b=10%%

  # Set weight of b to 10
  oc set route-backends web --adjust b=10

  # Set the weight to all backends to zero
  oc set route-backends web --zero

2.4.1.132. oc set selector

リソースにセレクターを設定します。

使用例

  # Set the labels and selector before creating a deployment/service pair.
  oc create service clusterip my-svc --clusterip="None" -o yaml --dry-run | oc set selector --local -f - 'environment=qa' -o yaml | oc create -f -
  oc create deployment my-dep -o yaml --dry-run | oc label --local -f - environment=qa -o yaml | oc create -f -

2.4.1.133. oc set serviceaccount

リソースの ServiceAccount を更新します。

使用例

  # Set deployment nginx-deployment's service account to serviceaccount1
  oc set serviceaccount deployment nginx-deployment serviceaccount1

  # Print the result (in YAML format) of updated nginx deployment with service account from a local file, without hitting the API server
  oc set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run -o yaml

2.4.1.134. oc set subject

RoleBinding/ClusterRoleBinding でユーザー、グループ、または ServiceAccount を更新します。

使用例

  # Update a cluster role binding for serviceaccount1
  oc set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

  # Update a role binding for user1, user2, and group1
  oc set subject rolebinding admin --user=user1 --user=user2 --group=group1

  # Print the result (in YAML format) of updating role binding subjects locally, without hitting the server
  oc create rolebinding admin --role=admin --user=admin -o yaml --dry-run | oc set subject --local -f - --user=foo -o yaml

2.4.1.135. oc set triggers

1 つ以上のオブジェクトでトリガーを更新します。

使用例

  # Print the triggers on the deployment config 'myapp'
  oc set triggers dc/myapp

  # Set all triggers to manual
  oc set triggers dc/myapp --manual

  # Enable all automatic triggers
  oc set triggers dc/myapp --auto

  # Reset the GitHub webhook on a build to a new, generated secret
  oc set triggers bc/webapp --from-github
  oc set triggers bc/webapp --from-webhook

  # Remove all triggers
  oc set triggers bc/webapp --remove-all

  # Stop triggering on config change
  oc set triggers dc/myapp --from-config --remove

  # Add an image trigger to a build config
  oc set triggers bc/webapp --from-image=namespace1/image:latest

  # Add an image trigger to a stateful set on the main container
  oc set triggers statefulset/db --from-image=namespace1/image:latest -c main

2.4.1.136. oc set volumes

Pod テンプレートでボリュームを更新します。

使用例

  # List volumes defined on all deployment configs in the current project
  oc set volume dc --all

  # Add a new empty dir volume to deployment config (dc) 'myapp' mounted under
  # /var/lib/myapp
  oc set volume dc/myapp --add --mount-path=/var/lib/myapp

  # Use an existing persistent volume claim (pvc) to overwrite an existing volume 'v1'
  oc set volume dc/myapp --add --name=v1 -t pvc --claim-name=pvc1 --overwrite

  # Remove volume 'v1' from deployment config 'myapp'
  oc set volume dc/myapp --remove --name=v1

  # Create a new persistent volume claim that overwrites an existing volume 'v1'
  oc set volume dc/myapp --add --name=v1 -t pvc --claim-size=1G --overwrite

  # Change the mount point for volume 'v1' to /data
  oc set volume dc/myapp --add --name=v1 -m /data --overwrite

  # Modify the deployment config by removing volume mount "v1" from container "c1"
  # (and by removing the volume "v1" if no other containers have volume mounts that reference it)
  oc set volume dc/myapp --remove --name=v1 --containers=c1

  # Add new volume based on a more complex volume source (AWS EBS, GCE PD,
  # Ceph, Gluster, NFS, ISCSI, ...)
  oc set volume dc/myapp --add -m /data --source=<json-string>

2.4.1.137. oc start-build

新しいビルドを開始します。

使用例

  # Starts build from build config "hello-world"
  oc start-build hello-world

  # Starts build from a previous build "hello-world-1"
  oc start-build --from-build=hello-world-1

  # Use the contents of a directory as build input
  oc start-build hello-world --from-dir=src/

  # Send the contents of a Git repository to the server from tag 'v2'
  oc start-build hello-world --from-repo=../hello-world --commit=v2

  # Start a new build for build config "hello-world" and watch the logs until the build
  # completes or fails
  oc start-build hello-world --follow

  # Start a new build for build config "hello-world" and wait until the build completes. It
  # exits with a non-zero return code if the build fails
  oc start-build hello-world --wait

2.4.1.138. oc status

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

使用例

  # See an overview of the current project
  oc status

  # Export the overview of the current project in an svg file
  oc status -o dot | dot -T svg -o project.svg

  # See an overview of the current project including details for any identified issues
  oc status --suggest

2.4.1.139. oc tag

既存のイメージをイメージストリームにタグ付けします。

使用例

  # Tag the current image for the image stream 'openshift/ruby' and tag '2.0' into the image stream 'yourproject/ruby with tag 'tip'
  oc tag openshift/ruby:2.0 yourproject/ruby:tip

  # Tag a specific image
  oc tag openshift/ruby@sha256:6b646fa6bf5e5e4c7fa41056c27910e679c03ebe7f93e361e6515a9da7e258cc yourproject/ruby:tip

  # Tag an external container image
  oc tag --source=docker openshift/origin-control-plane:latest yourproject/ruby:tip

  # Tag an external container image and request pullthrough for it
  oc tag --source=docker openshift/origin-control-plane:latest yourproject/ruby:tip --reference-policy=local

  # Remove the specified spec tag from an image stream
  oc tag openshift/origin-control-plane:latest -d

2.4.1.140. oc version

クライアントおよびサーバーのバージョン情報を出力します。

使用例

  # Print the OpenShift client, kube-apiserver, and openshift-apiserver version information for the current context
  oc version

  # Print the OpenShift client, kube-apiserver, and openshift-apiserver version numbers for the current context
  oc version --short

  # Print the OpenShift client version information for the current context
  oc version --client

2.4.1.141. oc wait

実験的: 1 つ以上のリソースの特定の条件を待機します。

使用例

  # Wait for the pod "busybox1" to contain the status condition of type "Ready".
  oc wait --for=condition=Ready pod/busybox1

  # The default value of status condition is true, you can set false.
  oc wait --for=condition=Ready=false pod/busybox1

  # Wait for the pod "busybox1" to be deleted, with a timeout of 60s, after having issued the "delete" command.
  oc delete pod/busybox1
  oc wait --for=delete pod/busybox1 --timeout=60s

2.4.1.142. oc whoami

現行セッションに関する情報を返します。

使用例

  # Display the currently authenticated user
  oc whoami

2.4.2. 追加リソース

2.5. OpenShift CLI 管理者コマンドリファレンス

このリファレンスは、OpenShift CLI (oc) 管理者コマンドの説明およびコマンド例を示しています。これらのコマンドを使用するには、cluster-adminまたは同等のパーミッションが必要です。

開発者コマンドは、「OpenShift CLI 開発者コマンドリファレンス」を参照してください。

oc adm help を実行して、すべての管理者コマンドを表示するか、または oc <command> --help を実行して、特定のコマンドに関する追加情報を取得します。

2.5.1. OpenShift CLI (oc) 管理者コマンド

2.5.1.1. oc adm build-chain

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

使用例

  # Build the dependency tree for the 'latest' tag in <image-stream>
  oc adm build-chain <image-stream>

  # Build the dependency tree for the 'v2' tag in dot format and visualize it via the dot utility
  oc adm build-chain <image-stream>:v2 -o dot | dot -T svg -o deps.svg

  # Build the dependency tree across all namespaces for the specified image stream tag found in the 'test' namespace
  oc adm build-chain <image-stream> -n test --all

2.5.1.2. oc adm catalog mirror

operator-registry カタログをミラーリングします。

使用例

  # Mirror an operator-registry image and its contents to a registry
  oc adm catalog mirror quay.io/my/image:latest myregistry.com

  # Mirror an operator-registry image and its contents to a particular namespace in a registry
  oc adm catalog mirror quay.io/my/image:latest myregistry.com/my-namespace

  # Mirror to an airgapped registry by first mirroring to files
  oc adm catalog mirror quay.io/my/image:latest file:///local/index
  oc adm catalog mirror file:///local/index/my/image:latest my-airgapped-registry.com

  # Configure a cluster to use a mirrored registry
  oc apply -f manifests/imageContentSourcePolicy.yaml

  # Edit the mirroring mappings and mirror with "oc image mirror" manually
  oc adm catalog mirror --manifests-only quay.io/my/image:latest myregistry.com
  oc image mirror -f manifests/mapping.txt

  # Delete all ImageContentSourcePolicies generated by oc adm catalog mirror
  oc delete imagecontentsourcepolicy -l operators.openshift.org/catalog=true

2.5.1.3. oc adm completion

指定されたシェル (bash または zsh) の補完コードを出力します。

使用例

  # Installing bash completion on macOS using homebrew
  ## If running Bash 3.2 included with macOS
  brew install bash-completion
  ## or, if running Bash 4.1+
  brew install bash-completion@2
  ## If oc is installed via homebrew, this should start working immediately.
  ## If you've installed via other means, you may need add the completion to your completion directory
  oc completion bash > $(brew --prefix)/etc/bash_completion.d/oc


  # Installing bash completion on Linux
  ## If bash-completion is not installed on Linux, please install the 'bash-completion' package
  ## via your distribution's package manager.
  ## Load the oc completion code for bash into the current shell
  source <(oc completion bash)
  ## Write bash completion code to a file and source it from .bash_profile
  oc completion bash > ~/.kube/completion.bash.inc
  printf "
  # Kubectl shell completion
  source '$HOME/.kube/completion.bash.inc'
  " >> $HOME/.bash_profile
  source $HOME/.bash_profile

  # Load the oc completion code for zsh[1] into the current shell
  source <(oc completion zsh)
  # Set the oc completion code for zsh[1] to autoload on startup
  oc completion zsh > "${fpath[1]}/_oc"

2.5.1.4. oc adm config current-context

current-context を表示します

使用例

  # Display the current-context
  oc config current-context

2.5.1.5. oc adm config delete-cluster

kubeconfig から指定されたクラスターを削除します。

使用例

  # Delete the minikube cluster
  oc config delete-cluster minikube

2.5.1.6. oc adm config delete-context

kubeconfig から指定されたコンテキストを削除します。

使用例

  # Delete the context for the minikube cluster
  oc config delete-context minikube

2.5.1.7. oc adm config delete-user

kubeconfig から指定されたユーザーを削除します。

使用例

  # Delete the minikube user
  oc config delete-user minikube

2.5.1.8. oc adm config get-clusters

kubeconfig に定義されるクラスターを表示します。

使用例

  # List the clusters oc knows about
  oc config get-clusters

2.5.1.9. oc adm config get-contexts

コンテキストを 1 つまたは複数記述します。

使用例

  # List all the contexts in your kubeconfig file
  oc config get-contexts

  # Describe one context in your kubeconfig file.
  oc config get-contexts my-context

2.5.1.10. oc adm config get-users

kubeconfig で定義されるユーザーを表示します。

使用例

  # List the users oc knows about
  oc config get-users

2.5.1.11. oc adm config rename-context

kubeconfig ファイルからのコンテキストの名前を変更します。

使用例

  # Rename the context 'old-name' to 'new-name' in your kubeconfig file
  oc config rename-context old-name new-name

2.5.1.12. oc adm config set

kubeconfig ファイルに個別の値を設定します。

使用例

  # Set server field on the my-cluster cluster to https://1.2.3.4
  oc config set clusters.my-cluster.server https://1.2.3.4

  # Set certificate-authority-data field on the my-cluster cluster.
  oc config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

  # Set cluster field in the my-context context to my-cluster.
  oc config set contexts.my-context.cluster my-cluster

  # Set client-key-data field in the cluster-admin user using --set-raw-bytes option.
  oc config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

2.5.1.13. oc adm config set-cluster

kubeconfig でクラスターエントリーを設定します。

使用例

  # Set only the server field on the e2e cluster entry without touching other values.
  oc config set-cluster e2e --server=https://1.2.3.4

  # Embed certificate authority data for the e2e cluster entry
  oc config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

  # Disable cert checking for the dev cluster entry
  oc config set-cluster e2e --insecure-skip-tls-verify=true

  # Set custom TLS server name to use for validation for the e2e cluster entry
  oc config set-cluster e2e --tls-server-name=my-cluster-name

2.5.1.14. oc adm config set-context

kubeconfig のコンテキストエントリーを設定します。

使用例

  # Set the user field on the gce context entry without touching other values
  oc config set-context gce --user=cluster-admin

2.5.1.15. oc adm config set-credentials

kubeconfig のユーザーエントリーを設定します。

使用例

  # Set only the "client-key" field on the "cluster-admin"
  # entry, without touching other values:
  oc config set-credentials cluster-admin --client-key=~/.kube/admin.key

  # Set basic auth for the "cluster-admin" entry
  oc config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

  # Embed client certificate data in the "cluster-admin" entry
  oc config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

  # Enable the Google Compute Platform auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=gcp

  # Enable the OpenID Connect auth provider for the "cluster-admin" entry with additional args
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

  # Remove the "client-secret" config value for the OpenID Connect auth provider for the "cluster-admin" entry
  oc config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

  # Enable new exec auth plugin for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

  # Define new exec auth plugin args for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

  # Create or update exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

  # Remove exec auth plugin environment variables for the "cluster-admin" entry
  oc config set-credentials cluster-admin --exec-env=var-to-remove-

2.5.1.16. oc adm config unset

kubeconfig ファイルでの個別値の設定を解除します。

使用例

  # Unset the current-context.
  oc config unset current-context

  # Unset namespace in foo context.
  oc config unset contexts.foo.namespace

2.5.1.17. oc adm config use-context

kubeconfig ファイルで current-context を設定します。

使用例

  # Use the context for the minikube cluster
  oc config use-context minikube

2.5.1.18. oc adm config view

マージされた kubeconfig 設定または指定された kubeconfig ファイルを表示します。

使用例

  # Show merged kubeconfig settings.
  oc config view

  # Show merged kubeconfig settings and raw certificate data.
  oc config view --raw

  # Get the password for the e2e user
  oc config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

2.5.1.19. oc adm cordon

ノードにスケジュール対象外 (unschedulable) のマークを付けます。

使用例

  # Mark node "foo" as unschedulable.
  oc adm cordon foo

2.5.1.20. oc adm create-bootstrap-project-template

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

使用例

  # Output a bootstrap project template in YAML format to stdout
  oc adm create-bootstrap-project-template -o yaml

2.5.1.21. oc adm create-error-template

エラーページのテンプレートを作成します。

使用例

  # Output a template for the error page to stdout
  oc adm create-error-template

2.5.1.22. oc adm create-login-template

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

使用例

  # Output a template for the login page to stdout
  oc adm create-login-template

2.5.1.23. oc adm create-provider-selection-template

プロバイダー選択のテンプレートを作成します。

使用例

  # Output a template for the provider selection page to stdout
  oc adm create-provider-selection-template

2.5.1.24. oc adm drain

ノードをドレイン (解放) してメンテナンスを準備します。

使用例

  # Drain node "foo", even if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet on it.
  $ oc adm drain foo --force

  # As above, but abort if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet, and use a grace period of 15 minutes.
  $ oc adm drain foo --grace-period=900

2.5.1.25. oc adm groups add-users

ユーザーをグループに追加します。

使用例

  # Add user1 and user2 to my-group
  oc adm groups add-users my-group user1 user2

2.5.1.26. oc adm groups new

新規グループを作成します。

使用例

  # Add a group with no users
  oc adm groups new my-group

  # Add a group with two users
  oc adm groups new my-group user1 user2

  # Add a group with one user and shorter output
  oc adm groups new my-group user1 -o name

2.5.1.27. oc adm groups prune

外部プロバイダーから欠落しているレコードを参照する以前の OpenShift グループを削除します。

使用例

  # Prune all orphaned groups
  oc adm groups prune --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups except the ones from the blacklist file
  oc adm groups prune --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist file
  oc adm groups prune --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist
  oc adm groups prune groups/group_name groups/other_name --sync-config=/path/to/ldap-sync-config.yaml --confirm

2.5.1.28. oc adm groups remove-users

グループからユーザーを削除します。

使用例

  # Remove user1 and user2 from my-group
  oc adm groups remove-users my-group user1 user2

2.5.1.29. oc adm groups sync

OpenShift グループと外部プロバイダーからのレコードを同期します。

使用例

  # Sync all groups with an LDAP server
  oc adm groups sync --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync all groups except the ones from the blacklist file with an LDAP server
  oc adm groups sync --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync specific groups specified in a whitelist file with an LDAP server
  oc adm groups sync --whitelist=/path/to/whitelist.txt --sync-config=/path/to/sync-config.yaml --confirm

  # Sync all OpenShift groups that have been synced previously with an LDAP server
  oc adm groups sync --type=openshift --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Sync specific OpenShift groups if they have been synced previously with an LDAP server
  oc adm groups sync groups/group1 groups/group2 groups/group3 --sync-config=/path/to/sync-config.yaml --confirm

2.5.1.30. oc adm inspect

指定のリソースのデバッグデータを収集します。

使用例

  # Collect debugging data for the "openshift-apiserver" clusteroperator
  oc adm inspect clusteroperator/openshift-apiserver

  # Collect debugging data for the "openshift-apiserver" and "kube-apiserver" clusteroperators
  oc adm inspect clusteroperator/openshift-apiserver clusteroperator/kube-apiserver

  # Collect debugging data for all clusteroperators
  oc adm inspect clusteroperator

  # Collect debugging data for all clusteroperators and clusterversions
  oc adm inspect clusteroperators,clusterversions

2.5.1.31. oc adm migrate template-instances

テンプレートインスタンスを更新して、最新の group-version-kinds を参照するようにします。

使用例

  # Perform a dry-run of updating all objects
  oc adm migrate template-instances

  # To actually perform the update, the confirm flag must be appended
  oc adm migrate template-instances --confirm

2.5.1.32. oc adm must-gather

Pod の新規インスタンスを起動してデバッグ情報を収集します。

使用例

  # Gather information using the default plug-in image and command, writing into ./must-gather.local.<rand>
  oc adm must-gather

  # Gather information with a specific local folder to copy to
  oc adm must-gather --dest-dir=/local/directory

  # Gather audit information
  oc adm must-gather -- /usr/bin/gather_audit_logs

  # Gather information using multiple plug-in images
  oc adm must-gather --image=quay.io/kubevirt/must-gather --image=quay.io/openshift/origin-must-gather

  # Gather information using a specific image stream plug-in
  oc adm must-gather --image-stream=openshift/must-gather:latest

  # Gather information using a specific image, command, and pod-dir
  oc adm must-gather --image=my/image:tag --source-dir=/pod/directory -- myspecial-command.sh

2.5.1.33. oc adm new-project

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

使用例

  # Create a new project using a node selector
  oc adm new-project myproject --node-selector='type=user-node,region=east'

2.5.1.34. oc adm node-logs

ノードのログを表示し、フィルターします。

使用例

  # Show kubelet logs from all masters
  oc adm node-logs --role master -u kubelet

  # See what logs are available in masters in /var/logs
  oc adm node-logs --role master --path=/

  # Display cron log file from all masters
  oc adm node-logs --role master --path=cron

2.5.1.35. oc adm pod-network isolate-projects

プロジェクトネットワークを分離します。

使用例

  # Provide isolation for project p1
  oc adm pod-network isolate-projects <p1>

  # Allow all projects with label name=top-secret to have their own isolated project network
  oc adm pod-network isolate-projects --selector='name=top-secret'

2.5.1.36. oc adm pod-network join-projects

プロジェクトネットワークに参加します。

使用例

  # Allow project p2 to use project p1 network
  oc adm pod-network join-projects --to=<p1> <p2>

  # Allow all projects with label name=top-secret to use project p1 network
  oc adm pod-network join-projects --to=<p1> --selector='name=top-secret'

2.5.1.37. oc adm pod-network make-projects-global

プロジェクトネットワークをグローバルにします。

使用例

  # Allow project p1 to access all pods in the cluster and vice versa
  oc adm pod-network make-projects-global <p1>

  # Allow all projects with label name=share to access all pods in the cluster and vice versa
  oc adm pod-network make-projects-global --selector='name=share'

2.5.1.38. oc adm policy add-role-to-user

現在のプロジェクトのユーザーまたはサービスアカウントをロールに追加します。

使用例

  # Add the 'view' role to user1 for the current project
  oc policy add-role-to-user view user1

  # Add the 'edit' role to serviceaccount1 for the current project
  oc policy add-role-to-user edit -z serviceaccount1

2.5.1.39. oc adm policy add-scc-to-group

SCC (Security Context Constraints) オブジェクトをグループに追加します。

使用例

  # Add the 'restricted' security context constraint to group1 and group2
  oc adm policy add-scc-to-group restricted group1 group2

2.5.1.40. oc adm policy add-scc-to-user

SCC (security context constraint) をユーザーまたはサービスアカウントに追加します。

使用例

  # Add the 'restricted' security context constraint to user1 and user2
  oc adm policy add-scc-to-user restricted user1 user2

  # Add the 'privileged' security context constraint to serviceaccount1 in the current namespace
  oc adm policy add-scc-to-user privileged -z serviceaccount1

2.5.1.41. oc adm policy scc-review

Pod を作成できるサービスアカウントを確認します。

使用例

  # Check whether service accounts sa1 and sa2 can admit a pod with a template pod spec specified in my_resource.yaml
  # Service Account specified in myresource.yaml file is ignored
  oc policy scc-review -z sa1,sa2 -f my_resource.yaml

  # Check whether service accounts system:serviceaccount:bob:default can admit a pod with a template pod spec specified in my_resource.yaml
  oc policy scc-review -z system:serviceaccount:bob:default -f my_resource.yaml

  # Check whether the service account specified in my_resource_with_sa.yaml can admit the pod
  oc policy scc-review -f my_resource_with_sa.yaml

  # Check whether the default service account can admit the pod; default is taken since no service account is defined in myresource_with_no_sa.yaml
  oc policy scc-review -f myresource_with_no_sa.yaml

2.5.1.42. oc adm policy scc-subject-review

ユーザーまたはサービスアカウントが Pod を作成できるかどうかを確認します。

使用例

  # Check whether user bob can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -f myresource.yaml

  # Check whether user bob who belongs to projectAdmin group can create a pod specified in myresource.yaml
  oc policy scc-subject-review -u bob -g projectAdmin -f myresource.yaml

  # Check whether a service account specified in the pod template spec in myresourcewithsa.yaml can create the pod
  oc policy scc-subject-review -f myresourcewithsa.yaml

2.5.1.43. oc adm prune builds

以前の完了済みおよび失敗したビルドを削除します。

使用例

  # Dry run deleting older completed and failed builds and also including
  # all builds whose associated build config no longer exists
  oc adm prune builds --orphans

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune builds --orphans --confirm

2.5.1.44. oc adm prune deployments

以前の完了済みおよび失敗したデプロイメント設定を削除します。

使用例

  # Dry run deleting all but the last complete deployment for every deployment config
  oc adm prune deployments --keep-complete=1

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune deployments --keep-complete=1 --confirm

2.5.1.45. oc adm prune groups

外部プロバイダーから欠落しているレコードを参照する以前の OpenShift グループを削除します。

使用例

  # Prune all orphaned groups
  oc adm prune groups --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups except the ones from the blacklist file
  oc adm prune groups --blacklist=/path/to/blacklist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist file
  oc adm prune groups --whitelist=/path/to/whitelist.txt --sync-config=/path/to/ldap-sync-config.yaml --confirm

  # Prune all orphaned groups from a list of specific groups specified in a whitelist
  oc adm prune groups groups/group_name groups/other_name --sync-config=/path/to/ldap-sync-config.yaml --confirm

2.5.1.46. oc adm prune images

参照されていないイメージを削除します。

使用例

  # See what the prune command would delete if only images and their referrers were more than an hour old
  # and obsoleted by 3 newer revisions under the same tag were considered
  oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

  # See what the prune command would delete if we are interested in removing images
  # exceeding currently set limit ranges ('openshift.io/Image')
  oc adm prune images --prune-over-size-limit

  # To actually perform the prune operation, the confirm flag must be appended
  oc adm prune images --prune-over-size-limit --confirm

  # Force the insecure http protocol with the particular registry host name
  oc adm prune images --registry-url=http://registry.example.org --confirm

  # Force a secure connection with a custom certificate authority to the particular registry host name
  oc adm prune images --registry-url=registry.example.org --certificate-authority=/path/to/custom/ca.crt --confirm

2.5.1.47. oc adm release extract

更新ペイロードの内容をディスクに抽出します。

使用例

  # Use git to check out the source code for the current cluster release to DIR
  oc adm release extract --git=DIR

  # Extract cloud credential requests for AWS
  oc adm release extract --credentials-requests --cloud=aws

2.5.1.48. oc adm release info

リリースに関する情報を表示します。

使用例

  # Show information about the cluster's current release
  oc adm release info

  # Show the source code that comprises a release
  oc adm release info 4.2.2 --commit-urls

  # Show the source code difference between two releases
  oc adm release info 4.2.0 4.2.2 --commits

  # Show where the images referenced by the release are located
  oc adm release info quay.io/openshift-release-dev/ocp-release:4.2.2 --pullspecs

2.5.1.49. oc adm release mirror

リリースを別のイメージレジストリーの場所にミラーリングします。

使用例

  # Perform a dry run showing what would be mirrored, including the mirror objects
  oc adm release mirror 4.3.0 --to myregistry.local/openshift/release \
  --release-image-signature-to-dir /tmp/releases --dry-run

  # Mirror a release into the current directory
  oc adm release mirror 4.3.0 --to file://openshift/release \
  --release-image-signature-to-dir /tmp/releases

  # Mirror a release to another directory in the default location
  oc adm release mirror 4.3.0 --to-dir /tmp/releases

  # Upload a release from the current directory to another server
  oc adm release mirror --from file://openshift/release --to myregistry.com/openshift/release \
  --release-image-signature-to-dir /tmp/releases

  # Mirror the 4.3.0 release to repository registry.example.com and apply signatures to connected cluster
  oc adm release mirror --from=quay.io/openshift-release-dev/ocp-release:4.3.0-x86_64 \
  --to=registry.example.com/your/repository --apply-release-image-signature

2.5.1.50. oc adm release new

新しい OpenShift リリースを作成します。

使用例

  # Create a release from the latest origin images and push to a DockerHub repo
  oc adm release new --from-image-stream=4.1 -n origin --to-image docker.io/mycompany/myrepo:latest

  # Create a new release with updated metadata from a previous release
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1 --name 4.1.1 \
  --previous 4.1.0 --metadata ... --to-image docker.io/mycompany/myrepo:latest

  # Create a new release and override a single image
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1 \
  cli=docker.io/mycompany/cli:latest --to-image docker.io/mycompany/myrepo:latest

  # Run a verification pass to ensure the release can be reproduced
  oc adm release new --from-release registry.svc.ci.openshift.org/origin/release:v4.1

2.5.1.51. oc adm taint

1 つ以上のノードでテイントを更新します。

使用例

  # Update node 'foo' with a taint with key 'dedicated' and value 'special-user' and effect 'NoSchedule'.
  # If a taint with that key and effect already exists, its value is replaced as specified.
  oc adm taint nodes foo dedicated=special-user:NoSchedule

  # Remove from node 'foo' the taint with key 'dedicated' and effect 'NoSchedule' if one exists.
  oc adm taint nodes foo dedicated:NoSchedule-

  # Remove from node 'foo' all the taints with key 'dedicated'
  oc adm taint nodes foo dedicated-

  # Add a taint with key 'dedicated' on nodes having label mylabel=X
  oc adm taint node -l myLabel=X  dedicated=foo:PreferNoSchedule

  # Add to node 'foo' a taint with key 'bar' and no value
  oc adm taint nodes foo bar:NoSchedule

2.5.1.52. oc adm top images

イメージの使用状況の統計を表示します。

使用例

  # Show usage statistics for images
  oc adm top images

2.5.1.53. oc adm top imagestreams

イメージストリームの使用状況の統計を表示します。

使用例

  # Show usage statistics for image streams
  oc adm top imagestreams

2.5.1.54. oc adm top node

ノードのリソース (CPU/メモリー) の使用状況を表示します。

使用例

  # Show metrics for all nodes
  oc adm top node

  # Show metrics for a given node
  oc adm top node NODE_NAME

2.5.1.55. oc adm top pod

Pod のリソース (CPU/メモリー) の使用状況を表示します。

使用例

  # Show metrics for all pods in the default namespace
  oc adm top pod

  # Show metrics for all pods in the given namespace
  oc adm top pod --namespace=NAMESPACE

  # Show metrics for a given pod and its containers
  oc adm top pod POD_NAME --containers

  # Show metrics for the pods defined by label name=myLabel
  oc adm top pod -l name=myLabel

2.5.1.56. oc adm uncordon

ノードにスケジュール対象 (schedulable) のマークを付けます。

使用例

  # Mark node "foo" as schedulable.
  $ oc adm uncordon foo

2.5.1.57. oc adm verify-image-signature

イメージ署名に含まれるイメージ ID を確認します。

使用例

  # Verify the image signature and identity using the local GPG keychain
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1

  # Verify the image signature and identity using the local GPG keychain and save the status
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1 --save

  # Verify the image signature and identity via exposed registry route
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 \
  --expected-identity=registry.local:5000/foo/bar:v1 \
  --registry-url=docker-registry.foo.com

  # Remove all signature verifications from the image
  oc adm verify-image-signature sha256:c841e9b64e4579bd56c794bdd7c36e1c257110fd2404bebbb8b613e4935228c4 --remove-all

2.5.2. 追加リソース

2.6. oc および kubectl コマンドの使用

Kubernetes のコマンドラインインターフェース (CLI) kubectl は、Kubernetes クラスターに対してコマンドを実行するために使用されます。OpenShift Container Platform は認定 Kubernetes ディストリビューションであるため、OpenShift Container Platform に同梱されるサポート対象の kubectl バイナリーを使用するか、または oc バイナリーを使用して拡張された機能を取得できます。

2.6.1. oc バイナリー

oc バイナリーは kubectl バイナリーと同じ機能を提供しますが、これは、以下を含む OpenShift Container Platform 機能をネイティブにサポートするように拡張されています。

  • OpenShift Container Platform リソースの完全サポート

    DeploymentConfigBuildConfigRouteImageStream、および ImageStreamTag オブジェクトなどのリソースは OpenShift Container Platform ディストリビューションに固有のリソースであり、標準の Kubernetes プリミティブにビルドされます。

  • 認証

    oc バイナリーは、認証を可能にするビルトインの login コマンドを提供し、Kubernetes namespace を認証ユーザーにマップする OpenShift Container Platform プロジェクトを使って作業できるようにします。詳細は、認証について を参照してください。

  • 追加コマンド

    追加コマンドの oc new-app などは、既存のソースコードまたは事前にビルドされたイメージを使用して新規アプリケーションを起動することを容易にします。同様に、追加コマンドの oc new-project により、デフォルトとして切り替えることができるプロジェクトを簡単に開始できるようになります。

2.6.2. kubectl バイナリー

kubectl バイナリーは、標準の Kubernetes 環境を使用する新規 OpenShift Container Platform ユーザー、または kubectl CLI を優先的に使用するユーザーの既存ワークフローおよびスクリプトをサポートする手段として提供されます。kubectl の既存ユーザーはバイナリーを引き続き使用し、OpenShift Container Platform クラスターへの変更なしに Kubernetes のプリミティブと対話できます。

OpenShift CLI のインストール手順に従って、サポートされている kubectl バイナリーをインストールできます。kubectl バイナリーは、バイナリーをダウンロードする場合にアーカイブに含まれます。または RPM を使用して CLI のインストール時にインストールされます。

詳細は、kubectl のドキュメント を参照してください。

第3章 Developer CLI (odo)

3.1. {odo-title} リリースノート

3.1.1. odo での主な変更点および改善点

  • odo が Devfile v2 をサポートするようになりました。
  • odo create -s2i は S2I コンポーネントを devfile コンポーネントに変換できるようになりました。odo create --s2i <component-type> odo を実行すると、指定されたコンポーネントタイプの S2I イメージに基づいて変換された Devfile コンポーネントが作成されます。

    この機能を使用すると、数多くの変更が導入されます。詳細は、「既知の問題」を参照してください。

  • Operator ベースのサービスは、odo push の実行後にのみクラスター上に作成され、odo service create 後には実行されなくなりました。
  • --container フラグを使用して、odo storage create コマンドの実行時にストレージを割り当てるコンテナーを指定できるようになりました。詳細は、ストレージの特定コンテナーへの追加について参照してください。
  • odo catalog component describe は、複数のレジストリーのコンポーネントに同じ名前が使用される場合に正しい JSON を返すようになりました。
  • 変更をクラスターに直接実装するコマンドにより、odo push が不要であることがユーザーに通知されるようになりました。
  • devfile からコンポーネントを作成する場合、odo create は名前が指定されていない場合にデフォルトのコンポーネント名を使用するようになりました。
  • odo には Telemetry が含まれるようになりました。「Telemetry セクション」を参照し、 Telemetry の承諾についての設定を変更する方法を参照してください。
  • odo service を使用すると、devfile にカスタムリソース定義および ServiceInstance 情報を追加または削除できるようになりました。

3.1.2. サポート

ドキュメント

ドキュメントのエラーが見つかったか、またはドキュメントの改善に関する提案をお寄せいただける場合は、Bugzilla に報告してください。OpenShift Container Platform の製品タイプおよび Documentation コンポーネントタイプを選択します。

製品

エラーを見つけた場合や、odo の機能に関するバグが見つかった場合やこれに関する改善案をお寄せいただける場合は、Bugzilla に報告してください。製品タイプとして OpenShift Developer Tools and Services を選択し、odo をコンポーネントとして選択します。

問題の詳細情報をできる限り多く入力します。

3.1.3. 既知の問題

  • Bug 1760574: 削除された namespace が odo project get コマンドで一覧表示されます。
  • Bug 1760586: odo delete コマンドは、プロジェクトが削除され、コンポーネント名が設定されると無限ループを開始します。
  • Bug 1760588: odo service create コマンドは Cygwin で実行されるとクラッシュします。
  • Bug 1760590: Windows 用の Git BASH では、odo login -u developer は要求された場合も入力されたパスワードを非表示にしません。
  • Bug 1783188: 非接続クラスターでは、odo component create コマンドは、コンポーネントがカタログ一覧に一覧表示されていてもエラーの …​tag not found…​ をスローします。
  • Bug 1761440: 1 つのオブジェクトに同じタイプの 2 つのサービスを作成することができません。
  • Bug 1821643 odo push は .NET コンポーネントタグ 2.1+ では機能しません。

    回避策: 以下を実行して .NET プロジェクトファイルを指定します。

    $ odo config set --env DOTNET_STARTUP_PROJECT=<path_to_your_project>
  • odo create --s2i の後に odo url create を実行すると、コマンドは失敗します。odo は、要求せずに URL を直接作成できるようになりました。
  • Wildfly および dotnet S2I コンポーネントは odo create で作成できません。
  • odo env set DebugPort は変換された devfile コンポーネントでは機能しません。回避策: odo config set --env DEBUG_PORT を使用します。
  • odo delete --wait は、リソースが devfile コンポーネントについて終了するのを待機しません。

3.2. odo について

odo は、OpenShift Container Platform および Kubernetes でアプリケーションを作成するための CLI ツールです。odo を使用すると、クラスター自体を管理する必要なしに、クラスターでアプリケーションを作成し、ビルドし、デバッグできます。デプロイメント設定、ビルド設定、サービスルートおよび他の OpenShift Container Platform または Kubernetes 要素の作成は、すべて odo によって自動化されます。

oc などの既存ツールは操作に重点が置かれ、Kubernetes および OpenShift Container Platform の概念の深い理解が必要です。odo は、複雑な Kubernetes および OpenShift Container Platform の概念を抽象化し、開発者が最も重要な「コード」にフォーカスできるようにします。

3.2.1. 主な特長

odo は、以下の主な特長によって単純化および簡潔化されるように設計されています。

  • プロジェクト、アプリケーションおよびコンポーネントなどの開発者にとって馴染みのある概念を中心とした単純な構文および設計。
  • 完全にクライアントベースである。デプロイメントに OpenShift Container Platform 以外のサーバーは必要ありません。
  • Node.js および Java コンポーネントの正式なサポート。
  • Ruby、Perl、PHP、Python などの言語およびフレームワークとの部分的な互換性。
  • ローカルコードの変更を検出し、これをクラスターに自動的にデプロイ。これにより、変更を検証するためのインスタントフィードバックがリアルタイムに提供されます。
  • クラスターのすべての利用可能なコンポーネントおよびサービスを一覧表示。

3.2.2. コアとなる概念

Project
Project (プロジェクト) は、別個の単一の単位で編成されるソースコード、テスト、ライブラリーです。
Application
Application (アプリケーション) は、エンドユーザー向けに設計されたプログラムです。アプリケーションは、アプリケーション全体を構築するために個別に動作する複数のマイクロサービスまたはコンポーネントで構成されます。アプリケーションの例: ビデオゲーム、メディアプレイヤー、Web ブラウザー。
Component
コンポーネントとは、コードまたはデータをホストする Kubernetes リソースのセットです。各コンポーネントは個別に実行され、デプロイできます。コンポーネントの例: Node.js、Perl、PHP、Python、Ruby
サービス
Service (サービス) は、コンポーネントのリンク先となるか、またはコンポーネントが依存するソフトウェアです。サービスの例: MariaDB、Jenkins、MySQLodo では、サービスは OpenShift Service Catalog からプロビジョニングされ、クラスター内で有効にされる必要があります。

3.2.2.1. 正式にサポートされる言語と対応するコンテナーイメージ

表3.1 サポートされる言語、コンテナーイメージ、パッケージマネージャー、およびプラットフォーム

言語コンテナーイメージパッケージマネージャープラットフォーム

Node.js

rhscl/nodejs-10-rhel7

NPM

amd64、s390x、ppc64le

 

rhscl/nodejs-12-rhel7

NPM

amd64、s390x、ppc64le

Java

redhat-openjdk-18/openjdk18-openshift

Maven、Gradle

amd64、s390x、ppc64le

 

openjdk/openjdk-11-rhel8

Maven、Gradle

amd64、s390x、ppc64le

 

openjdk/openjdk-11-rhel7

Maven、Gradle

amd64、s390x、ppc64le

3.2.2.1.1. 利用可能なコンテナーイメージの一覧表示
注記

利用可能なコンテナーイメージの一覧は、クラスターの内部コンテナーレジストリーおよびクラスターに関連付けられた外部レジストリーから取得されます。

利用可能なコンポーネントおよびクラスターの関連付けられたコンテナーイメージを一覧表示するには、以下を実行します。

  1. odo でクラスターにログインします。

    $ odo login -u developer -p developer
  2. 利用可能な odo がサポートするコンポーネントとサポートしないコンポーネント、および対応するコンテナーイメージを一覧表示します。

    $ odo catalog list components

    出力例

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

    TAGS コラムは利用可能なイメージバージョンを表します (例: 10rhoar-nodejs/nodejs-10 コンテナーイメージを表します)。CLI コマンドについての詳細は、odo CLI リファレンスについて参照してください。

3.2.2.2. odo での Telemetry

odoodo が使用される方法についての情報を収集します。オペレーティングシステム、RAM、CPU サイズ、コア数、odo のバージョン、エラー、成功/失敗、およびコマンドの完了までの所要時間についての情報を収集します。

odo preference を使用して Telemetry の承諾を変更できます。

  • odo preference set ConsentTelemetry true は Telemetry を承諾します。
  • odo preference unset ConsentTelemetry は Telemetry を無効にします。
  • odo preference view は現在の設定を確認します。

3.3. odo のインストール

以下のセクションでは、CLI または Visual Studio Code (VS Code) IDE を使用して各種の異なるプラットフォームに odo をインストールする方法を説明します。

注記

現時点では、odo はネットワークが制限された環境でのインストールをサポートしていません。

また、OpenShift Container Platform Web コンソールから最新のバイナリーへの URL を見つけるには、右上隅の ? アイコンをクリックし、Command Line Tools を選択します。

3.3.1. odo の Linux へのインストール

3.3.1.1. バイナリーインストール

手順

  1. バイナリーを取得します。

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64 -o /usr/local/bin/odo
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.1.2. tarball インストール

手順

  1. tarball を取得します。

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.1.3. Red Hat Enterprise Linux (RHEL) での yum を使用したインストール

手順

  1. Red Hat Subscription Manager に登録します。

    # subscription-manager register
  2. 最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*OpenShift Developer Tools and Services*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションの Pool ID フィールドを見つけ、これを登録されたシステムに割り当てます。

    # subscription-manager attach --pool=<pool_id>
  5. odo で必要なリポジトリーを有効にします。

    # subscription-manager repos --enable="ocp-tools-4.8-for-rhel-8-x86_64-rpms"
  6. odo パッケージをインストールします。

    # yum install odo
  7. odo がシステムで利用可能になっていることを確認します。

    $ odo version

3.3.2. odo の IBM Power の Linux へのインストール

3.3.2.1. バイナリーインストール

手順

  1. バイナリーを取得します。

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le -o /usr/local/bin/odo
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.2.2. tarball インストール

手順

  1. tarball を取得します。

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-ppc64le.tar.gz | gzip -d > /usr/local/bin/odo'
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.3. odo の IBM Z および LinuxONE の Linux へのインストール

3.3.3.1. バイナリーインストール

手順

  1. バイナリーを取得します。

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x -o /usr/local/bin/odo
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.3.2. tarball インストール

手順

  1. tarball を取得します。

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-linux-s390x.tar.gz | gzip -d > /usr/local/bin/odo'
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.4. odo の Windows へのインストール

3.3.4.1. バイナリーインストール

  1. 最新の odo.exe ファイルをダウンロードします。
  2. odo.exe の場所を GOPATH/bin ディレクトリーに追加します。
Windows 7/8 の PATH 変数の設定

以下の例は、パス変数の設定方法を示しています。バイナリーは任意の場所に配置することができますが、この例では C:\go-bin を場所に使用します。

  1. C:\go-binにフォルダーを作成します。
  2. Start を右クリックし、Control Panel をクリックします。
  3. System and Security を選択してから System をクリックします。
  4. 左側のメニューから「システムの詳細設定」を選択し、下部にある「環境変数」をクリックします。
  5. Variable セクションから Path を選択し、Edit をクリックします。
  6. New をクリックしてフィールドに C:\go-bin を入力するか、または Browse をクリックしてディレクトリーを選択してから OK をクリックします。
Windows 10 の PATH 変数の設定

検索機能を使用して環境変数を編集します。

  1. Search クリックして、env または environment を入力します。
  2. Edit environment variables for your account を選択します。
  3. Variable セクションから Path を選択し、Edit をクリックします。
  4. New をクリックしてフィールドに C:\go-bin を入力するか、または Browse をクリックしてディレクトリーを選択してから OK をクリックします。

3.3.5. odo の macOS へのインストール

3.3.5.1. バイナリーインストール

手順

  1. バイナリーを取得します。

    # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64 -o /usr/local/bin/odo
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.5.2. tarball インストール

手順

  1. tarball を取得します。

    # sh -c 'curl -L https://mirror.openshift.com/pub/openshift-v4/clients/odo/latest/odo-darwin-amd64.tar.gz | gzip -d > /usr/local/bin/odo'
  2. ファイルのパーミッションを変更します。

    # chmod +x /usr/local/bin/odo

3.3.6. odo の VS Code へのインストール

OpenShift VS Code 拡張 は、odooc バイナリーの両方を使用して OpenShift Container Platform クラスターと対話します。これらの機能を使用するには、OpenShift VS Code 拡張を VS Code にインストールします。

前提条件

  • VS Code がインストールされていること。

手順

  1. VS Code を開きます。
  2. Ctrl+P で VS Code Quick Open を起動します。
  3. 以下のコマンドを実行します。

    $ ext install redhat.vscode-openshift-connector

3.4. odo を使用したアプリケーションの作成とデプロイ

3.4.1. プロジェクトの使用

Project (プロジェクト) は、別個の単一の単位で編成されるソースコード、テスト、およびライブラリーです。

3.4.1.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.2. odo を使用した単一コンポーネントアプリケーションの作成

odo を使用すると、クラスターでアプリケーションを作成し、デプロイできます。

前提条件

  • odo がインストールされている。
  • 実行中のクラスターがある。CodeReady Containers (CRC) を使用して、ローカルクラスターを迅速にデプロイできます。

3.4.2.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.2.2. odo を使用した Node.js アプリケーションの作成

Node.js コンポーネントを作成するには、Node.js アプリケーションをダウンロードし、odoでソースコードをクラスターにプッシュします。

手順

  1. コンポーネントの新規ディレクトリーを作成します。

    $ mkdir my_components && cd my_components
  2. Node.js アプリケーションのサンプルをダウンロードします。

    $ git clone https://github.com/openshift/nodejs-ex
  3. 現在のディレクトリーをアプリケーションのあるディレクトリーに切り替えます。

    $ cd <directory_name>
  4. Node.js タイプのコンポーネントをアプリケーションに追加します。

    $ odo create nodejs
    注記

    デフォルトで、最新イメージが使用されます。また、odo create openshift/nodejs:8 を使用してイメージのバージョンを明示的に指定できます。

  5. 初期ソースコードをコンポーネントにプッシュします。

    $ odo push

    これで、コンポーネントは OpenShift Container Platform にデプロイされます。

  6. URL を作成し、以下のようにローカル設定ファイルにエントリーを追加します。

    $ odo url create --port 8080
  7. 変更をプッシュします。これにより、URL がクラスターに作成されます。

    $ odo push
  8. コンポーネントに必要な URL を確認するために URL を一覧表示します。

    $ odo url list
  9. 生成された URL を使用してデプロイされたアプリケーションを表示します。

    $ curl <url>

3.4.2.3. アプリケーションコードの変更

アプリケーションコードを変更し、それらの変更を OpenShift Container Platform のアプリケーションに適用します。

  1. 選択するテキストエディターで、Node.js ディレクトリー内のレイアウトファイルのいずれかを編集します。
  2. コンポーネントを更新します。

    $ odo push
  3. ブラウザーでアプリケーションを更新し、変更を確認します。

3.4.2.4. ストレージのアプリケーションコンポーネントへの追加

odo storage コマンドを使用して、永続データをアプリケーションに追加します。永続化する必要のあるデータの例には、.m2 Maven ディレクトリーなどのデータベースファイル、依存関係、およびビルドアーティファクトが含まれます。

手順

  1. ストレージをコンポーネントに追加します。

    $ odo storage create <storage_name> --path=<path_to_the_directory> --size=<size>
  2. ストレージをクラスターにプッシュします。

    $ odo push
  3. コンポーネント内のすべてのストレージを一覧表示して、ストレージがコンポーネントに割り当てられていることを確認します。

    $ odo storage list

    出力例

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Pushed

  4. コンポーネントからストレージを削除します。

    $ odo storage delete <storage_name>
  5. すべてのストレージを一覧表示して、ストレージの状態が Locally Deletedd (ローカルに削除) であることを確認します。

    $ odo storage list

    出力例

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Locally Deleted

  6. 変更をクラスターにプッシュします。

    $ odo push

3.4.2.5. ビルドイメージを指定するためのカスタムビルダーの追加

OpenShift Container Platform では、カスタムイメージの作成ごとに発生する差を埋めるカスタムイメージを追加できます。

以下の例は、redhat-openjdk-18 イメージの正常なインポートおよび使用方法について示しています。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. イメージを OpenShift Container Platform にインポートします。

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift \
    --confirm
  2. イメージにタグを付け、odo からアクセスできるようにします。

    $ oc annotate istag/openjdk18:latest tags=builder
  3. odo でイメージをデプロイします。

    $ odo create openjdk18 --git \
    https://github.com/openshift-evangelists/Wild-West-Backend

3.4.2.6. OpenShift Service Catalog を使用したアプリケーションの複数サービスへの接続

OpenShift サービスカタログは、Kubernetes 用の Open Service Broker API (OSB API) の実装です。これを使用すると、OpenShift Container Platform にデプロイされているアプリケーションをさまざまなサービスに接続できます。

前提条件

  • OpenShift Container Platform クラスターが実行中である。
  • サービスカタログがクラスターにインストールされ、有効にされている。

手順

  • サービスを一覧表示するには、以下を使用します。

    $ odo catalog list services
  • サービスカタログ関連の操作を使用するには、以下を実行します。

    $ odo service <verb> <service_name>

3.4.2.7. アプリケーションの削除

odo app delete コマンドを使用してアプリケーションを削除します。

手順

  1. 現在のプロジェクトのアプリケーションを一覧表示します。

    $ odo app list

    出力例

        The project '<project_name>' has the following applications:
        NAME
        app

  2. アプリケーションに関連付けられたコンポーネントを一覧表示します。これらのコンポーネントはアプリケーションと共に削除されます。

    $ odo component list

    出力例

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. アプリケーションを削除します。

    $ odo app delete <application_name>

    出力例

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y で削除を確定します。-f フラグを使用すると、確認プロンプトを非表示にできます。

3.4.3. odo を使用したマルチコンポーネントアプリケーションの作成

odo を使用すると、簡単かつ自動化された方法でマルチコンポーネントアプリケーションを作成し、変更し、そのコンポーネントをリンクすることができます。

この例では、マルチコンポーネントアプリケーション (シューティングゲーム) をデプロイする方法について説明します。アプリケーションはフロントエンド Node.js コンポーネントとバックエンド Java コンポーネントで構成されます。

前提条件

  • odo がインストールされている。
  • 実行中のクラスターがある。開発者は、CodeReady Containers (CRC) を使用して、ローカルクラスターを迅速にデプロイできます。
  • Maven がインストールされている。

3.4.3.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.3.2. バックエンドコンポーネントのデプロイ

Java コンポーネントを作成するには、Java ビルダーイメージをインポートし、Java アプリケーションをダウンロードし、odo でソースコードをクラスターにプッシュします。

手順

  1. openjdk18 をクラスターにインポートします。

    $ oc import-image openjdk18 \
    --from=registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift --confirm
  2. イメージに builder のタグを付け、イメージが odo でアクセスできるようにします。

    $ oc annotate istag/openjdk18:latest tags=builder
  3. odo catalog list components を実行し、作成されたイメージを表示します。

    $ odo catalog list components

    出力例

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO

  4. コンポーネントの新規ディレクトリーを作成します。

    $ mkdir my_components && cd my_components
  5. バックエンドアプリケーションのサンプルをダウンロードします。

    $ git clone https://github.com/openshift-evangelists/Wild-West-Backend backend
  6. バックエンドソースディレクトリーに移動します。

    $ cd backend
  7. ディレクトリーに正しいファイルがあることを確認します。

    $ ls

    出力例

    debug.sh  pom.xml  src

  8. バックエンドのソースファイルを Maven でビルドし、JAR ファイルを作成します。

    $ mvn package

    出力例

    ...
    [INFO] --------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] --------------------------------------
    [INFO] Total time: 2.635 s
    [INFO] Finished at: 2019-09-30T16:11:11-04:00
    [INFO] Final Memory: 30M/91M
    [INFO] --------------------------------------

  9. backend という Java コンポーネントタイプのコンポーネント設定を作成します。

    $ odo create --s2i openjdk18 backend --binary target/wildwest-1.0.jar

    出力例

     ✓  Validating component [1ms]
     Please use `odo push` command to create the component with source deployed

    設定ファイルの config.yaml は、デプロイ用のコンポーネントについての情報が含まれるバックエンドコンポーネントのローカルディレクトリーに置かれます。

  10. 以下を使用して config.yaml ファイルでバックエンドコンポーネントの設定内容を確認します。

    $ odo config view

    出力例

    COMPONENT SETTINGS
    ------------------------------------------------
    PARAMETER         CURRENT_VALUE
    Type              openjdk18
    Application       app
    Project           myproject
    SourceType        binary
    Ref
    SourceLocation    target/wildwest-1.0.jar
    Ports             8080/TCP,8443/TCP,8778/TCP
    Name              backend
    MinMemory
    MaxMemory
    DebugPort
    Ignore
    MinCPU
    MaxCPU

  11. コンポーネントを OpenShift Container Platform クラスターにプッシュします。

    $ odo push

    出力例

    Validation
     ✓  Checking component [6ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [124ms]
    
    Pushing to component backend of type binary
     ✓  Checking files for pushing [1ms]
     ✓  Waiting for component to start [48s]
     ✓  Syncing files to the component [811ms]
     ✓  Building component [3s]

    odo push を使用すると、OpenShift Container Platform はバックエンドコンポーネントをホストするためのコンテナーを作成し、そのコンテナーを OpenShift Container Platform クラスターで実行されている Pod にデプロイし、 backend コンポーネントを起動します。

  12. 以下を検証します。

    • odo でのアクションのステータス

      $ odo log -f

      出力例

      2019-09-30 20:14:19.738  INFO 444 --- [           main] c.o.wildwest.WildWestApplication         : Starting WildWestApplication v1.0 onbackend-app-1-9tnhc with PID 444 (/deployments/wildwest-1.0.jar started by jboss in /deployments)

    • バックエンドコンポーネントのステータス

      $ odo list

      出力例

      APP     NAME        TYPE          SOURCE                             STATE
      app     backend     openjdk18     file://target/wildwest-1.0.jar     Pushed

3.4.3.3. フロントエンドコンポーネントのデプロイ

フロントエンドコンポーネントを作成およびデプロイするには、Node.js アプリケーションをダウンロードし、ソースコードを odoでクラスターにプッシュします。

手順

  1. フロントエンドアプリケーションのサンプルをダウンロードします。

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. 現在のディレクトリーをフロントエンドディレクトリーに切り替えます。

    $ cd frontend
  3. フロントエンドが Node.js アプリケーションであることを確認するために、ディレクトリーの内容を一覧表示します。

    $ ls

    出力例

    README.md       openshift       server.js       views
    helm            package.json    tests

    注記

    フロントエンドコンポーネントはインタプリター型言語で記述され (Node.js)、ビルドされる必要はありません。

  4. frontendという名前の Node.js コンポーネントタイプのコンポーネント設定を作成します。

    $ odo create --s2i nodejs frontend

    出力例

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. コンポーネントを実行中のコンテナーにプッシュします。

    $ odo push

    出力例

    Validation
     ✓  Checking component [8ms]
    
    Configuration changes
     ✓  Initializing component
     ✓  Creating component [83ms]
    
    Pushing to component frontend of type local
     ✓  Checking files for pushing [2ms]
     ✓  Waiting for component to start [45s]
     ✓  Syncing files to the component [3s]
     ✓  Building component [18s]
     ✓  Changes successfully pushed to component

3.4.3.4. 2 つのコンポーネントのリンク

クラスターで実行されるコンポーネントは、対話するために接続される必要があります。OpenShift Container Platform は、リンクの仕組みを提供し、プログラムからクライアントへの通信バインディングを公開します。

手順

  1. クラスターで実行されるすべてのコンポーネントの一覧を表示します。

    $ odo list

    出力例

    OpenShift Components:
    APP     NAME         PROJECT     TYPE          SOURCETYPE     STATE
    app     backend      testpro     openjdk18     binary         Pushed
    app     frontend     testpro     nodejs        local          Pushed

  2. 現在のフロントエンドコンポーネントをバックエンドにリンクします。

    $ odo link backend --port 8080

    出力例

     ✓  Component backend has been successfully linked from the component frontend
    
    Following environment variables were added to frontend component:
    - COMPONENT_BACKEND_HOST
    - COMPONENT_BACKEND_PORT

    バックエンドコンポーネントの設定情報がフロントエンドコンポーネントに追加され、フロントエンドコンポーネントが再起動します。

3.4.3.5. コンポーネントの公開

手順

  1. frontend ディレクトリーに移動します。

    $ cd frontend
  2. アプリケーションの外部 URL を作成します。

    $ odo url create frontend --port 8080

    出力例

     ✓  URL frontend created for component: frontend
    
    To create URL on the OpenShift  cluster, use `odo push`

  3. 変更を適用します。

    $ odo push

    出力例

    Validation
     ✓  Checking component [21ms]
    
    Configuration changes
     ✓  Retrieving component data [35ms]
     ✓  Applying configuration [29ms]
    
    Applying URL changes
     ✓  URL frontend: http://frontend-app-myproject.192.168.42.79.nip.io created
    
    Pushing to component frontend of type local
     ✓  Checking file changes for pushing [1ms]
     ✓  No file changes detected, skipping build. Use the '-f' flag to force the build.

  4. ブラウザーで URL を開き、アプリケーションを表示します。
注記

アプリケーションに OpenShift Container Platform namespace にアクセスし、アクティブな Pod を削除するのに有効なサービスアカウントのパーミッションが必要な場合、バックエンドコンポーネントから odo log を参照すると以下のエラーが発生する場合があります。

Message: Forbidden!Configured service account doesn’t have access.Service account may have been revoked

このエラーを解決するには、サービスアカウントロールのパーミッションを追加します。

$ oc policy add-role-to-group view system:serviceaccounts -n <project>
$ oc policy add-role-to-group edit system:serviceaccounts -n <project>

これは実稼働クラスターでは実行しないでください。

3.4.3.6. 実行中のアプリケーションの変更

手順

  1. ローカルディレクトリーをフロントエンドディレクトリーに切り替えます。

    $ cd frontend
  2. 以下のコマンドを実行して、ファイルシステムで変更を監視します。

    $ odo watch
  3. index.html ファイルを編集して、ゲームの表示される名前を変更します。

    注記

    odo が変更を認識するまでに若干の遅延が発生する場合があります。

    odo は変更をフロントエンドコンポーネントにプッシュし、そのステータスをターミナルに印刷します。

    File /root/frontend/index.html changed
    File  changed
    Pushing files...
     ✓  Waiting for component to start
     ✓  Copying files to component
     ✓  Building component
  4. Web ブラウザーでアプリケーションページを更新します。これで新しい名前が表示されます。

3.4.3.7. アプリケーションの削除

odo app delete コマンドを使用してアプリケーションを削除します。

手順

  1. 現在のプロジェクトのアプリケーションを一覧表示します。

    $ odo app list

    出力例

        The project '<project_name>' has the following applications:
        NAME
        app

  2. アプリケーションに関連付けられたコンポーネントを一覧表示します。これらのコンポーネントはアプリケーションと共に削除されます。

    $ odo component list

    出力例

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. アプリケーションを削除します。

    $ odo app delete <application_name>

    出力例

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y で削除を確定します。-f フラグを使用すると、確認プロンプトを非表示にできます。

3.4.4. データベースと共にアプリケーションを作成する

以下の例では、データベースをフロントエンドアプリケーションにデプロイし、接続する方法を説明します。

前提条件

  • odo がインストールされている。
  • oc クライアントがインストールされている。
  • 実行中のクラスターがある。開発者は、CodeReady Containers (CRC) を使用して、ローカルクラスターを迅速にデプロイできます。
  • サービスカタログがクラスターにインストールされ、有効にされている。

    注記

    サービスカタログは OpenShift Container Platform 4 以降では非推奨になっています。

3.4.4.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.4.2. フロントエンドコンポーネントのデプロイ

フロントエンドコンポーネントを作成およびデプロイするには、Node.js アプリケーションをダウンロードし、ソースコードを odoでクラスターにプッシュします。

手順

  1. フロントエンドアプリケーションのサンプルをダウンロードします。

    $ git clone https://github.com/openshift/nodejs-ex frontend
  2. 現在のディレクトリーをフロントエンドディレクトリーに切り替えます。

    $ cd frontend
  3. フロントエンドが Node.js アプリケーションであることを確認するために、ディレクトリーの内容を一覧表示します。

    $ ls

    出力例

    README.md       openshift       server.js       views
    helm            package.json    tests

    注記

    フロントエンドコンポーネントはインタプリター型言語で記述され (Node.js)、ビルドされる必要はありません。

  4. frontendという名前の Node.js コンポーネントタイプのコンポーネント設定を作成します。

    $ odo create --s2i nodejs frontend

    出力例

     ✓  Validating component [5ms]
    Please use `odo push` command to create the component with source deployed

  5. フロントエンドインターフェースにアクセスするための URL を作成します。

    $ odo url create myurl

    出力例

     ✓  URL myurl created for component: nodejs-nodejs-ex-pmdp

  6. コンポーネントを OpenShift Container Platform クラスターにプッシュします。

    $ odo push

    出力例

    Validation
     ✓  Checking component [7ms]
    
     Configuration changes
     ✓  Initializing component
     ✓  Creating component [134ms]
    
     Applying URL changes
     ✓  URL myurl: http://myurl-app-myproject.192.168.42.79.nip.io created
    
     Pushing to component nodejs-nodejs-ex-mhbb of type local
     ✓  Checking files for pushing [657850ns]
     ✓  Waiting for component to start [6s]
     ✓  Syncing files to the component [408ms]
     ✓  Building component [7s]
     ✓  Changes successfully pushed to component

3.4.4.3. 対話モードでデータベースをデプロイする

odo は、デプロイをシンプルにするコマンドラインの対話モードを提供します。

手順

  • 対話モードを実行し、プロンプトに対応します。

    $ odo service create

    出力例

    ? Which kind of service do you wish to create database
    ? Which database service class should we use mongodb-persistent
    ? Enter a value for string property DATABASE_SERVICE_NAME (Database Service Name): mongodb
    ? Enter a value for string property MEMORY_LIMIT (Memory Limit): 512Mi
    ? Enter a value for string property MONGODB_DATABASE (MongoDB Database Name): sampledb
    ? Enter a value for string property MONGODB_VERSION (Version of MongoDB Image): 3.2
    ? Enter a value for string property VOLUME_CAPACITY (Volume Capacity): 1Gi
    ? Provide values for non-required properties No
    ? How should we name your service  mongodb-persistent
    ? Output the non-interactive version of the selected options No
    ? Wait for the service to be ready No
     ✓  Creating service [32ms]
     ✓  Service 'mongodb-persistent' was created
    Progress of the provisioning will not be reported and might take a long time.
    You can see the current status by executing 'odo service list'

注記

パスワードまたはユーザー名がフロントエンドアプリケーションに環境変数として渡されます。

3.4.4.4. データベースの手動デプロイ

  1. 利用可能なサービスを一覧表示します。

    $ odo catalog list services

    出力例

    NAME                         PLANS
    django-psql-persistent       default
    jenkins-ephemeral            default
    jenkins-pipeline-example     default
    mariadb-persistent           default
    mongodb-persistent           default
    mysql-persistent             default
    nodejs-mongo-persistent      default
    postgresql-persistent        default
    rails-pgsql-persistent       default

  2. サービスの mongodb-persistent タイプを選択し、必要なパラメーターを確認します。

    $ odo catalog describe service mongodb-persistent

    出力例

      ***********************        | *****************************************************
      Name                           | default
      -----------------              | -----------------
      Display Name                   |
      -----------------              | -----------------
      Short Description              | Default plan
      -----------------              | -----------------
      Required Params without a      |
      default value                  |
      -----------------              | -----------------
      Required Params with a default | DATABASE_SERVICE_NAME
      value                          | (default: 'mongodb'),
                                     | MEMORY_LIMIT (default:
                                     | '512Mi'), MONGODB_VERSION
                                     | (default: '3.2'),
                                     | MONGODB_DATABASE (default:
                                     | 'sampledb'), VOLUME_CAPACITY
                                     | (default: '1Gi')
      -----------------              | -----------------
      Optional Params                | MONGODB_ADMIN_PASSWORD,
                                     | NAMESPACE, MONGODB_PASSWORD,
                                     | MONGODB_USER

  3. 必須のパラメーターをフラグとして渡し、データベースのデプロイを待機します。

    $ odo service create mongodb-persistent --plan default --wait -p DATABASE_SERVICE_NAME=mongodb -p MEMORY_LIMIT=512Mi -p MONGODB_DATABASE=sampledb -p VOLUME_CAPACITY=1Gi

3.4.4.5. データベースのフロントエンドアプリケーションへの接続

  1. データベースをフロントエンドサービスにリンクします。

    $ odo link mongodb-persistent

    出力例

     ✓  Service mongodb-persistent has been successfully linked from the component nodejs-nodejs-ex-mhbb
    
    Following environment variables were added to nodejs-nodejs-ex-mhbb component:
    - database_name
    - password
    - uri
    - username
    - admin_password

  2. Pod のアプリケーションおよびデータベースの環境変数を確認します。

    1. Pod 名を取得します。

      $ oc get pods

      出力例

      NAME                                READY     STATUS    RESTARTS   AGE
      mongodb-1-gsznc                     1/1       Running   0          28m
      nodejs-nodejs-ex-mhbb-app-4-vkn9l   1/1       Running   0          1m

    2. Pod に接続します。

      $ oc rsh nodejs-nodejs-ex-mhbb-app-4-vkn9l
    3. 環境変数を確認します。

      sh-4.2$ env

      出力例

      uri=mongodb://172.30.126.3:27017
      password=dHIOpYneSkX3rTLn
      database_name=sampledb
      username=user43U
      admin_password=NCn41tqmx7RIqmfv

  3. ブラウザーで URL を開き、右下に表示されるデータベース設定を確認します。

    $ odo url list

    出力例

    Request information
    Page view count: 24
    
    DB Connection Info:
    Type:	MongoDB
    URL:	mongodb://172.30.126.3:27017/sampledb

3.4.5. データベースと共に Java アプリケーションを作成する

この例では、devfile を使用して Java アプリケーションをデプロイし、これをデータベースサービスに接続する方法を説明します。

前提条件

  • 実行中のクラスター。
  • odo がインストールされている。
  • Service Binding Operator がクラスターにインストールされている。Operator のインストール方法については、クラスター管理者にお問い合わせください。または、OperatorHub からの Operator のインストールについて参照してください。
  • Dev4Devs PostgreSQL Operator がクラスターにインストールされている。Operator のインストール方法については、クラスター管理者にお問い合わせください。または、OperatorHub からの Operator のインストールについて参照してください。

3.4.5.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.5.2. Java MicroServices JPA アプリケーションの作成

odo を使用すると、Java MicroServices JPA アプリケーションのサンプルを作成し、管理できます。

手順

  1. サンプルアプリケーションのクローン作成

    $ git clone -b jpa-sample https://github.com/redhat-developer/application-stack-samples.git
  2. アプリケーションディレクトリーに移動します。

    $ cd ./application-stack-samples/jpa
  3. プロジェクトを初期化します。

    $ odo create java-openliberty java-application
  4. アプリケーションをクラスターにプッシュします。

    $ odo push

    これで、アプリケーションがクラスターにデプロイされます。

  5. OpenShift Container Platform ログをターミナルにストリーミングして、クラスターのステータスを表示します。

    $ odo log

    テストの失敗および UnknownDatabaseHostException エラーがあることに注意してください。これはアプリケーションにまだデータベースがないためです。

    [INFO] [err] java.net.UnknownHostException: ${DATABASE_CLUSTERIP}
    [INFO] [err]    at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:220)
    [INFO] [err]    at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:403)
    [INFO] [err]    at java.base/java.net.Socket.connect(Socket.java:609)
    [INFO] [err]    at org.postgresql.core.PGStream.<init>(PGStream.java:68)
    [INFO] [err]    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:144)
    [INFO] [err]    ... 86 more
    [ERROR] Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.706 s <<< FAILURE! - in org.example.app.it.DatabaseIT
    [ERROR] testGetAllPeople  Time elapsed: 0.33 s  <<< FAILURE!
    org.opentest4j.AssertionFailedError: Expected at least 2 people to be registered, but there were only: [] ==> expected: <true> but was: <false>
            at org.example.app.it.DatabaseIT.testGetAllPeople(DatabaseIT.java:57)
    
    [ERROR] testGetPerson  Time elapsed: 0.047 s  <<< ERROR!
    java.lang.NullPointerException
            at org.example.app.it.DatabaseIT.testGetPerson(DatabaseIT.java:41)
    
    [INFO]
    [INFO] Results:
    [INFO]
    [ERROR] Failures:
    [ERROR]   DatabaseIT.testGetAllPeople:57 Expected at least 2 people to be registered, but there were only: [] ==> expected: <true> but was: <false>
    [ERROR] Errors:
    [ERROR]   DatabaseIT.testGetPerson:41 NullPointer
    [INFO]
    [ERROR] Tests run: 2, Failures: 1, Errors: 1, Skipped: 0
    [INFO]
    [ERROR] Integration tests failed: There are test failures.
  6. アプリケーションにアクセスするための Ingress URL を作成します。

    $ odo url create --port 8080
  7. 変更をクラスターにプッシュします。

    $ odo push
  8. 作成した URL を表示します。

    $ odo url list

    出力例

    Found the following URLs for component mysboproj
    NAME               STATE      URL                                           PORT     SECURE     KIND
    java-application-8080     Pushed     http://java-application-8080.apps-crc.testing     8080      false      ingress

    これでアプリケーションがクラスターにデプロイされ、作成される URL を使用してそのアプリケーションにアクセスできます。

  9. URL を使用して CreatePerson.xhtml データエントリーページに移動し、フォームを使用してユーザー名と年齢を入力します。Save をクリックします。

    アプリケーションにはまだデータベースが接続されていないため、View Persons Record List リンクをクリックしてデータが表示されないことに注意してください。

3.4.5.3. odo を使用したデータベースの作成

データベースを作成するには、データベース Operator へのアクセスが必要です。この例では、Dev4Devs PostgreSQL Operator が使用されます。

手順

  1. プロジェクトのサービス一覧を表示します。

    $ odo catalog list services

    出力例

    Operators available in the cluster
    NAME                                             CRDs
    postgresql-operator.v0.1.1                       Backup, Database

  2. サービスの YAML をファイルに保存します。

    $ odo service create postgresql-operator.v0.1.1/Database --dry-run > db.yaml
  3. db.yaml ファイルの metadata: セクションに以下の値を追加します。

      name: sampledatabase
      annotations:
        service.binding/db.name: 'path={.spec.databaseName}'
        service.binding/db.password: 'path={.spec.databasePassword}'
        service.binding/db.user: 'path={.spec.databaseUser}'

    この設定により、データベースサービスが起動すると、適切なアノテーションが追加されます。アノテーションは、Service Binding Operator が databaseNamedatabasePassword、および databaseUser の値をアプリケーションに挿入するのに役立ちます。

  4. YAML ファイルの spec: セクションで、以下の値を変更します。

      databaseName: "sampledb"
      databasePassword: "samplepwd"
      databaseUser: "sampleuser"
  5. YAML ファイルからデータベースを作成します。

    $ odo service create --from-file db.yaml

    これで、データベースインスタンスがプロジェクトに表示されます。

3.4.5.4. Java アプリケーションのデータベースへの接続

Java アプリケーションをデータベースに接続するには、odo link コマンドを使用します。

手順

  1. サービスの一覧を表示します。

    $ odo service list

    出力例

    NAME                        AGE
    Database/sampledatabase     6m31s

  2. データベースをアプリケーションに接続します。

    $ odo link Database/sampledatabase
  3. 変更をクラスターにプッシュします。

    $ odo push

    リンクが作成され、プッシュされた後に、データベース接続データが含まれるシークレットが作成されます。

  4. コンポーネントでデータベースサービスから挿入される値の有無を確認します。

    $ odo exec -- bash -c 'env | grep DATABASE'
    declare -x DATABASE_CLUSTERIP="10.106.182.173"
    declare -x DATABASE_DB_NAME="sampledb"
    declare -x DATABASE_DB_PASSWORD="samplepwd"
    declare -x DATABASE_DB_USER="sampleuser"
  5. Java アプリケーションの URL を開き、 CreatePerson.xhtml データエントリーページに移動します。フォームを使用して、ユーザー名と年齢を入力します。Save をクリックします。

    これで View Persons Record List リンクをクリックしてデータベースのデータを表示できることに注意してください。

    psql などの CLI ツールを使用してデータベースを操作することもできます。

3.4.6. odo での devfile の使用

3.4.6.1. odo での devfile について

devfile は、開発環境を記述する移植可能 (portable) ファイルです。devfile を使用すると、再設定をせずに移植可能な開発環境を定義できます。

devfile を使用すると、ソースコード、IDE ツール、アプリケーションランタイム、事前定義コマンドなどの開発環境を記述できます。devfile の詳細は、devfile ドキュメントを参照してください。

odo を使用して、devfile からコンポーネントを作成することができます。devfile を使用してコンポーネントを作成する場合、odo は devfile を OpenShift Container Platform、Kubernetes、または Docker で実行される複数のコンテナーで構成されるワークスペースに変換します。odo はデフォルトの devfile レジストリーを自動的に使用しますが、ユーザーは独自のレジストリーを追加できます。

3.4.6.2. devfile を使用した Java アプリケーションの作成

前提条件

  • odo がインストールされている。
  • Ingress ドメインクラスター名を把握している必要がある。不明な場合は、クラスター管理者にお問い合わせください。たとえば、apps-crc.testingRed Hat CodeReady コンテナー のクラスターのドメイン名です。
注記

現時点で、odo は --git または --binary フラグを使用して devfile コンポーネントを作成することをサポートしていません。これらのフラグを使用する場合にのみ S2I コンポーネントを作成できます。

3.4.6.2.1. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.4.6.2.2. 利用可能な devfile コンポーネントの一覧表示

odo を使用して、クラスター上で利用可能なすべてのコンポーネントを表示できます。利用可能なコンポーネントはクラスターの設定によって異なります。

手順

  1. クラスターで利用可能な devfile コンポーネントを一覧表示するには、以下を実行します。

    $ odo catalog list components

    出力には、利用可能な odo コンポーネントの一覧が表示されます。

    Odo Devfile Components:
    NAME                 DESCRIPTION                            REGISTRY
    java-maven           Upstream Maven and OpenJDK 11          DefaultDevfileRegistry
    java-openliberty     Open Liberty microservice in Java      DefaultDevfileRegistry
    java-quarkus         Upstream Quarkus with Java+GraalVM     DefaultDevfileRegistry
    java-springboot      Spring Boot® using Java                DefaultDevfileRegistry
    nodejs               Stack with NodeJS 12                   DefaultDevfileRegistry
    
    Odo OpenShift Components:
    NAME        PROJECT       TAGS                                                                           SUPPORTED
    java        openshift     11,8,latest                                                                    YES
    dotnet      openshift     2.1,3.1,latest                                                                 NO
    golang      openshift     1.13.4-ubi7,1.13.4-ubi8,latest                                                 NO
    httpd       openshift     2.4-el7,2.4-el8,latest                                                         NO
    nginx       openshift     1.14-el7,1.14-el8,1.16-el7,1.16-el8,latest                                     NO
    nodejs      openshift     10-ubi7,10-ubi8,12-ubi7,12-ubi8,latest                                         NO
    perl        openshift     5.26-el7,5.26-ubi8,5.30-el7,latest                                             NO
    php         openshift     7.2-ubi7,7.2-ubi8,7.3-ubi7,7.3-ubi8,latest                                     NO
    python      openshift     2.7-ubi7,2.7-ubi8,3.6-ubi7,3.6-ubi8,3.8-ubi7,3.8-ubi8,latest                   NO
    ruby        openshift     2.5-ubi7,2.5-ubi8,2.6-ubi7,2.6-ubi8,2.7-ubi7,latest                            NO
    wildfly     openshift     10.0,10.1,11.0,12.0,13.0,14.0,15.0,16.0,17.0,18.0,19.0,20.0,8.1,9.0,latest     NO
3.4.6.2.3. devfile を使用した Java アプリケーションのデプロイ

このセクションでは、devfile を使用して Maven および Java 8 JDK を使用するサンプル Java プロジェクトをデプロイする方法を説明します。

手順

  1. コンポーネントのソースコードを保存するディレクトリーを作成します。

    $ mkdir <directory-name>
  2. myspring という名前の Spring Boot コンポーネントのコンポーネント設定を作成し、そのサンプルプロジェクトをダウンロードします。

    $ odo create java-springboot myspring --starter

    直前のコマンドにより、以下の出力が生成されます。

    Validation
    ✓  Checking devfile compatibility [195728ns]
    ✓  Creating a devfile component from registry: DefaultDevfileRegistry [170275ns]
    ✓  Validating devfile component [281940ns]
    
    Please use `odo push` command to create the component with source deployed

    odo create コマンドは、記録された devfile レジストリーから関連付けられた devfile.yaml ファイルをダウンロードします。

  3. ディレクトリーの内容を一覧表示し、devfile およびサンプル Java アプリケーションがダウンロードされていることを確認します。

    $ ls

    直前のコマンドにより、以下の出力が生成されます。

    README.md    devfile.yaml    pom.xml        src
  4. デプロイされたコンポーネントにアクセスするための URL を作成します。

    $ odo url create --host apps-crc.testing

    直前のコマンドにより、以下の出力が生成されます。

    ✓  URL myspring-8080.apps-crc.testing created for component: myspring
    
    To apply the URL configuration changes, please use odo push
    注記

    URL の作成時にクラスターのホストドメイン名を使用する必要があります。

  5. コンポーネントをクラスターにプッシュします。

    $ odo push

    直前のコマンドにより、以下の出力が生成されます。

    Validation
     ✓  Validating the devfile [81808ns]
    
    Creating Kubernetes resources for component myspring
     ✓  Waiting for component to start [5s]
    
    Applying URL changes
     ✓  URL myspring-8080: http://myspring-8080.apps-crc.testing created
    
    Syncing to component myspring
     ✓  Checking files for pushing [2ms]
     ✓  Syncing files to the component [1s]
    
    Executing devfile commands for component myspring
     ✓  Executing devbuild command "/artifacts/bin/build-container-full.sh" [1m]
     ✓  Executing devrun command "/artifacts/bin/start-server.sh" [2s]
    
    Pushing devfile component myspring
     ✓  Changes successfully pushed to component
  6. コンポーネントの URL を一覧表示し、コンポーネントが正常にプッシュされたことを確認します。

    $ odo url list

    直前のコマンドにより、以下の出力が生成されます。

    Found the following URLs for component myspring
    NAME              URL                                       PORT     SECURE
    myspring-8080     http://myspring-8080.apps-crc.testing     8080     false
  7. 生成された URL を使用してデプロイされたアプリケーションを表示します。

    $ curl http://myspring-8080.apps-crc.testing

3.4.6.3. S2I コンポーネントの devfile コンポーネントへの変換

odo を使用すると、Source-to-Image (S2I) および devfile コンポーネントの両方を作成できます。既存の S2I コンポーネントがある場合には、odo utils コマンドを使用して devfile コンポーネントに変換できます。

手順

S2I コンポーネントディレクトリーからすべてのコマンドを実行します。

  1. odo utils convert-to-devfile コマンドを実行します。これにより、コンポーネントに基づいて devfile.yaml および env.yaml が作成されます。

    $ odo utils convert-to-devfile
  2. コンポーネントをクラスターにプッシュします。

    $ odo push
    注記

    devfile コンポーネントのデプロイメントに失敗した場合は、odo delete -a を実行してこれを削除します。

  3. devfile コンポーネントが正常にデプロイされたことを確認します。

    $ odo list
  4. S2I コンポーネントを削除します。

    $ odo delete --s2i

3.4.7. ストレージの使用

永続ストレージは、odo を再起動してもデータを利用可能な状態に維持します。

3.4.7.1. ストレージのアプリケーションコンポーネントへの追加

odo storage コマンドを使用して、永続データをアプリケーションに追加します。永続化する必要のあるデータの例には、.m2 Maven ディレクトリーなどのデータベースファイル、依存関係、およびビルドアーティファクトが含まれます。

手順

  1. ストレージをコンポーネントに追加します。

    $ odo storage create <storage_name> --path=<path_to_the_directory> --size=<size>
  2. ストレージをクラスターにプッシュします。

    $ odo push
  3. コンポーネント内のすべてのストレージを一覧表示して、ストレージがコンポーネントに割り当てられていることを確認します。

    $ odo storage list

    出力例

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Pushed

  4. コンポーネントからストレージを削除します。

    $ odo storage delete <storage_name>
  5. すべてのストレージを一覧表示して、ストレージの状態が Locally Deletedd (ローカルに削除) であることを確認します。

    $ odo storage list

    出力例

    The component 'nodejs' has the following storage attached:
    NAME           SIZE     PATH      STATE
    mystorage      1Gi      /data     Locally Deleted

  6. 変更をクラスターにプッシュします。

    $ odo push

3.4.7.2. 特定のコンテナーへのストレージの追加

devfile に複数のコンテナーがある場合、--container フラグを使用して、ストレージを割り当てるコンテナーを指定できます。

手順

  1. 複数のコンテナーで devfile を作成します。

    components:
      - name: runtime 1
        container:
          image: registry.access.redhat.com/ubi8/nodejs-12:1-36
          memoryLimit: 1024Mi
          endpoints:
            - name: "3000-tcp"
              targetPort: 3000
          mountSources: true
      - name: funtime 2
        container:
          image: registry.access.redhat.com/ubi8/nodejs-12:1-36
          memoryLimit: 1024Mi
    1
    runtime コンテナー。
    2
    funtime コンテナー。
  2. runtime コンテナーのストレージを作成するには、以下を実行します。

    $ odo storage create store --path /data --size 1Gi --container runtime

    コマンドの出力:

    ✓  Added storage store to nodejs-testing-xnfg
      Please use `odo push` command to make the storage accessible to the component

  3. コンポーネント内のすべてのストレージを一覧表示して、ストレージがコンポーネントに割り当てられていることを確認します。

    $ odo storage list

    出力例

    The component 'nodejs-testing-xnfg' has the following storage attached:
      NAME      SIZE     PATH      CONTAINER     STATE
      store     1Gi      /data     runtime       Not Pushed

  4. 変更をクラスターにプッシュします。

    $ odo push

3.4.7.3. 一時ストレージと永続ストレージ間の切り替え

odo preference コマンドを使用して、プロジェクトの一時ストレージと永続ストレージを切り換えることができます。odo preference はクラスターのグローバル設定を変更します。

永続ストレージを有効にすると、クラスターは複数回の再起動の間で情報を保存します。

一時ストレージを有効にすると、クラスターは再起動の間の情報を保存しません。

一時ストレージはデフォルトで有効にされます。

手順

  1. プロジェクトの現在の設定を参照してください。

    $ odo preference view

    出力例

    PARAMETER             CURRENT_VALUE
    UpdateNotification
    NamePrefix
    Timeout
    BuildTimeout
    PushTimeout
    Experimental
    PushTarget
    Ephemeral             true

  2. 一時ストレージの設定を解除し、永続ストレージを設定するには、以下を実行します。

    $ odo preference set Ephemeral false
  3. 一時ストレージを再度設定するには、以下を実行します。

    $ odo preference set Ephemeral true

    odo preference コマンドは、現在デプロイされているすべてのコンポーネントと、今後デプロイするコンポーネントのグローバル設定を変更します。

  4. odo push を実行して、odo がコンポーネントについての指定されたストレージを作成できるようにします。

    $ odo push

3.4.8. アプリケーションの削除

アプリケーションおよびプロジェクト内のアプリケーションに関連付けられたすべてのコンポーネントを削除できます。

3.4.8.1. アプリケーションの削除

odo app delete コマンドを使用してアプリケーションを削除します。

手順

  1. 現在のプロジェクトのアプリケーションを一覧表示します。

    $ odo app list

    出力例

        The project '<project_name>' has the following applications:
        NAME
        app

  2. アプリケーションに関連付けられたコンポーネントを一覧表示します。これらのコンポーネントはアプリケーションと共に削除されます。

    $ odo component list

    出力例

        APP     NAME                      TYPE       SOURCE        STATE
        app     nodejs-nodejs-ex-elyf     nodejs     file://./     Pushed

  3. アプリケーションを削除します。

    $ odo app delete <application_name>

    出力例

        ? Are you sure you want to delete the application: <application_name> from project: <project_name>

  4. Y で削除を確定します。-f フラグを使用すると、確認プロンプトを非表示にできます。

3.4.9. odo でのアプリケーションのデバッグ

odo を使用すると、デバッガーを割り当て、アプリケーションをリモートでデバッグできます。この機能は NodeJS および Java コンポーネントでのみサポートされます。

odo で作成されたコンポーネントは、デフォルトでデバッグモードで実行されます。デバッガーのエージェントは、特定のポートでコンポーネントに対して実行されます。アプリケーションのデバッグを開始するには、ポート転送を開始して、統合開発環境 (IDE) にバンドルされたローカルのデバッガーを割り当てる必要があります。

3.4.9.1. アプリケーションのデバッグ

odo debug コマンドを使用して、odo でアプリケーションをデバッグできます。

手順

  1. devfile で必要な debugrun ステップを含むサンプルアプリケーションをダウンロードします。

    $ odo create nodejs --starter

    出力例

    Validation
     ✓  Checking devfile existence [11498ns]
     ✓  Checking devfile compatibility [15714ns]
     ✓  Creating a devfile component from registry: DefaultDevfileRegistry [17565ns]
     ✓  Validating devfile component [113876ns]
    
    Starter Project
     ✓  Downloading starter project nodejs-starter from https://github.com/odo-devfiles/nodejs-ex.git [428ms]
    
    Please use `odo push` command to create the component with source deployed

  2. --debug フラグを使用してアプリケーションをプッシュします。これは、すべてのデバッグデプロイメントに必要です。

    $ odo push --debug

    出力例

    Validation
     ✓  Validating the devfile [29916ns]
    
    Creating Kubernetes resources for component nodejs
     ✓  Waiting for component to start [38ms]
    
    Applying URL changes
     ✓  URLs are synced with the cluster, no changes are required.
    
    Syncing to component nodejs
     ✓  Checking file changes for pushing [1ms]
     ✓  Syncing files to the component [778ms]
    
    Executing devfile commands for component nodejs
     ✓  Executing install command "npm install" [2s]
     ✓  Executing debug command "npm run debug" [1s]
    
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

    注記

    --debug-command="custom-step" フラグを使用してカスタムデバッグコマンドを指定できます。

  3. デバッグインターフェースにアクセスするためのローカルポートへのポート転送

    $ odo debug port-forward

    出力例

    Started port forwarding at ports - 5858:5858

    注記

    --local-port フラグを使用してポートを指定できます。

  4. デバッグセッションが別のターミナルウィンドウで実行されていることを確認します。

    $ odo debug info

    出力例

    Debug is running for the component on the local port : 5858

  5. 選択する IDE にバンドルされるデバッガーを割り当てます。手順は IDE によって異なります (例: VSCode デバッグインターフェース)。

3.4.9.2. デバッグパラメーターの設定

odo config コマンドでリモートポートを指定し、odo debug コマンドでローカルポートを指定できます。

手順

  • デバッグエージェントを実行するリモートポートを設定するには、以下を実行します。

    $ odo config set DebugPort 9292
    注記

    この値のコンポーネントをコンポーネントに反映させるには、コンポーネントを再デプロイする必要があります。

  • ローカルポートをポート転送に設定するには、以下を実行します。

    $ odo debug port-forward --local-port 9292
    注記

    ローカルポートの値は永続化されません。ポートを変更する必要がある場合は毎回これを指定する必要があります。

3.4.10. サンプルアプリケーション

odo は、OpenShift Container Platform カタログのコンポーネントタイプ内の言語またはランタイムとの部分的な互換性を提供します。例:

NAME        PROJECT       TAGS
dotnet      openshift     3.1,latest
httpd       openshift     2.4,latest
java        openshift     8,latest
nginx       openshift     1.10,1.12,1.8,latest
nodejs      openshift     0.10,4,6,8,latest
perl        openshift     5.16,5.20,5.24,latest
php         openshift     5.5,5.6,7.0,7.1,latest
python      openshift     2.7,3.3,3.4,3.5,3.6,latest
ruby        openshift     2.0,2.2,2.3,2.4,latest
wildfly     openshift     10.0,10.1,8.1,9.0,latest
注記

odo については、Java および Node.js は正式にサポートされているコンポーネントタイプです。odo catalog list components を実行して、正式にサポートされているコンポーネントタイプを確認します。

Web 経由でコンポーネントにアクセスするには、odo url create を使用して URL を作成します。

3.4.10.1. Git リポジトリーの例

3.4.10.1.1. httpd

この例は、CentOS 7 で httpd を使用して静的コンテンツをビルドし、提供するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージの使用方法についての詳細は、「Apache HTTP Server container image repository」を参照してください。

$ odo create httpd --git https://github.com/openshift/httpd-ex.git
3.4.10.1.2. java

この例は、CentOS 7 で Fat JAR Java アプリケーションをビルドし、実行するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「Java S2I Builder image」を参照してください。

$ odo create java --git https://github.com/spring-projects/spring-petclinic.git
3.4.10.1.3. nodejs

CentOS 7 で Node.js アプリケーションをビルドし、実行します。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「Node.js 8 container image」を参照してください。

$ odo create nodejs --git https://github.com/openshift/nodejs-ex.git
3.4.10.1.4. perl

この例は、CentOS 7 で Perl アプリケーションのビルドし、実行するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「Perl 5.26 container image」を参照してください。

$ odo create perl --git https://github.com/openshift/dancer-ex.git
3.4.10.1.5. php

この例は、CentOS 7 で PHP アプリケーションのビルドし、実行するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「PHP 7.1 Docker image」を参照してください。

$ odo create php --git https://github.com/openshift/cakephp-ex.git
3.4.10.1.6. python

この例は、CentOS 7 で Python アプリケーションをビルドし、実行するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「Python 3.6 container image」を参照してください。

$ odo create python --git https://github.com/openshift/django-ex.git
3.4.10.1.7. ruby

この例は、CentOS 7 で Ruby アプリケーションをビルドし、実行するのに役立ちます。OpenShift Container Platform の考慮点を含む、このビルダーイメージを使用する方法についての詳細は、「Ruby 2.5 container image」を参照してください。

$ odo create ruby --git https://github.com/openshift/ruby-ex.git

3.4.10.2. バイナリーのサンプル

3.4.10.2.1. java

Java を使用すると、以下のようにバイナリーアーティファクトをデプロイすることができます。

$ git clone https://github.com/spring-projects/spring-petclinic.git
$ cd spring-petclinic
$ mvn package
$ odo create java test3 --binary target/*.jar
$ odo push

3.5. 制限された環境での odo の使用

3.5.1. 制限された環境での odo について

odo を非接続のクラスター、または制限された環境でプロビジョニングされたクラスターで実行するには、クラスター管理者がミラーリングされたレジストリーでクラスターを作成していることを確認する必要があります。

非接続クラスターで作業を開始するには、まず odo init イメージをクラスターのレジストリーにプッシュしODO_BOOTSTRAPPER_IMAGE 環境変数を使用して odo init イメージパスを上書きする必要があります。

odo init イメージのプッシュ後に、レジストリーからサポートされているビルダーイメージをミラーリングしミラーレジストリーを上書きした後にアプリケーションを作成する必要があります。ビルダーイメージは、アプリケーションのランタイム環境を設定するために必要であり、これにはアプリケーションのビルドに必要なビルドツールが含まれます (例: Node.js の場合は npm、Java の場合は Maven)。ミラーレジストリーには、アプリケーションに必要なすべての依存関係が含まれます。

3.5.2. odo init イメージの制限されたクラスターレジストリーへのプッシュ

クラスターおよびオペレーティングシステムの設定に応じて、odo init イメージをミラーレジストリーにプッシュするか、または内部レジストリーに直接プッシュできます。

3.5.2.1. 前提条件

  • クライアントオペレーティングシステムに oc をインストールします。
  • odo をクライアントオペレーティングシステムにインストールします。
  • 内部レジストリーまたはミラーレジストリーが設定された制限付きクラスターへのアクセス。

3.5.2.2. odo init イメージのミラーレジストリーへのプッシュ

オペレーティングシステムによっては、以下のように odo init イメージをミラーレジストリーを持つクラスターにプッシュできます。

3.5.2.2.1. init イメージを Linux のミラーレジストリーにプッシュする

手順

  1. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. エンコーディングされたルート CA 証明書を適切な場所にコピーします。

    $ sudo cp ./disconnect-ca.crt /etc/pki/ca-trust/source/anchors/<mirror-registry>.crt
  3. クライアントプラットフォームのCAを信頼し、OpenShift Container Platformのミラーレジストリにログインします。

    $ sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart / docker && docker login <mirror-registry>:5000 -u <username> -p <password>
  4. odo init イメージをミラーリングします。

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
3.5.2.2.2. init イメージを MacOS のミラーレジストリーにプッシュする

手順

  1. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    $ echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. エンコーディングされたルート CA 証明書を適切な場所にコピーします。

    1. Docker UI を使用して Docker を再起動します。
    2. 以下のコマンドを実行します。

      $ docker login <mirror-registry>:5000 -u <username> -p <password>
  3. odo init イメージをミラーリングします。

    $ oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  4. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    $ export ODO_BOOTSTRAPPER_IMAGE=<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
3.5.2.2.3. Windows のミラーレジストリーに init イメージをプッシュする

手順

  1. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    PS C:\> echo <content_of_additional_ca> | base64 --decode > disconnect-ca.crt
  2. 管理者として、以下のコマンドを実行して、エンコーディングされたルート CA 証明書を適切な場所にコピーします。

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" disconnect-ca.crt
  3. クライアントプラットフォームのCAを信頼し、OpenShift Container Platformのミラーレジストリにログインします。

    1. Docker UI を使用して Docker を再起動します。
    2. 以下のコマンドを実行します。

      PS C:\WINDOWS\system32> docker login <mirror-registry>:5000 -u <username> -p <password>
  4. odo init イメージをミラーリングします。

    PS C:\> oc image mirror registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>
  5. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<mirror-registry>:5000/openshiftdo/odo-init-image-rhel7:<tag>"

3.5.2.3. odo init イメージを内部レジストリーに直接プッシュする

クラスターでイメージを内部レジストリーに直接プッシュできるようにする場合、以下のように odo init イメージをレジストリーにプッシュします。

3.5.2.3.1. init イメージを Linux 上で直接プッシュする

手順

  1. デフォルトのルートを有効にします。

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. ワイルドカードルート CA を取得します。

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    出力例

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. クライアントプラットフォームで CA を信頼します。

    $ sudo cp ca.crt  /etc/pki/ca-trust/source/anchors/externalroute.crt && sudo update-ca-trust enable && sudo systemctl daemon-reload && sudo systemctl restart docker
  5. 内部レジストリにログインします。

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init イメージをプッシュします。

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
3.5.2.3.2. init イメージを MacOS 上で直接プッシュする

手順

  1. デフォルトのルートを有効にします。

    $ oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. ワイルドカードルート CA を取得します。

    $ oc get secret router-certs-default -n openshift-ingress -o yaml

    出力例

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    $ echo <tls.crt> | base64 --decode > ca.crt
  4. クライアントプラットフォームで CA を信頼します。

    $ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ca.crt
  5. 内部レジストリにログインします。

    $ oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    $ docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init イメージをプッシュします。

    $ docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    $ docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    $ export ODO_BOOTSTRAPPER_IMAGE=<registry_path>/openshiftdo/odo-init-image-rhel7:1.0.1
3.5.2.3.3. init イメージを Windows 上で直接プッシュする

手順

  1. デフォルトのルートを有効にします。

    PS C:\> oc patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"defaultRoute":true}}' --type='merge' -n openshift-image-registry
  2. ワイルドカードルート CA を取得します。

    PS C:\> oc get secret router-certs-default -n openshift-ingress -o yaml

    出力例

    apiVersion: v1
    data:
      tls.crt: **************************
      tls.key: ##################
    kind: Secret
    metadata:
      [...]
    type: kubernetes.io/tls

  3. base64 を使用してミラーレジストリーのルート認証局 (CA) コンテンツをエンコードします。

    PS C:\> echo <tls.crt> | base64 --decode > ca.crt
  4. 管理者として、以下のコマンドを実行して、クライアントプラットフォームの CA を信頼します。

    PS C:\WINDOWS\system32> certutil -addstore -f "ROOT" ca.crt
  5. 内部レジストリにログインします。

    PS C:\> oc get route -n openshift-image-registry
    NAME       HOST/PORT    PATH   SERVICES     PORT  TERMINATION   WILDCARD
    default-route   <registry_path>          image-registry   <all>   reencrypt     None
    
    PS C:\> docker login <registry_path> -u kubeadmin -p $(oc whoami -t)
  6. odo init イメージをプッシュします。

    PS C:\> docker pull registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker tag registry.access.redhat.com/openshiftdo/odo-init-image-rhel7:<tag> <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
    
    PS C:\> docker push <registry_path>/openshiftdo/odo-init-image-rhel7:<tag>
  7. ODO_BOOTSTRAPPER_IMAGE 環境変数を設定してデフォルトの odo init イメージパスを上書きします。

    PS C:\> $env:ODO_BOOTSTRAPPER_IMAGE="<registry_path>/openshiftdo/odo-init-image-rhel7:<tag>"

3.5.3. コンポーネントの作成および非接続クラスターへのデプロイ

ミラーリングされたレジストリーを持つクラスターに init イメージをプッシュした後に、アプリケーションでサポートされるビルダーイメージを oc ツールでミラーリングし、環境変数を使用してミラーレジストリーを上書きし、コンポーネントを作成する必要があります。

3.5.3.1. 前提条件

3.5.3.2. サポートされるビルダーイメージのミラーリング

Node.js の依存関係に npm パッケージを使用し、Java の依存関係に Maven パッケージを使用し、アプリケーションのランタイム環境を設定するには、ミラーレジストリーから適切なビルダーイメージをミラーリングする必要があります。

手順

  1. 必要なイメージタグがインポートされていないことを確認します。

    $ oc describe is nodejs -n openshift

    出力例

    Name:                   nodejs
    Namespace:              openshift
    [...]
    
    10
      tagged from <mirror-registry>:<port>/rhoar-nodejs/nodejs-10
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs, hidden
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhoar-nodejs/nodejs-10:latest" not found
          About an hour ago
    
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      ! error: Import failed (NotFound): dockerimage.image.openshift.io "<mirror-registry>:<port>/rhscl/nodejs-10-rhel7:latest" not found
          About an hour ago
    
    [...]

  2. サポートされるイメージタグをプライベートレジストリーに対してミラーリングします。

    $ oc image mirror registry.access.redhat.com/rhscl/nodejs-10-rhel7:<tag> <private_registry>/rhscl/nodejs-10-rhel7:<tag>
  3. イメージをインポートします。

    $ oc tag <mirror-registry>:<port>/rhscl/nodejs-10-rhel7:<tag> nodejs-10-rhel7:latest --scheduled

    イメージを定期的に再インポートする必要があります。--scheduled フラグは、イメージの自動再インポートを有効にします。

  4. 指定されたタグを持つイメージがインポートされていることを確認します。

    $ oc describe is nodejs -n openshift

    出力例

    Name:                   nodejs
    [...]
    10-SCL (latest)
      tagged from <mirror-registry>:<port>/rhscl/nodejs-10-rhel7
        prefer registry pullthrough when referencing this tag
    
      Build and run Node.js 10 applications on RHEL 7. For more information about using this builder image, including OpenShift considerations, see https://github.com/nodeshift/centos7-s2i-nodejs.
      Tags: builder, nodejs
      Example Repo: https://github.com/sclorg/nodejs-ex.git
    
      * <mirror-registry>:<port>/rhscl/nodejs-10-rhel7@sha256:d669ecbc11ac88293de50219dae8619832c6a0f5b04883b480e073590fab7c54
          3 minutes ago
    
    [...]

3.5.3.3. ミラーレジストリーの上書き

Node.js の依存関係用の npm パッケージおよび Java の依存関係用の Maven パッケージをプライベートミラーレジストリーからダウンロードするには、クラスター上にミラー npm または Maven レジストリーを作成し、設定する必要があります。その後、既存のコンポーネントで、または新規コンポーネントの作成時にミラーレジストリーを上書きできます。

手順

  • 既存のコンポーネントでミラーレジストリーを上書きするには、以下を実行します。

    $ odo config set --env NPM_MIRROR=<npm_mirror_registry>
  • コンポーネントの作成時にミラーレジストリーを上書きするには、以下を実行します。

    $ odo component create nodejs --env NPM_MIRROR=<npm_mirror_registry>

3.5.3.4. odo を使用した Node.js アプリケーションの作成

Node.js コンポーネントを作成するには、Node.js アプリケーションをダウンロードし、odoでソースコードをクラスターにプッシュします。

手順

  1. 現在のディレクトリーをアプリケーションのあるディレクトリーに切り替えます。

    $ cd <directory_name>
  2. Node.js タイプのコンポーネントをアプリケーションに追加します。

    $ odo create nodejs
    注記

    デフォルトで、最新イメージが使用されます。また、odo create openshift/nodejs:8 を使用してイメージのバージョンを明示的に指定できます。

  3. 初期ソースコードをコンポーネントにプッシュします。

    $ odo push

    これで、コンポーネントは OpenShift Container Platform にデプロイされます。

  4. URL を作成し、以下のようにローカル設定ファイルにエントリーを追加します。

    $ odo url create --port 8080
  5. 変更をプッシュします。これにより、URL がクラスターに作成されます。

    $ odo push
  6. コンポーネントに必要な URL を確認するために URL を一覧表示します。

    $ odo url list
  7. 生成された URL を使用してデプロイされたアプリケーションを表示します。

    $ curl <url>

3.5.4. コンポーネントの作成および非接続クラスターへのデプロイ

3.5.4.1. 非接続クラスターでの devfile を使用した NodeJS アプリケーションの作成

警告

この手順では、Red Hat が保守していない nodejs-ex.git アプリケーションなどの外部依存関係を使用しています。これらの依存関係についてはドキュメントでは保守対象ではなく、それらの機能は保証されていません。

前提条件

  • 非接続クラスターを作成し、ログインしている。
  • プロキシーに raw.githubusercontent.comregistry.access.redhat.com、および registry.npmjs.org URL を追加している。

手順

  1. devfile で NodeJS アプリケーションを定義します。

    devfile の例

    schemaVersion: 2.0.0
    metadata:
    name: nodejs
    starterProjects:
    - name: nodejs-starter
      git:
        remotes:
          origin: "https://github.com/odo-devfiles/nodejs-ex.git"
    components:
    - name: runtime
      container:
        image: registry.access.redhat.com/ubi8/nodejs-12:1-36
        memoryLimit: 1024Mi
        endpoints:
          - name: "3000/tcp"
            targetPort: 3000
        env:
          - name: HTTP_PROXY
            value: http://<proxy-host>:<proxy-port>
          - name: HTTPS_PROXY
            value: http://<proxy-host>:<proxy-port>
        mountSources: true
    commands:
    - id: devbuild
      exec:
        component: runtime
        commandLine: npm install
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: build
          isDefault: true
    - id: build
      exec:
        component: runtime
        commandLine: npm install
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: build
    - id: devrun
      exec:
        component: runtime
        commandLine: npm start
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: run
          isDefault: true
    - id: run
      exec:
        component: runtime
        commandLine: npm start
        workingDir: ${PROJECTS_ROOT}
        group:
          kind: run

  2. アプリケーションを作成し、変更をクラスターにプッシュします。

    $ odo create nodejs --devfile <path-to-your-devfile> --starter $$ odo push

    出力例

    [...]
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

  3. アプリケーションにアクセスして、クラスターにプッシュするために URL を作成します。

    $ odo url create url1 --port 3000 --host example.com --ingress && odo push

    出力例

    Validation
     ✓  Validating the devfile [145374ns]
    
    Creating Kubernetes resources for component nodejs
     ✓  Waiting for component to start [14s]
    
    Applying URL changes
     ✓  URL url1: http://url1.abcdr.com/ created
    
    Syncing to component nodejs
     ✓  Checking file changes for pushing [2ms]
     ✓  Syncing files to the component [3s]
    
    Executing devfile commands for component nodejs
     ✓  Executing devbuild command "npm install" [4s]
     ✓  Executing devrun command "npm start" [3s]
    
    Pushing devfile component nodejs
     ✓  Changes successfully pushed to component

  4. ストレージをアプリケーションに追加します。

    $ odo storage create <storage-name> --path /data --size 5Gi

    出力例

    ✓  Added storage abcde to nodejs
    
    Please use `odo push` command to make the storage accessible to the component

  5. 変更をクラスターにプッシュします。

    $ odo push

3.5.4.2. 非接続クラスターでの devfile を使用した Java アプリケーションの作成

警告

この手順では、Red Hat でメンテナンスされていない quay.io/eclipse/che-java11-maven:nightly やアプリケーションサンプルの springboot-ex などの外部の依存関係を使用します。これらの依存関係についてはドキュメントでは保守対象ではなく、それらの機能は保証されていません。

前提条件

  • 非接続クラスターを作成し、ログインしている。
  • プロキシー設定に quay.ioregistry.access.redhat.comapache.orgquayio-production-s3.s3.amazonaws.com URL を追加している。

手順

  1. devfile で Java アプリケーションを定義します。

    devfile の例

    schemaVersion: 2.0.0
    metadata:
      name: java-maven
      version: 1.1.0
    starterProjects:
      - name: springbootproject
        git:
          remotes:
            origin: "https://github.com/odo-devfiles/springboot-ex.git"
    components:
      - name: tools
        container:
          image: quay.io/eclipse/che-java11-maven:nightly
          memoryLimit: 512Mi
          mountSources: true
          endpoints:
            - name: 'http-8080'
              targetPort: 8080
          volumeMounts:
            - name: m2
              path: /home/user/.m2
      - name: m2
        volume: {}
    commands:
      - id: mvn-package
        exec:
          component: tools
          commandLine: "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package"
          group:
            kind: build
            isDefault: true
      - id: run
        exec:
          component: tools
          commandLine: "java -jar target/*.jar"
          group:
            kind: run
            isDefault: true
      - id: debug
        exec:
          component: tools
          commandLine: "java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=${DEBUG_PORT},suspend=n -jar target/*.jar"
          group:
            kind: debug
            isDefault: true

  2. Java アプリケーションを作成します。

    $ odo create java-maven --devfile <path-to-your-devfile> --starter

    出力例

    Validation
     ✓  Checking devfile existence [87716ns]
     ✓  Creating a devfile component from registry: DefaultDevfileRegistry [107247ns]
     ✓  Validating devfile component [396971ns]
    
     Starter Project
     ✓  Downloading starter project springbootproject from https://github.com/odo-devfiles/springboot-ex.git [2s]
    
    Please use `odo push` command to create the component with source deployed

  3. 変更をクラスターにプッシュします。

    $ odo push

    出力例

    I0224 14:43:18.802512   34741 util.go:727] HTTPGetRequest: https://raw.githubusercontent.com/openshift/odo/master/build/VERSION
    I0224 14:43:18.833631   34741 context.go:115] absolute devfile path: '/Users/pkumari/go/src/github.com/openshift/odo/testim/devfile.yaml'
    [...]
    Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.2.1/plexus-utils-3.2.1.jar (262 kB at 813 kB/s)
    [INFO] Replacing main artifact with repackaged archive
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  19.638 s
    [INFO] Finished at: 2021-02-24T08:59:30Z
    [INFO] ------------------------------------------------------------------------
     ✓  Executing mvn-package command "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package" [23s]
     •  Executing run command "java -jar target/*.jar"  ...
    I0224 14:29:30.557676   34426 exec.go:27] Executing command [/opt/odo/bin/supervisord ctl start devrun] for pod: java-maven-5b8f99fcdb-9dnk6 in container: tools
    devrun: started
     ✓  Executing run command "java -jar target/*.jar" [3s]
    
    Pushing devfile component java-maven
     ✓  Changes successfully pushed to component

  4. ログを表示して、アプリケーションが起動していることを確認します。

    $ odo log

    出力例

    time="2021-02-24T08:58:58Z" level=info msg="create process:devrun"
    time="2021-02-24T08:58:58Z" level=info msg="create process:debugrun"
    time="2021-02-24T08:59:32Z" level=debug msg="no auth required"
    time="2021-02-24T08:59:32Z" level=debug msg="succeed to find process:devrun"
    time="2021-02-24T08:59:32Z" level=info msg="try to start program" program=devrun
    time="2021-02-24T08:59:32Z" level=info msg="success to start program" program=devrun
    ODO_COMMAND_RUN is java -jar target/*.jar
    Executing command  java -jar target/*.jar
    [...]

  5. アプリケーションのストレージを作成します。

    $ odo storage create storage-name --path /data --size 5Gi

    出力例

    ✓  Added storage storage-name to java-maven
    
    Please use `odo push` command to make the storage accessible to the component

  6. 変更をクラスターにプッシュします。

    $ odo push

    出力。

    ✓  Waiting for component to start [310ms]
    
    Validation
     ✓  Validating the devfile [100798ns]
    
    Creating Kubernetes resources for component java-maven
     ✓  Waiting for component to start [30s]
     ✓  Waiting for component to start [303ms]
    
    Applying URL changes
     ✓  URLs are synced with the cluster, no changes are required.
    
    Syncing to component java-maven
     ✓  Checking file changes for pushing [5ms]
     ✓  Syncing files to the component [4s]
    
    Executing devfile commands for component java-maven
     ✓  Waiting for component to start [526ms]
     ✓  Executing mvn-package command "mvn -Dmaven.repo.local=/home/user/.m2/repository -Dhttp.proxyHost=<proxy-host> -Dhttp.proxyPort=<proxy-port> -Dhttps.proxyHost=<proxy-host> -Dhttps.proxyPort=<proxy-port> package" [10s]
     ✓  Executing run command "java -jar target/*.jar" [3s]
    
    Pushing devfile component java-maven
     ✓  Changes successfully pushed to component

3.6. Operator によって管理されるサービスのインスタンスの作成

Operator は、Kubernetes サービスをパッケージ化し、デプロイし、管理する方法です。odo を使用して、Operator によって提供されるカスタムリソース定義 (CRD) からサービスのインスタンスを作成できます。その後、プロジェクトでこれらのインスタンスを使用し、それらをコンポーネントにリンクできます。

Operator からサービスを作成するには、要求されたサービスを起動するために必要な有効な値が Operator の metadata に定義されていることを確認する必要があります。odo は Operator の metadata.annotations.alm-examples YAML ファイルを使用してサービスを起動します。この YAML にプレースホルダーの値またはサンプルの値がある場合、サービスは起動できません。YAML ファイルを変更し、変更した値でサービスを起動することができます。YAML ファイルを変更する方法およびそのファイルからサービスを起動する方法については、YAML ファイルを使用したサービスの作成 について参照してください。

3.6.1. 前提条件

  • ocCLIをインストールし、クラスターにログインします。

    • クラスターの設定により利用できるサービスが異なることに注意してください。Operator サービスにアクセスするには、クラスター管理者はまずクララスターにそれぞれの Operator をインストールする必要があります。詳細は、「Adding Operators to the cluster」を参照してください。
  • odo CLI をインストールします。

3.6.2. プロジェクトの作成

プロジェクトを作成し、別個の単一の単位で編成されるソースコード、テスト、ライブラリーを維持します。

手順

  1. OpenShift Container Platform クラスターにログインします。

    $ odo login -u developer -p developer
  2. プロジェクトを作成します。

    $ odo project create myproject

    出力例

     ✓  Project 'myproject' is ready for use
     ✓  New project created and now using project : myproject

3.6.3. クラスターにインストールされている Operator からの利用可能なサービスの一覧表示

odo を使用して、クラスターにインストールされている Operator およびそれらが提供するサービスの一覧を表示できます。

  • 現在のプロジェクトにインストールされている Operator を一覧表示するには、以下を実行します。

    $ odo catalog list services

    コマンドは Operator および CRD を一覧表示します。コマンドの出力には、クラスターにインストールされている Operator が表示されます。以下は例になります。

    Operators available in the cluster
    NAME                          CRDs
    etcdoperator.v0.9.4           EtcdCluster, EtcdBackup, EtcdRestore
    mongodb-enterprise.v1.4.5     MongoDB, MongoDBUser, MongoDBOpsManager

    etcdoperator.v0.9.4 は Operator であり、 EtcdClusterEtcdBackup および EtcdRestore は Operator によって提供される CRD です。

3.6.4. Operator からのサービスの作成

要求されたサービスを起動するために必要な有効な値が Operator の metadata に定義されている場合、odo service create でサービスを使用できます。

  1. サービスの YAML をローカルドライブのファイルとして出力します。

    $ oc get csv/etcdoperator.v0.9.4 -o yaml
  2. サービスの値が有効であることを確認します。

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: example
    spec:
      size: 3
      version: 3.2.13
  3. EtcdCluster サービスを etcdoperator.v0.9.4 Operator から起動します。

    $ odo service create etcdoperator.v0.9.4 EtcdCluster
  4. サービスが起動していることを確認します。

    $ oc get EtcdCluster

3.6.5. YAML ファイルからのサービスの作成

サービスまたはカスタムリソース (CR) の YAML 定義に無効なデータまたはプレースホルダーのデータがある場合、--dry-run フラグを使用して YAML 定義を取得し、正しい値を指定し、修正された YAML 定義を使用してサービスを起動することができます。サービスを起動するために使用される YAML を出力および変更するために、odo はサービスの起動前に Operator によって提供されるサービスまたは CR の YAML 定義を出力する機能を提供します。

  1. サービスの YAML を表示するには、以下を実行します。

    $ odo service create <operator-name> --dry-run

    たとえば、etcdoperator.v0.9.4 Operator によって提供される EtcdCluster の YAML 定義を出力するには、以下を実行します。

    $ odo service create etcdoperator.v0.9.4 --dry-run

    YAML は etcd.yaml ファイルとして保存されます。

  2. etcd.yaml ファイルを変更します。

    apiVersion: etcd.database.coreos.com/v1beta2
    kind: EtcdCluster
    metadata:
      name: my-etcd-cluster 1
    spec:
      size: 1 2
      version: 3.2.13
    1
    名前を example から my-etcd-cluster に変更します。
    2
    サイズを 3 から 1 に縮小します。
  3. YAML ファイルからサービスを起動します。

    $ odo service create --from-file etcd.yaml
  4. EtcdCluster サービスが事前に設定された 3 つの Pod ではなく 1 つの Pod で起動されていることを確認します。

    $ oc get pods | grep my-etcd-cluster

3.7. 環境変数の管理

odo はコンポーネント固有の設定および環境変数を config ファイルに保存します。odo config コマンドを使用すると、config ファイルを変更せずに、コンポーネントの環境変数の設定、設定解除、および一覧表示を実行できます。

3.7.1. 環境変数の設定および設定解除

手順

  • コンポーネントで環境変数を設定するには、以下を実行します。

    $ odo config set --env <variable>=<value>
  • コンポーネントの環境変数の設定を解除するには、以下を実行します。

    $ odo config unset --env <variable>
  • コンポーネント内のすべての環境変数を一覧表示するには、以下を実行します。

    $ odo config view

3.8. odo CLI の設定

3.8.1. コマンド補完の使用

注記

現時点で、コマンドの補完は bash、zsh、および fish シェルでのみサポートされています。

odo は、ユーザー入力に基づくコマンドパラメーターのスマート補完を提供します。これを機能させるには、odo は実行中のシェルと統合する必要があります。

手順

  • コマンド補完を自動的にインストールするには、以下を実行します。

    1. 以下を実行します。

      $ odo --complete
    2. 補完フックのインストールを求めるプロンプトが出されたら、y を押します。
  • 補完フックを手動でインストールするには、complete -o nospace -C <full_path_to_your_odo_binary> odo をシェル設定ファイルに追加します。シェル設定ファイルを変更したら、シェルを再起動します。
  • 補完を無効にするには、以下を実行します。

    1. 以下を実行します。

      $ odo --uncomplete
    2. 補完フックをアンインストールするようプロンプトされたら y を押します。
注記

odo 実行可能ファイルの名前を変更した場合や、これを別のディレクトリーに移動する場合、コマンド補完を再度有効にします。

3.8.2. ファイルまたはパターンを無視する

アプリケーションのルートディレクトリーにある .odoignore ファイルを変更して、無視するファイルまたはパターンの一覧を設定できます。これは、odo push および odo watch の両方に適用されます。

.odoignore ファイルが存在 しない 場合、特定のファイルおよびフォルダーを無視するように .gitignore ファイルが代わりに使用されます。

.git ファイル、.js 拡張子のあるファイルおよびフォルダー tests を無視するには、以下を .odoignore または .gitignore ファイルのいずれかに追加します。

.git
*.js
tests/

.odoignore ファイルはすべての glob 表現を許可します。

3.9. odo CLI リファレンス

3.9.1. 基本的な odo CLI コマンド

3.9.1.1. app

OpenShift Container Platform プロジェクトに関連するアプリケーション操作を実行します。

app の使用例

  # Delete the application
  odo app delete myapp

  # Describe 'webapp' application,
  odo app describe webapp

  # List all applications in the current project
  odo app list

  # List all applications in the specified project
  odo app list --project myproject

3.9.1.2. catalog

カタログ関連の操作を実行します。

catalog の使用例

  # Get the supported components
  odo catalog list components

  # Get the supported services from service catalog
  odo catalog list services

  # Search for a component
  odo catalog search component python

  # Search for a service
  odo catalog search service mysql

  # Describe a service
  odo catalog describe service mysql-persistent

3.9.1.3. component

アプリケーションのコンポーネントを管理します。

component の使用例

# Create a new component
odo component create

# Create a local configuration and create all objects on the cluster
odo component create --now

3.9.1.4. config

config ファイル内で odo 固有の設定を変更します。

config の使用例

  # For viewing the current local configuration
  odo config view

  # Set a configuration value in the local configuration
  odo config set Type java
  odo config set Name test
  odo config set MinMemory 50M
  odo config set MaxMemory 500M
  odo config set Memory 250M
  odo config set Ignore false
  odo config set MinCPU 0.5
  odo config set MaxCPU 2
  odo config set CPU 1

  # Set an environment variable in the local configuration
  odo config set --env KAFKA_HOST=kafka --env KAFKA_PORT=6639

  # Create a local configuration and apply the changes to the cluster immediately
  odo config set --now

  # Unset a configuration value in the local config
  odo config unset Type
  odo config unset Name
  odo config unset MinMemory
  odo config unset MaxMemory
  odo config unset Memory
  odo config unset Ignore
  odo config unset MinCPU
  odo config unset MaxCPU
  odo config unset CPU

  # Unset an env variable in the local config
  odo config unset --env KAFKA_HOST --env KAFKA_PORT

アプリケーション

Application は、コンポーネントを含める必要のあるアプリケーションの名前になります。

CPU

コンポーネントが使用できる CPU の最小数と最大数

Ignore

プッシュと監視に関連して .odoignore ファイルを考慮します。

表3.2 利用可能なローカルパラメーター:

アプリケーション

コンポーネントを含める必要のあるアプリケーションの名前

CPU

コンポーネントが使用できる CPU の最小数と最大数

Ignore

プッシュおよび監視に関連して .odoignore ファイルを考慮するかどうか

MaxCPU

コンポーネントで使用可能な最大 CPU

MaxMemory

コンポーネントで使用可能な最大メモリー

Memory

コンポーネントで使用できる最小および最大メモリー

MinCPU

コンポーネントで使用できる最小 CPU

MinMemory

コンポーネントに指定される最小メモリー

Name

コンポーネントの名前

Ports

コンポーネントで開くポート

Project

コンポーネントを含めるプロジェクトの名前

Ref

git ソースからコンポーネントを作成するために使用する Git ref

SourceLocation

パスはバイナリーファイルまたは git ソースの場所を示します。

SourceType

コンポーネントソースのタイプ: git/binary/local

Storage

コンポーネントのストレージ

Type

コンポーネントのタイプ

Url

コンポーネントにアクセスするために使用する URL

3.9.1.5. create

OpenShift Container Platform にデプロイするコンポーネントを記述する設定を作成します。コンポーネント名が指定されていない場合、これは自動的に生成されます。

デフォルトで、ビルダーイメージは現在の namespace から使用されます。namespace を明示的に指定するには、odo create namespace/name:version を使用します。バージョンが指定されていない場合、デフォルトは latestに設定されます。

odo catalog list を使用してデプロイできるコンポーネントタイプの詳細一覧を表示します。

create の使用例

  # Create new Node.js component with the source in current directory.
  odo create nodejs

  # Create new Node.js component and push it to the cluster immediately.
  odo create nodejs --now

  # A specific image version may also be specified
  odo create nodejs:latest

  # Create new Node.js component named 'frontend' with the source in './frontend' directory
  odo create nodejs frontend --context ./frontend

  # Create a new Node.js component of version 6 from the 'openshift' namespace
  odo create openshift/nodejs:6 --context /nodejs-ex

  # Create new Wildfly component with binary named sample.war in './downloads' directory
  odo create wildfly wildfly --binary ./downloads/sample.war

  # Create new Node.js component with source from remote git repository
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git

  # Create new Node.js git component while specifying a branch, tag or commit ref
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref master

  # Create new Node.js git component while specifying a tag
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git --ref v1.0.1

  # Create new Node.js component with the source in current directory and ports 8080-tcp,8100-tcp and 9100-udp exposed
  odo create nodejs --port 8080,8100/tcp,9100/udp

  # Create new Node.js component with the source in current directory and env variables key=value and key1=value1 exposed
  odo create nodejs --env key=value,key1=value1

  # Create a new Python component with the source in a Git repository
  odo create python --git https://github.com/openshift/django-ex.git

  # Passing memory limits
  odo create nodejs --memory 150Mi
  odo create nodejs --min-memory 150Mi --max-memory 300 Mi

  # Passing cpu limits
  odo create nodejs --cpu 2
  odo create nodejs --min-cpu 200m --max-cpu 2

3.9.1.6. debug

コンポーネントをデバッグします。

debug の使用例

# Displaying information about the state of debugging
odo debug info

# Starting the port forwarding for a component to debug the application
odo debug port-forward

# Setting a local port to port forward
odo debug port-forward --local-port 9292

3.9.1.7. delete

既存のコンポーネントを削除します。

delete の使用例

  # Delete component named 'frontend'.
  odo delete frontend
  odo delete frontend --all-apps

3.9.1.8. describe

指定のコンポーネントについて説明します。

describe の使用例

  # Describe nodejs component
  odo describe nodejs

3.9.1.10. list

現在のアプリケーションのすべてのコンポーネントとコンポーネントの状態を一覧表示します。

コンポーネントの状態

Pushed
コンポーネントはクラスターにプッシュされています。
Not Pushed
コンポーネントはクラスターにプッシュされていません。
Unknown
odo はクラスターから切断されます。

list の使用例

  # List all components in the application
  odo list

  # List all the components in a given path
  odo list --path <path_to_your_component>

3.9.1.11. log

指定のコンポーネントのログを取得します。

log の使用例

  # Get the logs for the nodejs component
  odo log nodejs

3.9.1.12. login

クラスターにログインします。

login の使用例

  # Log in interactively
  odo login

  # Log in to the given server with the given certificate authority file
  odo login localhost:8443 --certificate-authority=/path/to/cert.crt

  # Log in to the given server with the given credentials (basic auth)
  odo login localhost:8443 --username=myuser --password=mypass

  # Log in to the given server with the given credentials (token)
  odo login localhost:8443 --token=xxxxxxxxxxxxxxxxxxxxxxx

3.9.1.13. logout

現在の OpenShift Container Platform セッションからログアウトします。

logout の使用例

  # Log out
  odo logout

3.9.1.14. preference

グローバル設定ファイル内の odo 固有の設定内容を変更します。

preference の使用例

  # For viewing the current preferences
  odo preference view

  # Set a preference value in the global preference
  odo preference set UpdateNotification false
  odo preference set NamePrefix "app"
  odo preference set Timeout 20

  # Enable experimental mode
  odo preference set experimental true

  # Unset a preference value in the global preference
  odo preference unset  UpdateNotification
  odo preference unset  NamePrefix
  odo preference unset  Timeout

  # Disable experimental mode
  odo preference set experimental false

  # Use persistent volumes in the cluster
  odo preference set ephemeral false

注記

デフォルトで、グローバル設定ファイルへのパスは ~/.odo/preferece.yaml であり、これは環境変数 GLOBALODOCONFIG に保存されます。環境変数の値を新規の設定パスに設定し、カスタムパスをセットアップできます (例: GLOBALODOCONFIG="new_path/preference.yaml")。

表3.3 利用可能なパラメーター:

NamePrefix

デフォルトのプレフィックスは、現在のディレクトリー名です。この値を使用して、デフォルトの名前のプレフィックスを設定します。

Timeout

OpenShift Container Platform サーバー接続チェックのタイムアウト (秒単位) です。

UpdateNotification

更新通知が表示されるかどうかを制御します。

3.9.1.15. project

プロジェクト操作を実行します。

project の使用例

  # Set the active project
  odo project set

  # Create a new project
  odo project create myproject

  # List all the projects
  odo project list

  # Delete a project
  odo project delete myproject

  # Get the active project
  odo project get

3.9.1.16. push

ソースコードをコンポーネントにプッシュします。

push の使用例

  # Push source code to the current component
  odo push

  # Push data to the current component from the original source.
  odo push

  # Push source code in ~/mycode to component called my-component
  odo push my-component --context ~/mycode

  # Push source code and display event notifications in JSON format.
  odo push -o json

3.9.1.17. registry

カスタムレジストリーを作成し、変更します。

registry の使用例

# Add a registry to the registry list
odo registry add <registry name> <registry URL>

# List a registry in the registry list
odo registry list

# Delete a registry from the registry list
odo registry delete <registry name>

# Update a registry in the registry list
odo registry update <registry name> <registry URL>

# List a component with a corresponding registry
odo catalog list components

# Create a component that is hosted by a specific registry
odo create <component type> --registry <registry name>

3.9.1.18. service

サービスカタログ操作を実行します。

service の使用例

  # Create new postgresql service from service catalog using dev plan and name my-postgresql-db.
  odo service create dh-postgresql-apb my-postgresql-db --plan dev -p postgresql_user=luke -p postgresql_password=secret

  # Delete the service named 'mysql-persistent'
  odo service delete mysql-persistent

  # List all services in the application
  odo service list

3.9.1.19. storage

ストレージ操作を実行します。

storage の使用例

  # Create storage of size 1Gb to a component
  odo storage create mystorage --path=/opt/app-root/src/storage/ --size=1Gi

  # Delete storage mystorage from the currently active component
  odo storage delete mystorage

  # List all storage attached or mounted to the current component and
  # all unattached or unmounted storage in the current application
  odo storage list

  # Set the `-o json` flag to get a JSON formatted output
  odo storage list -o json

3.9.1.21. update

コンポーネントのソースコードパスを更新します。

update の使用例

  # Change the source code path of a currently active component to local (use the current directory as a source)
  odo update --local

  # Change the source code path of the frontend component to local with source in ./frontend directory
  odo update frontend --local ./frontend

  # Change the source code path of a currently active component to git
  odo update --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named node-ex to git
  odo update node-ex --git https://github.com/openshift/nodejs-ex.git

  # Change the source code path of the component named wildfly to a binary named sample.war in ./downloads directory
  odo update wildfly --binary ./downloads/sample.war

3.9.1.22. url

コンポーネントを外部に公開します。

url の使用例

  # Create a URL for the current component with a specific port
  odo url create --port 8080

  # Create a URL with a specific name and port
  odo url create example --port 8080

  # Create a URL with a specific name by automatic detection of port (only for components which expose only one service port)
  odo url create example

  # Create a URL with a specific name and port for component frontend
  odo url create example --port 8080 --component frontend

  # Delete a URL to a component
  odo url delete myurl

  # List the available URLs
  odo url list

  # Create a URL in the configuration and apply the changes to the cluster
  odo url create --now

  # Create an HTTPS URL
  odo url create --secure

このコマンドを使用して生成される URL は、クラスター外からデプロイされたコンポーネントにアクセスするために使用できます。

3.9.1.23. utils

ターミナルコマンドのユーティリティーおよび odo 設定の変更

utils の使用例

  # Bash terminal PS1 support
  source <(odo utils terminal bash)

  # Zsh terminal PS1 support
  source <(odo utils terminal zsh)

3.9.1.24. version

クライアントバージョンの情報を出力します。

version の使用例

  # Print the client version of odo
  odo version

3.9.1.25. watch

odo は変更の有無の監視を開始し、変更時にコンポーネントを自動的に更新します。

watch の使用例

  # Watch for changes in directory for current component
  odo watch

  # Watch for changes in directory for component called frontend
  odo watch frontend

3.10. odo アーキテクチャー

このセクションでは、odo アーキテクチャーについて説明し、odo によるリソースのクラスターでの管理方法について説明します。

3.10.1. 開発者の設定

odo を使用すると、ターミナルを使って OpenShift Container Platform クラスターでアプリケーションを作成し、デプロイできます。コードエディタープラグインは、ユーザーがそれぞれの IDE ターミナルから OpenShift Container Platform クラスターと対話することを可能にする odo を使用します。odo を使用するプラグインの例: VS Code Openshift Connector、OpenShift Connector for Intellij、Codewind for Eclipse Che。

odo は Windows、macOS、および Linux のオペレーティングシステムで機能し、すべてのターミナルから使用できます。odo は bash および zsh コマンドラインシェルの自動補完を提供します。

odo は Node.js および Java コンポーネントをサポートします。

3.10.2. OpenShift Source-to-Image (S2I)

OpenShift Source-to-Image (S2I) はオープンソースプロジェクトであり、ソースコードからアーティファクトをビルドし、これらをコンテナーイメージに挿入するのに役立ちます。S2I は、Dockerfile なしにソースコードをビルドすることで、実行可能なイメージを生成します。odo は、コンテナー内で開発者ソースコードを実行するために S2I ビルダーイメージを使用します。

3.10.3. OpenShift クラスターオブジェクト

3.10.3.1. Init コンテナー

init コンテナーはアプリケーションコンテナーが起動する前に実行される特殊なコンテナーであり、アプリケーションコンテナーの実行に必要な環境を設定します。init コンテナーには、アプリケーションイメージにないファイル (設定スクリプトなど) を含めることができます。Init コンテナーは常に完了するまで実行され、Init コンテナーのいずれかに障害が発生した場合にはアプリケーションコンテナーは起動しません。

odo によって作成された Pod は 2 つの Init コンテナーを実行します。

  • copy-supervisord Init コンテナー。
  • copy-files-to-volume Init コンテナー。
3.10.3.1.1. copy-supervisord

copy-supervisord Init コンテナーは必要なファイルを emptyDir ボリュームにコピーします。メインのアプリケーションコンテナーはこれらのファイルを emptyDir ボリュームから使用します。

emptyDir ボリュームにコピーされるファイル:

  • バイナリー:

    • go-init は最小限の init システムです。アプリケーションコンテナー内の最初のプロセス (PID 1) として実行されます。go-init は、開発者コードを実行する SupervisorD デーモンを起動します。go-init は、孤立したプロセスを処理するために必要です。
    • SupervisorD はプロセス制御システムです。これは設定されたプロセスを監視し、それらが実行中であることを確認します。また、必要に応じてサービスを再起動します。odo の場合、SupervisorD は開発者コードを実行し、監視します。
  • 設定ファイル:

    • supervisor.conf は、SupervisorD デーモンの起動に必要な設定ファイルです。
  • スクリプト:

    • assemble-and-restart は、ユーザーソースコードをビルドし、デプロイするための OpenShift S2I の概念です。assemble-and-restart スクリプトは、まずアプリケーションコンテナー内でユーザーソースコードをアセンブルしてから、ユーザーの変更を有効にするために SupervisorD を再起動します。
    • Run は、アセンブルされたソースコードを実行することに関連した OpenShift S2I の概念です。run スクリプトは assemble-and-restart スクリプトで作成されたアセンブルされたコードを実行します。
    • s2i-setup は、assemble-and-restart および run スクリプトが正常に実行されるために必要なファイルおよびディレクトリーを作成するスクリプトです。このスクリプトは、アプリケーションのコンテナーが起動されるたびに実行されます。
  • ディレクトリー:

    • language-scripts: OpenShift S2I はカスタムの assemble および run スクリプトを許可します。language-scripts ディレクトリーにいくつかの言語固有のカスタムスクリプトがあります。カスタムスクリプトは、odo のデバッグを機能させる追加の設定を提供します。

emtpyDir ボリュームは、Init コンテナーとアプリケーションコンテナーの両方の /opt/odo マウントポイントにマウントされます。

3.10.3.1.2. copy-files-to-volume

copy-files-to-volume Init コンテナーは、S2I ビルダーイメージの /opt/app-root にあるファイルを永続ボリュームにコピーします。次に、ボリュームはアプリケーションコンテナーの同じ場所 (/opt/app-root) にマウントされます。

永続ボリュームが /opt/app-root にないと、このディレクトリーのデータは、永続ボリューム要求 (PVC) が同じ場所にマウントされる際に失われます。

PVC は、Init コンテナー内の /mnt マウントポイントにマウントされます。

3.10.3.2. アプリケーションコンテナー

アプリケーションコンテナーは、ユーザーソースコードが実行されるメインコンテナーです。

アプリケーションコンテナーは、以下の 2 つのボリュームでマウントされます。

  • emptyDir ボリュームは /opt/odo にマウントされます。
  • 永続ボリュームは /opt/app-root にマウントされます。

go-init はアプリケーションコンテナー内の最初のプロセスとして実行されます。次に、go-init プロセスは SupervisorD を起動します。

SupervisorD は、ユーザーのアセンブルされたソースコードを実行し、監視します。ユーザープロセスがクラッシュすると、SupervisorD がこれを再起動します。

3.10.3.3. 永続ボリュームおよび永続ボリューム要求 (PVC)

永続ボリューム要求 (PVC) は、永続ボリュームをプロビジョニングする Kubernetes のボリュームタイプです。永続ボリュームのライフサイクルは Pod ライフサイクルとは異なります。永続ボリュームのデータは Pod の再起動後も永続します。

copy-files-to-volume Init コンテナーは、必要なファイルを永続ボリュームにコピーします。メインアプリケーションコンテナーは、実行時にこれらのファイルを使用します。

永続ボリュームの命名規則は <component_name>-s2idata です。

コンテナーPVC のマウント先

copy-files-to-volume

/mnt

アプリケーションコンテナー

/opt/app-root

3.10.3.4. emptyDir ボリューム

emptyDir ボリュームは、Pod がノードに割り当てられている際に作成され、Pod がノードで実行されている限り存在します。コンテナーが再起動または移動すると、emptyDir の内容は削除され、Init コンテナーはデータを emptyDir に復元します。emptyDir の初期状態は空です。

copy-supervisord Init コンテナーは必要なファイルを emptyDir ボリュームにコピーします。これらのファイルは、実行時にメインアプリケーションコンテナーによって使用されます。

コンテナーemptyDir volume のマウント先

copy-supervisord

/opt/odo

アプリケーションコンテナー

/opt/odo

3.10.3.5. サービス

サービスは、一連の Pod と通信する方法を抽象化する Kubernetes の概念です。

odo はすべてのアプリケーション Pod についてサービスを作成し、これを通信用にアクセス可能にします。

3.10.4. odo push のワークフロー

このセクションでは、odo push ワークフローについて説明します。odo push は必要なすべての OpenShift Container Platform リソースを使って OpenShift Container Platform クラスターにユーザーコードをデプロイします。

  1. リソースの作成

    まだ作成されていない場合には、odo push は以下の OpenShift Container Platform リソースを作成します。

    • DeploymentConfig オブジェクト:

      • 2 つの init コンテナー copy-supervisord および copy-files-to-volume が実行されます。init コンテナーはファイルを emptyDirPersistentVolume タイプのボリュームのそれぞれにコピーします。
      • アプリケーションコンテナーが起動します。アプリケーションコンテナーの最初のプロセスは、PID=1 の go-init プロセスです。
      • go-init プロセスは SupervisorD デーモンを起動します。

        注記

        ユーザーアプリケーションコードはアプリケーションコンテナーにコピーされていないため、SupervisorD デーモンは run スクリプトを実行しません。

    • Service オブジェクト
    • Secret オブジェクト
    • PersistentVolumeClaim オブジェクト
  2. ファイルのインデックス設定

    • ファイルインデックサーは、ソースコードディレクトリーのファイルをインデックス化します。インデックサーはソースコードディレクトリー間を再帰的に移動し、作成、削除、または名前が変更されたファイルを検出します。
    • ファイルインデックサーは、.odo ディレクトリー内の odo インデックスファイルにインデックス化された情報を維持します。
    • odo インデックスファイルが存在しない場合、ファイルインデックサーの初回の実行時であることを意味し、新規の odo インデックス JSON ファイルが作成されます。odo index JSON ファイルにはファイルマップが含まれます。移動したファイルの相対パスと、変更され、削除されたファイルの絶対パスが含まれます。
  3. コードのプッシュ

    ローカルコードは、通常は /tmp/src の下にあるアプリケーションコンテナーにコピーされます。

  4. assemble-and-restart の実行

    ソースコードのコピーに成功すると、assemble-and-restart スクリプトは実行中のアプリケーションコンテナー内で実行されます。

第4章 OpenShift Serverless で使用する Knative CLI (kn)

Knative kn CLI は、OpenShift Container Platform の Knative コンポーネントとの簡単な対話を有効にします。

OpenShift Serverless をインストールして、OpenShift Container Platform で Knative を有効にすることができます。詳細は、OpenShift Serverless の使用開始について参照してください。

注記

OpenShift Serverless は kn CLI を使用してインストールできません。クラスター管理者は、OpenShift Container Platform の Serverless アプリケーション についてのドキュメントで説明されているように OpenShift Serverless Operator をインストールし、Knative コンポーネントをセットアップする必要があります。

4.1. 主な特長

kn CLI は、サーバーレスコンピューティングタスクを単純かつ簡潔にするように設計されています。kn CLI の主な機能には、以下が含まれます。

  • コマンドラインからサーバーレスアプリケーションをデプロイします。
  • サービス、リビジョン、およびトラフィック分割などの Knative Serving の機能を管理します。
  • イベントソースおよびトリガーなどの Knative Eventing コンポーネントを作成し、管理します。
  • 既存の Kubernetes アプリケーションおよび Knative サービスを接続するために、sink binding を作成します。
  • kubectl CLI と同様に、柔軟性のあるプラグインアーキテクチャーで kn CLI を拡張します。
  • Knative サービスの自動スケーリングパラメーターを設定します。
  • 操作の結果を待機したり、カスタムロールアウトおよびロールバックストラテジーのデプロイなどのスクリプト化された使用。

4.2. Knative CLI のインストール

Knative CLI のインストールについて参照してください。

第5章 Pipelines CLI (tkn)

5.1. tkn のインストール

tkn CLI を使用して、ターミナルから Red Hat OpenShift Pipeline を管理します。以下のセクションでは、各種の異なるプラットフォームに tkn をインストールする方法を説明します。

また、OpenShift Container Platform Web コンソールから最新のバイナリーへの URL を見つけるには、右上隅の ? アイコンをクリックし、Command Line Tools を選択します。

5.1.1. Linux への Red Hat OpenShift Pipelines CLI (tkn) のインストール

Linux ディストリビューションの場合、CLI を tar.gz アーカイブとして直接ダウンロードできます。

手順

  1. 関連する CLI をダウンロードします。

  2. アーカイブを展開します。

    $ tar xvzf <file>
  3. tkn バイナリーを、PATH にあるディレクトリーに配置します。
  4. PATH を確認するには、以下を実行します。

    $ echo $PATH

5.1.2. RPM を使用した Red Hat OpenShift Pipelines CLI (tkn) の Linux へのインストール

Red Hat Enterprise Linux (RHEL) バージョン 8 の場合は、Red Hat OpenShift Pipelines CLI (tkn) を RPM としてインストールできます。

前提条件

  • お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがある。
  • ローカルシステムに root または sudo 権限がある。

手順

  1. Red Hat Subscription Manager に登録します。

    # subscription-manager register
  2. 最新のサブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションを一覧表示します。

    # subscription-manager list --available --matches '*pipelines*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これを登録されたシステムにアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Red Hat OpenShift Pipelines で必要なリポジトリーを有効にします。

    • Linux (x86_64, amd64)

      # subscription-manager repos --enable="pipelines-1.5-for-rhel-8-x86_64-rpms"
    • Linux on IBM Z and LinuxONE (s390x)

      # subscription-manager repos --enable="pipelines-1.5-for-rhel-8-s390x-rpms"
    • Linux on IBM Power Systems (ppc64le)

      # subscription-manager repos --enable="pipelines-1.5-for-rhel-8-ppc64le-rpms"
  6. openshift-pipelines-client パッケージをインストールします。

    # yum install openshift-pipelines-client

CLI のインストール後は、tkn コマンドを使用して利用できます。

$ tkn version

5.1.3. Windows への Red Hat OpenShift Pipelines CLI (tkn) のインストール

Windows の場合、tkn CLI は zip アーカイブとして提供されます。

手順

  1. CLIのダウンロード
  2. ZIP プログラムでアーカイブを解凍します。
  3. tkn.exe ファイルの場所を、 PATH 環境変数に追加します。
  4. PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

    C:\> path

5.1.4. macOS への Red Hat OpenShift Pipelines CLI (tkn) のインストール

macOS の場合、tkn CLI は tar.gz アーカイブとして提供されます。

手順

  1. CLIのダウンロード
  2. アーカイブを展開し、解凍します。
  3. tkn バイナリーをパスにあるディレクトリーに移動します。
  4. PATH を確認するには、ターミナルウィンドウを開き、以下を実行します。

    $ echo $PATH

5.2. OpenShift Pipelines tkn CLI の設定

タブ補完を有効にするために Red Hat OpenShift Pipelines tkn CLI を設定します。

5.2.1. タブ補完の有効化

tkn CLI ツールをインストールした後に、タブ補完を有効にして tkn コマンドの自動補完を実行するか、または Tab キーを押す際にオプションの提案が表示されるようにできます。

前提条件

  • tkn CLI ツールをインストールしていること。
  • ローカルシステムに bash-completion がインストールされていること。

手順

以下の手順では、Bash のタブ補完を有効にします。

  1. Bash 補完コードをファイルに保存します。

    $ tkn completion bash > tkn_bash_completion
  2. ファイルを /etc/bash_completion.d/ にコピーします。

    $ sudo cp tkn_bash_completion /etc/bash_completion.d/

    または、ファイルをローカルディレクトリーに保存した後に、これを .bashrc ファイルから取得できるようにすることができます。

タブ補完は、新規ターミナルを開くと有効にされます。

5.3. OpenShift Pipelines tkn リファレンス

このセクションでは、基本的な tkn CLI コマンドの一覧を紹介します。

5.3.1. 基本的な構文

tkn [command or options] [arguments…​]

5.3.2. グローバルオプション

--help, -h

5.3.3. ユーティリティーコマンド

5.3.3.1. tkn

tkn CLI の親コマンド。

例: すべてのオプションの表示

$ tkn

5.3.3.2. completion [shell]

インタラクティブな補完を提供するために評価する必要があるシェル補完コードを出力します。サポートされるシェルは bash および zsh です。

例: bash シェルの補完コード

$ tkn completion bash

5.3.3.3. version

tkn CLI のバージョン情報を出力します。

例: tkn バージョンの確認

$ tkn version

5.3.4. Pipelines 管理コマンド

5.3.4.1. pipeline

パイプラインの管理

例: ヘルプの表示

$ tkn pipeline --help

5.3.4.2. pipeline delete

パイプラインの削除

例ネームスペースからのmypipelineパイプラインの削除

$ tkn pipeline delete mypipeline -n myspace

5.3.4.3. pipeline describe

パイプラインについて説明します。

mypipelineパイプラインを記述する

$ tkn pipeline describe mypipeline

5.3.4.4. pipeline list

パイプラインの一覧を表示します。

例パイプラインの一覧を表示する

$ tkn pipeline list

5.3.4.5. pipeline logs

特定のパイプラインのログを表示します。

mypipelineパイプラインのライブログをストリーミング再生する

$ tkn pipeline logs -f mypipeline

5.3.4.6. pipeline start

パイプラインを開始します。

mypipelineパイプラインの起動

$ tkn pipeline start mypipeline

5.3.5. パイプラインの実行コマンド

5.3.5.1. pipelinerun

パイプラインの実行を管理します。

例: ヘルプの表示

$ tkn pipelinerun -h

5.3.5.2. pipelinerun cancel

パイプラインの実行をキャンセルします。

例ネームスペースから実行されるmypipelinerunパイプラインのキャンセル

$ tkn pipelinerun cancel mypipelinerun -n myspace

5.3.5.3. pipelinerun delete

パイプラインの実行を削除します。

例名前空間から実行されるパイプラインの削除

$ tkn pipelinerun delete mypipelinerun1 mypipelinerun2 -n myspace

例最近実行された5つのパイプライン・ランを除く、すべてのパイプライン・ランをネームスペースから削除する

$ tkn pipelinerun delete -n myspace --keep 5 1

1
5は、保持したい直近に実行されたパイプラインランの数に置き換えてください。

5.3.5.4. pipelinerun describe

パイプライン・ランについて説明します。

例ネームスペースで実行されるmypipelinerunのパイプラインを記述する

$ tkn pipelinerun describe mypipelinerun -n myspace

5.3.5.5. pipelinerun list

パイプラインの実行を一覧表示します。

例名前空間でのパイプライン実行のリストを表示する

$ tkn pipelinerun list -n myspace

5.3.5.6. pipelinerun logs

パイプライン実行時のログを表示します。

例ネームスペース内のすべてのタスクとステップで実行されたmypipelinerunパイプラインのログを表示する

$ tkn pipelinerun logs mypipelinerun -a -n myspace

5.3.6. タスク管理コマンド

5.3.6.1. task

タスクを管理する。

例: ヘルプの表示

$ tkn task -h

5.3.6.2. task delete

タスクを削除します。

例ネームスペースからmytask1mytask2のタスクを削除する

$ tkn task delete mytask1 mytask2 -n myspace

5.3.6.3. task describe

タスクを説明する。

例名前空間にmytaskタスクを記述する

$ tkn task describe mytask -n myspace

5.3.6.4. task list

タスクをリストアップします。

例ネームスペース内のすべてのタスクをリストアップする

$ tkn task list -n myspace

5.3.6.5. task logs

タスクログを表示します。

例を示します。mytaskタスクのmytaskrunタスク実行時のログ表示

$ tkn task logs mytask mytaskrun -n myspace

5.3.6.6. task start

タスクを開始します。

例名前空間でのmytaskタスクの開始

$ tkn task start mytask -s <ServiceAccountName> -n myspace

5.3.7. タスク実行コマンド

5.3.7.1. taskrun

タスクの実行を管理します。

例: ヘルプの表示

$ tkn taskrun -h

5.3.7.2. taskrun cancel

タスク実行をキャンセルします。

例名前空間から実行されるmytaskrunタスクのキャンセル

$ tkn taskrun cancel mytaskrun -n myspace

5.3.7.3. taskrun delete

TaskRun を削除します。

例ネームスペースからmytaskrun1mytaskrun2のタスクランを削除する

$ tkn taskrun delete mytaskrun1 mytaskrun2 -n myspace

例名前空間から最近実行された5つのタスクランを除くすべてのタスクランを削除する

$ tkn taskrun delete -n myspace --keep 5 1

1
5は、保持したい直近に実行されたタスクランの数に置き換えてください。

5.3.7.4. taskrun describe

タスクの実行について説明します。

例名前空間で実行されるmytaskrunタスクを記述する

$ tkn taskrun describe mytaskrun -n myspace

5.3.7.5. taskrun list

タスクの実行を一覧表示します。

例ネームスペース内のすべてのタスク実行をリストアップする

$ tkn taskrun list -n myspace

5.3.7.6. taskrun logs

タスクの実行ログを表示します。

例ネームスペースで実行されるmytaskrunタスクのライブログを表示する

$ tkn taskrun logs -f mytaskrun -n myspace

5.3.8. 条件管理コマンド

5.3.8.1. condition

条件を管理します。

例: ヘルプの表示

$ tkn condition --help

5.3.8.2. condition delete

条件を削除します。

例: namespace からの mycondition1 条件の削除

$ tkn condition delete mycondition1 -n myspace

5.3.8.3. condition describe

条件を記述します。

例: namespace での mycondition1 条件の記述

$ tkn condition describe mycondition1 -n myspace

5.3.8.4. condition list

条件を一覧表示します。

例: namespace での条件の一覧表示

$ tkn condition list -n myspace

5.3.9. Pipeline リソース管理コマンド

5.3.9.1. resource

Pipeline リソースを管理します。

例: ヘルプの表示

$ tkn resource -h

5.3.9.2. resource create

Pipeline リソースを作成します。

例: namespace での Pipeline リソースの作成

$ tkn resource create -n myspace

これは、リソースの名前、リソースのタイプ、およびリソースのタイプに基づく値の入力を要求するインタラクティブなコマンドです。

5.3.9.3. resource delete

Pipeline リソースを削除します。

例: namespace から myresource Pipeline リソースを削除します。

$ tkn resource delete myresource -n myspace

5.3.9.4. resource describe

Pipeline リソースを記述します。

例: myresource Pipeline リソースの記述

$ tkn resource describe myresource -n myspace

5.3.9.5. resource list

Pipeline リソースを一覧表示します。

例: namespace のすべての Pipeline リソースの一覧表示

$ tkn resource list -n myspace

5.3.10. ClusterTask 管理コマンド

5.3.10.1. clustertask

ClusterTask を管理します。

例: ヘルプの表示

$ tkn clustertask --help

5.3.10.2. clustertask delete

クラスターの ClusterTask リソースを削除します。

例: mytask1 および mytask2 ClusterTask の削除

$ tkn clustertask delete mytask1 mytask2

5.3.10.3. clustertask describe

ClusterTask を記述します。

例: mytask ClusterTask の記述

$ tkn clustertask describe mytask1

5.3.10.4. clustertask list

ClusterTask を一覧表示します。

例: ClusterTask の一覧表示

$ tkn clustertask list

5.3.10.5. clustertask start

ClusterTask を開始します。

例: mytask ClusterTask の開始

$ tkn clustertask start mytask

5.3.11. 管理コマンドのトリガー

5.3.11.1. eventlistener

EventListener を管理します。

例: ヘルプの表示

$ tkn eventlistener -h

5.3.11.2. eventlistener delete

EventListener を削除します。

例: namespace の mylistener1 および mylistener2 EventListener の削除

$ tkn eventlistener delete mylistener1 mylistener2 -n myspace

5.3.11.3. eventlistener describe

EventListener を記述します。

例: namespace の mylistener EventListener の記述

$ tkn eventlistener describe mylistener -n myspace

5.3.11.4. eventlistener list

EventListener を一覧表示します。

例: namespace のすべての EventListener の一覧表示

$ tkn eventlistener list -n myspace

5.3.11.5. eventlistener ログ

EventListener のログを表示します。

例: namespace の mylistener EventListener のログ表示

$ tkn eventlistener logs mylistener -n myspace

5.3.11.6. triggerbinding

TriggerBinding を管理します。

例: TriggerBindings ヘルプの表示

$ tkn triggerbinding -h

5.3.11.7. triggerbinding delete

TriggerBinding を削除します。

例: namespace の mybinding1 および mybinding2 TriggerBinding の削除

$ tkn triggerbinding delete mybinding1 mybinding2 -n myspace

5.3.11.8. triggerbinding describe

TriggerBinding を記述します。

例: namespace の mybinding TriggerBinding の記述

$ tkn triggerbinding describe mybinding -n myspace

5.3.11.9. triggerbinding list

TriggerBinding を一覧表示します。

例: namespace のすべての TriggerBinding の一覧表示

$ tkn triggerbinding list -n myspace

5.3.11.10. triggertemplate

TriggerTemplate を管理します。

例: TriggerTemplate ヘルプの表示

$ tkn triggertemplate -h

5.3.11.11. triggertemplate delete

TriggerTemplate を削除します。

例: namespace の mytemplate1 および mytemplate2 TriggerTemplate の削除

$ tkn triggertemplate delete mytemplate1 mytemplate2 -n `myspace`

5.3.11.12. triggertemplate describe

TriggerTemplate を記述します。

例: namespace の mytemplate TriggerTemplate の記述

$ tkn triggertemplate describe mytemplate -n `myspace`

5.3.11.13. triggertemplate list

TriggerTemplate を一覧表示します。

例: namespace のすべての TriggerTemplate の一覧表示

$ tkn triggertemplate list -n myspace

5.3.11.14. clustertriggerbinding

ClusterTriggerBinding を管理します。

例: ClusterTriggerBinding のヘルプの表示

$ tkn clustertriggerbinding -h

5.3.11.15. clustertriggerbinding delete

ClusterTriggerBinding を削除します。

例: myclusterbinding1 および myclusterbinding2 ClusterTriggerBinding の削除

$ tkn clustertriggerbinding delete myclusterbinding1 myclusterbinding2

5.3.11.16. clustertriggerbinding describe

ClusterTriggerBinding を記述します。

例: myclusterbinding ClusterTriggerBinding の記述

$ tkn clustertriggerbinding describe myclusterbinding

5.3.11.17. clustertriggerbinding list

ClusterTriggerBinding の一覧を表示します。

例: すべての ClusterTriggerBinding の一覧表示

$ tkn clustertriggerbinding list

5.3.12. hub 対話コマンド

タスクやパイプラインなど、リソースの Tekton Hub と対話します。

5.3.12.1. hub

ハブと対話します。

例: ヘルプの表示

$ tkn hub -h

例: ハブ API サーバーとの対話

$ tkn hub --api-server https://api.hub.tekton.dev

注記

それぞれの例で、対応するサブコマンドとフラグを取得するには、tkn hub <command> --help を実行します。

5.3.12.2. hub downgrade

インストール済みのリソースをダウングレードします。

例: mynamespace namespace の mytask タスクを古いバージョンにダウングレードします。

$ tkn hub downgrade task mytask --to version -n mynamespace

5.3.12.3. hub get

名前、種類、カタログ、およびバージョン別に、リソースマニフェストを取得します。

例: tekton カタログからの特定バージョンの myresource パイプラインまたはタスクのマニフェスト取得

$ tkn hub get [pipeline | task] myresource --from tekton --version version

5.3.12.4. hub info

名前、種類、カタログ、およびバージョン別に、リソースに関する情報を表示します。

例: tekton カタログからの特定バージョンの mytask タスクについての情報表示

$ tkn hub info task mytask --from tekton --version version

5.3.12.5. hub install

種類、名前、バージョンごとにカタログからのリソースをインストールします。

例: mynamespace namespace の tekton カタログから mytask タスクの特定のバージョンのインストール

$ tkn hub install task mytask --from tekton --version version -n mynamespace

5.3.12.6. hub reinstall

種類および名前ごとにリソースを再インストールします。

例: mynamespace namespace の tekton カタログから mytask タスクの特定のバージョンの再インストール

$ tkn hub reinstall task mytask --from tekton --version version -n mynamespace

5.3.12.8. hub upgrade

インストール済みのリソースをアップグレードします。

例: mynamespace namespace のインストールされた mytask タスクの新規バージョンへのアップグレード

$ tkn hub upgrade task mytask --to version -n mynamespace

第6章 opm CLI

6.1. opm について

opm CLI ツールは、Operator Bundle Format で使用するために Operator Framework によって提供されます。このツールを使用して、ソフトウェアリポジトリーに相当する index と呼ばれるバンドルの一覧から Operator のカタログを作成し、維持することができます。結果として、インデックスイメージ というコンテナーイメージをコンテナーレジストリーに保存し、その後にクラスターにインストールできます。

インデックスには、コンテナーイメージの実行時に提供される組み込まれた API を使用してクエリーできる、Operator マニフェストコンテンツへのポインターのデータベースが含まれます。OpenShift Container Platform では、Operator Lifecycle Manager (OLM) はインデックスイメージを CatalogSource オブジェクトで参照し、これをカタログとして使用できます。これにより、クラスター上にインストールされた Operator への頻度の高い更新を可能にするためにイメージを一定の間隔でポーリングできます。

追加リソース

6.2. opm のインストール

opm CLI ツールは、Linux、macOS、または Windows ワークステーションにインストールできます。

前提条件

  • Linux の場合は、以下のパッケージを指定する必要があります。RHEL 8 は、以下の要件を満たすようにします。

    • podman バージョン 1.9.3 以降 (バージョン 2.0 以降を推奨)
    • glibc バージョン 2.28 以降

手順

  1. OpenShiftのミラーサイトに移動し、お使いのOSに合った最新版のtarballをダウンロードします。
  2. アーカイブを展開します。

    • Linux または macOS の場合:

      $ tar xvf <file>
    • Windows の場合、ZIP プログラムでアーカイブを解凍します。
  3. ファイルを PATH の任意の場所に置きます。

    • Linux または macOS の場合:

      1. PATH を確認します。

        $ echo $PATH
      2. ファイルを移動します。以下は例になります。

        $ sudo mv ./opm /usr/local/bin/
    • Windows の場合:

      1. PATH を確認します。

        C:\> path
      2. ファイルを移動します。

        C:\> move opm.exe <directory>

検証

  • opm CLI のインストール後に、これが利用可能であることを確認します。

    $ opm version

    出力例

    Version: version.Version{OpmVersion:"v1.15.4-2-g6183dbb3", GitCommit:"6183dbb3567397e759f25752011834f86f47a3ea", BuildDate:"2021-02-13T04:16:08Z", GoOs:"linux", GoArch:"amd64"}

6.3. 追加リソース

  • インデックスイメージの作成、更新、プルーニングを含む opm の手順は、「カスタムカタログの管理」を参照してください。

第7章 Operator SDK

7.1. Operator SDK CLI のインストール

Operator SDK は、Operator 開発者が Operator のビルド、テストおよびデプロイに使用できるコマンドラインインターフェース (CLI) ツールを提供します。ワークステーションに Operator SDK CLI をインストールして、独自の Operator のオーサリングを開始することができます。

Operator SDK についての詳細は、Operator の開発について参照してください。

注記

OpenShift Container Platform 4.8 以降は Operator SDK v1.8.0 をサポートします。

7.1.1. Operator SDK CLI のインストール

OpenShift SDK CLI ツールは Linux にインストールできます。

前提条件

  • Go v1.16+
  • docker v17.03+、podman v1.9.3+、または buildah v1.7+

手順

  1. OpenShift のミラーサイトに移動します。
  2. 4.8.4ディレクトリから、Linux用の最新版のtarballをダウンロードします。
  3. アーカイブを展開します。

    $ tar xvf operator-sdk-v1.8.0-ocp-linux-x86_64.tar.gz
  4. ファイルを実行可能にします。

    $ chmod +x operator-sdk
  5. 展開された operator-sdk バイナリーを PATH にあるディレクトリーに移動します。

    ヒント

    PATH を確認するには、以下を実行します。

    $ echo $PATH
    $ sudo mv ./operator-sdk /usr/local/bin/operator-sdk

検証

  • Operator SDK CLI のインストール後に、これが利用可能であることを確認します。

    $ operator-sdk version

    出力例

    operator-sdk version: "v1.8.0-ocp", ...

7.2. Operator SDK CLI リファレンス

Operator SDK コマンドラインインターフェース (CLI) は、Operator の作成を容易にするために設計された開発キットです。

Operator SDK CLI 構文

$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]

Kubernetes ベースのクラスター (OpenShift Container Platform など) へのクラスター管理者のアクセスのある Operator の作成者は、Operator SDK CLI を使用して Go、Ansible、または Helm をベースに独自の Operator を開発できます。Kubebuilder は Go ベースの Operator のスキャフォールディングソリューションとして Operator SDK に組み込まれます。つまり、既存の Kubebuilder プロジェクトは Operator SDK でそのまま使用でき、引き続き機能します。

Operator SDK についての詳細は、Operator の開発について参照してください。

7.2.1. bundle

operator-sdk bundle コマンドは Operator バンドルメタデータを管理します。

7.2.1.1. validate

bundle validate サブコマンドは Operator バンドルを検証します。

表7.1 bundle validate フラグ

フラグ説明

-h, --help

bundle validate サブコマンドのヘルプ出力。

--index-builder (文字列)

バンドルイメージをプルおよび展開するためのツール。バンドルイメージを検証する場合にのみ使用されます。使用できるオプションは、docker (デフォルト)、podman、または none です。

--list-optional

利用可能なすべてのオプションのバリデーターを一覧表示します。これが設定されている場合、バリデーターは実行されません。

--select-optional (文字列)

実行するオプションのバリデーターを選択するラベルセレクター。--list-optional フラグを指定して実行する場合は、利用可能なオプションのバリデーターを一覧表示します。

7.2.2. cleanup

operator-sdk cleanup コマンドは、run コマンドでデプロイされた Operator 用に作成されたリソースを破棄し、削除します。

表7.2 cleanup フラグ

フラグ説明

-h, --help

run bundle サブコマンドのヘルプ出力。

--kubeconfig (文字列)

CLI 要求に使用する kubeconfig ファイルへのパス。

n, --namespace (文字列)

CLI 要求がある場合の CLI 要求を実行する namespace。

--timeout <duration>

コマンドが失敗せずに完了するまでの待機時間。デフォルト値は 2m0s です。

7.2.3. completion

operator-sdk completion コマンドは、CLI コマンドをより迅速に、より容易に実行できるようにシェル補完を生成します。

表7.3 completion サブコマンド

サブコマンド説明

bash

bash 補完を生成します。

zsh

zsh 補完を生成します。

表7.4 completion フラグ

フラグ説明

-h, --help

使用方法についてのヘルプの出力。

以下は例になります。

$ operator-sdk completion bash

出力例

# bash completion for operator-sdk                         -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh

7.2.4. create

operator-sdk create コマンドは、Kubernetes API の作成または スキャフォールディング に使用されます。

7.2.4.1. api

create api サブコマンドは Kubernetes API をスキャフォールディングします。サブコマンドは、init コマンドで初期化されたプロジェクトで実行する必要があります。

表7.5 create api フラグ

フラグ説明

-h, --help

run bundle サブコマンドのヘルプ出力。

7.2.5. generate

operator-sdk generate コマンドは特定のジェネレーターを起動して、必要に応じてコードを生成します。

7.2.5.1. bundle

generate bundle サブコマンドは、Operator プロジェクトのバンドルマニフェスト、メタデータ、および bundle.Dockerfile ファイルのセットを生成します。

注記

通常は、最初に generate kustomize manifests サブコマンドを実行して、generate bundle サブコマンドで使用される入力された Kustomize ベースを生成します。ただし、初期化されたプロジェクトで make bundle コマンドを使用して、これらのコマンドの順次の実行を自動化できます。

表7.6 generate bundle フラグ

フラグ説明

--channels (文字列)

バンドルが属するチャネルのコンマ区切りリスト。デフォルト値は alpha です。

--crds-dir (文字列)

CustomResoureDefinition マニフェストのルートディレクトリー。

--default-channel (文字列)

バンドルのデフォルトチャネル。

--deploy-dir (文字列)

デプロイメントや RBAC などの Operator マニフェストのルートディレクトリー。このディレクトリーは、--input-dir フラグに渡されるディレクトリーとは異なります。

-h, --help

generate bundle のヘルプ

--input-dir (文字列)

既存のバンドルを読み取るディレクトリー。このディレクトリーは、バンドル manifests ディレクトリーの親であり、--deploy-dir ディレクトリーとは異なります。

--kustomize-dir (文字列)

バンドルマニフェストの Kustomize ベースおよび kustomization.yaml ファイルを含むディレクトリー。デフォルトのパスは config/manifests です。

--manifests

バンドルマニフェストを生成します。

--metadata

バンドルメタデータと Dockerfile を生成します。

--output-dir (文字列)

バンドルを書き込むディレクトリー。

--overwrite

バンドルメタデータおよび Dockerfile を上書きします (ある場合)。デフォルト値は true です。

--package (文字列)

バンドルのパッケージ名。

-q--quiet

quiet モードで実行します。

--stdout

バンドルマニフェストを標準出力に書き込みます。

--version (文字列)

生成されたバンドルの Operator のセマンティックバージョン。新規バンドルを作成するか、または Operator をアップグレードする場合にのみ設定します。

追加リソース

7.2.5.2. kustomize

generate kustomize サブコマンドには、Operator の Kustomize データを生成するサブコマンドが含まれます。

7.2.5.2.1. manifests

generate kustomize manifests は Kustomize ベースを生成または再生成し、kustomization.yaml ファイルを config/manifests ディレクトリーに生成または再生成します。これは、他の Operator SDK コマンドでバンドルマニフェストをビルドするために使用されます。このコマンドは、ベースがすでに存在しない場合や --interactive=false フラグが設定されていない場合に、デフォルトでマニフェストベースの重要なコンポーネントである UI メタデータを対話的に要求します。

表7.7 generate kustomize manifests フラグ

フラグ説明

--apis-dir (文字列)

API タイプ定義のルートディレクトリー。

-h, --help

generate kustomize manifests のヘルプ。

--input-dir (文字列)

既存の Kustomize ファイルを含むディレクトリー。

--interactive

false に設定すると、Kustomize ベースが存在しない場合は、対話式コマンドプロンプトがカスタムメタデータを受け入れるように表示されます。

--output-dir (文字列)

Kustomize ファイルを書き込むディレクトリー。

--package (文字列)

パッケージ名。

-q--quiet

quiet モードで実行します。

7.2.6. init

operator-sdk init コマンドは Operator プロジェクトを初期化し、指定されたプラグインのデフォルトのプロジェクトディレクトリーレイアウトを生成するか、または スキャフォールディング します。

このコマンドは、以下のファイルを作成します。

  • ボイラープレートライセンスファイル
  • ドメインおよびリポジトリーを含む PROJECT ファイル
  • プロジェクトをビルドする Makefile
  • プロジェクト依存関係のある go.mod ファイル
  • マニフェストをカスタマイズするための kustomization.yaml ファイル
  • マネージャーマニフェストのイメージをカスタマイズするためのパッチファイル
  • Prometheus メトリクスを有効にするためのパッチファイル
  • 実行する main.go ファイル

表7.8 init フラグ

フラグ説明

--help, -h

init コマンドのヘルプ出力。

--plugins (文字列)

プロジェクトを初期化するプラグインの名前およびオプションのバージョン。利用可能なプラグインは ansible.sdk.operatorframework.io/v1go.kubebuilder.io/v2go.kubebuilder.io/v3、および helm.sdk.operatorframework.io/v1 です。

--project-version

プロジェクトのバージョン。使用できる値は 2 および 3-alpha (デフォルト) です。

7.2.7. run

operator-sdk run コマンドは、さまざまな環境で Operator を起動できるオプションを提供します。

7.2.7.1. bundle

run bundle サブコマンドは、Operator Lifecycle Manager (OLM) を使用してバンドル形式で Operator をデプロイします。

表7.9 run bundle フラグ

フラグ説明

--index-image (文字列)

バンドルを挿入するインデックスイメージ。デフォルトのイメージは quay.io/operator-framework/upstream-opm-builder:latest です。

--install-mode <install_mode_value>

Operator のクラスターサービスバージョン (CSV) によってサポートされるインストールモード (例: AllNamespaces または SingleNamespace)。

--timeout <duration>

インストールのタイムアウト。デフォルト値は 2m0s です。

--kubeconfig (文字列)

CLI 要求に使用する kubeconfig ファイルへのパス。

n, --namespace (文字列)

CLI 要求がある場合の CLI 要求を実行する namespace。

-h, --help

run bundle サブコマンドのヘルプ出力。

追加リソース

7.2.7.2. bundle-upgrade

run bundle-upgrade サブコマンドは、以前に Operator Lifecycle Manager (OLM) を使用してバンドル形式でインストールされた Operator をアップグレードします。

表7.10 run bundle-upgrade フラグ

フラグ説明

--timeout <duration>

アップグレードのタイムアウト。デフォルト値は 2m0s です。

--kubeconfig (文字列)

CLI 要求に使用する kubeconfig ファイルへのパス。

n, --namespace (文字列)

CLI 要求がある場合の CLI 要求を実行する namespace。

-h, --help

run bundle サブコマンドのヘルプ出力。

7.2.8. scorecard

operator-sdk scorecard コマンドは、スコアカードツールを実行して Operator バンドルを検証し、改善に向けた提案を提供します。このコマンドは、バンドルイメージまたはマニフェストおよびメタデータを含むディレクトリーのいずれかの引数を取ります。引数がイメージタグを保持する場合は、イメージはリモートに存在する必要があります。

表7.11 scorecard フラグ

フラグ説明

-c, --config (文字列)

スコアカード設定ファイルへのパス。デフォルトのパスは bundle/tests/scorecard/config.yaml です。

-h, --help

scorecard コマンドのヘルプ出力。

--kubeconfig (文字列)

kubeconfig ファイルへのパス。

-L, --list

実行可能なテストを一覧表示します。

-n, --namespace (文字列)

テストイメージを実行する namespace。

-o, --output (文字列)

結果の出力形式。使用できる値はデフォルトの text、および json です。

-l, --selector (文字列)

実行されるテストを決定するラベルセレクター。

-s, --service-account (文字列)

テストに使用するサービスアカウント。デフォルト値は default です。

-x, --skip-cleanup

テストの実行後にリソースクリーンアップを無効にします。

-w, --wait-time <duration>

テストが完了するのを待つ秒数 (例: 35s)。デフォルト値は 30s です。

関連情報