デプロイメント・アーキテクチャ・オプションの理解

最初にプロビジョニングされると、Oracle Content ManagementのすべてのインスタンスはOracle Cloud Infrastructure上にデプロイされます。このアーキテクチャは、単一の地域内の複数の可用性ドメインにわたる高可用性トポロジです。ここでは、これらの可用性ドメイン全体で柔軟にスケーリングできるKubernetesクラスタとともにOracle Container Engine for Kubernetes (OKE)が使用されます。

  • 可用性ドメイン—可用性ドメインはリージョン内に配置された1つ以上のデータ・センターです。可用性ドメインは互いに分離されており、フォルト・トレラントで、同時に障害が発生する可能性が低くなります。可用性ドメインは電源や冷却、内部の可用性ドメイン・ネットワークなどの物理的なインフラストラクチャを共有しないため、1つの可用性ドメインに影響を与える障害が他の可用性ドメインに影響を与える可能性が低くなります。リージョン内の可用性ドメインは、低レイテンシ、高帯域幅ネットワークで互いに接続されています。可用性ドメイン間のこの予測可能で暗号化された相互接続では、高可用性と障害時リカバリの両方に対して構築ブロックを提供します。
  • フォルト・ドメイン—フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。可用性ドメインごとに3つのフォルト・ドメインが含まれています。フォルト・ドメインを使用すると、1つの可用性ドメイン内の同じ物理ハードウェア上にインスタンスが存在しないようにインスタンスを配置できます。そのため、1つのフォルト・ドメインに影響を与えるハードウェア障害またはメンテナンス・イベントは他のフォルト・ドメインのインスタンスに影響を与えません。オプションで、起動時に新規インスタンスにフォルト・ドメインを指定することも、システムがフォルト・ドメインを選択することもできます。

デフォルトのデプロイメントでは、OKEによって可用性ドメインに複数のクラスタ(またはノード)が自動的に作成されます。すべてのサイトおよびアセットは可用性ドメインごとに同期されます。1つの可用性ドメインが停止すると、OKEによって受信トラフィックが使用可能な可用性ドメインに自動的に転送されます。このように、エンド・ユーザーはサービスの停止を通知しませんが、障害が発生した可用性ドメインが復元されます。
高可用性アーキテクチャの例

「アップグレード・スケジュール」オプションを使用して、インスタンスがOracle Content Managementの新規リリースを受信するタイミングを制御することをお薦めします。ほとんどの場合、本番トラフィックを処理するインスタンスと、障害発生時にトラフィックを処理するインスタンスでは、遅延アップグレード・オプションを使用する必要があります。開発やテストを目的とするインスタンスでは、ただちにアップグレード・オプションを使用します。この組合せで設定することにより、コードの堅牢性を保証する完全なリリース・サイクルが実現され、問題があった場合には、それが本番トラフィックに影響を与える前に対応する時間を得られます。アップグレード・スケジュール・オプションは、Oracle Content Managementインスタンスを作成する際に設定します。

高可用性の拡張

高可用性サービスは長時間の稼働時間および高度なアクセシビリティを提供するように設計されていますが、さらに様々なアーキテクチャの提供を必要とする顧客が多数います。これらの追加アーキテクチャは、Oracle Cloud InfrastructureおよびOKEによって提供済のすぐに使用可能な高可用性を有効に利用しており、開発プロセス、複数リージョンのフェイルオーバーもサポートするように構築したり、プライベートの高パフォーマンス接続で拡張することもできます。ニーズに適したアーキテクチャを見つけるには、組織の開発プロセスのニーズ、受入れ可能なリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を判定する必要があります。

  • リカバリ時間目標(RTO)—RTOは障害が発生した後でアプリケーション機能を復元する際に必要なターゲット時間です。目標は、障害からすばやくリカバリする方法を評価するためのものです。通常、クリティカルなアプリケーションであればあるほど、RTOは低くなります。
  • リカバリ・ポイント目標(RPO)—RPOは、アプリケーションが許容可能な、失われたデータの受け入れ可能な時間枠です。RPOは、障害のシナリオにおいてアプリケーションで消失が許容されるデータの量です。

