This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.3.5. odo CLI リファレンス
3.5.1. odo build-images リンクのコピーリンクがクリップボードにコピーされました!
odo
は Dockerfile に基づいてコンテナーイメージをビルドし、それらのイメージをレジストリーにプッシュできます。
odo build-images
コマンドを実行すると、odo
は image
タイプで devfile.yaml
内のすべてのコンポーネントを検索します。以下に例を示します。
各イメージコンポーネントについて、odo は podman
または docker
(この順序で最初に見つかったもの) を実行し、指定された Dockerfile、ビルドコンテキスト、および引数でイメージをビルドします。
--push
フラグがコマンドに渡されると、イメージはビルド後にレジストリーにプッシュされます。
3.5.2. odo catalog リンクのコピーリンクがクリップボードにコピーされました!
odo
は異なる カタログ を使用して コンポーネント および サービス をデプロイします。
3.5.2.1. コンポーネント リンクのコピーリンクがクリップボードにコピーされました!
odo
は移植可能な devfile 形式を使用してコンポーネントを記述します。さまざまな devfile レジストリーに接続して、さまざまな言語およびフレームワークの devfile をダウンロードできます。詳細は、odo registry
を参照してください。
3.5.2.1.1. コンポーネントの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
異なるレジストリーで利用可能な devfile の一覧を表示するには、以下のコマンドを実行します。
odo catalog list components
$ odo catalog list components
出力例
3.5.2.1.2. コンポーネントに関する情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
特定のコンポーネントに関する詳細情報を取得するには、以下のコマンドを実行します。
odo catalog describe component
$ odo catalog describe component
たとえば、以下のコマンドを実行します。
odo catalog describe component nodejs
$ odo catalog describe component nodejs
出力例
スタータープロジェクトからプロジェクトを作成する方法については、odo create
を参照してください。
3.5.2.2. サービス リンクのコピーリンクがクリップボードにコピーされました!
odo
は Operator を利用して サービス をデプロイでき ます。
odo では、Operator Lifecycle Manager を利用してデプロイされた Operator のみがサポートされます。
3.5.2.2.1. サービスの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
利用可能な Operator およびそれらの関連サービスを一覧表示するには、以下のコマンドを実行します。
odo catalog list services
$ odo catalog list services
出力例
Services available through Operators NAME CRDs postgresql-operator.v0.1.1 Backup, Database redis-operator.v0.8.0 RedisCluster, Redis
Services available through Operators
NAME CRDs
postgresql-operator.v0.1.1 Backup, Database
redis-operator.v0.8.0 RedisCluster, Redis
この例では、2 つの Operator がクラスターにインストールされます。postgresql-operator.v0.1.1
Operator は、PostgreSQL に関連するサービス: Backup
と Database
をデプロイします。redis-operator.v0.8.0
Operator は、RedisCluster
および Redis
に関連するサービスをデプロイします。
利用可能な Operator の一覧を取得するには、odo
は Succeeded フェーズにある現在の namespace の ClusterServiceVersion (CSV) リソースを取得します。クラスター全体のアクセスをサポートする Operator の場合、新規 namespace が作成されると、これらのリソースがこれに自動的に追加されます。ただし、Succeeded フェーズに入るまでに時間がかかる場合がありますが、odo
はリソースが準備状態になるまで空の一覧を返す可能性があります。
3.5.2.2.2. サービスの検索 リンクのコピーリンクがクリップボードにコピーされました!
キーワードで特定のサービスを検索するには、以下のコマンドを実行します。
odo catalog search service
$ odo catalog search service
たとえば、PostgreSQL サービスを取得するには、以下のコマンドを実行します。
odo catalog search service postgres
$ odo catalog search service postgres
出力例
Services available through Operators NAME CRDs postgresql-operator.v0.1.1 Backup, Database
Services available through Operators
NAME CRDs
postgresql-operator.v0.1.1 Backup, Database
検索されたキーワードを名前に含む Operator の一覧が表示されます。
3.5.2.2.3. サービスに関する情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
特定のサービスに関する詳細情報を取得するには、以下のコマンドを実行します。
odo catalog describe service
$ odo catalog describe service
以下に例を示します。
odo catalog describe service postgresql-operator.v0.1.1/Database
$ odo catalog describe service postgresql-operator.v0.1.1/Database
出力例
サービスは、CustomResourceDefinition (CRD) リソースによってクラスターに表示されます。前のコマンドは、kind
、version
、このカスタムリソースのインスタンスを定義するために使用できるフィールドのリストなど、CRD に関する詳細を表示します。
フィールドの一覧は、CRD に含まれる OpenAPI スキーマ から抽出されます。この情報は CRD でオプションであり、存在しない場合は、サービスを表す ClusterServiceVersion (CSV) リソースから抽出されます。
CRD タイプの情報を指定せずに、Operator がサポートするサービスの説明を要求することもできます。CRD のないクラスターで Redis Operator を記述するには、以下のコマンドを実行します。
odo catalog describe service redis-operator.v0.8.0
$ odo catalog describe service redis-operator.v0.8.0
出力例
3.5.3. odo create リンクのコピーリンクがクリップボードにコピーされました!
odo
は devfile を使用してコンポーネントの設定を保存し、ストレージやサービスなどのコンポーネントのリソースを記述します。odo create コマンドはこのファイルを生成します。
3.5.3.1. コンポーネントの作成 リンクのコピーリンクがクリップボードにコピーされました!
既存のプロジェクトの devfile を 作成 するには、コンポーネントの名前とタイプ (たとえば、nodejs
または go
) を指定して odo create
コマンドを実行します。
odo create nodejs mynodejs
odo create nodejs mynodejs
この例では、nodejs
はコンポーネントのタイプで、mynodejs
は odo
が作成するコンポーネントの名前です。
サポートされるすべてのコンポーネントタイプの一覧については、コマンド odo catalog list components
を実行します。
ソースコードが現在のディレクトリーに存在する場合は、--context
フラグを使用してパスを指定できます。たとえば、nodejs コンポーネントのソースが現在の作業ディレクトリーと相対的に node-backend
というフォルダーにある場合は、以下のコマンドを実行します。
odo create nodejs mynodejs --context ./node-backend
odo create nodejs mynodejs --context ./node-backend
--context
フラグは、相対パスおよび絶対パスをサポートします。
コンポーネントがデプロイされるプロジェクトまたはアプリケーションを指定するには、--project
フラグおよび --app
フラグを使用します。たとえば、backend
プロジェクト内の myapp
アプリの一部であるコンポーネントを作成するには、次のコマンドを実行します。
odo create nodejs --app myapp --project backend
odo create nodejs --app myapp --project backend
これらのフラグが指定されていない場合、デフォルトはアクティブなアプリケーションおよびプロジェクトに設定されます。
3.5.3.2. スタータープロジェクト リンクのコピーリンクがクリップボードにコピーされました!
既存のソースコードがなく、devfile およびコンポーネントを迅速に稼働させる必要がある場合は、スタータープロジェクトを使用します。スタータープロジェクトを使用するには、--starter
フラグを odo create
コマンドに追加します。
コンポーネントタイプの利用可能なスタータープロジェクトの一覧を表示するには、odo catalog describe component
コマンドを実行します。たとえば、nodejs コンポーネントタイプの利用可能なスタータープロジェクトをすべて取得するには、以下のコマンドを実行します。
odo catalog describe component nodejs
odo catalog describe component nodejs
次に、odo create
コマンドで --starter
フラグを使用して必要なプロジェクトを指定します。
odo create nodejs --starter nodejs-starter
odo create nodejs --starter nodejs-starter
これにより、選択したコンポーネントタイプ (この例では nodejs
) に対応するサンプルテンプレートがダウンロードされます。テンプレートは、現在のディレクトリーまたは --context
フラグで指定された場所にダウンロードされます。スタータープロジェクトに独自の devfile がある場合、この devfile は保持されます。
3.5.3.3. 既存の devfile の使用 リンクのコピーリンクがクリップボードにコピーされました!
既存の devfile から新規コンポーネントを作成する場合は、--devfile
フラグを使用して devfile へのパスを指定して実行できます。たとえば、GitHub の devfile に基づいて mynodejs
というコンポーネントを作成するには、以下のコマンドを使用します。
odo create mynodejs --devfile https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml
odo create mynodejs --devfile https://raw.githubusercontent.com/odo-devfiles/registry/master/devfiles/nodejs/devfile.yaml
3.5.3.4. インタラクティブな作成 リンクのコピーリンクがクリップボードにコピーされました!
odo create
コマンドを対話的に実行して、コンポーネントの作成に必要な手順をガイドすることもできます。
コンポーネントのコンポーネントタイプ、名前、およびプロジェクトを選択します。スタータープロジェクトをダウンロードするかどうかを選択することもできます。完了したら、新しい devfile.yaml
ファイルが作業ディレクトリーに作成されます。
これらのリソースをクラスターにデプロイするには、odo push
コマンドを実行します。
3.5.4. odo delete リンクのコピーリンクがクリップボードにコピーされました!
odo delete
コマンドは、odo
によって管理されるリソースを削除するのに役立ちます。
3.5.4.1. コンポーネントの削除 リンクのコピーリンクがクリップボードにコピーされました!
devfile コンポーネントを削除するには、odo delete
コマンドを実行します。
odo delete
$ odo delete
コンポーネントがクラスターにプッシュされている場合、コンポーネントは依存するストレージ、URL、シークレット、他のリソースと共にクラスターから削除されます。コンポーネントがプッシュされていない場合、コマンドはクラスターのリソースが検出できなかったことを示すエラーを出して終了します。
確認質問を回避するには、-f
フラグまたは --force
フラグを使用します。
3.5.4.2. devfile Kubernetes コンポーネントのアンデプロイ リンクのコピーリンクがクリップボードにコピーされました!
odo deploy
でデプロイされた devfile Kubernetes コンポーネントをアンデプロイするには、--deploy
フラグを指定して odo delete
コマンドを実行します。
odo delete --deploy
$ odo delete --deploy
確認質問を回避するには、-f
フラグまたは --force
フラグを使用します。
3.5.4.3. すべて削除 リンクのコピーリンクがクリップボードにコピーされました!
以下の項目を含むすべてのアーティファクトを削除するには、--all
フラグを指定して odo delete
コマンドを実行します。
- devfile コンポーネント
-
odo deploy
コマンドを使用してデプロイされた devfile Kubernetes コンポーネント - devfile
- ローカル設定
odo delete --all
$ odo delete --all
3.5.4.4. 利用可能なフラグ リンクのコピーリンクがクリップボードにコピーされました!
-f
,--force
- このフラグを使用して確認質問を回避します。
-w
,--wait
- このフラグを使用して、コンポーネントおよび依存関係が削除されるのを待機します。このフラグは、アンデプロイ時には機能しません。
Common Flags フラグに関するドキュメントでは、コマンドで利用可能なフラグの詳細情報が提供されています。
3.5.5. odo deploy リンクのコピーリンクがクリップボードにコピーされました!
odo
を使用すると、CI/CD システムを使用してコンポーネントをデプロイする方法と同様に、コンポーネントをデプロイできます。まず、odo
はコンテナーイメージをビルドしてから、コンポーネントのデプロイに必要な Kubernetes リソースをデプロイします。
コマンド odo deploy
を実行すると、odo
は devfile で kind deploy
のデフォルトコマンドを検索し、以下のコマンドを実行します。このタイプの deploy
は、バージョン 2.2.0 以降の devfile 形式でサポートされます。
deploy
コマンドは通常、いくつかの 適用 コマンドで設定される 複合 コマンドです。
-
適用されると、デプロイするコンテナーのイメージを構築し、それをレジストリーにプッシュする
image
コンポーネントを参照するコマンド。 - Kubernetes コンポーネント を参照するコマンドは、適用されるとクラスターに Kubernetes リソースを作成します。
以下の devfile.yaml
ファイルのサンプルでは、コンテナーイメージはディレクトリーにある Dockerfile
を使用してビルドされます。イメージはレジストリーにプッシュされ、この新規にビルドされたイメージを使用して Kubernetes Deployment リソースがクラスターに作成されます。
3.5.6. odo link リンクのコピーリンクがクリップボードにコピーされました!
odo link
コマンドは、odo
コンポーネントを Operator がサポートするサービスまたは別の odo
コンポーネントにリンクするのに役立ちます。これは Service Binding Operator を使用して行います。現時点で、odo
は必要な機能を実現するために Operator 自体ではなく、Service Binding ライブラリーを使用します。
3.5.6.1. 各種リンクオプション リンクのコピーリンクがクリップボードにコピーされました!
odo
は、コンポーネントを Operator がサポートするサービスまたは別の odo
コンポーネントにリンクするための各種のオプションを提供します。これらのオプション (またはフラグ) はすべて、コンポーネントをサービスにリンクする場合でも、別のコンポーネントにリンクする場合でも使用できます。
3.5.6.1.1. デフォルト動作 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、odo link
コマンドは、コンポーネントディレクトリーに kubernetes/
という名前のディレクトリーを作成し、そこにサービスとリンクに関する情報 (YAML マニフェスト) を保存します。odo push
を使用すると、odo
はこれらのマニフェストを Kubernetes クラスター上のリソースの状態と比較し、ユーザーが指定したものと一致するようにリソースを作成、変更、または破棄する必要があるかどうかを判断します。
3.5.6.1.2. --inlined フラグ リンクのコピーリンクがクリップボードにコピーされました!
odo link
コマンドに --inlined
フラグを指定すると、odo
は、kubernetes/
ディレクトリーの下にファイルを作成する代わりに、リンク情報をコンポーネントディレクトリーの devfile.yaml
にインラインで保存します。--inlined
フラグの動作は、odo link
および odo service create
コマンドの両方で似ています。このフラグは、すべてが単一の devfile.yaml
に保存されている場合に便利です。コンポーネント用に実行する各 odo link
および odo service create
コマンドで --inlined
フラグを使用するのを覚えておく必要があります。
3.5.6.1.3. --map フラグ リンクのコピーリンクがクリップボードにコピーされました!
場合によっては、デフォルトで利用できる内容に加えて、コンポーネントにバインディング情報をさらに追加する必要がある場合があります。たとえば、コンポーネントをサービスにリンクしていて、サービスの仕様 (仕様の略) からの情報をバインドしたい場合は、-map
フラグを使用できます。odo
は、リンクされているサービスまたはコンポーネントの仕様に対して検証を実行しないことに注意してください。このフラグの使用は、Kubernetes YAML マニフェストの使用に慣れる場合にのみ推奨されます。
3.5.6.1.4. --bind-as-files フラグ リンクのコピーリンクがクリップボードにコピーされました!
これまでに説明したすべてのリンクオプションについて、odo
はバインディング情報を環境変数としてコンポーネントに挿入します。この情報をファイルとしてマウントする場合は、--bind-as-files
フラグを使用できます。これにより、odo
はバインディング情報をファイルとしてコンポーネントの Pod 内の /bindings
の場所に挿入します。環境変数のシナリオと比較して、-bind-as-files
を使用すると、ファイルはキーにちなんで名前が付けられ、これらのキーの値はこれらのファイルのコンテンツとして保存されます。
3.5.6.2. 例 リンクのコピーリンクがクリップボードにコピーされました!
3.5.6.2.1. デフォルトの odo link リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、バックエンドコンポーネントはデフォルトの odo link
コマンドを使用して PostgreSQL サービスにリンクされています。バックエンドコンポーネントでは、コンポーネントおよびサービスがクラスターにプッシュされていることを確認します。
odo list
$ odo list
出力例
APP NAME PROJECT TYPE STATE MANAGED BY ODO app backend myproject spring Pushed Yes
APP NAME PROJECT TYPE STATE MANAGED BY ODO
app backend myproject spring Pushed Yes
odo service list
$ odo service list
出力例
NAME MANAGED BY ODO STATE AGE PostgresCluster/hippo Yes (backend) Pushed 59m41s
NAME MANAGED BY ODO STATE AGE
PostgresCluster/hippo Yes (backend) Pushed 59m41s
ここで、odo link
を実行してバックエンドコンポーネントを PostgreSQL サービスにリンクします。
odo link PostgresCluster/hippo
$ odo link PostgresCluster/hippo
出力例
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo" To apply the link, please use `odo push`
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo"
To apply the link, please use `odo push`
次に、odo push
を実行して Kubernetes クラスターにリンクを作成します。
odo push
に成功すると、以下のような結果が表示されます。
バックエンドコンポーネントによってデプロイされたアプリケーションの URL を開くと、データベース内の
ToDo
アイテムのリストが表示されます。たとえば、odo url list
コマンドの出力では、todos
が記載されているパスが含まれます。odo url list
$ odo url list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Found the following URLs for component backend NAME STATE URL PORT SECURE KIND 8080-tcp Pushed http://8080-tcp.192.168.39.112.nip.io 8080 false ingress
Found the following URLs for component backend NAME STATE URL PORT SECURE KIND 8080-tcp Pushed http://8080-tcp.192.168.39.112.nip.io 8080 false ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow URL の正しいパスは http://8080-tcp.192.168.39.112.nip.io/api/v1/todos になります。URL は設定によって異なります。また、追加しない限りデータベースには
todo
がないため、URL に空の JSON オブジェクトが表示される場合があることにも注意してください。backend コンポーネントにインジェクトされる Postgres サービスに関連するバインディング情報を確認できます。このバインディング情報は、デフォルトで環境変数として挿入されます。バックエンドコンポーネントのディレクトリーから
odo describe
コマンドを使用してこれを確認できます。odo describe
$ odo describe
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの変数の一部は、バックエンドコンポーネントの
src/main/resources/application.properties
ファイルで使用されるため、JavaSpringBoot アプリケーションは PostgreSQL データベースサービスに接続できます。最後に、
odo
はバックエンドコンポーネントのディレクトリーにkubernetes/
というディレクトリーを作成しました。このディレクトリーには次のファイルが含まれています。ls kubernetes
$ ls kubernetes odo-service-backend-postgrescluster-hippo.yaml odo-service-hippo.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのファイルには、次の 2 つのリソースの情報 (YAML マニフェスト) が含まれています。
-
odo-service-hippo.yaml-odo service create
:odo service create --from-file ../postgrescluster.yaml
コマンドを使用して作成された Postgres サービス。 -
odo-service-backend-PostgresCluster-hippo.yaml-odolink
:odo link
コマンドを使用して作成された リンク。
-
3.5.6.2.2. --inlined フラグでの odo link の使用 リンクのコピーリンクがクリップボードにコピーされました!
odo link
コマンドで --inlined
フラグを使用すると、これがバインディング情報を挿入するというフラグなしに odo link
コマンドと同じ効果があります。ただし、上記の場合は、kubernetes/
ディレクトリーに 2 つのマニフェストファイルがあります。1 つは Postgres サービス用で、もう 1 つは backend コンポーネントとこのサービス間のリンク用です。ただし、-inlined
フラグを渡すと、odo
は kubernetes/
ディレクトリーの下に YAML マニフェストを保存するファイルを作成せず、devfile.yaml
ファイルにインラインで保存します。
これを確認するには、最初に PostgreSQL サービスからコンポーネントをリンク解除します。
odo unlink PostgresCluster/hippo
$ odo unlink PostgresCluster/hippo
出力例:
✓ Successfully unlinked component "backend" from service "PostgresCluster/hippo" To apply the changes, please use `odo push`
✓ Successfully unlinked component "backend" from service "PostgresCluster/hippo"
To apply the changes, please use `odo push`
クラスターでそれらをリンクするには、odo push
を実行します。kubernetes/
ディレクトリーを検査すると、1 つのファイルのみが表示されます。
ls kubernetes
$ ls kubernetes
odo-service-hippo.yaml
次に、--inlined
フラグを使用してリンクを作成します。
odo link PostgresCluster/hippo --inlined
$ odo link PostgresCluster/hippo --inlined
出力例:
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo" To apply the link, please use `odo push`
✓ Successfully created link between component "backend" and service "PostgresCluster/hippo"
To apply the link, please use `odo push`
--inlined
フラグを省略する手順など、クラスターで作成されるリンクを取得するために odo push
を実行する必要があります。odo
は設定を devfile.yaml
に保存します。このファイルに以下のようなエントリーが表示されます。
odo unlink PostgresCluster/hippo
を実行する場合に、odo
はまず devfile.yaml
からリンク情報を削除し、後続の odo push
はクラスターからリンクを削除するようになりました。
3.5.6.2.3. カスタムバインディング リンクのコピーリンクがクリップボードにコピーされました!
odo link
は、カスタムバインディング情報をコンポーネントに挿入することのできるフラグ --map
を受け入れます。このようなバインディング情報は、コンポーネントにリンクしているリソースのマニフェストから取得されます。たとえば、バックエンドコンポーネントおよび PostgreSQL サービスのコンテキストでは、PostgreSQL サービスのマニフェスト postgrescluster.yaml
ファイルからの情報をバックエンドコンポーネントに注入することができます。
PostgresCluster
サービスの名前が hippo
(または PostgresCluster サービスの名前が異なる場合は odo service list
の出力) の場合、その YAML 定義から postgresVersion
の値をバックエンドコンポーネントに挿入するときは、次のコマンドを実行します。
odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}'
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}'
Postgres サービスの名前が hippo
と異なる場合は、上記のコマンドで pgVersion
の値の .hippo
の代わりにそれを指定する必要があることに注意してください。
リンク操作後に、通常どおり odo push
を実行します。プッシュ操作が正常に完了すると、バックエンドコンポーネントディレクトリーから次のコマンドを実行して、カスタムマッピングが適切に挿入されたかどうかを検証できます。
odo exec -- env | grep pgVersion
$ odo exec -- env | grep pgVersion
出力例:
pgVersion=13
pgVersion=13
カスタムバインディング情報を複数挿入したい可能性があるため、odo link
は複数のキーと値のペアを受け入れます。唯一の制約は、これらを --map <key>=<value>
として指定する必要があるということです。たとえば、PostgreSQL イメージ情報をバージョンと共に注入する場合には、以下を実行できます。
odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}'
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}'
次に、odo push
を実行します。両方のマッピングが正しくインジェクトされたかどうかを確認するには、以下のコマンドを実行します。
odo exec -- env | grep -e "pgVersion\|pgImage"
$ odo exec -- env | grep -e "pgVersion\|pgImage"
出力例:
pgVersion=13 pgImage=registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
pgVersion=13
pgImage=registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
3.5.6.2.3.1. インラインかどうか。 リンクのコピーリンクがクリップボードにコピーされました!
odo link
が kubernetes/
ディレクトリー下のリンクのマニフェストファイルを生成するデフォルトの動作を受け入れます。または、すべてを単一の devfile.yaml
ファイルに保存する場合は、-inlined
フラグを使用できます。
3.5.6.3. ファイルとしてのバインド リンクのコピーリンクがクリップボードにコピーされました!
odo link
が提供するもう 1 つの便利なフラグは、--bind-as-files
です。このフラグが渡されると、バインディング情報は環境変数としてコンポーネントの Pod に挿入されませんが、ファイルシステムとしてマウントされます。
バックエンドコンポーネントと PostgreSQL サービスの間に既存のリンクがないことを確認します。これは、バックエンドコンポーネントのディレクトリーで odo describe
を実行して、以下のような出力が表示されるかどうかを確認することで実行できます。
Linked Services: · PostgresCluster/hippo
Linked Services:
· PostgresCluster/hippo
以下を使用してコンポーネントからサービスをリンクを解除します。
odo unlink PostgresCluster/hippo odo push
$ odo unlink PostgresCluster/hippo
$ odo push
3.5.6.4. --bind-as-files の例 リンクのコピーリンクがクリップボードにコピーされました!
3.5.6.4.1. デフォルトの odo link の使用 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、odo
はリンク情報を保存するために kubernetes/
ディレクトリーの下にマニフェストファイルを作成します。バックエンドコンポーネントおよび PostgreSQL サービスをリンクします。
odo link PostgresCluster/hippo --bind-as-files odo push
$ odo link PostgresCluster/hippo --bind-as-files
$ odo push
odo describe
出力例:
以前の odo describe
出力で key=value
形式の環境変数であったものはすべて、ファイルとしてマウントされるようになりました。cat
コマンドを使用して、これらのファイルの一部を表示します。
コマンドの例:
odo exec -- cat /bindings/backend-postgrescluster-hippo/password
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/password
出力例:
q({JC:jn^mm/Bw}eu+j.GX{k
q({JC:jn^mm/Bw}eu+j.GX{k
コマンドの例:
odo exec -- cat /bindings/backend-postgrescluster-hippo/user
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/user
出力例:
hippo
hippo
コマンドの例:
odo exec -- cat /bindings/backend-postgrescluster-hippo/clusterIP
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/clusterIP
出力例:
10.101.78.56
10.101.78.56
3.5.6.4.2. --inlined の使用 リンクのコピーリンクがクリップボードにコピーされました!
--bind-as-files
と --inlined
を一緒に使用した結果は、odolink--inlined
を使用した場合と同様です。リンクのマニフェストは、kubernetes/
ディレクトリーの別のファイルに保存されるのではなく、devfile.yaml
に保存されます。これ以外に、odo describe
出力は以前と同じになります。
3.5.6.4.3. カスタムバインディング リンクのコピーリンクがクリップボードにコピーされました!
バックエンドコンポーネントを PostgreSQL サービスにリンクしているときにカスタムバインディングを渡すと、これらのカスタムバインディングは環境変数としてではなく、ファイルとしてマウントされます。以下に例を示します。
odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}' --bind-as-files odo push
$ odo link PostgresCluster/hippo --map pgVersion='{{ .hippo.spec.postgresVersion }}' --map pgImage='{{ .hippo.spec.image }}' --bind-as-files
$ odo push
これらのカスタムバインディングは、環境変数として挿入されるのではなく、ファイルとしてマウントされます。これが機能することを確認するには、以下のコマンドを実行します。
コマンドの例:
odo exec -- cat /bindings/backend-postgrescluster-hippo/pgVersion
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgVersion
出力例:
13
13
コマンドの例:
odo exec -- cat /bindings/backend-postgrescluster-hippo/pgImage
$ odo exec -- cat /bindings/backend-postgrescluster-hippo/pgImage
出力例:
registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
3.5.7. odo registry リンクのコピーリンクがクリップボードにコピーされました!
odo
は移植可能な devfile 形式を使用してコンポーネントを記述します。odo
は各種の devfile レジストリーに接続して、さまざまな言語およびフレームワークの devfile をダウンロードできます。
公開されている利用可能な devfile レジストリーに接続するか、または独自の Secure Registry をインストールできます。
odo registry
コマンドを使用して、odo
によって使用されるレジストリーを管理し、devfile 情報を取得できます。
3.5.7.1. レジストリーの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
odo
で現在接続しているレジストリーを一覧表示するには、以下のコマンドを実行します。
odo registry list
$ odo registry list
出力例:
NAME URL SECURE DefaultDevfileRegistry https://registry.devfile.io No
NAME URL SECURE
DefaultDevfileRegistry https://registry.devfile.io No
DefaultDevfileRegistry
は odo によって使用されるデフォルトレジストリーです。これは devfile.io プロジェクトによって提供されます。
3.5.7.2. レジストリーの追加 リンクのコピーリンクがクリップボードにコピーされました!
レジストリーを追加するには、以下のコマンドを実行します。
odo registry add
$ odo registry add
出力例:
odo registry add StageRegistry https://registry.stage.devfile.io
$ odo registry add StageRegistry https://registry.stage.devfile.io
New registry successfully added
独自の Secure Registry をデプロイしている場合、--token
フラグを使用してセキュアなレジストリーに対して認証するためにパーソナルアクセストークンを指定できます。
odo registry add MyRegistry https://myregistry.example.com --token <access_token>
$ odo registry add MyRegistry https://myregistry.example.com --token <access_token>
New registry successfully added
3.5.7.3. レジストリーの削除 リンクのコピーリンクがクリップボードにコピーされました!
レジストリーを削除するには、以下のコマンドを実行します。
odo registry delete
$ odo registry delete
出力例:
odo registry delete StageRegistry
$ odo registry delete StageRegistry
? Are you sure you want to delete registry "StageRegistry" Yes
Successfully deleted registry
--force
(または -f
) フラグを使用して、確認なしでレジストリーを強制的に削除します。
3.5.7.4. レジストリーの更新 リンクのコピーリンクがクリップボードにコピーされました!
すでに登録されているレジストリーの URL またはパーソナルアクセストークンを更新するには、以下のコマンドを実行します。
odo registry update
$ odo registry update
出力例:
odo registry update MyRegistry https://otherregistry.example.com --token <other_access_token>
$ odo registry update MyRegistry https://otherregistry.example.com --token <other_access_token>
? Are you sure you want to update registry "MyRegistry" Yes
Successfully updated registry
--force
(または -f
) フラグを使用して、確認なしでレジストリーの更新を強制します。
3.5.8. odo service リンクのコピーリンクがクリップボードにコピーされました!
odo
は Operator を利用して サービス をデプロイでき ます。
インストールに使用できるオペレーターとサービスのリストは、odo catalog
コマンドを使用して見つけることができます。
サービスは コンポーネント のコンテキストで作成されるため、サービスをデプロイする前に odo create
コマンドを実行してください。
サービスは、以下の 2 つのステップに従ってデプロイされます。
- サービスを定義し、その定義を devfile に保存します。
-
odo push
コマンドを使用して、定義されたサービスをクラスターにデプロイします。
3.5.8.1. 新しいサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
新規サービスを作成するには、以下のコマンドを実行します。
odo service create
$ odo service create
たとえば、my-redis-service
という名前の Redis サービスのインスタンスを作成するには、以下のコマンドを実行します。
出力例
このコマンドは、サービスの定義を含む Kubernetes マニフェストを kubernetes/
ディレクトリーに作成し、このファイルは devfile.yaml
ファイルから参照されます。
cat kubernetes/odo-service-my-redis-service.yaml
$ cat kubernetes/odo-service-my-redis-service.yaml
出力例
コマンドの例
cat devfile.yaml
$ cat devfile.yaml
出力例
作成されたインスタンスの名前はオプションです。名前を指定しない場合は、サービスの小文字の名前です。たとえば、以下のコマンドは redis
という名前の Redis サービスのインスタンスを作成します。
odo service create redis-operator.v0.8.0/Redis
$ odo service create redis-operator.v0.8.0/Redis
3.5.8.1.1. マニフェストのインライン化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、新規マニフェストは kubernetes/
ディレクトリーに作成され、devfile.yaml
ファイルから参照されます。--inlined
フラグを使用して、devfile.yaml
ファイル内でマニフェストをインラインにすることができます。
odo service create redis-operator.v0.8.0/Redis my-redis-service --inlined
$ odo service create redis-operator.v0.8.0/Redis my-redis-service --inlined
Successfully added service to the configuration; do 'odo push' to create service on the cluster
コマンドの例
cat devfile.yaml
$ cat devfile.yaml
出力例
3.5.8.1.2. サービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
特定のカスタマイズを行わないと、サービスはデフォルト設定で作成されます。コマンドライン引数またはファイルのいずれかを使用して、独自の設定を指定できます。
3.5.8.1.2.1. コマンドライン引数の使用 リンクのコピーリンクがクリップボードにコピーされました!
--parameters
(または -p
) フラグを使用して、独自の設定を指定します。
以下の例では、Redis サービスを 3 つのパラメーターで設定します。
odo service create redis-operator.v0.8.0/Redis my-redis-service \ -p kubernetesConfig.image=quay.io/opstree/redis:v6.2.5 \ -p kubernetesConfig.serviceType=ClusterIP \ -p redisExporter.image=quay.io/opstree/redis-exporter:1.0
$ odo service create redis-operator.v0.8.0/Redis my-redis-service \
-p kubernetesConfig.image=quay.io/opstree/redis:v6.2.5 \
-p kubernetesConfig.serviceType=ClusterIP \
-p redisExporter.image=quay.io/opstree/redis-exporter:1.0
Successfully added service to the configuration; do 'odo push' to create service on the cluster
コマンドの例
cat kubernetes/odo-service-my-redis-service.yaml
$ cat kubernetes/odo-service-my-redis-service.yaml
出力例
odo catalog describe service
コマンドを使用して、特定のサービスの使用可能なパラメーターを取得できます。
3.5.8.1.2.2. ファイルの使用 リンクのコピーリンクがクリップボードにコピーされました!
YAML マニフェストを使用して独自の仕様を設定します。以下の例では、Redis サービスは 3 つのパラメーターで設定されます。
マニフェストを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マニフェストからサービスを作成します。
odo service create --from-file my-redis.yaml
$ odo service create --from-file my-redis.yaml Successfully added service to the configuration; do 'odo push' to create service on the cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.8.2. サービスの削除 リンクのコピーリンクがクリップボードにコピーされました!
サービスを削除するには、以下のコマンドを実行します。
odo service delete
$ odo service delete
出力例
odo service list
$ odo service list
NAME MANAGED BY ODO STATE AGE
Redis/my-redis-service Yes (api) Deleted locally 5m39s
odo service delete Redis/my-redis-service
$ odo service delete Redis/my-redis-service
? Are you sure you want to delete Redis/my-redis-service Yes
Service "Redis/my-redis-service" has been successfully deleted; do 'odo push' to delete service from the cluster
--force
(または -f
) フラグを使用して、確認なしでサービスを強制的に削除します。
3.5.8.3. サービスの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
コンポーネント用に作成されたサービスを一覧表示するには、以下のコマンドを実行します。
odo service list
$ odo service list
出力例
odo service list
$ odo service list
NAME MANAGED BY ODO STATE AGE
Redis/my-redis-service-1 Yes (api) Not pushed
Redis/my-redis-service-2 Yes (api) Pushed 52s
Redis/my-redis-service-3 Yes (api) Deleted locally 1m22s
サービスごとに、STATE
は、サービスが odo push
コマンドを使用してクラスターにプッシュされているか、またはサービスがクラスターで実行中であるが、odo service delete
コマンドを使用してローカルで devfile から削除されるかどうかを示します。
3.5.8.4. サービスに関する情報の取得 リンクのコピーリンクがクリップボードにコピーされました!
設定したパラメーターの種類、バージョン、名前、および一覧などのサービスの詳細を取得するには、以下のコマンドを実行します。
odo service describe
$ odo service describe
出力例
3.5.9. odo ストレージ リンクのコピーリンクがクリップボードにコピーされました!
odo
を使用すると、ユーザーはコンポーネントに割り当てられるストレージボリュームを管理できます。ストレージボリュームは、emptyDir
Kubernetes ボリュームを使用するエフェメラルボリューム、または 永続ボリュームクレーム (PVC) のいずれかです。PVC を使用すると、ユーザーは特定のクラウド環境の詳細を理解していなくても、永続ボリューム (GCE PersistentDisk や iSCSI ボリュームなど) を要求できます。永続ストレージボリュームは、再起動時にデータを永続化し、コンポーネントの再ビルドに使用できます。
3.5.9.1. ストレージボリュームの追加 リンクのコピーリンクがクリップボードにコピーされました!
ストレージボリュームをクラスターに追加するには、以下のコマンドを実行します。
odo storage create
$ odo storage create
出力例:
上記の例では、最初のストレージボリュームが /data
パスにマウントされており、サイズは 1Gi
で、2 番目のボリュームが /tmp
にマウントされ、一時的です。
3.5.9.2. ストレージボリュームの一覧表示 リンクのコピーリンクがクリップボードにコピーされました!
コンポーネントで現在使用されているストレージボリュームを確認するには、以下のコマンドを実行します。
odo storage list
$ odo storage list
出力例:
odo storage list
$ odo storage list
The component 'nodejs-project-ufyy' has the following storage attached:
NAME SIZE PATH STATE
store 1Gi /data Not Pushed
tempdir 2Gi /tmp Not Pushed
3.5.9.3. ストレージボリュームの削除 リンクのコピーリンクがクリップボードにコピーされました!
ストレージボリュームを削除するには、以下のコマンドを実行します。
odo storage delete
$ odo storage delete
出力例:
odo storage delete store -f
$ odo storage delete store -f
Deleted storage store from nodejs-project-ufyy
Please use `odo push` command to delete the storage from the cluster
上記の例では、-f
フラグを使用すると、ユーザーパーミッションを要求せずにストレージを強制的に削除します。
3.5.9.4. 特定のコンテナーへのストレージの追加 リンクのコピーリンクがクリップボードにコピーされました!
devfile に複数のコンテナーがある場合、odo storage create
コマンドで --container
フラグを使用して、ストレージを割り当てるコンテナーを指定できます。
以下の例は、複数のコンテナーを持つ devfile の抜粋です。
この例では、nodejs1
と nodejs2
の 2 つのコンテナーがあります。ストレージを nodejs2
コンテナーに割り当てるには、以下のコマンドを使用します。
odo storage create --container
$ odo storage create --container
出力例:
odo storage create store --path /data --size 1Gi --container nodejs2
$ odo storage create store --path /data --size 1Gi --container nodejs2
✓ Added storage store to nodejs-testing-xnfg
Please use `odo push` command to make the storage accessible to the component
odo storage list
コマンドを使用して、ストレージリソースを一覧表示できます。
odo storage list
$ odo storage list
出力例:
The component 'nodejs-testing-xnfg' has the following storage attached: NAME SIZE PATH CONTAINER STATE store 1Gi /data nodejs2 Not Pushed
The component 'nodejs-testing-xnfg' has the following storage attached:
NAME SIZE PATH CONTAINER STATE
store 1Gi /data nodejs2 Not Pushed
3.5.10. 共通フラグ リンクのコピーリンクがクリップボードにコピーされました!
以下のフラグは、ほとんどの odo
コマンドで利用できます。
コマンド | 説明 |
---|---|
| コンポーネントを定義するコンテキストディレクトリーを設定します。 |
| コンポーネントのプロジェクトを設定します。デフォルトは、ローカル設定で定義されたプロジェクトです。利用できる場合は、クラスターの現在のプロジェクトです。 |
| コンポーネントのアプリケーションを設定します。デフォルトは、ローカル設定で定義されたアプリケーションです。存在しない場合は、app にします。 |
|
デフォルト設定を使用していない場合は、パスを |
| このフラグを使用してログを表示します。 |
| このフラグを使用して、コマンドに対して確認を求めるプロンプトを出さないように指示します。 |
| 詳細レベルを設定します。詳細は、odo でのロギング について参照してください。 |
| コマンドのヘルプを出力します。 |
一部のコマンドでフラグを使用できない場合があります。--help
フラグを指定してコマンドを実行して、利用可能なすべてのフラグの一覧を取得します。
3.5.11. JSON 出力 リンクのコピーリンクがクリップボードにコピーされました!
コンテンツを出力する odo
コマンドは、通常、-o json
フラグを受け入れて、このコンテンツを JSON 形式で出力します。これは、他のプログラムがこの出力をより簡単に解析するのに適しています。
出力構造は Kubernetes リソースに似ており、kind
、apiVersion
、metadata
、spec
、および status
フィールドがあります。
リスト コマンドは、リストのアイテムを一覧表示する items
(または同様の) フィールドを含む List
リソースを返します。各アイテムも Kubernetes リソースに類似しています。
delete コマンドは Status
リソースを返します。ステータス Kubernetes リソース を参照してください。
他のコマンドは、Application
、Storage
、URL
などのコマンドに関連付けられたリソースを返します。
現在 -o json
フラグを許可するコマンドの全一覧は以下のとおりです。
コマンド | 種類 (バージョン) | リストアイテムの種類 (バージョン) | 完全なコンテンツかどうか |
---|---|---|---|
odo application describe | Application (odo.dev/v1alpha1) | 該当なし | いいえ |
odo application list | List (odo.dev/v1alpha1) | Application (odo.dev/v1alpha1) | ? |
odo catalog list components | List (odo.dev/v1alpha1) | missing | はい |
odo catalog list services | List (odo.dev/v1alpha1) | ClusterServiceVersion (operators.coreos.com/v1alpha1) | ? |
odo catalog describe component | missing | 該当なし | はい |
odo catalog describe service | CRDDescription (odo.dev/v1alpha1) | 該当なし | はい |
odo component create | Component (odo.dev/v1alpha1) | 該当なし | はい |
odo component describe | Component (odo.dev/v1alpha1) | 該当なし | はい |
odo component list | List (odo.dev/v1alpha1) | Component (odo.dev/v1alpha1) | はい |
odo config view | DevfileConfiguration (odo.dev/v1alpha1) | 該当なし | はい |
odo debug info | OdoDebugInfo (odo.dev/v1alpha1) | 該当なし | はい |
odo env view | EnvInfo (odo.dev/v1alpha1) | 該当なし | はい |
odo preference view | PreferenceList (odo.dev/v1alpha1) | 該当なし | はい |
odo project create | Project (odo.dev/v1alpha1) | 該当なし | はい |
odo project delete | Status (v1) | 該当なし | はい |
odo project get | Project (odo.dev/v1alpha1) | 該当なし | はい |
odo project list | List (odo.dev/v1alpha1) | Project (odo.dev/v1alpha1) | はい |
odo registry list | List (odo.dev/v1alpha1) | missing | はい |
odo service create | サービス | 該当なし | はい |
odo service describe | サービス | 該当なし | はい |
odo service list | List (odo.dev/v1alpha1) | サービス | はい |
odo storage create | Storage (odo.dev/v1alpha1) | 該当なし | はい |
odo storage delete | Status (v1) | 該当なし | はい |
odo storage list | List (odo.dev/v1alpha1) | Storage (odo.dev/v1alpha1) | はい |
odo url list | List (odo.dev/v1alpha1) | URL (odo.dev/v1alpha1) | はい |