Oracle Cloud Infrastructure FastConnectを使用したプライベート・インスタンス

パブリック・インターネット上では実現できないパフォーマンスやセキュリティの強化を必要とするお客様もいます。Oracle Cloud Infrastructure FastConnectを使用すると、Oracle Content Managementインスタンスへの、よりパフォーマンスの高い、堅牢で安全な接続を提供できます。このタイプの接続をよく使用するのは、アクセスを確実に内部ネットワークに制限する必要があるお客様や、エンド・ユーザーに可能なかぎり最善で最も信頼性の高い接続を用意する必要があるお客様です。

そのようなインスタンスを作成する必要がある場合は、Oracle Cloud Infrastructure FastConnectを設定し、いくつかの前提条件のステップを追加で実行する必要があります。FastConnectは、インターネットベースの接続と比較して、より高帯域で信頼性が高く、かつ一貫性のあるネットワーキング体験を提供する専用プライベート接続です。

Oracle Cloud Infrastructure FastConnectを使用したプライベート・インスタンスの作成を参照してください。

開発プロセス

これは、組織がOracle Content Managementの新機能およびコンテンツの構築およびデプロイに使用するプロセスです。これには、高度な環境および本番用に承認する前に新機能およびコンテンツが稼働する必要がある複数の環境が含まれます。共通の設定には、開発、テスト、ステージングおよび本番用の環境が含まれます。組織のニーズは変化することがあります。

複数のインスタンスを利用して開発プロセスをサポートする顧客は、このドキュメントの説明に従って追加のインスタンスをプロビジョニングする必要がありますが、直接アクセスできるように前面にWebアプリケーション・ファイアウォール(WAF)をプロビジョニングする必要はありません。インスタンスのいずれかにコンテンツを開発した後で、OCEツールキットのコマンドライン・インタフェース(CLI)を使用して、Oracle Content Managementのあるインスタンスから別のインスタンスへそのコンテンツを伝播できます。

注:

本番トラフィックを処理しないインスタンスを追加で作成する場合は、そのインスタンスを非プライマリとマークして、複製したアセットの支払いが生じないようにする必要があります。プライマリ・インスタンスは、インスタンス内のアセットの総数に対して課金されます。プライマリ以外のインスタンスは、レプリケートされるアセットの総数に関係なく、月当たりのアセットの単一ブロックに対して課金されます(たとえば、5,000アセット。また、Video Plusがある場合は250個のVideo Plusアセット)。詳細は、Oracle PaaSおよびIaaSユニバーサル・クレジット・サービスの説明を参照してください。

変更の伝播には、OCEツールキット・コマンドを使用でき、サイトの作成や、開発、テストおよび本番の各インスタンスにおけるサイトのライフ・サイクル管理が可能です。開発環境でサイトに変更を行い、これらの変更をテストおよび本番環境に伝播します。この一連のコマンドライン・ユーティリティをスクリプト環境に組み入れてデプロイメントを管理することもできます。CLIユーティリティを使用すると、アセットやコンポーネントなどの新規アイテムや既存のコンテンツの更新をロールアウトできます。

テストから本番(T2P)デプロイメントの設定を参照してください。

バックアップ・リージョンの実装

組織でバックアップ・リージョンを使用して、障害発生時にパブリック・サイト・コンテンツの配信を継続する場合は、Webアプリケーション・ファイアウォール(WAF)を構成し、コンテンツをバックアップにレプリケートします。

バックアップはプライマリ・インスタンスとして同じ地域または別のリージョンに存在できます。別のリージョンにバックアップを作成すると、データや可用性の損失に対する保護が強化されます。

注:

現在、Oracle Content Managementは、WAFを介したパブリック・サイトのみをサポートしています。サイトに認証が必要な場合は、オリジン・ドメインから直接アクセスする必要があります。

アーキテクチャの概要の例を次に示します:

WAF設定の例

バックアップを作成すると、特にサイトやアセットが多数ある場合、時間がかかることがあるため、業務時間外にバックアップを実行することをお薦めします。インスタンス内でのコンテンツの変更の量によっては、バックアップを毎日行うか週に1回の頻度にするかを決定する必要があります。

バックアップ・リージョンを実装する際は、Oracle Cloud Infrastructure Web Application Firewallサービスを使用して、トラフィックをプライマリ(アクティブ)インスタンスに転送し、障害が発生した場合には、バックアップ(スタンバイ)インスタンスを指すように切り替えます。

注:

バックアップ・インスタンスを作成すると、重複したアセットに支払うことがないように、インスタンスを非プライマリとしてマークします。プライマリと非プライマリのインスタンスは、別のレートで請求されます。

プライマリ・インスタンスの作成後、次のステップを実行してバックアップ・リージョンを実装します:

  1. 新しいOracle Content Managementインスタンスを作成します。

    このインスタンスはプライマリ・リージョンで障害が発生した場合にのみ本番トラフィックを処理しますが、これをプロビジョニングする際は、このインスタンスのすべてのアセットが二重に請求されないよう、必ず非プライマリとマークしてください。また、これは本番インスタンスになるため、これは遅延アップグレードに設定されている必要があります。ただし、プライマリとバックアップのリージョン間でトラフィックを切り替える際に問題が発生しないよう、アップグレード・スケジュールが、プライマリ・リージョンと同じである必要があります。

    プライマリ・インスタンスと異なるリージョンにバックアップを配置する場合、セカンダリ・リージョンにこれを作成します。

  2. Oracle Cloud Infrastructure Web Application Firewallサービスを使用して、Webアプリケーション・ファイアウォール(WAF)を構成します。
  3. OCEツールキットを使用して、プライマリ・インスタンスからバックアップ・インスタンスにすべてのサイトおよびアセットを転送します。
    1. プライマリ・インスタンスおよびバックアップ・インスタンスに存在するリポジトリ、チャネルおよびローカリゼーション・ポリシーを複製します。
    2. まだ行なっていない場合は、VMコンピュート・インスタンスを作成します
    3. VMコンピュート・インスタンスにOCEツールキットをインストールし、それでIDCS認証を使用します。
    4. Oracle Content Managementのプライマリ・インスタンスとバックアップ・インスタンスを登録します。
    5. サイトとそのアセットを転送(プライマリ・インスタンスからバックアップ・インスタンス)。
  4. データが正しくレプリケートされていることをテストします。各オブジェクト・タイプへの変更を含め、プライマリ・インスタンスにいくつかの変更(5件未満)を行ってから、OCEツールキットを使用してデータを再度バックアップし、変更がバックアップ・インスタンスに正しく反映されていることを確認します。
  5. プライマリ・インスタンスを使用できない場合、バックアップ・インスタンスのユーザー・インタフェースへのアクセスが必要なユーザーを同期します。たとえば、少なくとも管理者は同期する必要があります。

    注:

    バックアップ・インスタンスは、障害発生時のパブリック・サイト配信のテストまたは継続のみを目的としており、認証を必要とするサイトへの継続的なコントリビューションやアクセスを目的としていません。
  6. プライマリ・リージョンに障害が発生した場合、システムが期待したとおりに動作することをテストします:
    1. プライマリ・インスタンスを無効にします。
    2. WAFオリジンを切り替えます。トラフィックがバックアップ・インスタンスに転送されるようにWAFポリシーを更新することにより、これを行います。
    3. WAFポリシーの変更が伝播されたら、すべてのユーザー・エクスペリエンスがバックアップ・インスタンス上で期待どおりに動作することを確認します。
  7. プライマリ・インスタンスを再度有効にし、プライマリ・インスタンスを再度指すようにWAFポリシーを更新して、プライマリ・インスタンスがコンテンツ管理およびエンド・ユーザーへの配信の元の役割を引き継いだときに期待どおりに動作することを確認します。

Webアプリケーション・ファイアウォールの構成

Webアプリケーション・ファイアウォール(WAF)を構成および有効化してバックアップ・リージョンを実装するには、いくつかのステップがあります:

  1. WAFポリシーの作成
  2. SSL証明書およびキーのアップロード
  3. セカンダリ・オリジンの作成
  4. 変更の公開
  5. DNS構成の更新
  6. インスタンスでのWAFの構成

プライマリからセカンダリ・インスタンスへの切替えが必要な場合、これを行うには、WAFポリシーを更新します。

WAFポリシーの作成

WAFポリシーを構成するには、次のステップを実行します。

  1. クラウド・アカウント管理者としてOracle Cloudにサインインします。アカウント名とログイン情報は、ようこそ電子メールに記載されています。
  2. Infrastructureコンソールで、左上のナビゲーション・メニュー・アイコンをクリックしてナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックし、「Webアプリケーション・ファイアウォール」で、「ポリシー」をクリックします。
  3. WAFポリシーを作成するコンパートメントを選択します。
  4. WAFポリシーの作成をクリックします。
  5. 次の詳細を入力してWAFポリシーを作成します。
    • 名前: ポリシーの一意名(cross_site_WAFなど)を指定します。機密情報を入力しないでください。
    • プライマリ・ドメイン: アプリケーションの完全修飾ドメイン名(oce.example.comなど)を入力します。これは、ユーザーがアプリケーションへのアクセスに使用するURLで、プライマリまたはセカンダリOracle Content Managementインスタンスのいずれかを指します。
    • 追加のドメイン: オプションで、ポリシーが適用されるサブドメインを入力します。
    • オリジン名: プライマリ・オリジンの一意名( primary_salesdocuments1など)を指定します。
    • URI: プライマリ・インスタンスの公開エンドポイント(URI) (salesdocuments1-myaccount.cec.ocp.oraclecloud.comなど)を入力します。
  6. WAFポリシーの作成をクリックします。

SSL証明書およびキーのアップロード

SSL証明書およびキーをアップロードするには、次のステップを実行します:

  1. 作成したWAFポリシーの表示中に、左側で「設定」をクリックします。
  2. 「一般設定」タブで、「編集」をクリックします。
  3. 「設定の編集」ダイアログで次を実行します。
    1. 「HTTPSサポートの有効化」を選択すると、ブラウザとWebアプリケーション間の通信が暗号化されます。
    2. 「証明書と秘密キーのアップロードまたは貼付け」を選択します。
    3. 「証明書ソースのアップロード」で、ファイルをドラッグ・アンド・ドロップまたは選択するか、「テキスト」を選択してPEM形式の有効なSSL証明書に貼り付けます。中間証明書も含める必要があります(プライマリ・ドメイン証明書を最初にする必要があります)。
    4. 「秘密キー・ソースのアップロード」で、ファイルをドラッグ・アンド・ドロップまたは選択するか、「テキスト」を選択して、このフィールドのPEM形式の有効な秘密キーに貼り付けます。秘密キーはパスワードで保護できません。
    5. 自己署名証明書を使用している場合、「自己署名証明書」を選択してブラウザでSSL警告を表示します。
    6. 自動的にすべてのHTTPトラフィックをHTTPSにリダイレクトする場合、「HTTPからHTTPSへのリダイレクト」を選択します。
    7. 「変更の保存」をクリックします。この更新は、非公開の変更の下に表示されます。

セカンダリ・オリジンの作成

セカンダリ・オリジンを作成するには、次のステップを実行します。

  1. 「オリジン・グループ」タブをクリックします。
  2. 「オリジン・グループ」タブで、「編集」をクリックします。
  3. 「追加オリジン」をクリックします。
  4. 次の詳細を入力します。
    • 名前: セカンダリ・オリジンの一意名(secondary_salesdocuments1など)を指定します。
    • URI: セカンダリ・インスタンスの公開エンドポイント(URI) (salesdocuments2-myaccount.cec.ocp.oraclecloud.comなど)を入力します。
    • HTTPポート: セカンダリ・インスタンスがリスニングするHTTPポートを入力します。デフォルト・ポートは80です。
    • HTTPSポート: セカンダリ・インスタンスへのセキュアなHTTP接続に使用されるポートを入力します。デフォルト・ポートは443です。
  5. 「変更の保存」をクリックして、セカンダリ・オリジンを作成します。この更新は、非公開の変更の下に表示されます。

変更の公開

行った変更を公開するには、次のステップを実行します。

  1. 左側で、非公開の変更をクリックします。
  2. 「すべて公開」をクリックします。
  3. 「変更の公開」ダイアログで、「すべて公開」をクリックします。

    更新の完了にしばらく時間がかかる場合があります。

DNS構成の更新

ゾーンのCNAMEでDNS構成を更新してインターネット・クライアントからWAFにリクエストをルーティングします。作成したWAFポリシーを開いて、CNAMEを見つけることができます。CNAME値は、ハイフンで連結されたOCIドメイン内のプライマリ・ドメインのバージョン(oce-example-com.o.waas.oci.oraclecloud.netなど)です。

サブドメインcec.ocp.oraclecloud.comを使用している場合、Oracle SupportにDNSの更新を依頼するサポート・リクエストを記録する必要があります。

インスタンスでのWAFの構成

インスタンスでWAFを構成するには、次のステップを実行します。

  1. Infrastructureコンソールで、左上のナビゲーション・メニュー・アイコンをクリックしてナビゲーション・メニューを開き、「開発者サービス」、「コンテンツ管理」の順にクリックします。
  2. プライマリ・インスタンスをクリックしてインスタンス詳細を表示します。
  3. WAFの構成をクリックします。
  4. Webアプリケーション・ファイアウォールの構成ダイアログで、すでに作成したWAFポリシーを選択します。

    インスタンスのコンパートメント名が表示されます。WAFポリシーが別のコンパートメントにある場合、コンパートメントの変更をクリックして、適切なコンパートメントを選択します。

  5. 「変更の保存」をクリックします。

    更新がインスタンスに行われると、「アクティビティ」リストに進行状況が表示されます。更新の完了後、インスタンスの詳細を確認すると、WAFプライマリ・ドメインがリストされます。

  6. セカンダリ・インスタンスに対してステップ2から5を繰り返します。

WAFオリジンの切替え

テスト目的またはバックアップ目的でプライマリ・インスタンスからセカンダリ・インスタンスに(またはその逆)WAFオリジンを変更する必要がある場合、WAFポリシーを更新して、これを実行します。

Oracle Content Management

WAFオリジンを切り替えるには、次のステップを実行します。

  1. クラウド・アカウント管理者としてOracle Cloudにサインインします。アカウント名とログイン情報は、ようこそ電子メールに記載されています。
  2. Infrastructureコンソールで、左上のナビゲーション・メニュー・アイコンをクリックしてナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックし、「Webアプリケーション・ファイアウォール」で、「ポリシー」をクリックします。
  3. インスタンスに対して作成したWAFポリシーを開いてから、左側で「設定」をクリックします。
  4. 「オリジン・グループ」タブをクリックして、「編集」をクリックします。
  5. デフォルト・オリジンとして切り替えるオリジンを設定して、「変更の保存」をクリックします。この更新は、非公開の変更の下に表示されます。
  6. 左側で、非公開の変更をクリックします。
  7. 「すべて公開」をクリックします。
  8. 「変更の公開」ダイアログで、「すべて公開」をクリックします。

    更新の完了にしばらく時間がかかる場合があります。完了すると、選択したオリジンにアプリケーションへのトラフィックが転送されます。

WAFを介したリダイレクトは、障害発生時のパブリック・サイト配信のテストまたは継続のみを目的としていることに留意してください。ユーザーは、認証済サイトまたはOracle Content Managementユーザー・インタフェースに直接アクセスする必要があります。

テストから本番(T2P)デプロイメントの設定

これは、可用性の高い環境の効率的な運用や、アプリケーションがテストからステージング、本番へと移行する際のシームレスな管理に必要なチェックやバランスの提供に欠かせないモデルです。

このデプロイメントでは、専用のインスタンスを作成して、開発、テストおよび本番の分離を維持ます。

  1. 次の設定で、3つのOracle Content Managementインスタンスを作成します:
    • 開発—インスタンス・タイプ: 非プライマリ、アップグレード・スケジュール: 即時アップグレード
    • テスト—インスタンス・タイプ: 非プライマリ、アップグレード・スケジュール: 即時アップグレード
    • 本番—インスタンス・タイプ: プライマリ、アップグレード・スケジュール: 遅延アップグレード

    開発インスタンスとテスト・インスタンスを非プライマリに設定すると、これらのインスタンスのすべてのアセットに対して二重に請求されなくなります。

    開発インスタンスとテスト・インスタンスを即時アップグレード(Oracle Content Managementの新規リリースが使用可能になるとすぐ)に設定すると、これらのインスタンスでアップグレードをテストし、アップグレードがデプロイしたサイトに影響を及ぼさないことを確認できます。問題がある場合、遅延アップグレードを本番インスタンスに1リリース後に適用する前に、Oracleサポートに連絡して問題を解決できます。

  2. 開発インスタンスでリポジトリ、チャネル、ローカリゼーション・ポリシー、サイトおよびアセットを作成します。
  3. リポジトリ、チャネルおよびローカリゼーション・ポリシーを、テスト・インスタンスと本番インスタンスに複製します。
  4. まだ行なっていない場合は、VMコンピュート・インスタンスを作成します
  5. VMコンピュート・インスタンスにOCEツールキットをインストールし、それでIDCS認証を使用します。
  6. Oracle Content Managementのソース・インスタンスとターゲット・インスタンスを登録します。
  7. ソース・インスタンスからターゲット・インスタンスに、サイトとそのアセットを転送します。
  8. データが正しくレプリケートされていることをテストします。各オブジェクト・タイプへの変更を含め、ソース・インスタンスにいくつかの変更(5件未満)を行い、それらの変更がターゲット・インスタンスに正しく反映されていることを確認します。
  9. セカンダリ・インスタンスへのアクセスが必要になる可能性のあるユーザーを同期します。たとえば、少なくとも管理者と開発者は同期する必要があります。

OCEツールキットの詳細は、Building Sites with Oracle Content ManagementのOCEツールキットによるテストから本番への変更の伝播に関する項を参照してください。

VMコンピュート・インスタンスへのOCEツールキットのインストール

テストから本番(T2P)デプロイメントを作成するには、VMコンピュート・インスタンスにOCEツールキットをインストールし、そのツールキットでIDCS認証を使用する必要があります。

VMコンピュート・インスタンスで次のステップを実行します:

  1. OPCユーザーとしてサインインします。
  2. NodeJSを設定します:
    1. NodeJSをrootとしてインストールします: 
      sudo -s
cd /usr/local
wget https://nodejs.org/dist/v12.16.2/node-v12.16.2-linux-x64.tar.xz
tar xf node-v12.16.2-linux-x64.tar.xz
exit
    2. opcユーザーとしてNodeJSをPATHに追加し、プロファイルをリロードします: 
      vi ~/.bash_profile
--- add :/usr/local/node-v12.16.2-linux-x64/bin to the PATH -- e.g:
PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/node-v12.16.2-linux-x64/bin
source ~/.bash_profile
    3. NPMとNodeJSをテストします: 
      [opc@ocivm2pm ~]$ npm --version
6.14.4
[opc@ocivm2pm ~]$ node --version
v12.16.2
  3. OCEツールキットを設定します:
    1. OCEツールキットではIDCSアプリケーション経由の接続がサポートされているため、認証用にChromiumをポップ・アップさせる必要がありません。このダウンロードをスキップするようにフラグを設定します: 
      export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
    2. opcユーザーとしてツールキットをインストールします: 
      wget https://github.com/oracle/content-and-experience-toolkit/archive/master.zip
unzip master.zip
rm master.zip
cd content-and-experience-toolkit-master/sites/
npm install
    3. インストールをテストします: 
      [opc@ocivm2pm sites]$ ./node_modules/.bin/cec --version
20.4.1
    4. rootとしてcecバイナリにソフト・リンクを追加します: 
      sudo -s
ln -s /home/opc/content-and-experience-toolkit-master/sites/node_modules/.bin/cec /usr/local/bin/cec
exit
    5. opcユーザーとして、任意の場所からcecを実行できることをテストします: 
      cd
[opc@ocivm2pm ~]$ cec --version
20.4.1
    6. cecソース・フォルダを設定し、フォルダにcecをインストールします。これにより、package.jsonを含むソース・ツリーが作成され、npmインストールが実行されて、ソース・ツリーに依存関係がフェッチされます。 
      cd
mkdir cec
cd cec
cec install
  4. IDCSアプリケーション・ページの指示に従い、IDCSを構成して、インスタンスを登録します。

ソース・サーバーおよびターゲット・サーバーの登録

次のコマンドを使用して、ソース・インスタンスおよびターゲット・インスタンスの接続の詳細を登録します。たとえば、テストから本番デプロイメントのコンテンツを同期する場合に、開発(DEV)とステージング(TEST)、本番(PROD)の各インスタンスがあるとします。

cec register-server DEV -e http://server:port -u username -p password
cec register-server TEST -e http://server:port -u username -p password
cec register-server PROD -e http://server:port -u username -p password
  • 最初の値(DEV、TEST、PRODなど)は、インスタンスのエンドポイントの識別に使用するサーバー名です。これは、ユーザーが選択した任意の名前にできます。
  • 値-eは、インスタンスへのアクセスに使用するURLを構成するサーバーとポートです。
  • 値-uは、ユーザー名です。これは、ソース・インスタンスのサイトやアセットにアクセスできるユーザーか、ターゲット・インスタンスのサイトやアセットを所有する予定のユーザーにする必要があります。
  • 値-pは、ユーザーのパスワードです。

注:

--keyfileを渡すと、ファイルに保存されているパスワードを暗号化できます。

エンタープライズ・サイトの転送

次のコマンドを使用して、エンタープライズ・サイトを転送します:

cec transfer-site SiteName -s DEV -d TEST -r RepositoryName -l LocalizationPolicyName
  • 最初の値(SiteName)は、転送するサイトの名前です。
  • 値-sは、前のステップで登録したソース・インスタンスの名前です。
  • 値-dは、前のステップで登録したターゲット・インスタンスの名前です。
  • 値-rは、サイトの転送先のターゲット・インスタンスにあるリポジトリです。これは、ターゲット・インスタンスに新しいエンタープライズ・サイトを転送する場合にのみ必要です。
  • 値-lは、転送されるサイトに適用するターゲット・インスタンスのローカリゼーション・ポリシーです。これは、ターゲット・インスタンスに新しいエンタープライズ・サイトを転送する場合にのみ必要です。

ターゲット・インスタンスのサイトを更新する場合は、リポジトリとローカリゼーション・ポリシーを含める必要はありません。

詳細は、Building Sites with Oracle Content ManagementのOCEツールキットによるテストから本番への変更の伝播を参照してください。